I love the new DoorsCSE8 Hybrid Libraries, but I was kinda disappointed with the fact I have to use a computer to create a sprite sheet. The effort in trying to find an oncalc solution was extremely difficult, to the point of just putting calculator down and going to watch Youtube or play Terraria. But after so much trial and error and searching the web, I have found a solution! I am creating the program. I am off to a good start with UI and data file creating. I should be able to take pictures (since I can't use a computer to get GIFs) and display them in a later reply. Thanks to everyone at Cemetech (for BASIC Routines) and especially readroof2 for trying to figure this thing out.

Here are those photos:

Main Menu:
http://imgur.com/fGB9uCN
New File Creation:
(Up/down to select field, 2nd to confirm)
http://imgur.com/taGo6YG
Typing File Name:
http://imgur.com/kuXl0KA
Selecting Transparent Color (It freezes when the color lands on 1, so don't use it)
http://imgur.com/PHdefzD
File Creation in Progress
http://imgur.com/zRKvM2z
Open Option
http://imgur.com/SomjhLi
Open File Window (w/ X button selected; it works on the New File menu, too)
http://imgur.com/YhT2UM9
Typing in the name:
http://imgur.com/yedwmKk
Loading picture (Yes, I know it is slow, but that's all I can do.)
http://imgur.com/vfpHZc6[/url]

What exactly is it going to do to make the sprite sheet? Is it like a paint program that will make a sprite or something? Make a gif or something of it so we can see where it is getting the user to make a thing. I can see that it is looking good and stuff, but I think it is a lot easier to create sprites on the computer. I am horrible at pixel art. Unless you make them save it as a background, input the background number saved on the calculator, and then use real(0,1,1) and GetPixelB (xLIBC palette, TI-OS VALUES) at http://dcs.cemetech.net/index.php/DCSE:BasicLibs:DrawShape for the first half and then switch to the other side of the calculator screen. The transparent color could be the white that is where the background has no color, which it does for little stuff. But I don't know.

readroof2, I already said that I don't have a computer and therefore I cannot get those gifs. If I had a computer to work with (as well as a less confusing interface like Tokenizer ((sorry to the creator))), I would not be doing this project. This is simply for those people who, like myself, do not like using computers for calculators except for the transfering of files and prefer oncalc utilities. I do wish it was easier to create sprites...

EDIT: I intend no rudeness. As for the question on the sprite drawer itself, the editor displays the whole image, then allows the user to pick one of the 128 8x8 Sprites. Then you use a sub editor to draw the single 8x8 sprite the user chose.

Also, with the transparent color option, that makes the user's sprite creation easier. One must designate a color value as a transparent indicator (like the idea that a sprite in Microsoft C# XNA, the transparent color is rgb(255,0,255)) to draw the sprites with transparency. This is so that the user doesn't have to fill every single sprite they don't use with the transparent color manually.

I do admit I am very good at pixel art. My strategy is that I take a piece of graph paper and a pencil. Then draw a border for the size sprite you want to draw in 8 pixel intervals. Sketch the sprite in the box. Fit the pixels with the lines you just drew. And viola! You have your sprite!

Hey this is very cool! A valuable tool no doubt.

How are you reading the appvars to edit them?

Data structure goes like this:
What ever transparent color the user chose, it converts the number to hexadecimal and writes it to a program as 64 lines of 256 hex digits. Then the user picks the sprite he/she wants to edit. Then the data is selected and put in in matrix [G]. Then the usual sprite editor then once finished, it reads the lines and chops string and inserts it back. Then it writes to the file. If the user quits the program, the program will be archived. When finished, the user exports it by inserting an "Asm84CPrgm" token in the first line and AsmComp it. Then since wonderful Celtic can read lines of Asm programs, all I have to do is "XLIBPIC"+Str9 and insert it into an appvar.

EDIT: The program does the exporting work.

Nice one.

Are you using xLIBC to draw the sprites in the editor? (Like in sheet preview, sprite selection etc?).

Wow, this is really impressive; I'll definitely use it when it's finished! The method you use to convert it to an appvar is super clever.

Just wondering, though, how are you reading the sprite appvars to edit them? From that last picture, it looks like you're reading it pixel-by-pixel (using Celtic?), but it'd be faster to display it using xLIBC with something like this:

Code:


Good luck with this project. Don't hesitate to post code if you're stuck on anything, since this'll absolutely be a must-have for me once it's finished!

Nice! This looks really cool soulfighter and you know I've been looking for something like this since I started learning how to program in Xlibc, and hey if this works you could make an on-calc tilemapper. I think you should definitely upload this to the website archives when your done!

I don't think it's possible in TI-BASIC, unfortunately; the calculator doesn't have enough memory to store each pixel. Could definitely be done in assembly, though.

Here's a start on an interface of sorts, although I wouldn't recommend trying to run it all the way through - for some unfathomable reason, Celtic seems to object to adding 8193 lines to a program.


Code:

I don't think I agree. The whole point of tilemapping is that you're reusing sprites to fill the screen, so you have a relatively small number of sprites that you use to fill the screen (and thus need many fewer than 320*240 pixels of data for each screenful of data). Your tilemap editor would need (1) a sprite editor for the individual sprites in the tilemap's spritesheet, which seems to already be a solved problem, and (2) a tilemap editor that lets you drop one of the possible sprites in the spritesheet at each grid location in the tilemap. I think a tool like this would be really helpful, especially with xLIBCE planned for the TI-84 Plus CE with very similar functions to xLIBC.

Hm... I'm probably just doing it wrong then. My original plan was, once the 8194-line program was created, store a pixel color to it using the matrix formula, then compiling it using Asm84CPrgm. There's probably a more efficient way of encoding pixels, though.

It seems to me that you could edit individual sprites (1/128th of the spritesheet) one at a time, and store them back to the spritesheet before editing another one. Then, you only need to keep 8x8 pixels out of the "compressed" spritesheet at a time. Then, for the tilemap, all you need is the 1-byte (or 1-real, I guess) index of the sprite in each tilemap tile, which you could easily do with a matrix. I hope that makes sense.