[LogiCow]

About Opengl2:

Linear interpolation could set the viewpoint to the largest multiple of 640, 350 instead of just setting it to 640, 350. That way it would look much sharper on resolutions of 1280, 700 and above.

Problem is, it would require a 2048x1024 render to texture, which is slow on low-end video cards.

[Xx*SaturnineMatthias*xX]

Exophase, on Jul 1 2007, 08:11 PM, said:

djtiesto, on Jul 1 2007, 02:07 PM, said:

Also some questions for things that may or may not be in MZX (but should be if they aren't )

-Is there a way to prevent the LOAD menu from opening up if you hit F4? Like how you can disable f2_menu or enter_menu ...

-Is there a way to prevent you from hitting ESC to open the quit playing dialogue box... and on top of that is there a way to have it go back to the games title screen via Robotic?

Thanks.

Why do you want to go through such lengths, to convince the player that he/she isn't using MZX? I don't know about adding the first one, but disabling escape will never be done because it's malicious.

Personalisation.

Also, yeah, I also disagree with the ESC customisation, unless you throw in a three-button key combination that instantly halts MZX or something

[RoSS]

NihilistMatt, on Jul 1 2007, 03:56 PM, said:

Also, yeah, I also disagree with the ESC customisation, unless you throw in a three-button key combination that instantly halts MZX or something

Like Ctrl+Alt+Del? =)

[Frobozz]

logicow said:

Problem is, it would require a 2048x1024 render to texture, which is slow on low-end video cards.

Oh is that all? If I'm not mistaken, my card can only do 2048 by 2048 and it isn't exactly low-end.

[Lachesis]

keypressed and keycode don't appear in the F11 menu... I don't know if this is a bug or if it's supposed to do that, but I think it would be more conveinient if they were displayed in the menu.

This post has been edited by Kuroneko: 05 July 2007 - 05:48 PM

[Terryn]

As it is now, they'd just have the value of the F11 key there. =D

[Dr Lancer-X]

... no, there's no reason to have MZX doing that. What on earth could you possibly want the functionality for?

[Micah]

How about an UNDO function?

[Exophase]

Micah, on Jul 17 2007, 05:06 PM, said:

How about an UNDO function?

Asked for three times already, how about reading the thread...

[Dr Lancer-X]

Feature request: perl regexps!

if "$string" = "/PATTERN/" "do_something"

set "$string" "s/PATTERN/REPLACE/g"

set "$string" "qr/PATTERN/"
set "$string2" "s/$string/REPLACE/"

[Val]

I request a counter that you can set to 1 to make message row messages not disappear after 160 cycles. It's really annoying doing dialog in speed 2 with the messages constantly disappearing before you can finish reading them.

EDIT: or, as asgromo suggested, it could be 0 for never disappearing, and >0 for that many cycles until it disappears. I would really, really like this added to mzx, seriously.

This post has been edited by Guy: 05 August 2007 - 01:07 AM

[CJA]

I as well

[Micah]

Guy, on Aug 4 2007, 06:59 PM, said:

I request a counter that you can set to 1 to make message row messages not disappear after 160 cycles. It's really annoying doing dialog in speed 2 with the messages constantly disappearing before you can finish reading them.

EDIT: or, as asgromo suggested, it could be 0 for never disappearing, and >0 for that many cycles until it disappears. I would really, really like this added to mzx, seriously.

: "main"
set "$string0" "Message 1"
goto "#message"
set "$string0" "Message 2"
goto "#message"
set "$string0" "Message 3"
goto "#message"
* ""
end

: "#message"
* "&$string0&"
wait 1
if not spacepressed "#message"
goto #return

If you were really feeling frosty you could have it read from a text file.

[Exophase]

I'm going to go with micah's response if only because having a fixed display period is lame, it's either going to be too long or too short for everyone. No one likes being cut off while they're reading something, and no one likes waiting around when they're done.

BTW micah, you do realize that you haven't had to name strings things like "$string0" since MZX 2.80, right? Also, use clear mesg, not * "", you won't get a border that way. Oh, and going to the subroutine over and over again isn't going to work.

[Lachesis]

My engine like that is in the global robot and can have multiple options, and... works like a charm! And it's really simple to code, too, like Micah has shown.

[Koji]

