[ajs]

My dream feature for MZX 3.0 would be: a complete unit test suite for MZX, with robot scripts exploiting every nuance of robotic, every command and (within reason) every parameter. I'll write the test harness if somebody else writes the tests and expected outcomes.

It might not be as flashy as some of the other suggestions, but that would make re-writing MZX a lot easier!

--ajs.

[Kom]

I'd like the ability to 'attach' a sprite to a robot and make it so that when a position in the sprite is sent to a label, the attached robot will be sent to that label.

EDIT: Also, being able to name a new counter and set it in the debug screen woul really be nice. Maybe even the ability to look at local counters, too.

This post has been edited by Kom: 12 December 2007 - 12:28 PM

[Wervyn]

Quote

I'd like the ability to 'attach' a sprite to a robot and make it so that when a position in the sprite is sent to a label, the attached robot will be sent to that label.

Read. The. Tutorial. Seriously, you can do this, it's not hard.

"Why'd I bother writing all that if no one's going to read it."

[Kom]

that tutorial is only for sprite collisions with other sprites and the like, not for what i'm talking about.

[Micah]

Kom, on Dec 27 2007, 07:16 PM, said:

that tutorial is only for sprite collisions with other sprites and the like, not for what i'm talking about.

Then what ARE you talking about?

It's seriously not that hard to do that manually.

[CJA]

it's not hard to edit a 3x2 box of characters manually, either

[Kom]

What I'm talking about is having a robot that would send robots at certain positions to a "playershot" label, using the send X Y "label" command, just like some sword robot that uses the overlay. If I were to have a large boss that was, let's say, a 5x3 sprite, and i were to have the player hit somewhere in the sprite with the sword, which is just an overlay, not another sprite, how do I get the robot controlling the sprite to be sent to the "playershot" label, since the robot can only take up one space, and my sword robot has no way of sending a sprite to a label with the send X Y "label" command?. Hehe, run on sentences.

[Revvy]

Make the sword a sprite.

[asiekierka]

Removing the SMZX's 4x14 character limitation.

2 ways to do this:

#1. Use 2 chars per character, so you have 128 chars total.
Advantage: No need to change any format
Disadvantage: 128 chars aren't enough for anybody.
#2. Make every character 16x14, but show just the first 8x14 in normal MZX, and use the other 8x14 in SMZX to make it 4color/char and still 8x14 by storing 1/2 of SMZX data in one of 8x14, and the other 1/2 in the other one. Hard to explain, ya know?
Advantages:
- 256 chars availble, could be changed to 512 chars in MZX and 256 in SMZX, but who needs that many?
- Possible to make a world both MZX and SMZX at once by checking if the other 8x14 of a char is empty.
Disadvantage: Need to change formats.

[Kom]

Revvy, on Dec 28 2007, 06:33 PM, said:

Make the sword a sprite.

i guess that would be the better thing to do, but then what about guns that shoot instantly, or the weapons that do damage with particle effects... what happens then?

[Padz]

how about a 'rel player always' ect command

would save a lot of cmd lines in engines

[Terryn]

We have the "playerx", "playery", "thisx" and "thisy" counters, so that's not needed.

[GetDizzy]

(To illustrate terryn's point)

The functionality of "rel player" and then "thisx" or "thisy" can be condensed into
"('playerx'-'thisx')" and "('playery'-'thisy')" or maybe the reverse of that, I forget which it uses.
The function of rel player in general, in terms of x and y can be condensed into
"('playerx'+x)" and "('playery'+y)"

Expressions are your friend.

In fact, because of expressions, the "rel" commands are almost entirely useless.

[Padz]

hmmm well my coding ability is limited to simpler stuff lol but i think i see what your getting at. i'll prob stick to my rels

old dog cant learn new tricks

[Koji]

sure you can, is simple math. if you want to rel player, just use the same coordinates and add them to playerx and playery or if you want to rel self use thisx and thisy in a similar matter.

Now you can even rel other robots if you acquire their Robot id's and use the counter mechanism for obtaining local counter information from a specific Robot id something that was up till mzxak completely not doable (however mzxak's approach was terrible and was scrapped in favor of the one we have now) but all that is beyond what you're probably wanting to do.

[nooodl]

Comments really shouldn't be in strings, it's really annoying. For example, you have this line here:

send "dragon" to "go"

and you want to skip that part for testing, and you comment it, it becomes this:

. "send \"dragon\" to \"go\""

Now you want to uncomment it, you have to delete all the quotation marks and backslashes which is too annoying when working with strings. What comments should be like is this:

. send "dragon" to "go"

or even this:

. <spaces spaces spaces> send "dragon" to "go"

and they should have a different built-in color.

This post has been edited by nooodl: 15 January 2008 - 07:11 AM

[Terryn]

You can immediately uncomment a commented line by pressing Ctrl+C. Cleans right up, including those character codes.

[CJA]

Having a different built-in color for comments is an excellent idea, though, but probably wouldn't be implemented. I don't know about MZX's syntax coloring mechanism, but from any decent algorithm I can imagine, changing the color of just strings in comments would be hack-y.

[Koji]

Instead of these silly folk trying to parse out file names of required files for their game, could we just include in the source a mechanism that writes to a log all the unaccounted for files and other such bug messages durring test mode gameplay?

[Terryn]

