[Dr Lancer-X]

Old-Sckool, on 15 September 2010 - 01:44 PM, said:

How about XML support?

die

[Lachesis]

That would be incredibly easy to program yourself

[Dr Lancer-X]

Producing a fully-complaint XML reader with full DTD support and the like would not be trivial to implement at all, but I'd really ask why you'd need something like that in MZX.

[NovaYoshi]

It'd be nice if labels that get jumped to in response to an event could be made into subroutines, for example having a "#touch" that would get called instead of "touch", if found, that you could use "#return" from. It's bothersome to have a big, complicated routine and suddenly be forced out of it, unable to figure out exactly where you were in it.
It'd also help to be able to prevent the routine from being called again while it's already being executed, so things that call every cycle ( like key-repeat on the "key[keycode]" labels wouldn't ONLY run the first line of the handler. ( Or maybe be able to freeze everything else until the routine's done, so I wouldn't have to wait after )

It'd also be handy to have a "#skiplines[N]" I could jump to instead of making a new label to jump to that skips over some code.

Maybe a "wait for variable to be changed" command so I don't have to have a loop constantly wait and waste CPU?

[Dr Lancer-X]

Wahovipab, on 17 September 2010 - 10:16 AM, said:

It'd be nice if labels that get jumped to in response to an event could be made into subroutines, for example having a "#touch" that would get called instead of "touch", if found, that you could use "#return" from. It's bothersome to have a big, complicated routine and suddenly be forced out of it, unable to figure out exactly where you were in it.

I agree that this would be a worthwhile inclusion-- not sure how much, if at all, it would break compatibility of existing games to jump to a #touch or a #shoot if one is available.

Quote

It'd also help to be able to prevent the routine from being called again while it's already being executed, so things that call every cycle ( like key-repeat on the "key[keycode]" labels wouldn't ONLY run the first line of the handler. ( Or maybe be able to freeze everything else until the routine's done, so I wouldn't have to wait after )

I don't quite understand this request.

Quote

It'd also be handy to have a "#skiplines[N]" I could jump to instead of making a new label to jump to that skips over some code.

I think debytecode, if we ever get it, has some provision for labels that are 'local' within a particular block so that you can have a label that doesn't use up label namespace, so you can copy paste code. As for a literal skiplines, well, I don't really like the idea because:
1) it'd break if you changed the number of lines, of course, and
2) it relies on the internal concept of what is a line and what isn't to remain consistent. Blank lines count now, but in the future they'll probably disappear. Other 'lines' in the language may be simplified by turning them into multiple, simpler commands.. alternatively, common groups of commands could be combined together.

Quote

Maybe a "wait for variable to be changed" command so I don't have to have a loop constantly wait and waste CPU?

Hmm, I'm not sure about this one. I mean, I can definitely understand it from the perspective of simplifying code, but you wouldn't be wasting anything noticeable in terms of CPU to just throw in a

: "l"
wait 1
if "var#" != # "l"

I mean, you'd just be doing stuff that MZX would have to do itself anyway; the only difference is that it wouldn't go through the robotic interpreter. I don't think you'd ever achieve worthwhile speed savings from this.

[NovaYoshi]

Lancer-X, on 17 September 2010 - 01:33 AM, said:

I don't quite understand this request.

Something like this:
1. I press a key
2. The label for that specific key gets jumped to
3. I press another key while the routine is still running
4. The second press is ignored because the routine hasn't done #return yet

I like to put system calls in my global robot that do things in the game, and some return a value back to whatever called it. This means I'd have to wait for the return signal to get back, but if another robot were to use the same system call, or another one with the same local variables, while the routine was running, then things would get messed up.

[Dr Lancer-X]

Hmm, yeah, I don't think it's really necessary as it's something that can be replicated with a tiny amount of extra code anyway. zap/restore, lock/unlock, don't use the key labels, use the "key#" counters instead etc.

