Hi All,

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?
The screenshots look fantastic, and that list is quite awesome. I can't think of anything else right off top of my head, though if I come up with some suggestions, I'll be sure to post. Smile
Seems like pokemon and/or zelda inspired screenies. Wink I cant wait to use it with my soon-to-be-aquired TI84PCSE
All these things look great--I'd love to see some more updates. I'd also love to get my hands on a download to play with. This seems quite speedy, and it'd be great to get TokenIDE up to date with any new functions, formats, palettes, etc.


Here is a small tilemap test. There is 8-directional movement (arrows+combos) and tile collision checking, the sprite is moving 8-pixels at a time.

The animated tiles are 2 frames and take advantage of the way xLIB uses GRAM, meaning that they dont require any extra processing once drawn.

Im working on making some more routines to speed things up if possible.

I apologize for the crappiness of the video and the fact that i did it on my phone just before leaving for work.

Here are some screenshots of the map:

Wow that looks amazing--I can't wait for it to be available! The animation is really nice. Is there a way to slow it down at all? I'm assuming it's just the double buffering that allows for that.

Can't wait until there is more information on formats Smile
That looks fantastic!

Oooo~ Let the RPG planning commence! Very Happy
Yes the 2-frame tile animation is just a bi-product of using 2 sides of GRAM to buffer. This is why you can technically have a full screen of animated tiles for free.

The tile graphics are stored in appvars. They are 128x64 in size and are 256 colours (8192 bytes + header). They are stored 'by tile' and are stored 'by column'.
Darnit tr1p, now you're gonna make me have to buy an 84C and start porting games and finishing old ones, aren't you? Haha!
tifreak8x wrote:
That looks fantastic!

Oooo~ Let the RPG planning commence! Very Happy
Yeah I actually had plans for one, using tiles I made in 2008 (that never got used, although some were modified Reuben/ROL3 tiles) that I recently colorized:

but first I would obviously need character, NPC and monster sprites, as well as a game title. Razz

xLIB should hopefully make it easier, since this version seems really fast. Smile

I'm pretty much stuck between the HP Prime and xLIB 84C now, so there are some chances that I try to port any of my future xLIB stuff to the HP Prime.
128x64? They look square in your video. Are the colors 565? How are the tilemaps stored?
merthsoft wrote:
128x64? They look square in your video. Are the colors 565? How are the tilemaps stored?
Part of how the double buffering works is it splits GRAM in half and scales it to the screen, so a 128x64 sprite is displayed at 128x128. That is how you can have animated tiles and double buffering without needing more GRAM to work with.
I think in this instance, I'm going to need to see sample coding to even remotely understand what is going on on that screen. :<
Wow, very cool! Smile The animated tiles are a cool feature, though I'm not sure how I would put them to use since the animation toggle is tied to the (impressively fast) refresh speed.
Well once other stuff is added it will slow down, but getting decent 2-frame animated tiles is always a mission.

The xLIB tile PIC's are custom and never displayed on screen, they hold the tiledata for the tilemap. xLIB is always 256 colours using a standard palette, so they are 1 byte per pixel. Its enough to store 128 8x8 tiles in 1 PIC. There is space to load 2 of these into temp RAM so that you can use 256 tiles if necessary.

There is another image format called xLIB BGPIC, which are low res, 80x60 images scaled to fullscreen. They only take up 4800 bytes and are likely usable for RPG battle backgrounds etc since they are low detail.

There is a rickroll test of the images here:
Thanks for sending along the beta for me to test out in Doors CSE, tr1p1ea! I'm hoping we can coordinate quickly getting it into a working, debugged state, and I'll put as many Cemetech TI-BASIC/Hybrid BASIC coders on testing xLIBc in Doors CSE as possible. One thing I notice from perusing your code is that you force all BASIC programs running with xLIBc enabled into 15MHz mode, even if the program doesn't use xLIBc features. I'd personally recommend only forcing 15MHz mode either when the programmer uses an xLIBc function, or with a specific xLIBc call, to keep regular programs designed to run at some specific rate at 6MHz functioning properly. Thoughts? Also, I notice you use the "old" version of the DrawLine routine. Smile
Well I personally would rather prefer having all my BASIC games running at 15 MHz all the time, else they'll just be too slow >.<
DJ_O wrote:
Well I personally would rather prefer having all my BASIC games running at 15 MHz all the time, else they'll just be too slow >.<
The ones you programmed, yes, but I'd rather have you need to explicitly set fast mode at the beginning of your programs than force all BASIC programs to run fast. Smile
Oh ok, I was worried that I would need to set fast mode manually after every xLIB command Shock.
I don't think there's any danger of any program on the 84+CSE, ever, running too fast. 15 MHz mode should be used all the time except when you're busy-waiting, and it was a bad idea for TI to preserve all the old kludges for running programs at 6 MHz.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page 1, 2, 3, 4, 5, 6, 7, 8  Next
» View previous topic :: View next topic  
Page 1 of 8
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement