[LogiCow]

StarbladeEnkai, on Aug 25 2008, 03:45 PM, said:

Has someone mentioned "copying between vlayer and overlay" yet?

Copy overlay block at 1 1 for 1 1 to "#1" "#1"


if I'm not mistaken

[Terryn]

That's overlay to vlayer; to reverse, it's COPY OVERLAY BLOCK at "#1" "#1" for 1 1 to 1 1 instead.

[Koji]

You know what might potentially be pretty cool, a simple LISP like interpreter built into the expressions. You could represent any created function as a string. You'd be able to do so much more in one expression and it would finally add user level customizable functions to mzx.

[Exophase]

Koji, on Sep 4 2008, 01:02 PM, said:

You know what might potentially be pretty cool, a simple LISP like interpreter built into the expressions. You could represent any created function as a string. You'd be able to do so much more in one expression and it would finally add user level customizable functions to mzx.

Yeah, Lua isn't obscure enough, let's get people to write in Lisp for robots.

You CAN'T ADD FUNCTIONS to Robotic with the current bytecode, if you could I would have done so already.

[Seventh Shade]

Man, I'd just settle for a counter that let you set background color fading to certain percentage. Set BackFade to 50 would fade the background colors of characters to 50% brightness. It'd be a cheap, quick, hacky way to get more colors.

And, holy god, I want more characters. But that's for a later era of megazeux I guess.

[Pyro1588]

Seventh Shade, on Sep 4 2008, 08:21 PM, said:

Man, I'd just settle for a counter that let you set background color fading to certain percentage. Set BackFade to 50 would fade the background colors of characters to 50% brightness. It'd be a cheap, quick, hacky way to get more colors.

And, holy god, I want more characters. But that's for a later era of megazeux I guess.

actually this sounds like a really nifty idea. it could be a pretty useful color hack. heck, if we could possibly implement it for each of the 16 colors (and possibly a foreground fade,) it'd be the epitome of nifty.

i admit, however, that i've got no idea how simple it would be...

[Koji]

Actually after thinking about it yeah Exo you're right, people are already trying to implement other languages into mzx and it's all a kludge Lisp would be just as bad in all likely hood.

However, do you think we could implement some way to define a string that when called would be evaluated with the expression routine? something like

Set "$func" to "func('var1' + 'var2' / 2)"

would set $func without evaluating the expression (because it is preceded with "func" or some other special chars to denote this feature), but when the string was called, it would return the evaluation of the expression.

Is this something that would be doable and seen as a worth while feature?

Another idea I know others have had was allowing an expression to set a counter independent of the counter it's to be evaluated to.

Using these features in conjunction you could create rudimentary functions using two lines of robotic code to call them with multiple value passing.

Eg.

set "$func" to "func('var1' + 'var2)"
...
...
set "t" to "((set 'var1' 10) & (set 'var2' 4))"
. "operations return 1 if successful 0 if fail"
set "return" to "$func"

Its less of a kludge than implementing forth lua or lisp. I don't know if it's enough to say that this would replace the want for these languages in mzx but I think it would be a cool addition nonetheless.

[Exophase]

If it were possible to correctly do functions then that's not how I would do them, it'd have been more simply something like:

: "#sub@('a1', 'a2')"
goto "#return@('a1' + 'a2')"

set "x" "('y' + '#sub@(1, 2)')"

The reason why it's not compatible with the current bytecode is because expressions aren't compiled. You can't return into the middle of an expression.

Actually, now that I think about it, your idea would have been a pretty simple to implement hack. But not really in the way you're saying it, more like:

set "$expr" "lit('x' + 'y')"
set "z" "eval&$expr&"

Where lit would force the strong to be encoded literally (not evaluated at all), and eval would force the string to be evaluated twice. Then you could easily do what you're saying, and it wouldn't be much of a hack on top of MZX. That's actually an annoyingly good idea and I'm angry at myself for not having thought of it >_<

But, it's not like expressions would have the capabilities Robotic does in its entirety, nor should they. It'd be possible to add something to compile actual Robotic code but I don't think I'd want to go there.

[Koji]

Actually after some thought experimentation today I discovered that this idea is deceptively good. Things could actually get hairy if someone tried to implement a recursive mathematical expression using these "functions". The Expression evaluator would constantly be seeking to the deepest parenthesis which it would never find

for example:
set "$expr" to "lit((inc 'temp' 1)('temp'<'n')('temp'+'eval&$expr&'))"
. "returns the sum of the numbers 0 to n"
. "or something

If this were going to be made possible, It would be a terrible source of bugs, namely the infinite expandability of this expression due to nesting the expression within itself. The only way to negate this would be for MZX to detect or predict when 'r'<10 would be 0 and thus stop evaluation because anything in parenthesis after that would end up being 0.

"Thus I have shot myself in the foot and stolen my own digital watch"

