Creating 7800basic compatible graphics images with Gimp

[+Atarius Maximus]

I spent a great deal of time trying to figure out how to create 7800basic compatible graphics with my first game, so I thought I'd share the steps I took to make it work. Using Gimp is the easiest way to get started, you can download it here. I threw this together pretty quickly, I can add more detail if anyone needs that.

First, open the 7800basic palette file, which you can download here. Please see the next post in this thread for palette attachments from Trebor that include a more accurate layout.

Next, click on Windows | Dockable Dialogs | Palettes, we need the Palettes dialog box to be open.

 

Next, right click on the palettes dialog box and click Import Palette.

 

Once the window is open, click on Image, Palette name (rename to Atari7800), and click on Import.

 

Click on Image | Mode | Indexed.

 

Click on Generate Optimized Palette and change the number to 13, then click on convert.

 

 

Change setting back to RGB, just so we can go back and change it to Indexed again to make one more modification...

 

 

Click on Image | Mode | Indexed again to make one more change.

 

 

Click on Use custom palette, then the button next to it.

 

Click on the 7800palette that was just added, then convert.

 

Click on open image, and open the tileset_rocks image from one of RevEng's samples in the distribution.

 

Click on View | Zoom | 800% so you can actually see the image on the screen.

 

Resize the window so you can see the entire image.

 

Click on Windows | Dockable Dialogs | Brushes, we need the brushes dialog box open.

 

Change brush size to 1.0. Go to Windows Menu | Toolbox or press CTRL+B to open the Toolbox Tool Options if you don't see it on screen.

 

Click on color picker tool and choose one of the four colors to modify the image. The colors in this image don't matter yet, as they are changeable with the PxCx command in the code. One of the colors is transparent and will take the background color.

 

Click on the brush tool to change the image.

 

Use the brush tool to modify a 16x16 area, there are three side by side in the samples from RevEng, each is 16 pixels across. Don't worry about the colors, as they are set with the PxCx commands in software. You can use the same colors in the sample images.

 

When you're done, click on File | Export As to save

 

Export the image as a PNG file and you're ready to go.

[Trebor]

Maximus,

 

Thank you for providing those detailed steps - it is greatly appreciated.

 

May I humbly suggest a closer to accurate layout of the 256 color Atari (NTSC) palette, matching the brilliance and file type linked above here:

 

Here is the *.act file which can be imported: Atari256_267NTSCx6.zip

 

Or a more 'brillance neutral' palette here:

 

Here is the corresponding *.act file: Atari256_267NTSCx0.zip

 

They are both set with a 26.7 degrees phase shift and not manually hand-picked, that better matches the documented as well as 'real hardware' results of the systems.

[gambler172]

Hi AM

wow...i will have a look at this by the weekend

greetings Walter

[gambler172]

Unfortunately,i cannot see any pics in your post

greetings Walter

[Marc Oberhäuser]

No pictures for me as well.

 

BTW: Works it the same way in Photoshop? I own CS5 and really don't want to downgrade to GIMP.

[+Atarius Maximus]

No pictures for me as well.

 

BTW: Works it the same way in Photoshop? I own CS5 and really don't want to downgrade to GIMP.

 

Unfortunately,i cannot see any pics in your post

greetings Walter

 

Picture links are fixed. Marc, I assume the process would be similar in Photoshop, but I can't give you detailed directions for it.

[gambler172]

Hi AM

now it works.Thanx for this little beginner tutorial

greetings Walter

[Loktar]

No pictures for me as well.

 

BTW: Works it the same way in Photoshop? I own CS5 and really don't want to downgrade to GIMP.

 

Works pretty close to the same I did it with CC just fine, haven't tried with cs5 or 6 as I don't have those installed anymore.

 

Download the .act and put it into your swatches directory

 

\Users\%username%\AppData\Roaming\Adobe\Adobe Photoshop CC\Presets\Color Swatches

 

Then make sure the swatches window is displayed (go to window/swatches), then just click the top right of the swatches window and go to either load or replace swatches, change the filetype that PS is looking for in the loading dialog to .ACT and you should see your file there, load it and all the colors are available.