[Old-Sckool]

Use the key_code or key_pressed counters instead of labels. Use key_code if you want to ignore auto-repeat (like a jump button), key_pressed if you want to use auto-repeat or for "keyboard" engines.

[NovaYoshi]

How about a "send robot to subroutine and wait for it to finish" command? I tried a workaround, but it doesn't work the way I want it to, that being with the first and second of these robots moving at the same speed.

. "To see how fast a robot would go if"
. "it moved each cycle ( for comparison )"
: "loop"
/ "e"
goto "loop"

: "loop"
. "robot is usually busy doing other things"
wait for 4
goto "loop"
: "#activate"
. "this gets called by the timer robot"
. "to make this robot do something"
/ "E"
set "done" to 1
goto "#return"

: "loop"
. "this robot gives another one a command"
. "and waits for it to finish"
set "done" to 0
. "pass the command"
send "activate" to "#activate"

. "wait for the command to finish executing"
: "wait"
if "done" = 0 then "wait"
wait for 1
goto "loop"

[Lachesis]

. "@moveguy"
:"l"
cycle 1
goto "l"
: "#move"
. "send first, since the go command ends the cycle"
send "donkeydong" "done"
go EAST for 1
goto "#return"

. "@donkeydong"
: "done"
send "moveguy" "#move"
end

[nooodl]

Default board size set to 80x25, instead of the absolutely pointless 100x100.

[Lachesis]

Doesn't that take all of 3 seconds to change when you press ALT+P

What I'd enjoy more in that regard is when you create a new board, it automatically brings up the ALT+P dialogue before you can do anything. I always end up forgetting to change that stuff until the last minute.

Edit: as an extension of this, you could probably find a way to merge the ALT+P, I, and X menus into the same screen. Maybe have tabs?

[Lachesis]

herp a derp





of course nobody gives a fuck so this is never going to happen :D

[Lachesis]

Directory functions for custom file selection menus in games or etc, I dunno if there's already something like this but I don't recall there being anything

. "this gets the files in the game's root directory"
set "DIR_SCAN" to "/"
loop start
set "$prefix" ""
if "DIR_FILE_IS_DIR" = 1 "#isDir"
write overlay c0f "&$prefix&&DIR_FILE&" 0 "loopcount"
set "DIR_GET_NEXT" 1
loop "('DIRS_FOUND'-1)"
end
: "#isDir"
set "$prefix" "[DIRECTORY] "
goto "#return"

__test.mzx
a_game.mzx
happy_feet.avi
[DIRECTORY] my_sfx
[DIRECTORY] .top_secret_18+_paulguy_pics

[smilymzx]

