[zzo38]

A board-local counter called "BOARDLOCAL". It is simply a counter you can use for whatever you want to use it for.

A board-local counter called "BOARD_X_CLIP". It is equal to the board width by default, and can store a number. The number is a cut-off X coordinate if non-zero. Things cannot move into the cut-off area, CHANGE and IF ANY and stuff like that ignore it, nothing in the cut-off area can be addressed by coordinates, etc. But robots in the cut-off area still update, overlays still work, and the cut-off area is unaffected by freezetime/slowtime/blind or other potion/ring effects. For example, if BOARD_X_CLIP is 30 and the width is 40, then everything with the X coordinates 30 to 39 is the cut-off area, moving east off of X=29 will go to the board east, moving west off of a board onto this board will go to X=29, etc.

A read-only counter "BOARD_NUMBER" with the number of the current board.

Counters "SAVE_BOARD" and "LOAD_BOARD" to save and load boards. If you give a number after the name of the counter, it will use that slot instead of the current board. The filename for LOAD_BOARD can be a board file, or it can be a world file and with a colon and number after the filename, in which case it will copy that board from that world.

Option in configuration file for changing ALT+D in editor between the old and new function.

Option in configuration file to disable centering the mouse at the window (leaving the real mouse pointer where it is and setting the MZX mouse pointer to the lower-right corner). Another option for mouse would be that the MZX pointer is not displayed in window mode, and the normal mouse pointer is (always) displayed, regardless of mouse pointer state. However you should still hide the real mouse pointer if a game uses the mouse coordinate counters without enabling the normal mouse cursor display.

Option in configuration file for uppercase Robotic commands.

Keyboard shortcuts in robot editor for block actions, instead of having to select from a list. (For example, CTRL+X cut, CTRL+C copy, CTRL+Z clear)

Able to use Robot/PushableRobot/Sensor/Sign/Scroll in CHANGE and similar commands. If changing something into a Robot p?? or PushableRobot p??, it will become a copy of the current robot, but starting from the beginning. If the Robot parameter is a string, it starts with a character @ or ! or % to become a copy of the robot with that name, loaded from bytecode, or loaded from a text file, respectively. If a Sensor, you give the parameter as a string indicating the sensor name, robot name, and character number, separated by semicolons (for example: c04 Sensor "sensor1;controller;254"). For Sign/Scroll, the parameter string is a name of a string variable or a filename. On the left side of a CHANGE, or in IF ANY or similar commands, using a Robot with a string parameter checks for robots with that given name.

Some way to set strings without interfering with special words. Possibly MODULO "$name" "text" could be made to do that.

Add a CHAR ID setting for the character to display for the outside of view border.

Some way to make it scrolls and signs use the in-game character set rather than the system character set.

And now for Extended MZX stuff:

First, in order to enable Extended MZX, you need to make the first line of the global robot into a comment with a greater than sign at the beginning. After the greater than sign is a filename. (I will write the C codes for interpreting the file and executing things defined in it later.) If the filename has angle-brackets around it, it will look for the file in the subdirectory of the MegaZeux executable called "Extended". If it doesn't have angle-brackets, it will look in the same directory as the world file is stored in.

The thing numbers 128-255 are Extended Kinds, and shall use a higher offset of the CHAR ID table because offsets 128-255 are already used.

The Forth codes file (indicated in global robot) is reloaded after every time you exit the global robot editor, every time the world is loaded in any way (game, title, swap, editor, etc), and when a certain key combination is pushed during the level editor or robot editor (you could make it CTRL+R, or something else if you wanted to).

Extended Kinds are defined in the Forth codes file, indicating the number 128-255, the default CHAR ID value, the parameter type (which can be any one of the built-ins), the flags, and the name. They will be listed in the F11 menu in the editor. The CHAR ID editor will list any Extended Kinds you have defined in which the default value is not 0 or 255. The names defined are now also displayed in the editor and can be used in Robotic codes.

There are Extended MZX events defined in the file also. Game play events are: KEYBOARD JUSTENTERED PLAYERHIT PLAYERHURT PLAYERMOVING UPDATE SPEC_PUSH SPEC_BOMB ITEM SPEC_SHOT AFFECTSTOOD. Editor events are: SF5 SF6 SF7 SF8 BEFOREADDBOARD AFTERADDBOARD. Some events are 128 such events, one for each Extended Kind.

