Sprite editors

[sometimes99er]

Patterns (1 double sized sprite):

http://sometimes.planet-99.net/patterns.html

 

Patterns32 (4 double sized sprites):

http://sometimes.planet-99.net/patterns32.html

 

There's an input text field. It's the wide rectangle at the bottom. I've tried to set focus and put a cursor there, but not all browsers pick up on that. The usual functionality, like Ctrl+A to select/highlight all text, should work. Try typing in or copying garbage to the input field, - should be pretty robust.

 

Edited August 27, 2019 by sometimes99er

[+Lee Stewart]

Very nice!

 

Now we can. indeed, paste existing pattern strings into your editor from the Windows clipboard. Very convenient. Thanks!

 

...lee

[Willsy]

This is awesome! I suggest it be added to the development resources on this forum, if it's not already. It's very very handy!

[matthew180]

Very nice, thanks!

[kl99]

nice! I missed it when it was away and I neeeded to draw a quick sprite!

please leave it on the page, people appreciate this tool

[sometimes99er]

Thanks for feedback.

 

If some of you haven't already figured it out, you can actually use it as is at the top of this thread. Embedded Flash.

 

Here's one for ya

0306000F1930202220311F0000301C07180C003CE682829282C67C0000061CF0

[matthew180]

sometimes99er, any chance you might update your sprite editor to support 2-bit and 3-bit color? The F18A supports extra colors for sprites and tiles, and an editor will be critical for defining patterns, especially since it is more confusing with the extra bits.

 

If you are interested, the details are as follows:

 

In both 2-bit and 3-bit modes, the pattern becomes the color index, with 00 or 000 always being transparent. To get a pixel's color, you take the corresponding bit from each set of patterns. For example:

pattern 1: CF (1 1 0 0 1 1 1 1) . . . more pattern
pattern 2: A8 (1 0 1 0 1 0 0 0) . . . more pattern

In this case (only showing the first byte of a pattern), the first pixel would use an index of "11" (color 3), the second "01" (color 1), the third "10" (color 2), and the fourth "00" (color 00 is always transparent), etc. In the case of 3-bit mode, there is another pattern for the 3rd set of pixels. The new patterns add most-significant bits to the color index number.

 

That's pretty much it. :-)

[sometimes99er]

I did work on a sprite editor (Beryl) with more colors (stacking sprites), but I guess both input and output is not usable for what you are describing.

 

http://sometimes.pla....net/beryl.html

 

I did consider merging the two (Patterns and Beryl), but then Patterns was to be more like a quick and dirty experience (easy to "get"/get to).

Edited March 8, 2012 by sometimes99er

[matthew180]

Unfortunately sprite stacking does not achieve the same result, as you pointed out. I totally understand keeping Patterns (your sprite editor) simple, that's one of the aspects that makes it so nice to use. In trying to keep it simple, I envisioned two more text input/output fields under the current field, and 7 colors down the side, with a line after the first color (probably black) and the third color to indicate the separations between original/1-bit color, and 2-bit or 3-bit color. If you used any color other than black, the 2nd and 3rd patterns would change accordingly, otherwise they would be all 0.

 

I have no idea how much effort that would be, and it's just a request if you want to do it. Either way though, I'll need a 2-bit/3-bit pattern editor simply to keep my sanity, whether someone adapts an existing editor or I have to write one (YATE (yet another tile editor)), but I really like the portability and simplicity of your Patterns program.

Edited March 8, 2012 by matthew180

[sometimes99er]

So the color palette for 2- and 3-bit is actually totally fixed ? Like 2-bit is always transparent, black, green and light green ? No adding of index to sprite color information and then maybe forcing the first index to be transparent ? I'm asking since the App will be multicolor anyway, then you might as well draw with the actually colors (and limit the choices accordingly to avoid further error handling).

 

We might just add a tiny switch for 2 and 3-bit operation. If one choose 2- or 3-bit operation, then maybe the app could unfold/expand (opposite of collapsing).

 

7 separate input fields would probably be a bit tedious. Maybe just one grand text field (perhaps using linefeed) for easier copy-paste. And maybe a button to update clipboard and text field (from the drawn patterns) to avoid lag on older/smaller computers/platforms.

 

And I guess many text editors can have macros to easily format into and from Assembler, Turboforth, GCC or MLC statements.

[matthew180]