[Exophase]

Such recursion is quite deliberate though, I don't think it'd be a horrible problem to allow it to go through, although it would probably break MZX games entirely if they tried that (but so does setting commands super high then entering an infinite loop so I think this is somewhat moot)

On the other hand, if short circuiting was done for the OR and AND operators you could pull off recursion usefully.

[Koji]

so is this something that we could look forward to or is this all just hypothetical musings?

EDIT: another thought I had recently was having a special set of counter that would be connected with this idea of functions called $arg.x nnd arg.x where x would be the ordered numbering of the arguments passed. Counters AND Strings because then the programmer has a choice of which format they want to pass without having to add much more to mzx in order to differentiate. Thus you could make a "function" using the Lit and Eval functions

set "$expr" to "lit('arg.0' + 'arg.1)"

set "local" to "&func('eval('expr')')(0)(1)&"

where the func function takes in a literal expression which in this case is an eval call to a string set to a literal, and a set of values separated by into parentheses that are copied into the $arg.x string, and and arg.x counter.

Then of course we could forget the short circuiting of the And's and Or's if we implimented a list style If construct into expressions.

The Lisp If construct is pretty straight forward (if ([condition]) ([then]) ([else]))

set "$sum" to "lit(if (arg.0 > 0) ('arg.1' + 'func('eval('$sum')')('arg.0'-1)('arg.1'+1)') (0))"
. "function made to find the sum of 0 to 'i'"
. "usage 'func('eval('$sum')')('i')(0)'"

This would provide a much safer version of the if statement than the rudimentary logical one I used in the previous post, thus the expression isn't necessarily evaluated infinitely.

This post has been edited by Koji: 07 September 2008 - 09:04 PM

[Koji]

I ran out of time to edit and wanted to change things so here:

EDIT: another thought I had recently was having a special set of counter that would be connected with this idea of functions called $arg.x and arg.x where x would be the ordered numbering of the arguments passed. The counter string duality of each argument would be the simplest way I can think of to make this able to define functions that take in any number and combination of counters and strings without having to add too much to mzx's expressions as they are. Thus you could make a "function" using the Lit and Eval functions

set "$expr" to "$lit('arg.0' + 'arg.1')"

set "local" to "func&$expr&.(0).(1)"

where the func counter takes in a literal expression which in this case is an call to a string set to a literal, and a set of values separated by periods, the args are copied into the arg.x strings, and counters. Then the literal expression is evaluated.

Then of course we could forget the short circuiting of the And's and Or's if we implemented a lisp style If construct into expressions.

The Lisp If construct is pretty straight forward if ([condition]) ([then]) ([else]), but of course the else part is optional in lisp.

set "$sum" to "$lit('if(arg.0 > 0).&$lit('arg.1' + 'func&$sum&.('arg.0' - 1).('arg.1' + 1)')&.0')"
. "function made to find the sum of 0 to 'i'"
. "usage 'func&$sum&.('i').0'"

if would effectively be another counter command that would be like "if[bool].[literal expression 1].[literal expression 2]" depending on Bool one of the two literal expressions are evaluated.

Also another String Counter duality might serve well. someone programming could specify that the return from the if is a string by calling the $if[...] instead of the if[...].

This would provide a much safer version of the if statement than the rudimentary logical one I used in the previous post, thus the expression isn't necessarily evaluated infinitely...

This post has been edited by Koji: 07 September 2008 - 09:54 PM

[Wervyn]

Alright, this really needs to stop right here. MZX does NOT need functions implemented like this. It helps no one, accomplishes nothing that can't be done already, and substitutes another ugly hack in place of introducing what MZX actually NEEDS, which is real program flow control structures. As much as I enjoy packing if statements into complex conditional expressions, it is simply the most retarded idea ever to force people to define functions in a single inscrutable line inside of an unformated string. The most it really makes sense to do for this is to double evaluate strings, which is something I've thought would be kind of nice myself. We don't need expressions to be more complicated than they already are. If you really must implement recursion, do it yourself in robotic, instead of polluting the expression syntax like this.

"MZX needs a program stack and a frame pointer counter."

[Koji]

okay maybe the if was a bit to much. ^^;

[RyanThunder]

If this doesn't exist somewhere already, what I'd really like to see in the future is a "play only" version of MegaZeux, which would basically be MegaZeux minus the editor. The "config.txt" file would have to be edited too and omitting all configuration functions except for the ones required for play (i.e. graphic options, joypad options, etc.).

This sounds kind of stupid at first, but you would be able to share your work with friends, relatives, and gaming sites in a much easier way, since you could give it to anybody as one, stand-alone package.

I know they are ways to work-around MegaZeux to make it look like your .MZX file stands on its own, but I just think this would be convenient overall.

EDIT: Eh, come to think of it, I guess I don't really mind it that much. I just thought it would make your game look more formal without the editor in it.