That would require the tester/author to not only play through the game, but play through every little branch of it and reach every little aspect of it. Who would do that? MZXers usually don't do that before they release anyway, for chrissakes.

checkres works just fine, thanks, and it doesn't take several hours to get the whole picture.

[Exophase]

Koji, on Jan 15 2008, 11:12 AM, said:

Instead of these silly folk trying to parse out file names of required files for their game, could we just include in the source a mechanism that writes to a log all the unaccounted for files and other such bug messages durring test mode gameplay?

lalala im koji and i refuse to listen to better ideas than mine lalala

[nooodl]

Terryn, on Jan 15 2008, 12:07 PM, said:

You can immediately uncomment a commented line by pressing Ctrl+C. Cleans right up, including those character codes.

Thanks for the info!

Hey, it's not a new feature, but maybe send "all" should be replaced with a special parameter thing send ALL, so that you can have a robot named "all".

[Exophase]

nooodl, on Jan 16 2008, 03:04 AM, said:

Terryn, on Jan 15 2008, 12:07 PM, said:

You can immediately uncomment a commented line by pressing Ctrl+C. Cleans right up, including those character codes.

Thanks for the info!

Hey, it's not a new feature, but maybe send "all" should be replaced with a special parameter thing send ALL, so that you can have a robot named "all".

This is actually not a bad idea at all, for some somewhat subtle reasons (I think the one you mentioned isn't really the most pressing) but with only so many commands left there's kind of a precedent to not waste them. Personally I'm for starting a major restructuring of how MZX works, but that's hard work. I think there are about 5 or more major projects I want to work on, it'd be great if I had the drive and time management to really get anywhere on any of them. Ahwell

(I guess it could be done w/o adding a new command, like by encoding send 0 "label", but then you have to deal with compatibility transition, much better to start worrying about that stuff after the bytecode/language interdependence is done away with)

[asiekierka]

An option to half the horizontal resolution of the window while in SMZX mode. (you can even do this with config.txt (only tried mzx281f_lol though), but i wanted it to happen just with SMZX modes.)

This post has been edited by asiekierka: 06 February 2008 - 03:36 PM

[nooodl]

asiekierka, on Feb 6 2008, 04:35 PM, said:

An option to half the horizontal resolution of the window while in SMZX mode. (you can even do this with config.txt (only tried mzx281f_lol though), but i wanted it to happen just with SMZX modes.)

Well, it's already an option then, is it?

[paulguy]

window it, grab the right hand side of the window then pull it. if you want full screen then just repeat this step until it fills your screen.

[Spectere]

paulguy, on Feb 7 2008, 05:22 PM, said:

window it, grab the right hand side of the window then pull it.

Not when you're using software rendering...

[Koji]

Asikierkas idea of combining two characters to get one char in smzx mode is not an old idea, however I still agree with it.

Using 2 characters to make one SMZX char (each of the two chars accounting for a 4x14 half of the end resulting Smzx character) would be most benificial, and completely doable now since smzx mode is not video card hack dependant. The only headache might be adjusting the format to accomodate the extra 256 characters. for the first incarnation of such a version of mzx, the later 256 characters would do nothing in normal mzx, you couldn't even access them, however in SMZX mode they are used to augment the normal character set.

Since the character set right now is just a collection of bytes, and a character file is similarly so, the only difference in an SMZX charset and a standard one is that the SMZX charset it twice as long to fill out the 512 characters.

Some games may depend on the partial char load roll over that if you load a partial charset near the end of the character set and it's too long the extra characters will be written to the first characters of the characterset, so to maintain backwards compatability the character set could be treated as though it's only 256 characters unless SMZX mode it on and then it would be treated as 512.

I think this is totally within the realm of possibilities.

This post has been edited by Koji: 08 February 2008 - 04:52 PM

[Spectere]

It's definitely possible. Hell, making a full graphics mode for MegaZeux is technically possible.

The real issue, I think, would be the number of hacks that would have to be implemented. With the SMZX thing, you'd have to think of a way to load that extra 256 characters. The world format doesn't support it so it would have to be loaded at runtime.

I doubt they'd waste a command for it, so it would likely be implemented using a dirty hack (a counter hack, a "load char set" hack, or something along those lines. It'd wind up being yet another exception to the rule that would have to be carried over if Exo's vision of MZX3 ever becomes a reality.

It would be nice and would certainly make SMZX mode a lot more useful, but I just can't see how it could be implemented in a clean manner without changing the world format.

[Koji]

Eh, the only alterations might be to the save file to accomodate a 512 charset rather than a 256 one, which wouldn't be too much trouble, and the load charset command would only need to not roll over at char 256 when loading a charset while in smzx mode which is probably the least intrusive "hack" ever. I don't see how this couldn't be thrown into the next version. In relation to other additions like sprites and expressions this is a very tiny addition that would add lots to mzx graphical capabilities.

Also another aspect of this new mode should be that the color value doesn't refer to come hard coded algorithm defined pallet, but rather one of 256 programmer defined palettes

set "palette#_0" to "color0"
set "palette#_1" to "color1"
set "palette#_2" to "color2"
set "palette#_3" to "color3"

# would be 0-255 (denoting each of the 256 palettes chosen by the color of the block and each "color#" counter is just a stand it for any reference to one of the 256 colors on the SMZX palette.

NOW THAT would be a hack, but also a very good one.

This post has been edited by Koji: 09 February 2008 - 10:53 PM