As you may have seen, there has been a small amount of interest in bringing an ASM lib with some graphics features to the TI-84+CSE (84C for short).
I have been toying with a few small ideas that i may end up implementing in a preliminary version for BASIC programmers.
There are some pretty serious speed and memory limitations on the 84C which mean that fast paced BASIC+ASM lib games arent likely if the entire screen is utilised per frame. That being said, if there are a handful of sprites on screen at any time, this should be ok.
Just a note, there will be a radical difference between the way this lib and earlier versions of xLIB (for the 83+ etc) work.
Some of the proposed features:
256 internal but user accessible 16-bit variables (functions will take references to these variables instead of TIOS variables)
Graphics mode will be 160x120 (half res)
128x64, 256 colour (standard palette) custom PIC's (likely stored in appvars) ~8192 bytes+header. Enough to store 128, 8x8 tiles/sprites.
Ability to 'load' 2 custom PIC's into temp RAM for faster access
Ability to store 2 copies of the LCD into temp RAM (kind of like a temp storePIC)
8x8 fullscreen tilemapping (160x120 = 20x15 tiles)
256 colour (standard palette) sprites (not sure on max size yet)
Capability to 'chain' keypresses and update user variables if necessary (can test up to 16 keypresses with 1 command)
On calc PIC/tile/sprite editor
*Possibly* an on calc map editor
Line/shape drawing
Colour text routines
Archived program execution
And possibly more, but that for now.
One of the BIG traps that older versions of xLIB fell into was people requesting odd or specific features that would only be used *very* rarely, if at all. These considerably slowed the entire lib down for almost no benefit. This is something that i would really like to avoid with this incarnation.
Anyway ive been testing a few small things, but screenshots are difficult to make without a fully functioning emulator. But anyway here is a small tilemap test:
Simple sprite tests, with transparency as well:
Scrolling is not ideal speed wise. Though there are options to speed things up (interlacing etc). The most probable method for games will be to scroll screen-by-screen if that makes sense.
Here are a couple of sprite tests as well:
Left screenie is with no transparency, right is with the transparent colour specified.
The tilemap is drawn as a background and the sprites are drawn over it. The tile that the sprite is over is redrawn every offscreen frame to effectively 'clear' the sprite. The map is not drawn every frame, rather it serves as a background.
Here is an incredibly crappy quality screenshot showing 16x16 sprite (with transparency) moving around. It appears to run a little slower than on calc (due to capture issues).
The 16x16 sprite is made up of 4 * 8x8 tiles. You can specify which tiles in a PIC make up the sprite, and they dont have to be in order in the PIC either.
For example you could say that tiles 1,2,3,4 make up your sprite, or if you say want to have the same body but a different head on the sprite you can say that 55,56,3,4 make up the sprite etc (if that makes sense).
The screenshot is actually drawing 2 16x16 sprites since the 4 tiles that are 'behind' the main sprite are calculated and drawn every off-screen-frame in order to clear the sprite. This saves having to clear and redraw the entire screen ... which would be very slow!
Just wondering if anyone has any ideas/thoughts?
