Background

Hey everyone!

A week or two ago I found myself on a long trip with not much to do and decided to try my hand at a TI-BASIC program using the new Celtic CE library. It's been awhile since I worked on a TI-BASIC program and it brought back a lot of memories! (Along with reminding me why I hate using TI-BASIC )

Anyways, I had initially planned on making a game, but on-calc sprite creating was a huge pain without a proper program to do it. Long story short, instead of making a game I made a sprite editor!

The code is most certainly not the best, but the program works and isn't too slow, so who really cares

Eye Candy



What can it do?

Spriter offers a nice, minimalist interface for editing sprites using both the xLibC and BufSprite (OS color) palettes. You can create sprites anywhere between 1×1 and 128×128, though keep in mind that loading a 128×128 sprite takes a significantly long time. In the editor, you can zoom in and out, choose different colors, erase and place pixels, anything basic you'd expect from an on-calc editor. Spriter offers two different export options, where you can either save your sprite to a string variable you can recall into a program to use later, or insert the sprite as an icon into a TI-BASIC program (Provided it uses the BufSprite palette and is 16×16).

Download
You can download Spriter from GitHub, or from Cemetech if you'd like. If you're using this program, make sure to install the Celtic CE library first!

Enjoy!

Looks pretty nice! I like the interface a lot. One thing I would be concerned about though is that the cursor appears to just be a square in the currently selected color--wouldn't that make it impossible to see when filling large areas with the same color? I maybe would replace it with a simple white, black, or red outline instead that's aware of the color behind it so it can change color to be visible when necessary.

Anyway, nice work and I look forward to trying it out once it's uploaded to the archives!

That's a great suggestion and definitely something that wouldn't be too difficult to do either. I'd probably aim towards a black border, and switch it to white when needed to contrast. Thanks for the feedback