: "#ROUTINE"
: "LOOP"
if "wanttoloop" = 1 "LOOP"
goto "#return"

THIS IS HOW YOU DO IT.

[Exophase]

Koji, on Aug 6 2007, 10:03 AM, said:

: "#ROUTINE"
: "LOOP"
if "wanttoloop" = 1 "LOOP"
goto "#return"

THIS IS HOW YOU DO IT.

No, you put a wait one before looping.

[Dr Lancer-X]

lolz koji busylooped

[djtiesto]

Were multiple global robots requested earlier, or is there a newfangled way that I don't know about to do something like this?

[Dr Lancer-X]

yes, the trick is to carefully multithread your global robot to do everything at once.

come on, put your programming skill to the test!

[Elig]

Here are some things that I think would be nice to add to MZX:

1: Zoom, it'd be really, really nice for per pixel games and cinema, and wouldnt be terribly hard to code, though it might heavily go against the nature of MZX, really.

2: Per pixel camera offset. Obviously this is the single most useful feature that I can think everyone can easily agree should be implemented. Unfortunately, I looked at the MZX source to see if I could do such a thing myself, and realized just how hard coded the 80x25 view port is, and have decided this would require entirely too massive of an overhaul to be worth it.

3: Alterable grids in the editor. I've suggested this a lot before, and it's been shot down every time, though I still think it'd be an awesome feature.

4: Actually decent loop support of some form. Why not, after all, sub routines are already in MZX, isnt it about time we hacked in some form of DECENT recursion? Surely we can all agree that attempting to loop in MZX is an absolute nightmare.

5: Per pixel sprite locations. Perhaps far, far easier to implement than per pixel camera offset, this would bring per pixel capability to the masses, and stop everyone from complaining about how difficult it is to do per pixel things. Plus, this would allow everyone to easily do Logicow style games, hence making his productions seem far less Demo-ish, and making all the smaller members of the community feel much less left out, etc. etc. Ofcourse, this would be a massive break with MZX design, and so perhaps it shouldn't be done. However, since so many seem so intent to design per pixel games, it would seem the demand is there to implement such a feature.

[Frobozz]

Most of what you suggest is extremely difficult due to how MegaZeux is coded. It just isn't designed to work past text mode stuff. Anything else is going to be more of a hack than a real implementation due to the effort it would involve.

Looping on the other hand probably wouldn't take much work. But good luck convincing anyone to add it. Nobody seems to want to modify the base commands of Robotic until version 3.0 (thus why counters are still used for crap). I suspect they're all hoping someone will volunteer to redo most, if not all, of the source.

This post has been edited by Frobozz: 07 August 2007 - 03:57 AM

[hob nado]

Replace Robotic with Lua =D

[asiekierka]

OR!
Add lua, preserve Robotic.
Add all functionalities to Lua and ignore Robotic.

[Elig]

Frobozz, on Aug 7 2007, 03:56 AM, said:

Most of what you suggest is extremely difficult due to how MegaZeux is coded. It just isn't designed to work past text mode stuff. Anything else is going to be more of a hack than a real implementation due to the effort it would involve.

Looping on the other hand probably wouldn't take much work. But good luck convincing anyone to add it. Nobody seems to want to modify the base commands of Robotic until version 3.0 (thus why counters are still used for crap). I suspect they're all hoping someone will volunteer to redo most, if not all, of the source.

I think the irony if this statement is that I probably know better than you about how MZX is or isnt coded But, maybe you've just spent hours upon hours staring at MZX's code that I am unaware of.

The grid idea is entirely easy to code without practically any major change to MZX's source, and with preserving the look and feel of MZX. But noone ever wants grids in MZX, for some reason that is utterly beyond me. Personally I think it's crazy that noone wants grids, they're in every single paint or photo editing program on the internet for christ sake.

Per pixel sprites are actually a lot easier to properly implement than you think, since sprites themselves are rather seperate from all the other rendering and likewise code. In terms of the per pixel camera movement, that is indeed very, very hard to implement. In terms of zooming, this is probably the easiest suggestion of all to implement, as you could simply render a smaller view area and software zoom in SDL. All the things that I've suggested aside from the per pixel camera movement are actually fairly easy to implement (With per pixel sprites requiring the most work, but still not THAT much).

