MaxCoderz.org

Wow that's insanely fast. Where's a link for download?

Nowhere... heh. I just randomly had that screenshot from way back when...

Edit: Also, I'm guessing it was recorded in 15MHz, whereas Ben's was probably 6MHz.

By not clearing and only drawing the head/(erasing) the tail instead of keeping a list of all elements, you can speed it up considerably. Im assuming thats what calc has done. Very nice btw.

Very nice screenshot, calc84maniac.

That's what I do, at any rate; a ring buffer with a pointer to the "head" element some way ahead of the "tail" element. Normally the head and tail pointers move forwards together, but to elongate the snake you can move the head pointer forwards and leave the tail pointer where it was.

As the game world is 24x16 units where each block is either "on" or "off" I use a 48 byte buffer (one bit per block) instead of a 1536 byte 24x16 array. This additional bit manipulation -
- probably does little for speed but it reduces memory concerns somewhat.

In a similar vein the longest snake would be 24x16 units long, and with an X and Y component for each you'd end up with a 3072 byte array, so I instead use a 768 byte buffer.

My screenshot was recorded at 15MHz, but I tried to get speed 9 roughly the same on both. (Last time I checked it played about as fast at 6MHz). You can make it run faster on an SE by removing the delay between frames entirely (currently capped at 3 centiseconds, ie 30ms) which is stored in the static variable S%:
The game runs in the Windows version of BBC BASIC (where I originally developed it) if you can't be bothered to send it to your calculator.

Wow!
This is looking great. It makes me feel like I want to learn BBC Basic, but time will not permit... This is really coming along great, Ben.
Aren't you making a documentation on how to use BBC Basic and some coding?
Keep up the good work.

I'm afraid I don't really go in for tutorials - most of my learning is from reference material and examples. I could try writing a tutorial but for the reasons above I don't think it would be very good.

There's always the BBC BASIC for Windows documentation, but I have not yet checked it myself to see how different it is.

Yes, Ben has a nice looking help document with the apps for the calc. I will try this BASIC sometime... It is a new field in calc dev.

EDIT: you are right Ben. It is more documentation of commands. =/ We can solve that solve that. And making update advanced TI-BASIC stuff like grayscale and others would be nice, too. =P

As you may have noticed there aren't many MODE numbers allocated so in theory it may be possible to create a greyscale mode. The main issue there is runtime memory (as it would require three additional screen buffers, and memory is tight enough as it is). I'd personally rather work on getting the existing graphics commands up to scratch first!

I say using the TI-BASIC+lib method would be feasable, xor'ing screen images every frame instead of a full blow interrupt driven implementation.

I started making a small map demo, ill let you know how it goes .

What may be useful would be a way to select the buffer that drawing operations write to. That way you could DIM some space on the heap and use that as your second buffer; all you'd then need to do would be to swap this buffer and the regular plotsscreen and call *REFRESH to repaint the LCD.

Is there a way to write small sized text to the screen while in Mode 4?

Not currently, and I don't think it would ever be possible in VDU 4 (text fits in a grid fixed), but it would be possible in VDU 5 (text is drawn at the graphics cursor location) with an additional command. Good idea, I'll add it.

The new version adds two features. Possibly the most useful is *FONT, which allows you to switch between SMALL and LARGE font sizes when used with VDU 5.

The other main new feature is the rather dangerous *GBUF, which lets you reposition the graphics buffer. A flickery greyscale demo follows:

A rather nasty crashing bug has also been fixed (scrolling a one row high text viewport which doesn't fill the width of the screen used to trigger an instant crash).

Edit: There is a mistake in the documentation. buf%=HIMEM:HIMEM=HIMEM-768 would place buf% above the old value of HIMEM. You want to place buf% above the new value of HIMEM, ie HIMEM=HIMEM-768:buf%=HIMEM.

Fortunately BBC BASIC has the 2KB user-definable character buffer above HIMEM anyway so all you'll end up doing is overwriting these characters rather than crashing the calculator. I'll fix the docs in the next version.

The new version contains amended documentation and one minor feature; the Clear button now generates ASCII ESC (27) - the same as the On key when *ESC OFF has been used.

Nice program, but (on the TiLem emu, fortunately), I had a serious crash while trying to figure out how the thing worked xD (my own fault) and trying to run some of the samples, and it asked me to reinstall the os, I hope this will never happen on my real calc