Jump to content
Atarius Maximus

Creating 7800basic compatible graphics images with Gimp

Recommended Posts

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.
post-2143-0-90220100-1402947758_thumb.png

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

post-2143-0-03496800-1402947760_thumb.png

 

Next, right click on the palettes dialog box and click Import Palette.
post-2143-0-09860200-1402947761_thumb.png

 

Once the window is open, click on Image, Palette name (rename to Atari7800), and click on Import.
post-2143-0-93783600-1402947761_thumb.png

 

Click on Image | Mode | Indexed.
post-2143-0-56403900-1402947762_thumb.png

 

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

 

post-2143-0-13982400-1402947763_thumb.png

 

Change setting back to RGB, just so we can go back and change it to Indexed again to make one more modification...
post-2143-0-90793500-1402947763_thumb.png

 

 

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

 

post-2143-0-50183700-1402947764_thumb.png

 

Click on Use custom palette, then the button next to it.
post-2143-0-11331200-1402947765_thumb.png

 

Click on the 7800palette that was just added, then convert.
post-2143-0-87789900-1402947765_thumb.png

 

Click on open image, and open the tileset_rocks image from one of RevEng's samples in the distribution.
post-2143-0-53983800-1402947772_thumb.png

 

Click on View | Zoom | 800% so you can actually see the image on the screen.
post-2143-0-60831800-1402947773_thumb.png

 

Resize the window so you can see the entire image.
post-2143-0-20668900-1402947774_thumb.png

 

Click on Windows | Dockable Dialogs | Brushes, we need the brushes dialog box open.
post-2143-0-89601700-1402947774_thumb.png

 

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.
post-2143-0-56767300-1402947775_thumb.png

 

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.
post-2143-0-27029400-1402947776_thumb.png

 

Click on the brush tool to change the image.
post-2143-0-92346800-1402947776_thumb.png

 

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.
post-2143-0-52468400-1402947777_thumb.png

 

When you're done, click on File | Export As to save
post-2143-0-17722300-1402947778_thumb.png

 

Export the image as a PNG file and you're ready to go.
post-2143-0-85258500-1402947778_thumb.png

post-2143-0-90220100-1402947758_thumb.png

post-2143-0-03496800-1402947760_thumb.png

post-2143-0-09860200-1402947761_thumb.png

post-2143-0-93783600-1402947761_thumb.png

post-2143-0-56403900-1402947762_thumb.png

post-2143-0-13982400-1402947763_thumb.png

post-2143-0-90793500-1402947763_thumb.png

post-2143-0-50183700-1402947764_thumb.png

post-2143-0-11331200-1402947765_thumb.png

post-2143-0-87789900-1402947765_thumb.png

post-2143-0-53983800-1402947772_thumb.png

post-2143-0-60831800-1402947773_thumb.png

post-2143-0-20668900-1402947774_thumb.png

post-2143-0-89601700-1402947774_thumb.png

post-2143-0-56767300-1402947775_thumb.png

post-2143-0-27029400-1402947776_thumb.png

post-2143-0-92346800-1402947776_thumb.png

post-2143-0-52468400-1402947777_thumb.png

post-2143-0-17722300-1402947778_thumb.png

post-2143-0-85258500-1402947778_thumb.png

  • Like 12

Share this post


Link to post
Share on other sites

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:

 

post-18-0-86321500-1402928924_thumb.png

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

 

Or a more 'brillance neutral' palette here:

 

post-18-0-96793800-1402928923_thumb.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.

  • Like 3

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.)

Share this post


Link to post
Share on other sites

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. :P

 

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

Share this post


Link to post
Share on other sites

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."

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by juanitogan

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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:

 

attachicon.gifATARI256_26.7x6LG.PNG

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

 

Or a more 'brillance neutral' palette here:

 

attachicon.gifATARI256_26.7x0LG.PNG

Here is the corresponding *.act file: attachicon.gifAtari256_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?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...