[pacgreg]

I followed all of the steps, but what does this final image do?

[gambler172]

Well,i tried it,but this is much to complicated for me......

Isn`t there any other program,i can use to draw my sprites?????

GIMP is too hard

greetings Walter

[TXG/MNX]

Yep for me aswell would be great if 7800basic could read normal png,gif or jpg that any art package can output or a simple convertor

[TXG/MNX]

Maybe www.imagemagick.org/ can be used will look at it but i am not a very skilled c++ programmer.

[RevEng]

Yep for me aswell would be great if 7800basic could read normal png,gif or jpg that any art package can output or a simple convertor

MARIA holds its images in an indexed/palatalized fashion. I could do a conversion from your various RGB sources to indexed on import, but then your MARIA images will have semi-random color indexes. e.g. when we see the player sprite facing away, it may have fewer colors for that frame, and the indexes will be different and the display of that sprite won't use your colors correctly.

 

The discipline for keeping color indexes consistent will need to be somewhere. With an anything goes import you'll need to tediously sort the indexes in a non-visual fashion in the source code with each and every "incgraphic" command, versus the current method of working up front with indexed source images and just keep color indexes consistent there.

 

One of the resources to be planned and managed in a 7800 game is the palette colors. Clever planning will allow your game to have a ton of apparent colors. Ignoring palette management will squander palette resources.

 

tl;dr? MARIA isn't a PC. If you don't feed her images with consistent indexes, your graphics won't have consistent colors.

[Mord]

With regards to this, is it possible to set it up so if you're trying to import a graphic for a 2-bit color mode, and you're trying to feed it a 4-bit color png, if it can attempt to import it so long as only the first 4 colors are used in the imported graphics? ie: if it finds index 4-15 (from 0-15) in the imported graphics, it balks, otherwise processes as a 2-bit.

 

The graphics editor I tend to use, Paint Shop Pro 8, can apparently save as 1-bit (2 colors) or 4-bit (16 colors) but it has no option for 2-bit. It can open 2-bit pngs just fine, but it apparently converts them to 4-bit in the process so when you save the file it's no longer usable by 7800basic. (I tested this by just opening up one of the sample graphics and instantly resaving it without any modifications. End result, new file is unusable because it now has 4-bit depth color.)

[RevEng]

Sounds reasonable. I can kick the current error down to a warning, and see what I can do. If it does work out, hopefully I won't get a bunch of "my 256 color image doesn't display right" posts.

 

When you get a chance, please PM me a sample image or two so I have something to work with.

[Mord]

Sent.

 

You can probably cut down on the number of posts complaining about that so long as the importer gives a specific error like "Too many unique colors found in image. Mode X may only use indices 0 to Y."

[+xucaen]

I followed all the steps in the first post, and I am up to the step which reads "open the tileset_rocks image from one of RevEng's samples in the distribution".

 

Where would I find RevEng's samples?

Going forward, when I want to create a new sprite, what width, height, resolution, color space do I pick?

Once I have exported as my sprite.png, what tool do I use to convert it?

[Mord]

Rev's examples are included with 7800Basic. Once you unzip it, there will be a samples directory.

 

The thing is, this tutorial is for preparing an image to be imported into a 7800basic program - the tool that converts it to usable asm is 7800basic itself.

 

You could of course make a small 7800basic program that does little more than import the graphics, then look for the .asm program that gets generated as part of the compiling process. If you know where to look for it, the graphics of the images will be in the assembly that you could likely just copy/paste into your own programs.

[Savage38]

Anybody got a good way to implement this method in photoshop? I followed it as closely as I could but not having success.

[juanitogan]

The discipline for keeping color indexes consistent will need to be somewhere.

 

I don't know anything about 7800basic other than what I just now read (I was looking for something else) but, if I were handling this, I would modify incgraphic to accept an optional second PNG file to set the color order in the import. That way, 8-bit PNGs can be supported (and whatever other bit widths you care to support) instead of just the poorly-supported-in-3rd-party-tools indexed-2-bit PNGs. I believe most users will find that creating an extra palette.png for each of their design palettes, in their favorite paint or animation tool, at their favorite bit width (probably 8-bit with the full 7800 palette, or subset of that palette), will be far easier than converting their assets to indexed 2-bit PNGs all the time. Total freedom to work with their art assets in their reference color, and keep them that way.

 

Thus, use of incgraphic optionally becomes something like:

incgraphic p1sprite1.png palette1.png 160A

palette1.png would be a 4x1-pixel file with the first pixel being the alpha color and the next three being PxC1,2,3 in that order. If a color is then found in p1sprite1.png that does not exist in palette1.png, throw an error. Similarly, 1-color and 12-color sprites could also be supported.

 

This method has the caveat that you cannot create p1sprite1_colorX constants with it, so the user will need to set PxCx to the correct index values themselves -- unless a third PNG/PAL/ACT index file were included to lookup the palette colors in (which may be too much for the user to make or manage correctly given all the 7800 palette variants out there). Personally, I think that users managing the indexing in code is a non-issue. This:

P1C1 = p1sprite1_color1
P1C2 = p1sprite1_color2
P1C3 = p1sprite1_color3

becomes this:

P1C1 = $04
P1C2 = $0f
P1C3 = $18

So what. I would rather go that route. It only needs to be done once per palette (or palette change) and not once per image, and I can create my own constants if I want.

 

Or, perhaps, a new and optional command to index the palette image to a master IrfanView or Adobe palette file:

incpalette palette1.png index.pal <or index.act>

creates:

const palette1_color1 = $04
const palette1_color2 = $0f
const palette1_color3 = $18

I suppose all this would also change the other inc* commands similarly.

 

There is even precedence for this model. I recall needing to supply a palette image to ffmpeg when using it to generate animated GIFs with a limited palette. I felt that was a fine solution to the problem (albeit, a slightly different problem from this one).

 

----

 

Then, once all that is working (or instead of changing incgraphic), I would consider adding a function to the language to bring these in at compile time (How slow could it really be these days?) which would also put the user in more control of things like variable naming. This, well, probably needs a preprocessing loop added to the compiler if you don't have one for such things already... and support for reading string data (filenames) in these preprocessor commands. ... But, I suppose this asset management is usually handled almost as well in a script file with the command-line stuff.

 

----

 

In case the info is useful to anyone, IrfanView supports saving 2-bit PNGs if you also use the PNGOUT plugin with it. It doesn't appear to have support for indexed palettes so it may not be of much use here. But it's there. Also, I currently use GraphicsGale to convert .act palette files to .pal palette files but there are probably a dozen tools to do this (and note that the .pal files that Trebor supplies are really .act files and need to be renamed as such to convert them).

Edited January 26, 2018 by juanitogan

[+xucaen]

Would having a paint program specifically made for drawing 7800 sprites be helpful?

[juanitogan]

Would having a paint program specifically made for drawing 7800 sprites be helpful?

Not to me. It would have to be able to compete with -- and cooperate with -- all my other favorite tools for such work. More likely, a plugin to a current tool, or a 3rd-party tool to do more or less what I just described -- but to create 2-bit-indexed PNGs -- might be useful if 7800basic doesn't build this in. Or, maybe, write an ImageMagick script to do it.

[Lavalamp]

Maximus,

 

Thank you for providing those detailed steps - it is greatly appreciated.

 

May I humbly suggest a closer to accurate layout of the 256 color Atari (NTSC) palette, matching the brilliance and file type linked above here:

 

ATARI256_26.7x6LG.PNG

Here is the *.act file which can be imported: Atari256_267NTSCx6.zip

 

Or a more 'brillance neutral' palette here:

 

ATARI256_26.7x0LG.PNG

Here is the corresponding *.act file: Atari256_267NTSCx0.zip

 

They are both set with a 26.7 degrees phase shift and not manually hand-picked, that better matches the documented as well as 'real hardware' results of the systems.

 

 

 

Has anyone come across PAL .act files for GIMP?

[Trebor]

Has anyone come across PAL .act files for GIMP?

 

The PAL act files in the below zip archives should work. They correspond similar to their NTSC counterparts in the prior post.

 

Atari256_267PALx6.zip

Atari256_267PALx0.zip