No, this isn't a project, though I have actually thought out a way to do it in BASIC, I'm not sure it'd be fast enough to work. It'd not be overly different from the BASIC version I created for the 83+/84+ a long time ago.

The thought is, how should BASIC programs be able to quickly display sprites. Before, we didn't have to think about colors, it was just on and off.

Would it not be best for us to use hex, but more along the lines of what color a pixel gets turned into?

My idea for a BASIC version was to have 1-15 equated to hex values. That way, it would be 9+hex value to turn on the pixel to the proper color. Of course, an asm version would be slightly different, but we could essentially use the same principal. And we could have a character, like theta, to tell the sprite display tool that it is an end of a row, to start back at the first column of the next, so optimizations could be made.

I really don't know how sprites are displayed on color screens, hence my throwing this out there.

How good of an idea is this? Is this something our illustrious team of ASM experts that have a CSE could get done? :p

Edit:

Also, for possible inputs:

Str9: Hex string of sprite data
|LSPR: elements 1 and 2 are the dimensions of the sprite, for varying sizes, 3 and 4 for X and Y starting coordinates

Well, I think we need to think out what all Hybrid BASIC-using programmers are going to want, because no matter what you end up using is what's going to stick, I suspect. We're right at the forefront of TI-84+CSE development, and the first color BASIC library is likely to set the interface used by most other libraries for compatibility. I think that programmers will want at least two types of colors: palettized colors and "true" 8-bit or 16-bit color. What you're talking about is palettized color, where we stick with the color palette that TI designed.

By the way, this library should also allow selecting both text background and foreground, if we can figure out how to do that.

From comments on OmnomIRC, I noticed that some people would rather be able to use 160x120 style resolution so that they can stick to 8x8 sprites, eliminating most extra pixel art work that would be required from simply porting old games.

However, if we stick to pure BASIC (which I assume is the main topic here), the only decent way I could find so far are text sprites. I haven't experimented with the Line command much for sprites. THe problem with text sprites, though, is that in most cases the background is always white (or gray), which limits map design a lot:


(this took about 14 seconds to generate, but it's only because I drew each character at 3 pixels interval instead of 1)

I might eventually experiment with the Line command to see if it would be possible to do something similar to vertical/horizontal text sprites without massive slowdowns. Text sprites can be annoying with a forced white/gray background because you have to wait until the entire map is drawn before you can draw portions of the HUD located right next to sprites.

Interesting. Hopefully more TI-BASIC programmers will weigh in on that here.

Actually, I thought we were talking about Hybrid BASIC, hence:

Thanks for your investigation of text-based sprites; I agree that they're quite limited. I think for any truly graphics-intensive game, a hybrid BASIC library may become necessary.

This is extremely true. As I said, I know nothing about creating color sprites. On the other calcs, it's just on and off, and that was simple.

And the palettized colors would be amazing. Got any example kind of syntax we would use if we went with something like this?

@DJ_O: I can create something like this in BASIC easily enough, but for a good speed, we need an asm version.

You sounded unhappy that I didn't get to address this yet, so I made sure to think about this before I went to sleep tonight. Just real() as the stand-in for a Hybrid BASIC hooked token something like real(42,X,Y,8,8,"1A1A742098E4","11333311......"), where the first string is four 16-bit color values, and the second string are color indices (two pixels of the 1A1A color, four pixels of the 7420 color, etc). That's for custom palettes. For the default OS palette, we could just use 0-F for the pixels, so real(43,X,Y,8,8,"05EAF691...[64 total ASCII characters") would be an 8x8 sprite.

I agree. I think we should start with a simple ASM stub called with string and Ans arguments and run via Asm(), and use that to figure out what features would be good for a Hybrid library with hooks.

Not unhappy, I just want to keep the talks going on this, want to get things set up and ready to be planned out. I figured it'd be just easier to start out with something like the program you fixed that benryves had given me for pokemon, then when it is set up properly on it's own, it can be later added to a library as you have time to create it.

now, displaying color sprites isnt new, just to this platform.

Im looking into displaying sprites in other ~older~ systems, like the coleco vision, and studying codes from this may help us understand things better. the primary way, as i have seen, is to store a sprite's shade and shape, but not color. take the data, and use a color table to replace a shade (im sure i brought this up before, but i still dont understand 'how' this would work).

maybe this method would work:

The sprite:

01111110
02222220
03333330
04444440
05555550
00000000
05000050
00000000

This part is the sprite shape; only what is "On", or not Zero, would be colorized and "Off" would be ignored by the colorize routine.

and then some routine would put a color pixel on the screen based on what the number is. might not be good with speed, but i cant think of any other way you could draw sprites in color. so, the basic program would have to provide the sprite data, sprite location, and a color table to reference.

this is mere speculation, though.

As I figured and speculated myself, but from a BASIC standpoint, we have the option of 15 colors, listed here. That's not really enough to do what most are wanting to do, hence why I am putting this topic out there to see what we can do with asm to give BASIC users more colors.

well, i meant the color tables to look like

1=colorhex1
2=colorhex2
3=colorhex3
....

that way, they could use their own colors, if the calc could use that.

What you're describing is palettized sprites, which Kerm has mentioned.

I'm just going to re-quote my post, because I think only Merthsoft actually read it.

Palettized sprites:

Asm( program vs. hooked tokens:

I read it, I was just agreeing with you.

tifreak8x and merthsoft, in that case. Is it worthwhile to also have an 8-bit mode, do you think, with 3-3-2 color, or is the fidelity just not worth it? That would be 2 ASCII characters for each pixel. Here is the 8-bit color palette:


(From http://en.wikipedia.org/wiki/8-bit_color)

Edit: It just occurred to me that base64-encoded sprites would be a good idea.

Okay, let's say I wanted to turn on the sprite in the third column, 3rd row, just one pixel, what kind of hex format are we talking for to pass in a BASIC string?

And I'm not sure what base64 sprites would look like in terms of coding.

Edit:

I also had an idea for this, to make it more versatile.

We could have it set up for the programmer to pass off the width of the sprite, and just run to the end of the string data. This way, it would potentially display a sprite of any size.

Yeah, the "8,8" arguments in my code above were meant to be width and height. As you point out, all we really need is the width; the height can be inferred from the length of the sprite data. Here are the options we're talking about so far:

1) Palettized with 16-bit palette colors and at most 16 colors
2) Palettized with TI-OS palette and 15 colors (+transparency = 16)
3) 8-bit-color as ASCII-encoded hex
4) 8-bit color as base64-encoded hex (this saves 33% space)

An Asm() lib would be nice for small games, while an hook-based one would be nice for games that absolutely need every bit of speed it can get.