For the last two or three days, PT_ and I have begun discussing and putting together a program intended to create and edit spritesheets on-calc, similar to TokenIDE. Essentially, the program will be a drawing program, which saves the final drawing as a spritesheet for use with xLibC. As you may know, I don't know how to progam in asm, and since a part of the program must be done in asm, PT_ will be taking care of that and has informed me that he MIGHT be able to make it cross compatible between the Ce and CSE. Currently, the program is in a very early stage, here is a list of what it does, hopefully it gets substantially longer as time goes on!

Inputting the name of a new or existing appvar
Checking whether the input is valid (is the name taken, does it exist, is it a spritesheet)
If it is an existing valid appvar, display the whole thing, if it is a new one, display an empty rectangle
Draw using pixels of any size (although this will probably be capped at 9x9)

Of course, to keep this topic interesting, here is a screenshot of the editing screen with a spritesheet I converted from the web (creds to whoever drew these)


Todo list:

Saving image as spritesheet
Add a help page
Eyedropper tool
Ability to change colors
Drawing rectangles and filled rectangles
Drawing Lines
Make the program look nicer

This looks great! Although, we are all waiting on DCE before I can say that I will actively use this. once DCE is out, I plan to delve into the world of hybrid basic, and this tool will definitely be a must-have as I do much of my programming during class at school.

Cool! I have been looking into this as well and after looking at the code for 16x16 smiley face sprite I made(in tokenIDE) the first line started with "PolarLIBPIC" with 64 tokens following it that appeared to be the sprite itself and the last 8,000 bytes of tokens was just "]]]]]]]]]]]]]]]]]]]]]]]]]" for the rest of the string.
Don't know if this helps at all but I'll post it anyway.
Anyway good luck on this project and I hope it turns out great!

Yep, the PolarLIBPIC is actually xLIBPIC except that the x gets turned into the Polar token, the tilepics are stored as a string of 8 bit numbers (0-255) and if you read them out, the calculator tries to associate tokens to these numbers. the ] you observed were just your transindex. If I got this right, the right bracket has a hex code of 5D which makes it equivalent to 93 in decimal, which means your background color for your spritesheet was some hue of blue (I may be wrong though)

No, the ] is the token associated with $07, which is light green, looking at the xLIBC color table.

Very nice guys! Looking very good and can't wait to see the end result.

This will be a very useful program.

Small update, the pixel size changing thing is now fully functional and indeed capped at a pixel size of 9. Added a quit button on the editing screen, to which I might add a confirmation screen because people might have been working hard on an image and could lose it all by accidentally clicking on the wrong icon.
Added the possibility to have numbers in the name of spritesheets. Also, I'm currently working on the color picking. I am hesitating between two formats to display the colors, feel free to tell me which one looks the nicest



(I intend to use two inverted lines that intersect on the color you are at. This means that I don't need a cursor around the colors and can make the squares 5x5 rather than 4x4!)
EDIT: Color picking now fully works.

Is the dithering on calc or just a result of the screenshot (gif)?

I personally like the second one better .

I agree with tr1p1ea that the second one (with the squares) looks better. I definitely understand the wish to make the grid a little less monotonous than squares, but I think it's going to be the clearest way to present the colors.

As the program nears completion, here is an update on what's been done. This is most likely the final update before the program's release.

1. The program has a Doors CSE icon.
   
   
   
   
2. Moving through the tools menu now indicates what tool you are currently on (displays a name for the tool) and for the Pt-Size tool, it also displays a point beside the text to show the size.
   
   
   
   
3. Icons have been added for each tool
   
   
4. As indicated by their greenness on the todo list in the first post, the rectangle, filled rectangle and line tools now work. For those who noticed my little issue with negative width and height in the chat, this has been fixed by simply not allowing the user to move to a spot where the arguments would be negative.
   
   
5. Since I haven't shown it yet, the color picking is done with inverted lines that are moved around the palette. Since this does not require me to have any extra space around the colors for a cursor (which was the initial plan) I can make the squares 5x5 rather than 4x4! For some reason, Jstified messes up the screenshot a little so just imagine the XlibC palette is displayed correctly which it is. xD
   
   
   

looking great!
I dont recognize the characters in this image:

What is it from?

As with the previous spritesheet, I didn't draw these myself (because I can't draw for my life) I got these from the web, however, I was able to find who drew them (at least a profile somewhere). Here is a link to the profile of the person who drew these on some pixel art site. I use images like these because it makes for nicer screenshots, but of course, you don't have to load an existing spritesheet to use the program, you can create a new one, which will just be a green (7) rectangle.