That looks great, nice work! I was trying to remember some comps that I've previously seen, and while it appears that I hallucinating tifreak8x having created a hybrid BASIC sprite editor, I did accurately recall Frederick's Designer program (https://www.cemetech.net/downloads/files/2128/x2456). There's always space for various tools for the job, so people can pick the one that they like best, but I'm also curious to understand where you feel Spriter particularly excels.

TIFreak does indeed have an icon creator which should work on the TI-84 Plus CE. It's good, but only works for icons. Frederik's designer program is wonderful and definitely a big recommend from me, even over this, though because it's written in ICE it can experience a lot of crashes at times and requires a version of the C libraries that's a few versions older, making it sadly somewhat impractical to use.

I've always used ICE sprite creator by calclover2514 and CalcMeister, although its only supports xLibC. https://www.cemetech.net/downloads/files/1889/x1889. I'll definitely try this one out.

Funnily enough, this was going to be one of the steps I was going to take for making progress on my projects. Might still poke around with it, might just use this. It looks pretty good!

I'm going to assume the readme tells you how to use the program, but it might be nice to have what keys does what displayed, like where you're selecting the size of the sprite to work with and such.

So I finally found some sprites I thought I'd try to translate over to the calc manually (for testing purposes) and.. I can't use Spriter. When I press the arrows, it gives me an "Error: Version". I'm going to assume that it's complaining about OS version? I'm running 5.0.1.0012.

I'd assume that's got to be it because I believe it does use some "newer" TI-BASIC tokens like eval( and such which I think weren't added until 5.2.x (maybe even 5.3.0?).

I personally prefer using 5.3.0 on my older CE, since it also lets you run archived programs (so you can essentially create a near 3 MB large pure TI-BASIC game). 5.3.1 disables Asm84CEPrgm and AsmComp(). They still show up but with a strikeout and cannot be selected in the catalog so only Asm() remain. 5.5.1 and higher removes Asm() altogether so you need ArTIfiCE, CabriJr and AsmHook. Unfortunately I cannot downgrade my newer CE so I had no choice but to use ArTIfiCE. I don't need AsmHook anymore because I can launch ASM programs from Celtic CE commands.

Yeah, I found one of my CEs with 5.4, so I'll switch over to that calculator for my development

Bit of a time bump here. Some notes/questions.

1. While using the program to build a sprite, I encountered it dimming the screen and sometimes going into power down mode while in use. Not sure if you have a timer that is trying to look for no activity, but isn't properly being reset when a key is pressed?

2. Would be nice if one can load in a sprite to either edit or resume working on.

I'm glad you gave the program a try! As far as the first suggestion goes, that's just an APD issue with the OS. I don't do any dimming or inactivity checking, and as far as I'm aware there really isn't a good way to fix that.

For the second option, that's a good idea! How would you envision such a feature, maybe selecting a string to load from and then setting the width and height of the sprite so it loads properly?

Yeah, that seems like the smartest move. though to get around asking for the dimensions, you could have them set the dimensions normally, like you're about to start from scratch, add in a "load" option from the drawing screen, choose the str# from there?

Another feature request that shouldn't be too hard to implement. When zooming, it'd be nice if it could display the level of magnification. And when it hits its limit on expanding, the number or designator would either indicate MAX or be in Red, or both?

Update post:

I figured out what my issue was we were discussing in my thread. There does seem to be an issue of some kind with Spriter. I created 1 16x16 image. Red X from corner to corner, blue lines along the red, and green arrow heads filling out the borders. I saved this data to Str1, Str0, and Str9, and then recalled them into a program:



These are supposed to be 16x16 sprites. I get the same reaction with this, the top half of the sprite displays fine, the middle to bottom is static.

I was visiting extended family for Christmas which led to some time to pass while travelling, so it was a great opportunity to work on Spriter again! I've been working on the various suggestions, and here's how it's looking so far:



I've added an outline to the cursor (Only viewable at scales 3 or greater, so it doesn't obscure the drawing color). I may make this toggleable, given that it seemed to introduce a tiny bit of lag.

I've also added an indicator for the current scale, and as you can see in the screenshot, the [+] or [-] buttons are shown in red when you cannot increase or decrease the scale any more.

The loading feature is currently in progress, since I ran into a few bugs and need to get it sorted out. It hopefully shouldn't be too much longer though.

As far as the saving bug goes, I think I might have a hypothesis:

The way saving works in Spriter, it will back up the icon with Celtic's BackupString and then save which string to restore to when the program exits. This is because Spriter uses string variables throughout, so it ensures no strings are written to that could possibly interfere or be erased before the program exits. However, it has the side effect of only being able to save to one string, meaning that it will only save to the string last selected. My guess is that saving to multiple different strings could be what caused the behavior, though I'm not sure. Str0, 1, and 9 are also the most commonly used in Spriter, so it's possible that they were still somehow corrupted, though I don't think so.

I'm not really sure what the best way to fix this would be. The best way would probably be to limit the strings which can be saved to and then write to them immediately, or to note somewhere that you can really only save to one string per instance. I suppose I could also just write to any string, with the hope that the user understands that Spriter may overwrite them while the program is still being ran (and almost certainly will if it's Str9).

What behavior would you suggest or think makes most sense (also let me know if you have any other ideas)?

Nice to see some updates. I agree that saving to 1 string might help reduce issues, perhaps using the same thought for another string to load data into would be good? Is this using Celtic libraries? If you wanted to get fancy, saving to a program would be easy enough, even loading from them should theoretically be easy.

The only reason I saved to 3 different strings was to try to see the differences in the data, incase there was a glitch in the parsing part of the program to convert the picture to string data.

Edit 1/20:

Dug around in your code, you're using ALL the str vars already. I haven't tried deciphering your code yet to see why, but that will certainly make things a bit tricky. I'll continue poking around when I can get away from work, see if there's anything I can help out with on it.

I've published an update on Cemetech and GitHub. It includes the cursor outline, along with the scaling ability indicator.

I decided to use Str5 for saving and loading. The overall process should be a lot smoother and hopefully not glitchy. Feel free to give it a try and let me know what you think

Also: Spriter does already save to programs, in the form of the icon export feature, by inserting the appropriate header and icon. However, it does not create new programs, and it always inserts at the top with the idea that it is being used for a program icon.

Excellent, I'll get it downloaded and tried out as soon as I can!

As to the upload/download from a program, I mean it literately. Just having a specific program to save and load from would be easy enough, since with Celtic you can determine how many lines are in a program. If you save to every second one (just to give a space between saved lines of data to break it up) you can then have it recall them by indicating which sprite data to pull from Might be fancier than what you are looking to do, though.