[Exophase]

weasel, on 17 July 2010 - 02:45 AM, said:

random thought, perhaps a strong high-pass filter could be put over the PC Speaker sounds to remove the bass and make it sound like the classic tinny noise we're all used to. =P

It's a square wave. I think you can imagine what a square wave looks like after a high pass filter has been put through it. You might really want a bandpass for this.

[zzo38]

Exophase, on 17 July 2010 - 09:59 AM, said:

It's a square wave. I think you can imagine what a square wave looks like after a high pass filter has been put through it. You might really want a bandpass for this.

Maybe a configuration setting can be added for this purpose. Is there a way to generate it already filtered (without applying a filter afterward)? Can changing the duty cycle change anything important?

[Lachesis]

To be honest, in the SMZX character editor, I find the "1-4 Select" to be a bit cumbersome. Could it just be so that 1-4 puts the color that you want? I do quite like the way the mouse buttons work in the SMZX editor, though I think middle click should cycle through the colors instead of acting the same as the left click.

[Zinfandel]

Y'know what'd be cool? The ability to create a loop within an OGG via metadata tags. ZDOOM just implemented it, so I figure it couldn't be that hard to implement it in Megazeux... nah, who am I kidding, trying to add that would probably break 15 other things.

[ajs]

That feature was already added by Mr_Alert in MZX 2.83.

--ajs.

[Old-Sckool]

I wish Megazeux had a built-in MZM editor.

[Lachesis]

It does. It's called the board editor and Import/Export MZM.

[Exophase]

Maybe "import board to MZM" and "export board to MZM" would close much of the gap there.

[Dr Lancer-X]

Thought I'd formalise these requests:

String loading support

Ability to use strings as files for (atomic) file reading and writing functions. No need to include support for the non-atomic functions because that doesn't really add anything.

load char set "$string"
load char set "@###$string"
load palette "$string"
put "@$string" image_file p## # #
set "$string" "load_robot"
set "$string" "load_bc"
set "$string" "load_game"

copy block # # # # "@$string" #
set "$string" "save_robot"
set "$string" "save_bc"
set "$string" "save_game"

This is mostly for the MZM and char set operations because those are some of the fastest ways to change a lot of charset and palette at once in MZX, but to do anything with data that isn't constant you need to write out temporary files and rubbish like that. I'm not as sure about load_robot/save_robot and the like given the possible implementation of debytecode at some point, however, load_robot by itself should still be plenty useful.

Case-insensitive string comparisons

Not really sure what a good interface for this would be, but I'd like to see case-insensitive string comparison support, mainly for comparing large blocks of data.

[nooodl]

loop start "i"
loop start "j"
put c0f CustomBlock pdb "j" "i"
loop 80
loop 25

[Wervyn]

Oh hell no. Don't you dare propose a nested loop structure without a more logical way to nest it. We don't need to add any more cruft to the terrible, terrible built in loop code. Better to wait until someone finally overhauls the language to allow for real loops. Meanwhile, you can just set a local counter and if "local" < 80 "L1" like the rest of us.

"I've been standing here the whole time."

[Old-Sckool]

nooodl, on 21 August 2010 - 09:57 AM, said:

loop start "i"
loop start "j"
put c0f CustomBlock pdb "j" "i"
loop 80
loop 25

Or you could turn that into

loop start
put c0f CustomBlock pdb "('loopcount'%80)" "('loopcount'/80)"
loop (80*25-1)

[Dr Lancer-X]

I think more of us would use comparison loops like Wervyn suggested if they 1) weren't so freaking SLOW and 2) didn't eat up the label namespace. Bigger issue here is optimising the interpreter, not adding more varied loop structures. The namespace issue is harder to deal with cleanly; certainly the best way is to replace the whole language with one that doesn't need labels for everything.

[nooodl]

Quote

1) weren't so freaking SLOW and 2) didn't eat up the label namespace.

These are indeed the reasons nesting three or four loops into each other gives me headaches, but honestly, my feature request was wishful thinking -- it seems it's difficult to change Robotic without completely rewriting it.

So, nesting's impossible, how about the backwards compatible

loop start "n"
* "n is &n&"
wait 1
loop 50

loop start
* "when no name is specified loopcount is used: &loopcount&"
wait 1
loop 100

...which at least looks cleaner and is easier to write than

loop start
set "n" "loopcount"
* "n is &n&"
...

[Wervyn]

You know, if you're finding labels in nested loops annoying, you could always look for opportunities to do this:

set "x" to 0
set "y" to 0
set "z" to 0
: "loop"
* "~f(&x&, &y&, &z&)"
wait for 1
inc "x" by 1
if "x" < 10 then "loop"
set "x" to 0
inc "y" by 1
if "y" < 20 then "loop"
set "y" to 0
inc "z" by 1
if "z" < 30 then "loop"