I will explain a bit more about the ASM part (my part) of this program. Since this program will be compatible with both DoorsCSE and DoorsCE, and they use a different processor, I need to figure out whether it's the CSE or the CE. Luckily, DoorsC[S]E does this for us, so I don't have to worry for that. Since z80 ASM is not compatible with the ez80, we need 2 different programs to run the ASM part.
We found a good way to make sure it will not crash, while still keeping the compability. With DoorsC[S]E you can check with det([[20about what version of Doors you're running, and thus which calc. If that number < 85, you're at the CSE, and >=90, the CE. Based on that value, we will load the ASM stuff in a string. With that string, we can create a temporary file, execute it, and delete it. Very easy, and handy.

I have to do this part in ASM:
- Loading the appvar (rendering)
- Saving to the appvar

Loading the appvar, is first searching them with _ChkFindSym, and loading the pointer to in in (saveSScreen) or anywhere else. The second part is getting the value of the pointer, load them into Ans, and increment the pointer. That way, you can call the temp ASM program 8192 times (128*64), and after that, you can delete it.

Saving in an appvar is a bit more difficult. First we need to search for the appvar. If it exists, and the length is 8192+7 bytes, no worries. Otherwise, if it isn't a spritesheet, give an error. Otherwise, if the appvar doesn't exists, create one with length 8192+7 bytes. Now it loads again the pointer into a save location. The second part is first getting the value in Ans, loading it into the address of the pointer, and increment the pointer.

I hope this explains a bit more how our program works

Did some minor changes today, fixed a little bug that I hadn't thought of... essentially, when drawing rectangles filled or empty, to prevent having negative values for widths and heights, I made it move the cursor 2 pixels right and 2 pixels down, then prevented the user from moving backwards (you can only make a rectangle starting from the top left corner of the rectangle) However this made it so that you could end up outside of the drawing area by drawing a rectangle 2 or 1 pixels away from the right and bottom sides. It no longer does that... Also, I just changed the way it checks for a valid input in terms of the name of the appvar, it does the same checks as before except that instead of reading the first line and looking for the PolarLIBPIC header, it just uses det(8 and checks the size. I initially didn't want to use this because there is that one odd chance that someone might have an appvar that is exactly 8199 bytes long who would try to put that in as input, in which case idk what would happen, probably cause the program to throw an error when it gets to drawing the spritesheet, but I then figured something similar could be said about the other method, someone could have an appvar that happens to start with PolarLIBPIC and tried to dump that in as input... The only difference is that of course the speed is way better, since it doesn't have to make a 16Kb string, and you don't risk running out of memory Besides that the eyedropper tool now works, turned out to be particularly easy... just calling real(7,1 basically

Wow, this looks pretty awesome! Great job getting this going, I will definitely be using this.

Worked mostly on some cosmetic stuff today, trying to get the program to look half decent... Essentially added a handfull of sprites to the main menu, since I don't want to clutter up the drawing area (which is almost full of stuff anyway)
Here's a screenie of the main menu...

Note, the stars spawn randomly (always at the same spot to prevent them being everywhere, but the type of star is chosen at random between the three different sprites and therefore is extremely likely to differ every time the program is opened)
Besides that, I got the help page done, it's just plain white text on a black background, nothing too exciting to see there...

One suggestion for this program... could you add a grid onto the sprite map thing? I'm not very good at pixel art if there is no grid...

This is an old and pretty dead project, but concerning having a grid, I though about it, the problem is that unlike in tokenIDE, in the on-calc version, each pixel is actually a pixel, so the actual grid lines would end up appearing in the final spritesheet (since there are no pixels in between pixels) not sure if I did a good job explaining what I mean, but basically, there is no easy way to do it. Besides, this project was not and cannot be released because it can't export the spritesheets, which is the most fundamental part.

Oh well... I was really looking forward to this project being released... You had a very good start though

Problem is that almost no one uses xLIBC anymore, so this tool would be useless for now. Once xLIBCE is out, we might talk about picking it up again