This post has been edited by Elig: 07 August 2007 - 10:15 AM

[Frobozz]

Well if they're so easy to implement go ahead and try. Last time I briefly glanced over the code was a couple versions ago. Regardless I seem to recall it looking a bit hard to accomplish that effect. But if you know better, then by all means - go ahead and try it.

esdemo1 said:

Replace Robotic with Lua =D

Funny but I jokingly suggested that once on IRC. It was quickly shot down by virtually everyone - except Asie who, of course, liked the idea.

This post has been edited by Frobozz: 07 August 2007 - 02:00 PM

[Koji]

in my defence, I never set "commands" to anything so busy looping in that case is fine, so long as nothing sets commands

Elig, I agree with you on every point of your post except one, per pixel scrolling. The idea would be redundant if you have per pixel sprites, as you could easily make a sprite for the scrolling background, and move is by pixels.

Pixel perfect sprites are totally doable, especially since sprites are an afterthought rendering between or on top of the physical and overlay layers. Also mzx may LOOK text based, but it isn't, it's been completely graphical for a while now. It isn't completely out of the question to ask for sprite scaling or even rotation, reflecting etc. Really, the only thing that might break are some collision detection configuration, but that can be retooled.

Alot of these things have already been done, just not incorporated into the existing sprite construct, that's all that needs to be done in order to mainstream it. And if it was mainstreamed then theres no reason to keep it out. Especially if it works and increases the rate at which games are released.

This post has been edited by Koji: 07 August 2007 - 02:55 PM

[ajs]

As stated multiple times before, there would have to be:

a) A community consensus for adding such a feature

b) A "clean" implementation with a committed maintainer

I'm certainly not interested in implementing non-MZXish features. I'll trivially extend existing functionality but I won't risk de-stabilizing MZX for glitz. World file changes are possible, but only if absolutely necessary.

--ajs.

[Exophase]

koji said:

in my defence, I never set "commands" to anything so busy looping in that case is fine, so long as nothing sets commands

You mean with all your fancy engines you never set commands to anything? And here you were talking about these pixel engines you did or whatever.

koji said:

Elig, I agree with you on every point of your post except one, per pixel scrolling. The idea would be redundant if you have per pixel sprites, as you could easily make a sprite for the scrolling background, and move is by pixels.

Nope. He said pixel based sprite locations, not pixel based sprite references. Two totally different things.

koji said:

Pixel perfect sprites are totally doable, especially since sprites are an afterthought rendering between or on top of the physical and overlay layers. Also mzx may LOOK text based, but it isn't, it's been completely graphical for a while now. It isn't completely out of the question to ask for sprite scaling or even rotation, reflecting etc. Really, the only thing that might break are some collision detection configuration, but that can be retooled.

Alot of these things have already been done, just not incorporated into the existing sprite construct, that's all that needs to be done in order to mainstream it. And if it was mainstreamed then theres no reason to keep it out. Especially if it works and increases the rate at which games are released.

Nope. Sprites are rendered to the the text screen, so as far as the implementation is aware it's 100% text mode. The only thing that isn't in text mode is a rendering of the entire screen. And you're all dead wrong about pixel scrolling being significantly less work than per-pixel sprites because to render sprites at a pixel layer you need to start rendering separate layers at a graphical level and not just a text level. End result: up the minimum requirements of the rendering engine by like 3x and completely rewrite every renderer (and factor out a bunch of other code from places outside of graphics.c). Per-pixel scroll offsets are easier because while you have to alter the renderers, you just have to add edge code to do partial chars at the boundaries and extend the viewports a little. This is assuming the scrolling affects the entire screen, but that's how it has always been anyway, except for static overlays. For static overlay you're back to the same problem as with sprites, but at least you don't have to z-sort the sprites before you can render them. Unless you have static sprites. I'm going to ASSUME that it was acceptable to not allow static anything with this because that's far from used in everything all the time.

Then with per-pixel sprites people will probably want transparency, since it'd be "so natural due to the implementation." Then they'll want different dimensions for chars. Then they'll want actual colors. By this point all the purists will be throwing a fit for the ruining of their MZX, and everyone else will keep demanding more features. Then it'll eventually be renamed to "Gamemaker."