As for the other thing, it's possible but it just doesn't seem that useful to me, plus you're setting yourself up for some hilarious namespace bugs if you use that with non-local counters.

"Dijkstra moar liek Dickstra amirite"

[Lachesis]

Actually, while we're on the topic, I wouldn't mind a shorter counter name for loopcount, since I find myself setting it to single-letter counter names at the start of a loop anyway for stuff like particle engines. You could make "_" reference it or something, some counter name that nobody uses anyway.

[Dr Lancer-X]

I'm pretty sure I've used every possible 0- and 1-character counter at some point. I've definitely used _

It's good typing exercise, anyway.

[Lachesis]

have you used "|"

[nooodl]

Quote

I'm pretty sure I've used every possible 0- and 1-character counter at some point.

I doubt that!

[zzo38]

Quote

Oh hell no. Don't you dare propose a nested loop structure without a more logical way to nest it. We don't need to add any more cruft to the terrible, terrible built in loop code. Better to wait until someone finally overhauls the language to allow for real loops.

Lancer-X, on 22 August 2010 - 05:47 PM, said:

I think more of us would use comparison loops like Wervyn suggested if they 1) weren't so freaking SLOW and 2) didn't eat up the label namespace. Bigger issue here is optimising the interpreter, not adding more varied loop structures. The namespace issue is harder to deal with cleanly; certainly the best way is to replace the whole language with one that doesn't need labels for everything.

If you use PZX-version (and enable PZX-mode), there is Forth, but that doesn't replace Robotic. In Forth you can create any kinds of loops you want, without labels, and they are faster than Robotic (for many reasons, ask if you are interested). You can also create new Robotic commands using Forth codes, although there is currently no way to make a new command act as a label (the new command names all must start with "-", and can take up to 2 parameters of any types). (Of course, these features do not work with mainstream MegaZeux.)

[Exophase]

Nobody wants to use Forth (except you of course). Saying anything is faster than the current Robotic implementation is like saying there are ways to count from 1 to 10 that don't involve negative numbers.

The debytecode path eventually intended for macros in the form of custom commands, which would make implementing things like loop control structures trivial (assuming simple support for generating unique labels and whatever). Separating bytecode from source code was the most crucial step in this, hence the name of the effort, and that was the part accomplished. Anything that didn't take this initial step would be an ever increasing kludge and implementation and performance compromise - I imagine even your modifications added overhead because of this.

[Exophase]

Lachesis, on 25 August 2010 - 09:29 AM, said:

have you used "|"

Both of us have used single character names with edited characters denoting the identifier (sometimes with pretty pictures!) and suffice it to say that the pipe character isn't exactly important in Robotic ;p

[zzo38]

Exophase, on 25 August 2010 - 09:00 PM, said:

Anything that didn't take this initial step would be an ever increasing kludge and implementation and performance compromise - I imagine even your modifications added overhead because of this.

They did add slight overhead (hardly noticeable, since they don't do things many times per cycle) (also, most of it can be avoided by writing Forth codes that properly clean up the dictionary), but a lot of the overhead is stuff that is already there, due to even normal MegaZeux requiring many counter name lookups every cycle (which slows down the game the more counters are used, and with Forth codes, the names are no longer needed after the Forth code is loaded, which makes it faster), and these counter name lookups required by normal MegaZeux could be fixed by storing LIVES and HEALTH and so on in direct fields of the world structure instead of in counters. These are the counters which are probably most often accessed by internal MegaZeux codes: "TIME", "LIVES", "HEALTH", "INVINCO", "BLIND_ADDRESS" (fixing this would greatly increase the performance, something I didn't do yet, but my next version might fix this feature (and I do know about the gateway counters, so I will remember to fix that part of it too)). Therefore, in conclusion, my modifications actually make the game faster, not slower. (I have also removed various useless conditions and stuff like that.) I never intended to replace Robotic codes, and I don't plan to (currently Robotic codes are the only way to display message boxes with colors and choices and all that stuff, and I do not think it is needed to change that). Robotic codes are still good for many things, but not everything. It is intended that if you have a few kinds of new pieces which are found all everywhere, that you can implement them in Forth, increasing performance, saving robot memory (due to the limit of 255 robots per board), improving accuracy, making the program easier to maintain, and various other benefits. These are the reasons why the overhead added by my modifications is not significant.

This post has been edited by zzo38: 26 August 2010 - 07:37 AM

[Exophase]