So the color palette for 2- and 3-bit is actually totally fixed ? Like 2-bit is always transparent, black, green and light green ? No adding of index to sprite color information and then maybe forcing the first index to be transparent ? I'm asking since the App will be multicolor anyway, then you might as well draw with the actually colors (and limit the choices accordingly to avoid further error handling).

 

No, the colors are partial indexes into the 64 12-bit palette registers. I was just suggesting a way to keep it simple. I figured having the 64 palette registers would be overly complicated for this particular editor, since it seems you want to keep it minimal (which is good IMO).

 

In 2-bit color mode, you can reference 16 palettes of 4 colors each. In 3-bit color mode, you have 8 palettes of 8 colors each. Tiles also have an extra attribute byte with a bit that controls if a pixel color index of 0 (00 or 000) is considered transparent or the color at that index. However, I would not expect the editor to specifically support that since it is not related to the pattern directly, other than a color index of 0 *might be* transparent, and could be simulated in the editor by making color 0 the same as the background color.

 

For sprites, a color index of 0, 00, or 000 is *always* transparent. So really, you can only have 1, 3, or 7 colors per sprite. With tiles, transparency is controllable.

 

7 separate input fields would probably be a bit tedious. Maybe just one grand text field (perhaps using linefeed) for easier copy-paste. And maybe a button to update clipboard and text field (from the drawn patterns) to avoid lag on older/smaller computers/platforms.

 

You lost me there. I don't understand why you would need 7 input fields?

Edited March 9, 2012 by matthew180

[sometimes99er]

Yes, of course, 3 bits would need 3 input fields not 7 (no. of colors minus transparent got to me there somehow).

 

If this is like official operating modes from another chip (like the V9938), then there might already be sprite editors out there ?

[matthew180]

Nope, no other VDP that I know of does this, other than the NES, which is where I got the idea. The NES has 2-bit color tiles, but they arranged the pattern data differently, and no 3-bit color support. The way I set up the F18A was such that any patterns you currently have will still show up correctly in the 2-bit and 3-bit modes, and you can add the extra color patterns as needed. The hard part about picking the pixel colors by hand is, you define the patterns in rows, but the colors are defined in columns across the patterns. It took me like 15 minutes to define a single 8x8 tile by hand (I kept messing up), which is when I decided an editor was not just "nice to have" any more, it will be essential.

[sometimes99er]

Okay, so we forget all about tiles, and concentrate on sprites ? 2- and 3-bit operation modes. That's 4 or 8 color operation. I guess it's still 16x16 pixels only ? I guess the 12-bit color registers are not preset (as in user-definable) ? I think drawing must be so much easier if you can draw with the "right" colors - the colors defined / to be defined. How does these 12-bit colors relate to 24-bit ? With whatever colors you choose, I think it's equally important to be able to pick a background color for editing (even though this background will end up being transparent) ?

 

Now, 16x16 pixels editing shouldn't really require stuff like lines and fills, but even so, it might be easier to draw the sprites in a more ordinary graphic editor. Now if you save the image as PNG (Portable Network Graphics), then an App could load the image and convert patterns and colors into the desired statements ? If you want to edit an existing sprite, you'd take the original image (which you did save) and alter this before putting it through the oneway conversion ?

[sometimes99er]

[media=600,518]http://sometimes.planet-99.net/spriteeditor.swf[/media]

Edited March 10, 2012 by sometimes99er

[matthew180]

Okay, so we forget all about tiles, and concentrate on sprites ? 2- and 3-bit operation modes. That's 4 or 8 color operation. I guess it's still 16x16 pixels only ?

 

Sprites and tiles work the same way in the enhanced color modes, with the only main difference being that color index 0 is always transparent for sprites. Yes, the 8x8 or 16x16 sizes did not change.

 

I guess the 12-bit color registers are not preset (as in user-definable) ?

 

Yes, the 64 12-bit palette registers are user programmable.

 

I think drawing must be so much easier if you can draw with the "right" colors - the colors defined / to be defined.

 

I agree, but I was trying to keep the editor simple for now.

 

How does these 12-bit colors relate to 24-bit ?

 

There are 4-bit per color, so there are 16 steps for each color from black (0000) to max color (1111):

0000	 . . . 1111
no red   . . . full red
no blue  . . . full blue
no green . . . full green

 

To pull the 12-bit palette from a 24-bit palette, you divide 255 by 15, which is 17, and that defines the set for the color values in each red, green, and blue:

 

0, 17, 34, 51, 68, 85, 102, 119, 136, 153, 170, 187, 204, 221, 238, 255

 