How about several Import and Export functions (since it's getting close to Megazeux v3.0), such as:

t*- Make your own ZZTesqe boarder that shows Stats, can use a seperate board and/or Vlayer, but overlaps the default grey border that is used constantly
t*- (Super)ZZT Board and World (Approximate support)
t*- Dump (Super)ZZT OOP scripts for use in a text editor for translation to MZX,
*- Import Font Mania ZZT fonts to CHR internally
*- Add a 8x8 font for use below
- do the config in a plain .TXT file in all systems instead of the long .CONFIG
- Support ANSI and ASCII art/text (Was in previous versions)
- Add the Older Font set from v1.xx versions of Megazeux
- To Finally use any of 8x8, 40 column (SuperZZT) and Blinking modes, or both, Is Text mode compliant (as in compatible)
(In addition to default SMZX modes, Can make for a (Super)ZZT modes, a NES-like mode-in combo with SMZX modes, or a bunch of complex modes)

Short Notes:
*=Optional
t=Template in any editable format may be accepted with the conversion process

[Frobozz]

Lancer-X, on 15 September 2010 - 04:29 PM, said:

Producing a fully-complaint XML reader with full DTD support and the like would not be trivial to implement at all, but I'd really ask why you'd need something like that in MZX.

Would you really need that much functionality? I think something along the lines of IrrXML would be more than enough for most people. Assuming anyone even cares, you could probably use it to handle the configuration settings as well.

Edit: Of course, you'd need something different than IrrXML, because IrrXML requires C++. Still, you don't need some really fancy XML reader/writer.

This post has been edited by Frobozz: 11 November 2010 - 11:55 AM

[zzo38]

smilymzx, on 11 November 2010 - 12:29 AM, said:

How about several Import and Export functions (since it's getting close to Megazeux v3.0), such as:

t*- Make your own ZZTesqe boarder that shows Stats, can use a seperate board and/or Vlayer, but overlaps the default grey border that is used constantly

My fork of MegaZeux has this feature. You cannot use a board overlay at the same time though (the overlay is used for the status area), but you can make something like ZZT dark rooms by using the BLIND_ADDRESS counter and the A_SEEBLIND attribute.

Quote

t*- (Super)ZZT Board and World (Approximate support)
t*- Dump (Super)ZZT OOP scripts for use in a text editor for translation to MZX,

Not needed

Quote

*- Import Font Mania ZZT fonts to CHR internally

Make an external program if wanted for this

Quote

*- Add a 8x8 font for use below

I think there is a (obsolete) fork of MegaZeux which does this, but I think this feature is not needed anyways, although if it is, I suppose a SMZX mode can be added for this

Quote

- do the config in a plain .TXT file in all systems instead of the long .CONFIG

I think they already are plain text files.

Quote

- Support ANSI and ASCII art/text (Was in previous versions)

This could be a external program (I could write it if needed, I guess); or you can write the ANSI format conversion in Robotic and/or Forth.

Quote

- Add the Older Font set from v1.xx versions of Megazeux

This can be a external .CHR file

Quote

- To Finally use any of 8x8, 40 column (SuperZZT) and Blinking modes, or both, Is Text mode compliant (as in compatible)
(In addition to default SMZX modes, Can make for a (Super)ZZT modes, a NES-like mode-in combo with SMZX modes, or a bunch of complex modes)

My own fork of MegaZeux supports blinking modes. It does not do any of the other things listed here, though.

Frobozz, on 11 November 2010 - 04:54 AM, said:

Would you really need that much functionality? I think something along the lines of IrrXML would be more than enough for most people. Assuming anyone even cares, you could probably use it to handle the configuration settings as well.

I think XML support is not needed in MegaZeux at all.

[Lachesis]

copy block 0 0 80 25 "@$virtualFile" 1
put "@$virtualFile" Image_File p00 0 0

[CJA]

write overlay c?? "&$string&" at "#x" "#y"

[Lachesis]

Lachesis, on 21 June 2010 - 09:24 PM, said:

1. write overlay c0f "A STRING" "#0" "#0"

Exophase, on 21 June 2010 - 10:15 PM, said:

Of course that looks stupid since it's "write overlay" ;p

:(

[CJA]

put c?? String "&$string& dollars" at "#x" "#y"

lozl

[smilymzx]

About the ZZT part: A converter exists, It used to have source, the source to ZZT2MZX no longer has any trace.

How can I convert the original Darbytown (to be remade in MZX) without Disassembling the EXE file!

I swear a year ago Kuddy made a (Preliminary) converter as a viewer/generator in MZX, but is no longer seen here either.

EDIT: Typo fixed

This post has been edited by smilymzx: 15 November 2010 - 03:30 AM

[Exophase]

That comment was pretty tongue in cheek. The only reason I'd say not to add that is because I had the proper command slated in the command revision set for debytecode path, but if no one is doing that stuff then it doesn't really matter. Even if they are, it can just be one of the set of things translated.

[Lachesis]

I actually kind of liked the "write vlayer" idea.

Does debytecode have a command limit? If not, all sorts of silly notation like "#x" "#y" "+x" "+y" could get replaced with more intuitive things like

copy vlayer block at 0 0 for 20 by 10 to 10 10

copy vlayer block at 0 0 for 10 by 10 to overlay at 0 0

copy overlay block at 0 0 for 1840 by 1 to board at 0 0 for 80 by 23 as Customblock

Okay, that last one is pushing it <.<

[zzo38]

smilymzx, on 14 November 2010 - 08:26 PM, said:

About the ZZT part: A converter exists, It used to have source, the source to ZZT2MZX no longer has any trace.

In order to convert a ZZT game to work properly (I mean very properly) on MegaZeux, you have to do one (actually, probably both) of these things:

• Use PZX-mode.
  
• Do the convertion (partially) manually.

Quote

What I'd enjoy more in that regard is when you create a new board, it automatically brings up the ALT+P dialogue before you can do anything. I always end up forgetting to change that stuff until the last minute.

Or do it how the DOS MegaZeux did it, which is use the board size of the board you were on before creating the new one. (You can also do what I did in Super ASCII MZX Town Part II; or, maybe you cannot do that.)

This post has been edited by zzo38: 16 November 2010 - 12:42 AM

[smilymzx]

What about since the ANSi converter is an option: a .ZZT to ANSi Format converter to go along with it

Converting from ZZT to ANSi should be better than starting with nothing!

(Yes, please do a ANSi Converter, e-mail me if you're ready!)

This post has been edited by smilymzx: 17 November 2010 - 04:47 AM

[zzo38]

smilymzx, on 16 November 2010 - 09:40 PM, said:

What about since the ANSi converter is an option: a .ZZT to ANSi Format converter to go along with it

Converting from ZZT to ANSi should be better than starting with nothing!

(Yes, please do a ANSi Converter, e-mail me if you're ready!)

You are not making much sense. (Perhaps you mean .BRD to ANSi; that makes a bit more sense.) I can do the program that converts between MZM and ANSi formats, but I will not send e-mail to you when ready. I can send a private message using this forum, and/or I can post a public message to this forum.

[Exophase]

Lachesis, on 15 November 2010 - 11:40 AM, said:

I actually kind of liked the "write vlayer" idea.

Does debytecode have a command limit? If not, all sorts of silly notation like "#x" "#y" "+x" "+y" could get replaced with more intuitive things like

copy vlayer block at 0 0 for 20 by 10 to 10 10

copy vlayer block at 0 0 for 10 by 10 to overlay at 0 0

copy overlay block at 0 0 for 1840 by 1 to board at 0 0 for 80 by 23 as Customblock

Okay, that last one is pushing it <.<

http://exophase.devz...and_convert.txt

There wasn't a parameter for what to turn overlay into but it had the other stuff.

[Lachesis]

The proposed string indexing and subroutine command would be kind of cumbersome to type out -- I'd prefer stuff more like

$str.n --> $str[n]
$str.length --> stays the same
$str+x#y --> $str[x,y]
#subroutine --> sub "subroutine"

I'm also not sure what the problem with set "$string" "string" is.

As for loops, I think the best thing would be to keep the existing functionality the same but also add for and (do?) while.

[smilymzx]

zzo38, on 16 November 2010 - 09:36 PM, said:

You are not making much sense. (Perhaps you mean .BRD to ANSi; that makes a bit more sense.) I can do the program that converts between MZM and ANSi formats, but I will not send e-mail to you when ready. I can send a private message using this forum, and/or I can post a public message to this forum.

Then a program to extract all ZZT (and SuperZZT?) boards to proper BRD files with DOS names can be in order? (ZBRDEX - ZZT Board Extractor, could be a name for one),

And these other utilities: BRD2ANS, BRD2MZM, ANS2MZM, and MZM2ANS, We should call these five: MZCNVPAK (MegaZeux Converter Pack)

Yes, If you can post it here, or at least submit it to ''Other Software Releases'' forums