[sega16]

I am not sure why I did not post this here earlier but nonetheless it is here now and with a new release. Since I do not want to do a quick double post I have put the content of what was a new post on other boards at the bottom of this post.

Retro Graphics Toolkit is a GPLv3 or later licensed open source graphics editor that stores truecolor information in addition to regular tiles. This allows for non destructive editing of palettes. When the palette is changed the tiles can be dithered to fit the new palette.

With Retro Graphics Toolkit you can save palettes, tiles, tilemaps, sprites and levels for the Sega Genesis, NES, Master System and Game Gear. Support for more systems is planed for future versions.

The best way to get started With Retro Graphics Toolkit is to read the wiki
https://github.com/C...cs-Toolkit/wiki

Although there is nothing special about the format outputted by Retro Graphics Toolkit (complying with existing formats for the system is one of my goals). I do provide examples currently for the Sega Genesis, NES, Master System and Game Gear.
https://github.com/C...master/examples
Screenshots:

The plane editor is what you will be using when importing an image and displaying on the game system. You don't even have to worry about making sure your image's dimension are a multiple of the tile width and tile height for the system. Retro Graphics Toolkit can center images to conform to tile size. This makes it very easy to directly import an image. Also a selection of color quantization algorithms and ways to pick which tile uses what row allows for quick and easy high quality images.

Retro Graphics Toolkit features an advanced sprite editor capable on creating groups making alignment much easier, even including buttons to do very easy alignment and Retro Graphics Toolkit can import an image creating a sprite group large images are divided up using as few sprites as possible.

Another feature that goes in hand with Retro Graphics Toolkit's philosophy of easy importing is the sprite sheet importer. Typically sprite sheets have many sprites on it that are spaced in a non-uniform way with a background color that is not used anywhere on the sprite or uses an alpha channel. This means that simply dividing up the image into even rectangles will not work. Retro Graphics Toolkit solves this problem by first identifying the background color


If a background color was used that is treated as transparent. Next line segments are created and those line segments are merged to create rectangles. The longest line segment determines the width and height of the rectangle that is created.



The level editor is a new feature starting in version 0.8 RC1. Sprites from the sprite editor can be displayed on the level editor as well.


The easy to use palette editor is great for viewing the entire palette at once making changes a breeze.

Levels are constructed with chunks. This shows Green Hill zone's graphics converted to the NES. And it looks much better than Somari. This shows the power of Retro Graphics Toolkit.

Source code: https://github.com/C...raphics-Toolkit
Windows binary:
https://github.com/C...sToolkit.exe.7z
To download the windows binary click "View Raw" (without the quotes).

If you have any bug reports, feature requests, pull requests or patches I would like to hear about them. With Lua scripting it should be much easier to get Retro Graphics Toolkit to do what you need as opposed to writing your own tool. If you made any useful Lua scripts be sure to post them.


Today is a good day for Retro Graphics Toolkit and its users. I have decided to do a new release.

Introducing Retro Graphics Toolkit v0.8 RC1:

Previous versions of Retro Graphics Toolkit were missing two important features:

• Flexibility
  
• Level Editing

Flexibility is gained via Lua scripting with an extensive binding for FLTK, zlib, kens and Retro Graphics Toolkit itself. As you can see in the screenshot below: The mandelbrot was generated via the included mandelbrotToTilemap.lua example.



As it turns the second is made possible by the first. The level editor GUI was implemented entirely in Lua. This shows the power of the Lua bindings.

Also Retro Graphics Toolkit only supported the Sega Genesis and the NES. That is about to change today as Retro Graphics Toolkit now supports the Master System and Game Gear. It also has partial support for the TMS9118.

This is a release candidate because I still need to finish TMS9118 and some of the Lua bindings need a bit of work and need to be more complete especially the metasprite binding. However I wanted to do a release because many bugs were fixed. So even if you have all the features you need in 0.7 you should still upgrade.

TMS9118 support is lacking in the two modes in which for every eight tiles the foreground and background color of the tile is selected. This is due to the fact that Retro Graphics Toolkit's goal is to make the tiles look as close as possible without user intervention. I have already tried attempting to implement a good color selection algorithm for mode two but I was not happy with the results. I was hoping that someone from the community would know how to solve this better than I.

Also on the topic of algorithms I am interested in a better method for selecting which tile uses what row. Does anyone have any experience with that?
As always let me know if you have any bug reports, feature requests, patches and pull requests.

The download link has not changed it is still: https://github.com/C...sToolkit.exe.7z (for windows users)
The source is located here: https://github.com/C...raphics-Toolkit

This post has been edited by sega16: 09 July 2015 - 12:14 PM

[Rabid]

It's so beautiful, after months of converting resident evil 2 backgrounds to mega drive formats as a pointless project this seems perfect!

[flamewing]

Been awaiting a release now for some time; now to play around with it.

sega16, on 09 July 2015 - 03:06 AM, said:

TMS9118 support is lacking in the two modes in which for every eight tiles the foreground and background color of the tile is selected. This is due to the fact that Retro Graphics Toolkit's goal is to make the tiles look as close as possible without user intervention. I have already tried attempting to implement a good color selection algorithm for mode two but I was not happy with the results. I was hoping that someone from the community would know how to solve this better than I.

You may want to look into the color selection algorithms used in this project; I had some success in converting and scaling art with it, although it does need some hand-tweaking for best results. It selects colors one color at a time, executing multiple iterations until everything converges. Another approach would be to use k-means segmentation using the color metric you already define in color_compare.cpp; here is a summary of several techniques. You probably can lift several of these from OpenCV.

sega16, on 09 July 2015 - 03:06 AM, said:

Also on the topic of algorithms I am interested in a better method for selecting which tile uses what row. Does anyone have any experience with that?

What I would do is try rendering the tile in all rows, then use the row with the smallest total distance (= sums of the distances of all pixels) to the original tile. But that can get slow.

[GeneHF]

Fine program you got there, but you might wanna settle down with the up-selling. Parts of your speech feel like you're directly potshotting the works of others here. Not the best way to make a first impression, especially when you then try to ask for a little help.

[Ritz]

Good stuff!

sega16, on 09 July 2015 - 03:06 AM, said:

(more systems planed for future versions)

Neo Geo, I dare you.

Tangential, but now that you nerds are starting to get into color quantization, this seems like as good a time as any to say that I really REALLY wish there were a format for color indexes greater than 256. This old guy had it all figured out and then never followed through because true color had become the standard, but there's still a definite use for that in game development today. I want high color palette cycling.

[sega16]

@flamewing Thank you for the suggestions. I was not aware of the Pixelated Image Abstraction algorithm. This will be useful for tile palette row selection. Also the image segmentation algorithms look useful especially k-means. I hope to try and add some of these.

@GeneHF Thank you for telling me that. Sometimes I have trouble knowing how others will react to something that I have written. Is it the Are you tired of... introduction that seems this way? The reason I wrote the introduction that way is because I wanted to answer the question that I thought people would have when they read this topic: what is this and why should I use it? After that question is answered the next question might be: what advantages does this provide over what I am using now? I presume how I handled answering the third question is what is bothering you? My goal is not to cause offense. I will edit my post and try a Wikipedia style post please tell me if you think it is more effective.

@Ritz Neo Geo would be very interesting and in fact I will do it. It does rely more heavily on sprites so what I will do is have a mode where the sprites are treated as tiles to make layout easier. As for more than 256 color support that can already be done. I am just not sure if the quanitzers I am using support that.

This post has been edited by sega16: 09 July 2015 - 11:54 AM