19 replies to this topic

[huhn_m]

Please write down suggestions here. See the other topic for the rules!

[huhn_m]

forum is open now ... the auto open option does not seem to work

[huhn_m]

1) The Editor is able to save files to flash directly and load them from there as well.
2) The interpreter will also load programs from regular flash drivers. So yes it is possible
3) Categories ... this is difficult. maybe, maybe not lets see ...

However, all these things are far down the list of things to do. First we need the MLC2 interpreter to run all things reliably from where they run now. The editor is LOWEST priority and is currently only developed when I am stuck with the interpreter / compiler. So you will see none of these in the near future. I don't expect the first usable editor to appear before june.

[burntfuse]

I think MLC2 needs a command to check if a certain key is pressed (not just returning the code of the current key that's pressed). We had one like that in the old MLC, and it was ESSENTIAL for games, so that someone could hold down one of the arrow keys and the fire key at the same time, for example. Maybe something like this?

CKEY [key name],[int var]
Check if [key name] is pressed, if not, set [int var] to 0, otherwise set [int var] to 1.

Also, on an unrelated subject, when is the list of standard key names going to be released? The '86 interpreter is getting close enough to being usable that I need to test it with some programs. Should I get it from the MLC2 source?

[huhn_m]

hm ... you are right. I will probably use IsKey (#IKEY) as the command.
So you can do #IKEY "FIRE",*%IsFire
and then check if *%IsFire is 1.

And for the list of standard keys:

FIRE
LEFT
RIGHT
UP
DOWN
JUMP
SELECT
ALT-FIRE
ALPHA

Also some keys like the alpha keys may have double meaning.
However so alpha is the Modifier key. If pressed (or locked, probably with #LOCK "ALPHA") then you can check for the alpha keys so:

#FNCT MAIN 
  #IKEY "ALPHA",*%IsAlpha
  #IIFF *%IsAlpha,HandleAlpha
  #IIFF *%IsAlpha!1,HandleAdvanced
#FEND

#FNCT HandleAlpha
   #IKEY "A",*%Alpha
   #IIFF %Alpha,InsertAFunction
#FEND

#FNCT HandleAdvanced
  #IKEY "FIRE",*%Fire
  #IIFF *%Fire,FireFunction
#FEND

This way alpha and a can be assigned to the same keys and are then differed by the different modifiers. The LOCK command would make ALPHA always return 1.

However, I think this still needs some thought. I also am far from a usable version. There is no thing to handle sprites, events or the mouse. I maybe change the keyboard system again. However, I first want to have the graphics engine running. I prefer a beta to be unusable for real game programming since the beta is not intended for this. Version 0.3 will include some major changes and so will not be compatible to version 0.2 source code. Please be patinet. I will make a statement to the keyboard system probably by the end of the comming week. Sorry. (PS: For further discussion please start a new thread)

[SRM]

It is exactly how GKEY runs. So why do you want to add IKEY ?
When do you think the next beta will be released ?

[huhn_m]

No. It is not how GKEY runs. GKEY does only work if 1 key is pressed.
This would also work if multiple are.

However, I think you're right but in another aspect. I already thought about it and it seems that I will make the keycodes (that hide behind the names) "multi key" this means that "SHIFT+LEFT" can be assigned to an action by the user making the IKEY command obsolete.

Thanks.

[SRM]

Ok. I meant that if you want to press multi keys, you can do :

GKEY "alpha",%alpha
GKEY "fire",%fire
IIFF %alpha*%fire,"bomb"
...

FNCT bomb
boom

But if we can put multi keys in the KAT, it's better !!



One question about arrays :
Will they be static or dynamic ?
I like the way it's used in basic with lists : you define a dimension, and after, if you exceed that dimension, the dimension is extended by one. So you can do so easily : 5->List 1[1+Dim List 1]
Will it be possible to do something as easy as this ? It's not necessary, but would be usefull.
In the same way, if we could delete one line, it could be as usefull :

KILL @List 1(2)

This would delete the line 2 of the array @List 1. And then put the line 3 in place of the line 2. For exemple :

@Array(0)=0
@Array(1)=1
@Array(2)=2
@Array(3)=3

KILL @Array(2)

@Array would become:
@Array(0)=0
@Array(1)=1
@Array(2)=3

Then if you do : @Array(5)=1
@Array would become:
@Array(0)=0
@Array(1)=1
@Array(2)=3
@Array(3)=0
@Array(4)=0
@Array(5)=1

Could we start Arrays at @Array(1) for the first line, or is it necessary to start at @Array(0) ?

[huhn_m]

arrays are way down the list and while the feature of extending is nice it bears the risk of unintentionally writing to big elements. I'd rather prefer range checking instead.

And GKEY has this syntax;

GKEY <KeyVariable>

so it does return the key value.

[SRM]

You're right, there's a risk to overflow the calc capacities. However, the programmer have to be carefull writting his programs. If he writes too big elements then that means there's a bug. So the programmer has to check his program. If the program is well done, there's no reason to not add those features. We just have to prevent people to be carefull with limitations. I think if the program doesn't have bugs, those commands could optimize programs a lot, on the both hands : program size and memory.

If you think I'm right, two commands are usefull too (I've got no idea how to write the command) : Dim, and is exist ?
I know there's a function to define arrays dimension, but if we can change it, it would be usefull to ask to the calc the new dimension, like in basic (exemple : Dim List 1->A). Moreover, if we ask the dimension of an array that doesn't already exist, the interpreter would give an error. So, a command that ask if an array exist would be nice. This would help to load saved games.

Perhaps you could add an utilities at the end of the programs's execution that would determine the free memory size left. So, programmers could easily know how much space is free. It's very helpfull when you don't know how much bitmaps you can add, or arrays, or functions, ...


Sorry about GKEY, I used the MLC 1 syntax. So, well, I better see the use of IKEY : it's the same command than the GKEY of MLC 1 !! I let you choose what is best.

[huhn_m]

the number of elements of an array can be determined with the SIZE command. this (probably) will be the only "overloaded" command, that supports multiple parameter types.

As for range checking: I agree that it would be usefull. However I think we should also create a Flag to set range checking or to extend the array automagically.

like:

#FLAG RangeCheck On

or:

#FLAG LeadingZeros Off

for the leading zeros example of the other topic. I think this feature would be nice to have (sort of a compiler flag thing ...)Arrays are realized by the compiler and not the interpreter anyways so dynamic arrays would only blow the compiler not the interpreter.

Checking if an array exists could be done by the SIZE command returning 0 as the elements size. This would be valid for all types.

However, Integers are automatically created and initialized with 0.
Strings, however, are not, but are used with forward referencing (3rd pass determines if the string does exist at all)

[huhn_m]

Thanks for your interrest in the project!

Works fine till now. Nearly everything needed for beta3 is implemented. However, I need to rewrite some part of the string handing since the
current version doesn't work as I wanted it (failure on my side). I can not say when I finish it. Only that it'll be soon. I'm quite busy some times....

[SRM]

I asked a friend how random functions are created on PC. He told me it's a function of the PC time clock (I don't know more). I hope it'll help you to design it.

News about beta 3R2 ? Perhaps you should release it now so we can continue to test more.

[huhn_m]

I will release the Beta 3R2 tomorrow, regardless of status:

Folowing fixes have been done:

Added VM Setup menu (AC/On Key)
Added Restart Program point to the VM Setup menu
Added Terminate MLC2 point to the VM Setup menu
Fixed 0 not displaying as white but as transparent
Fixed white printing
Fixed rectangles printing slow/wrong when x0 > x1 or y0 > y1
Fixed mouse bound checking that was missing from previsous release
Fixed mouse_Flag reset that lead to program "remembering" mouse press
Fixed Integer conversion routine not working correctly for 256 - 999
Introduced overflow handler, not yet working
Initial support for negative numbers

Its not much but it's a start. What I have not been able to fix yet is that the program hangs after pressing the Abort Button 10 times. The stacks seem to be fine so it seems to be a problem of the VM itsself.

[alias4399]

Suggestion: Discover whether MLC2 is compatible with CFX-9860G ? If not, perhaps make it compatible ?...

[huhn_m]

I'm quite sure that it is not compatible and would need to be ported but who knows

[alias4399]

I know how to do random numbers! And yes, it does involve system time. First, call a function that returns an integer value of the system's current time, then call modulus operator on it and add one.

random_number = (time() % 3)+1, which will generate a random number from 1-3.

if time = 3, random_number will be 1.
if time = 4, random_number will be 2.
if time = 5, random_number will be 3.
if time = 6, random_number will be 1.

Simple

[huhn_m]

thanks.