With whatever colors you choose, I think it's equally important to be able to pick a background color for editing (even though this background will end up being transparent) ?

 

Correct, if you have a way to define the background, then any 0-index color would be transparent and show the background color, or a tile's color if the transparent sprite pixel was over a tile at the time it was drawn.

 

Now, 16x16 pixels editing shouldn't really require stuff like lines and fills, but even so, it might be easier to draw the sprites in a more ordinary graphic editor. Now if you save the image as PNG (Portable Network Graphics), then an App could load the image and convert patterns and colors into the desired statements ? If you want to edit an existing sprite, you'd take the original image (which you did save) and alter this before putting it through the oneway conversion ?

 

Yes, that is possible I suppose. And the app that converts the image could also deal with complete "sets" of patterns, i.e. the full 256 8x8 tiles. But the process would be much more involved than having a dedicated editor that had knowledge of the way the colors and patterns are laid out. Also, you have to deal with a file format that produces indexed colors, or your converter program would have to identify all the unique colors in the graphic and let you assign index value (0 to 3 or 0 to 7) for each color. A dedicated editor would do that for you.

 

Anyway, it was just a thought if modifying "Patterns" was easy and you had the interest in doing it.

Edited March 10, 2012 by matthew180

[sometimes99er]

I'll look at it.

 

Apart from the straightforward hexadecimal in input (/output) fields, any special formatting on the clipboard (output only) ?

[matthew180]

The text input / output field is fine how it is IMO. If you want to make the input ignore any characters other than hex, then somone could paste in some addembly like >FFEE, >AABB or XB "FFFFAABBCCDD1234" (with the quotes) and still have it work. As for the output, if you wanted to add a selection for "none", "assembly", or "XB", that might be nice, but certainly not necessary.

[sometimes99er]

The input/output field should already behave like that.

 

>FFEE, >AABB or XB "FFFFAABBCCDD1234"

37 characters becomes

FFEEAABBBFFFFAABBCCDD1234

25 chaarcters

 

>FFEE, >AABB or XB "FFFFAABBCCDD1234" >FFEE, >AABB or XB "FFFFAABBCCDD1234" >FFEE, >AABB or XB "FFFFAABBCCDD1234"

113 characters - more than 64 characters becomes

FFEEAABBBFFFFAABBCCDD1234FFEEAABBBFFFFAABBCCDD1234FFEEAABBBFFFFA

64 characters

 

If you can't see the tool at the top, it is still embedded/referenced here on AtariAge, but the host, planet-99.net, does not exist right now, at least here at my end.

Edited March 11, 2012 by sometimes99er

[Willsy]

It seems to be a problem with my web host - turboforth.net is also down.

 

I'll contact them.

[matthew180]

The input/output field should already behave like that.

 

Very cool! I didn't know that.

[sometimes99er]

Yes, got an Android the other day. Nice to see Patterns running on it, but otherwise not very useful (on the phone). Hopefully I will finish projects on TI-99/4A style demos and games in Flash, but also more Android specific ones (coding in Java). Managed to merge in some F18A functionality. Will preserve the old drawing functionality (pixels on or off based on what's been clicked) for the sake of speed (speedy drawing). You'll be able to change the original background and foreground colors, and still operate in the original mode. If however you select any other colors (other than the first two - being background and foreground), you will effectively have F18A mode kick in. From then on you draw in whatever color selected (no delete effect based on what's been clicked).

 

The color picker, which is yet to be designed, will support quick access to the original colors of the TI-99/4A, but also boosts selection tools accessing the 4,096 colors of the F18A.

[matthew180]

Very nice! I can't wait to see the enhancements. Thank you!

[sometimes99er]

Testing ...

 

[media=600,450]http://sometimes.planet-99.net/patterns0009.swf[/media]

 

Trying to preserve a good deal from the old Patterns, but also cleaning up a lot of code. What is missing is the ability to edit individual colors, input output fields and copy to clipboard. Flash does not allow complete control of right mouse click, so everything is done with left mouse. In the original 2 color mode, there's the special erase mode, detecting what you click. In the F18A mode, there's no erase feature - choose whatever color you want to paint with. Also F18A mode is only 8 colors, just limit yourself to the first 4 colors if that's what you want (I'll explain more about this when I get it all together).

[matthew180]

Very cool! It will be interesting to see the input fields working. I really like the preview at various sizes too, very helpful!