People keep chiming in with the same old story, "it's not text mode anymore!" never realizing that that wasn't the real limitation in the first place. Emulating text mode is relatively easy (hence why we have like 300 renderers now). Building a new GCS around it isn't, and unless you start thinking really big from the start it's going to be a bunch of hacks on top of hacks. Same goes with crap like adding grids inside the editor - why won't it be done? Because the editor lives inside a text mode environment (except with really easy additions like banked charsets and palettes that were trivial to craft on top of it) and if you take one step outside of that you throw the entire thing out and have to do one hell of a lot more work for it. For something no one ever really wanted in the first place.

Now ask yourself, how many people in the history of MZX have done a hell of a lot of work in redesigning it? Yeah, that's what I thought. Until you can understand why it won't happen it isn't going to matter how much more you've read the source code than everyone else (lulz im a master of teh source, yeah, then do it yourself).. so maybe you should go (back to) make(ing) vaporware GCSes of your own.

I think the real reason why no one wants to do serious work on MZX is because they know certain people spend more time caring about what MZX lacks than they're willing to actually work at using it. I for one eventually got tired of adding things to MZX at a rate that far outstripped how much people were using anything (it was especially annoying hearing people ask for things that were already in there, but that's another story). I had big plans - plans that were IMO as big as they needed to be, because MZX reached a point where it could no longer take any more hacks (and hence why the core set of things you can do has changed little since 2.80). So it was either that or nothing, and you can see what I picked. If you want a "serious" GCS there are other choices out there, I suggest you get serious yourself and leave MZX alone because all of these little graphical features aren't going to cause people to make stellar new games. It's especially jarring hearing that come from Koji.

Oh yeah, and because this comes up a lot. The reason why no one wants to add world file changes (or at least why I didn't want to) is because soon the world loader ends up being a bunch of version switch hacks and it gets harder and harder to keep it together. That's how the save loader was and eventually it started breaking down left and right so I threw out backwards compatibility with save files. I personally was planning a major change to the world file so that it could be more upgrade ready but that never happened and I doubt anyone wants to do that now.

P.S. Grids in MZX, wtf? You mean like, borders around the pixels in the char editor, or around the chars on the board? It could be that no one wants them because your cursor is aligned to what you're drawing and because the things you're drawing are big and obvious, and in the case of the char editor one of two colors. I can't see a possible reason why anyone would want this, why it would help in any way whatsoever, much less enough to be worth completely redoing the way the editor is rendered.

[ajs]

Just for the record, Mr_Alert made a lot of nice cleanups to graphics.c and factored out the renderers already. So they're basically minimal, and most of the code that was just copy/pasted is now shared. So editing that crap pile would be easier.

Also, I think the loaders could be rewritten. It'd be painful, and would introduce bugs, but it's possible. Not that I'm dying to do it, but it is on my list of things to do (mostly for robustness purposes, not for making world file format changes).

All in all, I think it's possible to make these changes, I just see a lot of people saying "they should be made" and nobody actually coding it. And even when people do code it (to a degree, i.e. Logicow) it's mostly for show, with no intention of releasing a mergable solution or fully supporting all the new renderers. As far as I'm concerned, the code would have to be there and working. And it would have to be maintained.

Even now I'm still fixing a huge number of bugs that crept in before and after 2.80, a vast majority of which are a result of new features. Not that I'm trying to apportion blame, just that there's a lot more to MZX development than simply implementing a new feature. You have to test it like crazy. And people just won't do that.

Plus, every time this crap comes up, the same 5-6 people hugely support the initiative, and the rest of the community seems pretty much against it. Even if that's an exaggeration, it isn't a consensus.

Regardless, right now, a lot's changing for me (job, home, summer) and I've not been as committed to MZX maintenance as I'd like to be. But it's pretty much my plan to go through this entire thread with Terryn (and at least discuss it with Exo, if he has the time) to figure out what features are reasonable and unreasonable, sort them by difficulty, and work from the bottom up. I'd probably summarise them on the wiki or something before I started. Also Lancer and Mr_Alert have chipped in for the last couple of releases, so we could make some decent progress. Not Exo speed, but maybe something better than what we've done so far.

So, more coders, please. More people contributing. And how about we start with the easy stuff, and think about mind bending changes later.

--ajs.