Just for the hell of it, I decided to remake TIFreaks sprite2hex program on the PC using wxWidgets. It can create hex from 8x8, 16x16, or 32x32 sprites (selectable via the menubar). It also has 2 "zoom" levels (5x and 10x) for drawing, and a preview which is at a set zoom of 2x.

First, the screenshots

8x8 sprite at the default 5x zoom level


Same 8x8 sprite, but at a 10x zoom


16x16 sprite at 10x zoom level


32x32 sprite at 10x zoom level


Now for the bad news. It is available source-only. Sorry, no binaries yet for any platform.

Source: http://www.kllrnohj.com/cemetech/sprite2hex/sprite2hex-0.1.tar.bz2

To compile, simply do "./configure && make". The binary will be src/sprite2hex

NOTE: wxWidgets is the only dependancy

NOTE2: I haven't really verified fully that it is generating the HEX correctly aside from a few quick comparisons against TIFreaks sprite2hex. So please lemme know of any bugs.

Comments? Suggestions?

That's pretty cool, but there are already a few utilities out there that do this (Image Studio). Although, this is the first open source/linux one that I have heard about.

Nice job

Oh, I figured there were already programs that did this same sort of thing (I think Kerm said he wrote a script to convert a .bmp to hex). I was just bored waiting for my new PC to arrive, and had nothing better to do, so...

Plus, it was a good way to brush up on the ol' c++ skillz after doing so much python

Kllrnohj: http://www.cemetech.net/projects/php/bmp2hex.php

Nicely done, this looks quite nice and useful. Always good to keep your programming skills in shape.

*cough, 404 error, cough*



Why thank you, I tried really hard on it, I really did

looks nice! Hehe, I didn't think my sprite2hex program would inspire anyone to port it.

It was more because I heard you talking about how crazy long it was taking you to make each sprite. I was like, there has to be a much easier (and faster) way than a slow BASIC program, and being able to just click on "pixels" to draw them is much faster and easier than what your sprite2hex program has. Sooo.... I figured I'd make one - although I'll probably never actually use it, lol....

Does anyone think they will have any use for this? As in are windows binaries needed/wanted? (Don't worry, you won't hurt my feelings if you say you won't use it - I had lots of fun programming it, so I don't care)

I don't want to make you do more work than what you want to do, but if you were able to make a windows binary with:

-Output in layers (if it's drawn in grey it should be white in one layer and black in the other)
-Output in z80 form as an option (simply adding a .db to the beginning and the appropriate $ or h)
-Output with choice of compression (rle, verticle rle etc...) and have the decompressor as an asm routine that someone can include in their asm program.

I would get tons of use out of it and never use another image editor again (bye bye paint). But, that's if you want to add those features.

Output in .z80 should be easy enough, I can handle that one.

Not sure about rle or other formats, I will look into that.

What do you mean by layers? Are you talking about for greyscale? Please elaborate on that one a bit...

Adding features should be easy enough, as the code is not at all complex (yet) In fact, of the ~1125 lines, I only actually coded ~200 of them Thank God for RADs!

Yeah, I'm talking greyscale. Basically what I would be suggesting will be to allow the user to draw in let's say 4 level greyscale. Then it would output 4 layers (each layer is a complete hex version of the image, each shade of grey would occupy different amounts of layers. Example:

Let's say I had a picture of a 3x3 box, and I wanted the inside grey and the borders black. The hex should look like this:


Code:


Capiche?

Yeah... I kinda sorta maybe get it. For white, it is 0 in both layers, for black, it is 1 in both layers, correct? Now the part I'm unsure of. Is dark grey in the first or second layer? (I'm assuming light grey would just be the opposite of dark grey)

It's the ratio of how many times you display white to how many times you display black that determines the final color. In 4 level grey scale: White = 0 layers, Light Grey = 1 layer, Dark Grey = 2 layers, Black = 3 Layers. Order only matters when you're trying to mimize flickering. In the case of Dark Grey you'd want to make the 2 layers it occupies NON-consequtive. Other than that, you can pretty much put whatever you want in each layer as far as I know (I have made greyscale images before FYI).

Ah, so your 3x3 example would have been 3-level greyscale, and for 4 level greyscale you use 3 layers?

I believe so. I may not have the terminology exactly straight. In my book, however many different shades of black (white, grey, black etc) you have determines the number greyscale it is. I think that's the official version, but you'd have to double check.

So as far as I know the number of layers = number greyscale - 1

Edit: Ok here's a technique for more advanced greyscale:

The main goal of greyscale is to be as flickerless as possile. In that vain, if you are using 3 level greyscale and you are trying to make a large part of an image grey, you shouldn't make the grey part entirely black in one layer, and white in the other because the switching back and forth will cause noticable flicker. The solution to this is to alternate grey pixels so that you make a checker board of off and on, on each layer. That way, when you switch back and forth quickly your mind doesn't see any flicker. I think this could be an awesome feature if you decide to include greyscale at all.

Um yeah, it had nothing to do with the speed of the program, that is killer fast for BASIC imo... Oh well, had my hopes up

Kllnrohj: Oopa, I meant this: http://www.cemetech.net/projects/php/bmptohex.php

Chipmaster: Yeah, I think 2-bit grayscale would be a nifty addition. There are a couple of proggies at ticalc.org that do it, but none that do it particularly well.

No, I mean that moving a cursor in BASIC using a D-Pad is slow (the whole press and wait thing), not that your implematation of the concept was slow.

@Chip: I looked at Image Studio's 4-level greyscale output, and it has layer 1 = light grey, layer 2 = dark grey.

I don't really understand why there would be a difference. It must have something to do with the lcd. I do hope that if you do grey scale you take my alternating pixel suggestion.

I can create it however you want, just give me a concrete example and I can add it. I have only learned minimal z80, so all this greyscale format talk and how to implement it is still beyond my measely z80 skillz.

I will start by just allowing for greyscale at all (I mean adding the ability to the backend), and just have it convert all gray's to black until something satisfactory is worked up....

Definitely. Generally, with z80 ASM, two layers are used. The first one is displayed for precisely half as long as the second: therefore, any pixel on on both is black, on only on the first is light gray, only on the second is dark gray, and off on both is white.