Two new counters dealing with Extended MZX. The counter "FORTH_STACK" is push to data stack if written to, pop from data stack if read. The counter "FORTH_EVENT" is write-only and calls the event with that given number.

For example:

128 12 0 A_ITEM A_PUSH + EXTKIND ZztKey
EV.ITEM ZztKey + :EVENT COLOR-AT DUP TAKEKEY SWAP GIVEKEY DROP 0= ;
EV.BEFOREADDBOARD :EVENT GETBOARDSIZE ;
EV.AFTERADDBOARD :EVENT SETBOARDSIZE REMOVE-OVERLAY ;

[zzo38]

Oops, I forgot one more proposal:

Make a counter named "STRING_TERMINATOR" that can be value 0 to 255 with a default value of 42.

Also, it seems that 255 is for "no ID" (not sure what that means), so you can use only 128-254 I guess (if that is in fact the case)

O, and a new string operator "$name!x!y" where x is a list of number of characters separated by commas, y is one number of element of list or two number separated by commas (the second can be omitted with leaving only the comma for all to the end). So example SET "$string" "$string!13!0" can be used to strip carriage return if you set STRING_TERMINATOR to 10 and then read text-file, and strip carriage-returns that comes before the linefeed if there are any.

This post has been edited by zzo38: 18 May 2009 - 09:36 PM

[Dr Lancer-X]

