MLC: Multi-Platform Language for Calcs

[kalan_vod]

ok i checked out these games out on vti and its relly cool, it runs pretty fast campared to basic. :p gj keep up the work

[the_unknown_one]

Well said Crimson Couldnt have said it better

[dysfunction]

I'm not sure if anyone's brought this up, but not only does the 83 have far inferior processing power, it also has only emulated greyscale- which slows it down a lot. The 86 and higher models of TI have an actual 4-color screen, and I assume so does the AFX and other high-end Casios. However, the 83/+/SE requires greyscale emulation, which drastically lowers performance. Are you sure greyscale MLC will even be possible on 83?

[kv83]

I'm not sure if anyone's brought this up, but not only does the 83 have far inferior processing power, it also has only emulated greyscale- which slows it down a lot. The 86 and higher models of TI have an actual 4-color screen, and I assume so does the AFX and other high-end Casios. However, the 83/+/SE requires greyscale emulation, which drastically lowers performance. Are you sure greyscale MLC will even be possible on 83?

Also I wonder how this will work on the ti-83+, cause your documentation says:

|| The run speed on some calcs has also
|| been artificially dropped to match the lowest speed
|| we've done this to make sure all games run equally
|| well on all calcs.

This means that, as far as I can predit that, ti-83+ should be one of those minimum calcs. Conclusion of that is that you have either to speed down all other calcs, or step away from the above statement.

[Duck]

The TI86 does not have a 'true' grayscale screen. The gameboy has true grayscale meaning that its screen physically consists of two layers: a lightgray and a darkgray layer.

On the TI86, grayscale is much faster though since it has a memory-mapped display; swapping between the two buffers is as easy as changing a pointer. This pointer-swapping is done by the interrupt.

The TI83 models do not have a memory-mapped display; the data has to be put through the LCD port manually by for example ionFastCopy. To achieve grayscale, the interrrupt must output one of the two buffers to the LCD. This takes kind of long. But because this is done manually anyway, GPP uses the 'wasted clocks' to blend the two buffers in special way and makes it look a lot less flickery. The TI86 grayscale does not do blending so it should in theory look more flickery and ugly. I have never seen TI86 grayscale in real-life before so I dont know for sure how does looks.

Dysfunction: I'm having the same speed concerns as you have; thats why I asked about the speed on the ti86. I think that only if the TI86 is able to run the games at >200% of their required speed, it will be possible to run the games fast enough on the TI83.

[kv83]

Speed is defently a main concern on the ti83 series. especially if you take grayscale and a 'on-the-flow' interpreted language like MCL should be. Pure asm can take grayscale games in real-time (Desolate, Zelda demo). Theorticlay MLC is on the same level as Basic. Though MLC is a little bit faster because it doesn't debug the code 'on-the-flow' like basic does, I think that it won't be able to produce such games on the ti-83series:


Multiple scrolling objects in grayscale is a huge step. Even in asm it's not (really) fast enough to do such things. Look at Desolate, which has to fight the speed limits already...

Maybe you should rethink the whole concept and use B/W graphics for the 83 series instead of grayscale... it would be much more doable

[Duck]

Monochrome graphics would indeed be much more doable. Maybe its better to forget grayscale until there's an incredibly fast engine. A bytecode interpreter would be much faster then a source interpreter to begin with.

[DJ_O]

Maybe you could only use 3 level grayscale and use the method of using a 64x96 mask switching back and forth pixels that must be gray in the same way than my BASIC grayscale trick. Here is an example of what it does with codex in VTI (notice the pattern):



With my omnicalc trick the gray pixel are inverted 25 times per second on my SE so in MLC it might be a lot faster

[Duck]

From what I understand of this, you're using a mask to generate a checkered pattern (/blending)? This wont speed up GPP's interrupt since its already as fast as it the LCD driver can handle: ~65 clocks per outputted byte. Speeding it up more would choke the LCD driver.

[DJ_O]

So basically I think it would be better to not have grayscale at all. That way, games will run fast on all calc model and MLC will be easier to complete. You can make good gfx in b&w graphics. Also games will be smaller without grayscale.

[Duck]

Well, there is a theoretical method of very fast grayscale
Let the upper part of the screen (row 0 to 31) be the darkgray buffer. Let the lower part of the screen be the lightgray buffer. Then let the interrupt change the LCD Z-value between 0 and 32. Tape off the lower part of the screen... and voila!

[CrimsonCasio]

duck, im not sure if your aware of this, but MLC does interperate bytecode, before running a program it translates it into bytecode, then runs it (some basic error checking is also done at this point), thats why its faster than basic (well, thats one reason). of course the source code isnt effected

from what your saying, if nessicary i guess we could blend the grays on MLC83 so that there is only one gray level... but that could cause some problems with compatibility (not just with how things look, some programs look for pixels of a specific color)...

i really cant speak to the speed stuff... though the copter demo on the afx is somewhat slow (quickly fixed by making things move more than one pixle at a time...), its an extreamly simple game and can handle all that movement because thats all it does. look at bounce for a balenced MLC game (no more than 3 moving objects at a time)

[Duck]

No, I was not aware of the fact it was converted to bytecode. Good. Do you know how the size of this bytecode compares with the size of the source?

If grayscale buffers are needed for grayscale pixel checking, just leave the buffers as they are and just output to screen in monochrome.

Has anyone checked how fast "Bounce" runs on the TI86? If its so simple (with just three moving objects), it may be fast enough for grayscale on the TI83(+). But lets stop hypothyzing and wait until the programmers who said they will do it start on the ti83(+) port... We've seen nothing yet.

[kalan_vod]

i checked out bounce and it runs almost like asm

[CrimsonCasio]

no, i dont believe we've ever compared it... but it should be considerably smaller, considering that each command takes up 5 bytes, when translated to bycode it should take only 1 or 2...

thats surely a possibility... though it would still be strange
i guess we could enable display modes if need be (mono/color).

gimpynerd just signed on to help with MLC83, so im hoping to see a bit of progress now

@kalan_vod: thanks, bounce actually has room to run faster, but i left it some wiggle room so that i could potentially add new things and/or have difficulty modes. also, nobody but me has beat the 2nd level... so i think that it would be a bad idea to speed it up...