Yes, I'm sure you've benchmarked the results and everything proving your intuition that looking up those builtin counters is a lot more overhead than stuff that's added to command parsing - no wait, no you didn't. At any rate, this doesn't really have anything to do with what I said. Yeah you can pick at things to improve but it's not an awful lot like it'd be if you a) decoupled the source representation from its machine representation b) did a much better machine representation and c) did a much better VM implementation of said machine representation. Saying it's faster because you're spending all your time executing Forth instead isn't really here nor there. No one (else) wants to use Forth, they want Robotic to suck less.

[zzo38]

Exophase, on 26 August 2010 - 06:53 PM, said:

Yes, I'm sure you've benchmarked the results and everything proving your intuition that looking up those builtin counters is a lot more overhead than stuff that's added to command parsing - no wait, no you didn't.

Actually I have benchmarked these things (I haven't used any proper benchmarking software, but I have done actual tests, and the results might not be perfectly accurate but the main idea is still the same, even if the precise numbers aren't). (I don't know if you have even seen my modifications to the C codes in MegaZeux. I haven't even added a lot of things to command parsing, Forth is also a separate VM from Robotic, so they do not affect each other, and even the things I did add certainly do not add as much overhead than looking up the builtin counters. A Forth VM is actually very efficient.)

Quote

At any rate, this doesn't really have anything to do with what I said.

OK. You are correct about that. But it is something you seem to have disregarded. The counter lookups in the internal game loop do add some overhead.

Quote

Yeah you can pick at things to improve.....

Many of the things I mentioned have to do with the internal game loop in MegaZeux, and not with Robotic codes.

Quote

a) decoupled the source representation from its machine representation b) did a much better machine representation

You would be right, that is what debytecode is supposted to do, isn't it? One of the things that might be useful to fix is having it parse expressions ahead of time. An optimizer could also be added, if you want to.

Quote

c) did a much better VM implementation of said machine representation.

I do agree that the current Robotic VM isn't very good. But changing it to a different implementation might mess up various things, and cause some games to work differently, and incorrectly. But you can still try, in case it might be done accurately enough that it doesn't matter.

Quote

Saying it's faster because you're spending all your time executing Forth instead isn't really here nor there.

It is faster than Robotic, I didn't say it was faster than MegaZeux! C codes will certainly run faster.

Quote

No one (else) wants to use Forth, they want Robotic to suck less.

Fair enough. I wasn't complaining about debytecode or about anything else, and there is nothing wrong with anyone wanting Robotic to suck less, or that nobody else wants to use Forth (there may be very few other people who want to use Forth, but it isn't only me) (and it is certainly possible to have programs to convert something else into Forth, too, if someone wants to do that, but of course they probably don't, so therefore it is probably irrelevant).

[Exophase]

Debytecode does parse expressions ahead of time (in the robot editor), it doesn't generate bytecode if the expressions are malformed. They're still stored as expressions which the robot VM still has to parse, but since they're already verified a lot of assumptions are made, plus they're stripped of whitespace and stuff. This was only really done since I had to rewrite the runtime for it anyway, I wasn't really trying to improve performance although it probably does a little anyway. The eventual goal of course was a much better bytecode and compiler. I don't think maintaining compatibility (aside from perhaps a few really explicit and deliberate edge cases that can be dealt with if they exist in games) would be that bad, 2.80+ itself managed okay (eventually) despite having a lot of rewrite and reimplementation.

Other people certainly want to use Forth, just not in MZX ;p

[allison]

XRNS support. XRNS is a tracker file such as S3M, MOD, XM, etc. and is for the tracker Renoise.

[mzxgiant]

crazyal02, on 01 September 2010 - 11:43 AM, said:

XRNS support. XRNS is a tracker file such as S3M, MOD, XM, etc. and is for the tracker Renoise.

what kind of halfassed leaving forever is that :confused:/>

[ajs]

I had a brief look at the format, mostly out of curiosity. There's multiple technical reasons why I wouldn't even attempt to implement it.

Though it supports Ogg Vorbis and raw PCM samples (both things MZX supports already), by default samples are compressed with FLAC. This would require me to add a dependency on libFLAC, which is a non-trivial library (~300K for the Linux binary), or require people to manually repack their XRNS files with Ogg Vorbis samples.

The rest of the file format is contained in an XML document. While things could be worse, parsing XML would probably require an XML library which I'd be reluctant to add at this stage. There's also no XML-DTD I can find for XRNS documents, so there's no easy way to validate them. There's no documentation or schema for the XRNS XML document.

As Lancer alluded to on the other thread, supporting XRNS fully would be more difficult than other historical module formats. This is primarily due to Renoise's ability to load and use VSTs and similar audio plugins, which is stored abstractly in the XRNS document. Implementing 100% Renoise compatibility would be a big job, and may well be impossible to do portably.

--ajs.

[Old-Sckool]

How about XML support?