oh no :(

[Exophase]

zzo38, on May 18 2009, 01:56 PM, said:

A board-local counter called "BOARDLOCAL". It is simply a counter you can use for whatever you want to use it for.

Only one? Doesn't sound very useful or largely desired. You can make your "own" with $board_name.

zzo38, on May 18 2009, 01:56 PM, said:

A board-local counter called "BOARD_X_CLIP". It is equal to the board width by default, and can store a number. The number is a cut-off X coordinate if non-zero. Things cannot move into the cut-off area, CHANGE and IF ANY and stuff like that ignore it, nothing in the cut-off area can be addressed by coordinates, etc. But robots in the cut-off area still update, overlays still work, and the cut-off area is unaffected by freezetime/slowtime/blind or other potion/ring effects. For example, if BOARD_X_CLIP is 30 and the width is 40, then everything with the X coordinates 30 to 39 is the cut-off area, moving east off of X=29 will go to the board east, moving west off of a board onto this board will go to X=29, etc.

This could be useful, but I think it's a bad direction to move towards. Having more global robots or robots not attached to actual robots on board would solve the robot resources problem, and vlayer solves the overlay resources problem.

zzo38, on May 18 2009, 01:56 PM, said:

A read-only counter "BOARD_NUMBER" with the number of the current board.

Board IDs are only used in pretty limited context and it should stay this way. Use $board_name, although you'll have to be sure not to name multiple boards the same thing if you want uniqueness - but it's already this way way for board addressing (directions, teleport player) anyway. It does mean you can't bake caves and whatever but you're probably better off using robots for those anyway. Your suggestion wouldn't be very easy for helping this, since you'd have to bounce around boards saving their IDs in counters just to grab them.

zzo38, on May 18 2009, 01:56 PM, said:

Counters "SAVE_BOARD" and "LOAD_BOARD" to save and load boards. If you give a number after the name of the counter, it will use that slot instead of the current board. The filename for LOAD_BOARD can be a board file, or it can be a world file and with a colon and number after the filename, in which case it will copy that board from that world.

Why not use MZMs instead?

zzo38, on May 18 2009, 01:56 PM, said:

Option in configuration file for changing ALT+D in editor between the old and new function.

What was the old function again..? What's the new function, for that matter ;P

zzo38, on May 18 2009, 01:56 PM, said:

Option in configuration file to disable centering the mouse at the window (leaving the real mouse pointer where it is and setting the MZX mouse pointer to the lower-right corner). Another option for mouse would be that the MZX pointer is not displayed in window mode, and the normal mouse pointer is (always) displayed, regardless of mouse pointer state. However you should still hide the real mouse pointer if a game uses the mouse coordinate counters without enabling the normal mouse cursor display.

The centering things sound like issues with SDL. I'm not following the usefulness of overriding what the game should have legitimate control over.

zzo38, on May 18 2009, 01:56 PM, said:

Option in configuration file for uppercase Robotic commands.

Robotic is case insensitive. If you're angry at it converting your commands to uppercase then you're better off waiting for a version of MZX that leaves your robot code alone.

zzo38, on May 18 2009, 01:56 PM, said:

Keyboard shortcuts in robot editor for block actions, instead of having to select from a list. (For example, CTRL+X cut, CTRL+C copy, CTRL+Z clear)

This one is not actually a bad idea, the only concerns being that a lot of hotkeys are taken.

zzo38, on May 18 2009, 01:56 PM, said:

Able to use Robot/PushableRobot/Sensor/Sign/Scroll in CHANGE and similar commands. If changing something into a Robot p?? or PushableRobot p??, it will become a copy of the current robot, but starting from the beginning. If the Robot parameter is a string, it starts with a character @ or ! or % to become a copy of the robot with that name, loaded from bytecode, or loaded from a text file, respectively. If a Sensor, you give the parameter as a string indicating the sensor name, robot name, and character number, separated by semicolons (for example: c04 Sensor "sensor1;controller;254"). For Sign/Scroll, the parameter string is a name of a string variable or a filename. On the left side of a CHANGE, or in IF ANY or similar commands, using a Robot with a string parameter checks for robots with that given name.

I consider signs and scrolls to both be obsolete and I don't encourage their usage, much less new functionality to be added for them. I'd be on the fence with sensors, but who is really using them? Such that they have to create them dynamically... I'm generally against creating robots dynamically as well, for various reasons that I won't get into. Changes to Robotic would make this less desirable.

Adding more runtime hacks to Robotic parsing is a very bad idea. Changes of this caliber, if desired, should be held off until something is done to clean up the language.

zzo38, on May 18 2009, 01:56 PM, said:

Some way to set strings without interfering with special words. Possibly MODULO "$name" "text" could be made to do that.

I don't follow this one.

zzo38, on May 18 2009, 01:56 PM, said:

Add a CHAR ID setting for the character to display for the outside of view border.

Isn't there a command for this? I dunno.

zzo38, on May 18 2009, 01:56 PM, said:

Some way to make it scrolls and signs use the in-game character set rather than the system character set.

See my stance on scrolls and signs.

zzo38, on May 18 2009, 01:56 PM, said:

And now for Extended MZX stuff:

First, in order to enable Extended MZX, you need to make the first line of the global robot into a comment with a greater than sign at the beginning. After the greater than sign is a filename. (I will write the C codes for interpreting the file and executing things defined in it later.) If the filename has angle-brackets around it, it will look for the file in the subdirectory of the MegaZeux executable called "Extended". If it doesn't have angle-brackets, it will look in the same directory as the world file is stored in.

The thing numbers 128-255 are Extended Kinds, and shall use a higher offset of the CHAR ID table because offsets 128-255 are already used.

The Forth codes file (indicated in global robot) is reloaded after every time you exit the global robot editor, every time the world is loaded in any way (game, title, swap, editor, etc), and when a certain key combination is pushed during the level editor or robot editor (you could make it CTRL+R, or something else if you wanted to).

Extended Kinds are defined in the Forth codes file, indicating the number 128-255, the default CHAR ID value, the parameter type (which can be any one of the built-ins), the flags, and the name. They will be listed in the F11 menu in the editor. The CHAR ID editor will list any Extended Kinds you have defined in which the default value is not 0 or 255. The names defined are now also displayed in the editor and can be used in Robotic codes.

There are Extended MZX events defined in the file also. Game play events are: KEYBOARD JUSTENTERED PLAYERHIT PLAYERHURT PLAYERMOVING UPDATE SPEC_PUSH SPEC_BOMB ITEM SPEC_SHOT AFFECTSTOOD. Editor events are: SF5 SF6 SF7 SF8 BEFOREADDBOARD AFTERADDBOARD. Some events are 128 such events, one for each Extended Kind.

Two new counters dealing with Extended MZX. The counter "FORTH_STACK" is push to data stack if written to, pop from data stack if read. The counter "FORTH_EVENT" is write-only and calls the event with that given number.

For example:

128 12 0 A_ITEM A_PUSH + EXTKIND ZztKey
EV.ITEM ZztKey + :EVENT COLOR-AT DUP TAKEKEY SWAP GIVEKEY DROP 0=;
EV.BEFOREADDBOARD :EVENT GETBOARDSIZE;
EV.AFTERADDBOARD :EVENT SETBOARDSIZE REMOVE-OVERLAY;

I can't follow this perfectly well because I think you're missing some important details, but it doesn't look especially appealing.

Bear in mind, for something to be embraced and added into MZX it has to be something that a number of people find useful, not just something you want. There's no way anyone aside from you is going to program anything Forth related into MZX, and if you manage to do it then chances are it won't get merged into mainline.

People don't want more builtins, even user customizable ones - that's why Robotic is there. It doesn't sound like you want to extend MZX as much as you want to graft something around it that basically allows the same things as now, with a vaguely different approach. Except the editor monitoring stuff. That's just wonky.

[zzo38]

Exophase, on May 18 2009, 02:43 PM, said:

This could be useful, but I think it's a bad direction to move towards. Having more global robots or robots not attached to actual robots on board would solve the robot resources problem, and vlayer solves the overlay resources problem.

Can you display stuff outside the board boundaries?

Quote

Board IDs are only used in pretty limited context and it should stay this way. Use $board_name, although you'll have to be sure not to name multiple boards the same thing if you want uniqueness - but it's already this way way for board addressing (directions, teleport player) anyway. It does mean you can't bake caves and whatever but you're probably better off using robots for those anyway. Your suggestion wouldn't be very easy for helping this, since you'd have to bounce around boards saving their IDs in counters just to grab them.

Then fine I will just use SAVE_GAME and read the board number directly from the save-game using FREAD_OPEN. And that will cause all sorts of problems such as different save-game file format.

Quote

Why not use MZMs instead?

MZMs can't save scrolls, signs, sensors, or the player.

Quote

What was the old function again..? What's the new function, for that matter ;P

The old function is toggle if some built-ins should set to default color when selected from the menu. The new function resets the palette (which I believe ALT+E ALT+D does the same thing).

Quote

The centering things sound like issues with SDL. I'm not following the usefulness of overriding what the game should have legitimate control over.

O. I don't know much about SDL.

Quote

Robotic is case insensitive. If you're angry at it converting your commands to uppercase then you're better off waiting for a version of MZX that leaves your robot code alone.

No, I meant like old versions of MZX gave you the option to do. This isn't really necessary it is just something possible

Quote

This one is not actually a bad idea, the only concerns being that a lot of hotkeys are taken.

Which hotkeys are not taken? Fore sure there must be some of that.

Quote

I consider signs and scrolls to both be obsolete and I don't encourage their usage, much less new functionality to be added for them. I'd be on the fence with sensors, but who is really using them? Such that they have to create them dynamically... I'm generally against creating robots dynamically as well, for various reasons that I won't get into. Changes to Robotic would make this less desirable.

I disagree, but that's OK for now

Quote

I don't follow this one.

I mean if you want the text to be the actual text "$string1" or "BOARD_NAME" or "FREAD" or whatever.

Quote

I can't follow this perfectly well because I think you're missing some important details, but it doesn't look especially appealing.

Bear in mind, for something to be embraced and added into MZX it has to be something that a number of people find useful, not just something you want. There's no way anyone aside from you is going to program anything Forth related into MZX, and if you manage to do it then chances are it won't get merged into mainline.

People don't want more builtins, even user customizable ones - that's why Robotic is there. It doesn't sound like you want to extend MZX as much as you want to graft something around it that basically allows the same things as now, with a vaguely different approach. Except the editor monitoring stuff. That's just wonky.

Extended MZX is not meant to replace Robotic at all. It is designed to extend MZX, hence the name. And it isn't only the same things as now, they are various different things also. And the editor monitoring stuff would also be very useful.

You have left me with only one choice: To fork the project and then poke you with the fork. And I should upgrade to GNU GPL v3 to have a war. And then everyone will complain about the war and stuff like that. But the other difference is that anything added to the new version of MegaZeux I will have to put on mine also to make it compatible. What should I call it?

[Exophase]

I don't think a "war" will happen if you fork MZX to do your silly things, I think you'll just be ignored. Have fun though.

[zzo38]

Exophase, on May 18 2009, 03:49 PM, said:

I don't think a "war" will happen if you fork MZX to do your silly things, I think you'll just be ignored. Have fun though.

But what shoudl I call it? And also I want to know if there is some sort of seeing what differences in codes between different version so that any upgrades for normal MegaZeux can also be added into my own also, to make it compatible with normal MegaZeux also.

[Exophase]

Read the man pages for "diff" and "patch." Call it whatever you want.

[Risu2112]

Additional built in sign and scroll support? This was a joke right?

Just in case this wasn't a joke some one should probably tell him not to bother trying to make anything forward compatible since the only reason that some one would download this in the first place is because they miss clicked on the link.

[zzo38]

Quote

I don't think a "war" will happen if you fork MZX to do your silly things, I think you'll just be ignored.

Well, because I upgrade to GNU GPL v3, it might, in case of at least one feature someone decides they want for normal MZX also, they will have to either upgrade to GNU GPL v3 or write it themself. It isn't likely to be that significant, however.

Quote

Read the man pages for "diff" and "patch." Call it whatever you want.

OK I will look at those man pages. I shall call it "ProngZeux" because that name was suggested on IRC. Now, what libraries and compilers and stuff do I need to compile it? Is there a list somewhere that explains it? I want to know how to compile both on Linux and on Windows.

If the first line of the global robot is a comment with > sign then it will enable the extra features and set the default extension to .PZX, otherwise it will use .MZX so that it can be loaded in normal MegaZeux (the file-formats are the same, the only reason for different extension is so that you can tell which world files don't work on normal MegaZeux). If you want to make a PZX that doesn't use any Forth codes, you can give a comment . ">" without a filename.

Quote

Additional built in sign and scroll support? This was a joke right?

Not actually a joke. But at least the one to use the game character set for signs/scrolls would be helpful if at least for the only reason that some older games might use it.

Quote

Just in case this wasn't a joke some one should probably tell him not to bother trying to make anything forward compatible since the only reason that some one would download this in the first place is because they miss clicked on the link.

I doubt anyone will miss-click on the link. But even then, I would like it possible for ProngZeux to not only load future MegaZeux games, but also mix ProngZeux features with normal MegaZeux features that are implemented in the future. And if someone does get ProngZeux for whatever reason, I would like it to still play normal MegaZeux games also.

[mzxgiant]

At least it's not a delicious mint julep!.

edit: At least it's not B-A-N-G-!.
... that word replacement is still around?!

[zzo38]

I would like a description somewhere that tells what is needed to compile it on Linux and on Windows.

Other features I plan to implement (probably not all at once):

New overlay modes, displace overlay mode and screen overlay mode. Displace mode uses board coordinates and screen mode uses screen coordinates but otherwise it is the same. There is two counters "OVERLAY_DISPLACE_X" and "OVERLAY_DISPLACE_Y" used to displace the overlay by that number of pixels. These overlay modes will display the overlay over everything, including the border and message line (but not dialog boxes).

New read-only counters, if the name starts with an asterisk then it searches the Forth dictionary for the word after the asterisk. If it a constant that will be the value. If it is the name/address of a subroutine it will call that subroutine in Forth and pop the data stack to return the value. The Forth dictionary also includes the name of all built-ins as well, so you can do things like CHANGE CHAR ID "*Key" 33 instead of using the number for the Key.

When writing to a asterisk counter that is a subroutine, it will push the robot ID and value to write and call the subroutine. This makes an alternative way to call Forth codes from Robotic codes. Also, since spaces are not valid characters in a Forth word, after the word (whether reading or writing), you can indicate a counter or expression after a space to push that value to the stack before calling the subroutine.

New counter __VERSION__ which makes it act like older version, in case you want to modify a older world file and still have it work, without changing everything.

Change the A_ flags to 32-bits instead of 16-bits (it is already 32-bit int size, and the flags[] array is int type, so it will work). Add two new A_ flags A_CRUSH and A_USERFLAG. A_CRUSH makes it if something with this flag is being pushed indirectly and there is nowhere to move it to, it will be destroyed so the other things can move in its way. If there is more than one object in the pushing line that has A_CRUSH, it will crush the one farthest from the object that is doing the pushing. A_USERFLAG does absolutely nothing.

A new ARRIVE event for when something arrived on a floor-type object.

Another new event called BULLET_HIT which is used when a bullet is about to hit a solid object. The event can be cancelled, restarted, go normally, or destroy what it hits anyways even though it cannot normally be destroyed by bullets.

An area in the Forth memory map for things that are not saved/restored with save-games.

Silly directions like CW IDLE don't mean anything useful, so using CW IDLE as a direction can treat the "LOCAL32" counter as an angle (modulo 4, 0=E, 1=N, 2=W, 3=S) and use that as the direction.

Allow angle-brackets to be used anywhere a filename can be used for reading only, in which case it will use the one from the subdirectory of the directory of the executable. (This cannot be used when you are writing to a file.)

Make it so Forth codes can edit Robotic codes of robots, such as zapping and restoring labels, and also other things.

Use the high nybble of save_mode (or some other board property that doesn't normally have that many possible values) for custom stuff, which can then be read by Robotic codes and Forth codes.

Use a few of the low bits of the extended kind number to determine what to do if the CHAR ID value for that extended kind is set to zero. Some of the possibilities might be: Thin arrows, thick arrows, etc.

Also, after some things in ProngZeux start working, I will also work on another program called CoZZT which is used to convert .ZZT worlds into .PZX worlds. Some programs to do similar things already exist, but the ones that currently exist are extremely inaccurate. Using the new PZX features (and also knowing more about how ZZT works), we can make the conversion more accurate. I am the ZZT Scientist so I know a lot of things about how ZZT works that some other people don't know. (Of course some things in ZZT still won't be able to be converted properly, but at least the games by Potomac Computer Systems and many other ZZT games should work fine, the few other things can be entered in manually after it is converted).

I hope at least one other person thinks these are good features, but even if it isn't I still plan to implement it.

[Terryn]

Read the relevant READMEs in the /arch/ dir in the source tarball.

Here's a specific one for mingw: http://mzx.devzero.c...ys-megazeux.txt

Your mileage may vary on that; mingw/msys's dependencies setup is outright inimical.

[Dr Lancer-X]

I'm glad to see that all of zzo's proposed changes are almost universally bad, so that there's no chance of people actually using this hack.

[zzo38]

Quote

Read the relevant READMEs in the /arch/ dir in the source tarball.

Here's a specific one for mingw: http://mzx.devzero.c...ys-megazeux.txt

Thanks for those informations.

Quote

I'm glad to see that all of zzo's proposed changes are almost universally bad, so that there's no chance of people actually using this hack.

Well, they are useful to *me*, at least. Once I make things using these new features, then other people might decide differently whether or not they like it (they could change both ways, they used to like it and now dislike it, or they used to dislike it and now like it).


Here is an example of CoZZT:

ZZT codes:

#PUT SEEK WHITE NORMAL

Robotic codes:

SET "LOCAL32" "*ZZTSEEK ROBOT_ID"
PUSH CW IDLE
PUT c0f Normal p00 CW IDLE

Forth codes:

: ZZTSEEK DIR.SEEK DIR>ANGLE COUNTER@ "INVINCO" IF 2 + THEN ;

[ajs]

I'd certainly be more receptive to you changing things if you didn't threaten people with forks and tell us all the first thing you'd do was deliberately change the code license to make the changes incompatible with the existing MZX code base. All this, following detached and constructive feedback from Exo. Talk about unprovoked!

I'm interested to see what you'll achieve, but I think you could be quite a bit less of a prick about it.

--ajs.

[zzo38]

ajs, on May 22 2009, 11:11 AM, said:

I'd certainly be more receptive to you changing things if you didn't threaten people with forks and tell us all the first thing you'd do was deliberately change the code license to make the changes incompatible with the existing MZX code base. All this, following detached and constructive feedback from Exo. Talk about unprovoked!

I'm interested to see what you'll achieve, but I think you could be quite a bit less of a prick about it.

--ajs.

OK I will try. The reason I wanted to upgrade to GPLv3 was to make a war. But maybe I won't do so unless I feel later on, after a while, that a was is necessary.

If you are interested to see what I might achieve, then I will try to be less of a prick about it, and not make the imcompatible license, but rather be more open to feedback instead.

This post has been edited by zzo38: 22 May 2009 - 07:32 PM

[Frobozz]

If you want people to adopt something then you should try to make it appeal to them. But randomly forking to start an argument is only going to keep people from your project and make you look like a troll. Regardless, I'd have to say the Forth code you posted above is extremely annoying to read. Maybe if you had applied capitalization in certain spots and not the entire thing it'd be better. But, personally, if that's what Forth looks like then I'd have no interest in trying to make use of it.

[zzo38]

O, I forgot to list some other features (I will also copy this topic to my computer so that I can also use it as a list to remember things by):

Polyphonic PC effects. ? is channel, @ is percussion, ^ is volume, * is waveform types.

SHIFT+F2 in editor will display a different character if the robot is already a exclamation mark.

SHIFT+F1, SHIFT+F2, SHIFT+F3, SHIFT+F4 will cycle the colors if it already has the same foreground and background color.

When you save a world using the editor, make the directory of the world to be the current directory, so that any files created in Robotic codes or Forth codes, and any save-game files, will go in the same directory as world file.

Allow the update_host configuration setting to contain a port number (I'm not sure if it is already allowed)

Make in file selection dialog boxes you can type in a filename mask to make it list files from that mask.

[ajs]

I'd be happy to take the following features into the official MZX if you code them up. If this interests you, it might be worth doing these things first.

• Shift-F2 change
  
• Shift-XX changes
  
• Save dir change (actually there are more related changes required here but that's okay)
  
• Dialog box mask enhancement (make sure you either have * work in a filename or prohibit it)
  
• update_host port change
  
• Upper case robotic decompiler config.txt option (though as Exo said this could well be obsolete soon)
  
• SDL mouse fixes (if possible)
  
• Robot editor hotkey additions, if Exo's concerns about conflicts are addressed
  
• Alt-D change (config.txt option) if you must

This doesn't prevent you from continuing a fork (a la ProngZeux) for the other changes, it means the differences between the versions are minimised, and if your fork does die, your work isn't wasted.

--ajs.

[zzo38]

I have no general interest to code these things in a particular order (although I might), but regardless of the order, it is certainly acceptable to look at my changes and then merge in the ones you like.

Quote

Save dir change (actually there are more related changes required here but that's okay)

I guess there probably are more related changes, and I would always check for such things as that.

Quote

Upper case robotic decompiler config.txt option (though as Exo said this could well be obsolete soon)

Well, this is one of the least important features I listed, but it existed in older versions of MegaZeux and in the help file.

Quote

Regardless, I'd have to say the Forth code you posted above is extremely annoying to read. Maybe if you had applied capitalization in certain spots and not the entire thing it'd be better.

I code Forth codes in mostly all uppercase. You can do it differently, but you still have to be consistent in the case you use (or use a case-insensitive Forth system, or change the existing Forth system to be case-insensitive). (Or maybe I should just make a case-insensitive Forth system like everything else in MegaZeux is case-insensitive, so that way you can write Forth codes in lowercase if you prefer, or mixed case, or watever) (I am likely to still write the Forth codes for CoZZT in mostly entirely uppercase, though, because that is the style I tend to use when coding Forth codes)

I can give an explanation for the Forth code implementing ZZTSEEK or any other Forth codes if you want it, in case you don't understand it already.

(And PZX will still have full compatibility with normal MZX if the PZX-specific features are not being used, so everything will be done in exactly the same way as normal MZX if you do not use the PZX-specific features. This is one of the goals of this project)

This post has been edited by zzo38: 23 May 2009 - 12:05 PM

[Sai'ke]

So, how many people do you think will use forth in their mzx games?

[zzo38]

Sai'ke, on May 23 2009, 05:51 AM, said:

So, how many people do you think will use forth in their mzx games?

At least one (myself), but possibly three (or more). Even if nobody else wants to program in Forth directly, other people can still use libraries of Forth codes that are already written (which is necessary if you want to use CoZZT, but we can use this for other purposes as well if you want to). Even if no other MZX users use Forth codes, it is possible that other people who like Forth programming might start making a game in MZX with Forth if someone just wants to use the sort of stuff in MZX and PZX. (And even if nobody else uses it, I will use it and show other people what it can be used for.) For example, maybe you don't like some of the things in MZX and want them different (such as two kind of gates horizontal and vertical, or having it do something else when stepping off of a board to a new board where a wall or item is, etc) then I can write a library of Forth codes to do those things (and more) and people who want these specific changes to the MZX engine can use these specific libraries of Forth codes.

[ajs]

In my view, there is nothing wrong with customised versions of MZX that experiment with something fundamental like a new language. My concern is that you have effectively muddied the water by proposing a slew of unrelated changes which you don't seem to be willing to do separately. This would make convergence very difficult, which I hope isn't your intention.

Something similar happened recently (done in a very different way) with Nightwatch's Lua extensions. Though he's AWOL and that effectively died off, he was very good at splitting up his changes into "bugfixes", "general improvements" and "lua stuff". The bugfixes have already been added (see the changelog) and the "general improvements" will make their way in, as I have them in a separate SVN branch already. The "lua stuff" was never finished, but it could be revisited.

Obviously, you're free to do what you like, but I'll keep nagging you nonetheless.

--ajs.

[zzo38]

Quote

Obviously, you're free to do what you like, but I'll keep nagging you nonetheless.

OK, if you want to.

I guess you could say it is some sort of experimenting. The most difference is that unlike the Lua extensions, the Forth is not meant to be a new program language for robot coding, it is meant to be used separately (you can still use Robotic in robots and Forth codes separate both in the same world file, and Robotic codes and Forth codes can interact with each other too, if you programmed the Forth codes to do that).

Quote

This would make convergence very difficult, which I hope isn't your intention.

That isn't my intention, but then, making convergence easy isn't my intention either.

And if the Lua stuff ever becomes standard, *please* don't make it automatically convert Robotic codes into Lua codes. Allow Robotic codes to be used too (and even allow Robotic and Lua to be used in the same world). The other thing that happens if the Lua stuff ever becomes standard, is that I will have to add it to PZX also, for compatibility reasons (and will also provide a way for Lua codes and Forth codes to interact with each other).

This post has been edited by zzo38: 23 May 2009 - 05:51 PM

[Frobozz]

zzo38, on May 23 2009, 01:45 PM, said:

And if the Lua stuff ever becomes standard, *please* don't make it automatically convert Robotic codes into Lua codes. Allow Robotic codes to be used too (and even allow Robotic and Lua to be used in the same world). The other thing that happens if the Lua stuff ever becomes standard, is that I will have to add it to PZX also, for compatibility reasons (and will also provide a way for Lua codes and Forth codes to interact with each other).

I think the concept was that Robotic would be compiled into bytecode that would run on the Lua VM. I'm not entirely sure anymore since I haven't read about it in a long time.

[Exophase]

Nightwatch backed off so I don't think there's any real potential for that Lua thing ever happening. I got more work done on my branch but that got stalled too.

[Koji]

You know, I'm all for some construct that might implement some feature of a programming language into mzx, HOWEVER implementing the whole other programming language within robotic is not the way to go.

I mean you might as well ask Exo that lisp and Prolog be implemented in the expression evaluation algorithms. It's not going to happen. I know when I was first learning lisp I initially did ask for lisp in mzx expressions, however looking back I cringe, it's really not a good idea. It's far more complex than you initially imagine it to be, and hell expressions already can get complicated enough without adding

This post has been edited by Koji: 26 May 2009 - 12:28 PM

[zzo38]

I fixed some things but now I want to debug it. How do I debug MegaZeux in MinGW? (O, I found out gdb is there, never mind about this question now)

This post has been edited by zzo38: 28 May 2009 - 07:43 PM

[zzo38]

The features that I have gotten to work so far consist of:

Quote

=== Version 2.82bP1 ===

New config.txt options:
* pzx_old_altd: Boolean, if 1 then uses old ALT+D function.
* pzx_allow_char_id_255: Boolean, if 1 then you can set CHAR ID values to
255 in the editor. If you do set it to 255 then it will ask you for the
character to represent that object when you place it.

Game:
* Overlay mode 5 (color-only normal) and mode 6 (color-only static)
* Overlay mode 4 draws the overlay on the border instead of on the board
* Overlay mode 8 and 9, like 1 and 2 but using the system charset
* Overlay modes 65/66/69/70 act like 1/2/5/6 but hides the board
* New SMZX mode 141 for blinking text (like in ZZT)
* New counter BOARD_NUMBER for the number of the current board
* OVERLAY_MODE counter is writable.

Note: Any of the in-game stuff requires the first line of the global robot to contain a comment starting with a greater than sign. If you don't do this, it will run in compatibility mode.

This post has been edited by zzo38: 29 May 2009 - 02:41 AM