This post has been edited by RyanThunder: 08 October 2008 - 11:49 PM

[Terryn]

RyanThunder, MZX used to have that in the past. It was called MZXRun. One can compile up versions of MZX that act the same right now (the editor is a compile-time option) but we're working on making an MZXRun-type build official again and in a far easier way than having to compile the editor out. It'll almost assuredly be done for 2.82b.

[RyanThunder]

Terryn, on Oct 8 2008, 08:45 PM, said:

RyanThunder, MZX used to have that in the past. It was called MZXRun. One can compile up versions of MZX that act the same right now (the editor is a compile-time option) but we're working on making an MZXRun-type build official again and in a far easier way than having to compile the editor out. It'll almost assuredly be done for 2.82b.

Ah, yes, I could have sowrn MegaZeux used to have that feature, and I suppose I was right! But anyway, that is excellent to hear and I'll definitely be looking forward to it!

[RyanThunder]

Another convenient little feature would be a speed variable on the SCROLL CHAR command. For example:

scroll char 'C' to EAST for 6

A command like this would scroll the char 'C' to the right at the speed of 6. This would shave off a tiny bit of coding time instead of issuing the SCROLL CHAR command multiple times.

This post has been edited by RyanThunder: 12 October 2008 - 02:07 AM

[Lachesis]

loop start
scroll char 'C' EAST
loop 5

[RyanThunder]

That code will only scroll 'C' to EAST for 5 cycles and end. I'm talking about the speed at which it scrolls at.

This post has been edited by RyanThunder: 12 October 2008 - 06:47 PM

[Lachesis]

It executes "scroll char 'C' EAST' six times, and the way I remember it, the command doesn't use a cycle.

[Terryn]

The loop number is a bit of a misnomer. You see, MZX executes the loop at least once before hitting "loop for #". Instead of how most people assume that the first pass is part of that number, it's on top of that number.

[LogiCow]

Could we use a function to load a file into a string and vice-versa?

Set "$string" to "write_to_file_blah.txt"
Set "$string" to "load_from_file_blah.txt"

I wouldn't use it but it might simplify things for some. I don't know.

[Exophase]

LogiCow, on Oct 29 2008, 06:22 PM, said:

Could we use a function to load a file into a string and vice-versa?

Set "$string" to "write_to_file_blah.txt"
Set "$string" to "load_from_file_blah.txt"

I wouldn't use it but it might simplify things for some. I don't know.

Lame.

set "blah.txt" "fopen_read"
set "fread_pos" -1
set "file_size" "fread_pos"
set "fread_pos" 0
set "$string" "fread&fread_pos&"

[Dr Lancer-X]

Exophase, on Oct 30 2008, 11:20 AM, said:

Lame.

set "blah.txt" "fopen_read"
set "fread_pos" -1
set "file_size" "fread_pos"
set "fread_pos" 0
set "$string" "fread&fread_pos&"

Lame.

set "blah.txt" "fread_open"
set "$string" "fread(2<<24)"


(oh, and 'fread_open' instead of 'fopen_read', and you should use the 'file_size' counter in the fread command, otherwise it won't work)

[Kom]

I'd like to be able to swap worlds with mzx games within megazeux's subdirectories, that doesn't seem to ever work for me

[Terryn]

You mean from a world to another world in a subdirectory (relative to the first world)? You can do that just fine!

SWAP WORLD "subdir/target.mzx"

The working dir swaps along with the world, so going back to the original world is impossible, but it makes referencing things in the new world as painless as one should expect.

[Exophase]

Lancer-X, on Oct 30 2008, 04:47 AM, said:

Lame.

set "blah.txt" "fread_open"
set "$string" "fread(2<<24)"


(oh, and 'fread_open' instead of 'fopen_read', and you should use the 'file_size' counter in the fread command, otherwise it won't work)

That method is silly. You're silly. But yes, thanks for fixing my mistakes ;P

[Kom]

Terryn, on Nov 16 2008, 01:59 PM, said:

You mean from a world to another world in a subdirectory (relative to the first world)? You can do that just fine!

SWAP WORLD "subdir/target.mzx"

The working dir swaps along with the world, so going back to the original world is impossible, but it makes referencing things in the new world as painless as one should expect.

That wasn't working for me at all though. I'll have to try it again i guess.

I had another idea though, being able to drag and drop mzx games onto the executable to load them automatically.

EDIT: i guess i must have been doing it wrong, it worked fine this time.

This post has been edited by Kom: 17 November 2008 - 02:09 AM

[paulguy]

I'm pretty sure you can associate files with MZX, but you need to make sure the MZX files are in MZX's directory or else it wont find it's files. it requires some manual editing, since it requires a command line argument to open with a file. To open on files dragged to it, I'm not sure. That might just work automatically with the association.