Retro Graphics Toolkit

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Retro Graphics Toolkit
by on (#108922)
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/ComputerNerd/Retro-G ... olkit/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/ComputerNerd/Retro-G ... r/examples
Screenshots:
Image
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.
Image
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
Image

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

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

Image
The easy to use palette editor is great for viewing the entire palette at once making changes a breeze.
Image
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/ComputerNerd/Retro-Graphics-Toolkit
Windows binary:
https://github.com/ComputerNerd/Retro-G ... kit.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.
Re: Retro Graphics Toolkit
by on (#108923)
1: Does it have features for SNES? If not, Can you add support?

2: Can there be a Windows binary too? I use Windows 7 64-bit.
Re: Retro Graphics Toolkit
by on (#108924)
Hamtaro126 wrote:
1: Does it have features for SNES? If not, Can you add support?

2: Can there be a Windows binary too? I use Windows 7 64-bit.

It does not have SNES support right now I will add it at some point though also I am working on a windows binary right now. Right now I am waiting for fltk to compile.
Re: Retro Graphics Toolkit
by on (#108928)
Sorry for the double post but I now have a windoze binary up
https://github.com/ComputerNerd/Retro-G ... kit.exe.7z
Click View Raw to download
Re: Retro Graphics Toolkit
by on (#108966)
*Downloading*.
Seems to be pretty cool! :)
Hope to see support for Sega Master System / Game Gear someday!

EDIT: There are many DLL files missing and no clue of what I should download to make it work.
Re: Retro Graphics Toolkit
by on (#108968)
Sorry about the dll error it is caused by me not staticly linking libgcc and libgccstd++ I will fix that shortly I will make a reply when I have fixed that.
Re: Retro Graphics Toolkit
by on (#108970)
If you had DLL errors with the windows binary please re-download.
https://github.com/ComputerNerd/Retro-G ... kit.exe.7z
Click View Raw to download
Re: Retro Graphics Toolkit
by on (#109225)
nintendo8 wrote:
If you had DLL errors with the windows binary please re-download.
http://www.mediafire.com/download.php?pj85d8vg666tx5c


Now it works - thank you so much! :)
Re: Retro Graphics Toolkit
by on (#112554)
Just to let you guys know I added support for automatic 4 row palette generation and more awesome features check it out at github https://github.com/ComputerNerd/Retro-Graphics-Toolkit
Image
Re: Retro Graphics Toolkit
by on (#112707)
Someone requested an updated windows binary so here it is
https://github.com/ComputerNerd/Retro-G ... kit.exe.7z
Click View Raw to download
Re: Retro Graphics Toolkit
by on (#112883)
Hmm is that raspbian I see there?
Re: Retro Graphics Toolkit
by on (#112892)
No it is Gentoo GNU/Linux running lxde. Those screenshots are old I switched to xfce and there are some slight gui changes.
Re: Retro Graphics Toolkit
by on (#112958)
nintendo8 wrote:
No it is Gentoo GNU/Linux running lxde. Those screenshots are old I switched to xfce and there are some slight gui changes.


Ah, I see. I'm only familiar with Ubuntu and Raspbian, honestly.
Re: Retro Graphics Toolkit
by on (#132224)
I am sorry to bump this old topic but I would like to point out that recently I have been doing some work on Retro Graphics Toolkit and have made huge improvements. I recently started keeping a change-log so that what has been improved is apparent https://github.com/ComputerNerd/Retro-G ... /Changelog I would like to point out that this only covers since I started keeping track of changes using a changelog, it is likely that there are more improvements or bug-fixes since the last release you downloaded that is not mentioned in the changelog. The most notable improves that for v0.7 is the advanced sprite editor and undoing and redoing for most actions.

I will note that about the NES example was my first NES program that I have ever wrote. If there are any issues with code being suboptimal or not working on real hardware feel free to tell me. It was good to see that all along Retro Graphics Toolkit has been producing valid data for the NES.

For sonic sprite mapping When importing and exporting it uses the same format the the github disassembles are using. So for sonic 1 it will import and export assembly data. For sonic 2 binary data will be produced. I tested Retro Graphics Toolkit's export sonic 2 mapping and dplc and it produced bit identical output. Please tell me if this is not the case for other objects.
Re: Retro Graphics Toolkit
by on (#132230)
I propose these be added:

Nintendo's PPU display format (used in various games, example: SMB1-3, Duck Hunt, etc.)
Mario 1 tileset format (Attributes are 4-quad, depends on tile bits 6 and 7: $00, $40, $80, $C0)
Mario 3 tileset format (Similar to SMB1, but uses a different tile renderer, attribute bits are the same though!)

I'd really appreciate it if these get added.
Re: Retro Graphics Toolkit
by on (#132232)
If we are talking about the same thing it already supports PPU display format. In fact I made an example using Retro Graphics Toolkit for the NES see https://github.com/ComputerNerd/Retro-G ... es/NES/asm
As for "4-quad" attributes do you mean http://wiki.nesdev.com/w/index.php/PPU_attribute_tables if so Retro Graphics Toolkit already supports that. I will look into the Mario games format and add it. I think it would be a beneficial feature to have.
Re: Retro Graphics Toolkit
by on (#132237)
The PPU format is the format based off RLE, but also allows uncompressed 32-byte tile display

Orbit2002 explained the format here: http://forums.nesdev.com/viewtopic.php?f=5&t=10676&p=120677&hilit=ppu+format#p120677

SMB1 (and 2j) and 3 both can use the disassemblies if you add support:

SMB3DIS is by Southbird, SMBDIS and SMB2JDIS (Lost levels) are by Doppelganger and need credit when used.

http://www.romhacking.net/documents/344/ (SMBDIS)
http://www.romhacking.net/documents/653/ (SMB2jDIS)
http://sonicepoch.com/sm3mix/ (SMB3DIS)

By 4-Quad, The Tileset is split into 4 mini-sets representing 4 color attributes within $00-$3F, $40-$7F, $80-$BF, and so forth...
These are colored indivisually to better suit Nintendo's graphical needs.
Re: Retro Graphics Toolkit
by on (#132300)
I now understand what you mean by "4-Quad". When I implement it I will let the user choice the divisor factor in-case they don't have 256 tiles. Also I will add support for the mario games.
Re: Retro Graphics Toolkit
by on (#135487)
I apologize for the double post but I am considering the direction of the project and I realize one big issue with this project in it's current state is the static nature of what you can do in Retro Graphics Toolkit that is you can only really do what I have coded for example there was not an automated way to sort palettes by hue lightness or saturation until I coded that feature in because I needed it for myself. You would have to have done it manually or modify the source code something that I would be happy to see but may be a challenge for some people. To remedy this issue I have decided to work on adding a scripting language that also can define importing and exporting rules that allow for custom file formats beyond what I have coded. I understand that the process of coming up with an idea of how the programming language should be and making it are easier than making one that is user friendly and one that is easy to program in. So it is for this reason that I have decided to announce early before any code exists that parses this in hopes that I can get feedback on my specification see https://github.com/ComputerNerd/Retro-G ... -scripting. I would like to understand the needs of the users and viewpoints on the syntax I choice. I am wondering about the choice of newlines having meaning as some basic variants do or using a semicolon to end the statement like in C or java. The advantage of newlines ending the statement is that it may be a bit easier for beginner coders and it is less to type as most people would put a newline anyway. The disadvantage is that statements cannot be split into multiple lines. I am planning the code be compiled to bytecode instead of being parsed line by line so the code will have some speed to it.
Here is some example code with the current syntax
Code:
# Changes the palette using hue saturation lightness
type=palette
gui double shifth<Shift hue by>,shifts<Shift saturation by>,shiftl<Shift lightness by>
begin main
end main
begin loop
   double hsl[3]
   unsigned rgb[3]
   rgbtohsl(r,g,b,hsl)
   hsltorgb(rgb,(hsl[0]+shift)%360,(hsl[1]+shifts)%1,(hsl[2]+shiftl)%1)
   rgbToPalSetEntry(rgb[0],rgb[1],rgb[2],entry)
end
func rgbtohsl(unsigned r,unsigned g,unsigned b,double*hsl)
   double R=r/255,G=g/255,B=b/255
   double cmax=max(r,max(g,b))
   double cmin=min(r,min(g,b))
   double delta=cmax-cmin
   if cmax==r
      hsl[0]=(G-B)/delta%6*60 # Yes you can do module on double
   eif cmax==g
      hsl[0]=((B-R)/delta+2)*60
   else
      hsl[0]=((R-G)/delta+4)*60
   end
   hsl[2]=(cmax+cmin)/2
   if delta
      hsl[1]=delta/(1-fabs(2*hsl[2]-1))
   else
      hsl[1]=0
   end
end
func hsltorgb(unsigned*rgb,double h,double l,double s)
   double C=(1-fabs(2*l-1))*s
   double X=(1-fabs(h/60%2-1))*C
   double m=l-(C/2)
   double R,G,B
   if h>=300
      R=C
      G=0
      B=X
   eif h>=240
      R=X
      G=0
      B=C
   eif h>=180
      R=0
      G=X
      B=C
   eif h>=120
      R=0
      G=C
      B=X
   eif h>=60
      R=X
      G=C
      B=0
   else
      R=C
      G=X
      B=0
   end
   rgb[0]=(R+m)*255
   rgb[1]=(G+m)*255
   rgb[2]=(B+m)*255
end

Here is an example of an importing/exporting script
Code:
# Sonic 1's level format based on information from the sonic retro wiki
type=level
gui bool loop # Upon running this a checkbox will be created on the level editor and for each element the boolean option loop will be stored in ram and in project files and when exporting this variable will be updated automatically storing the current element
begin main
   which.max=127
   askfile()
end
begin headerread
   width=read1()+1
   height=read1()+1
end
begin headerwrite
   write1(width-1)
   write1(height-1)
end
begin loopread
   unsigned val=read1()
   which=val.0_6
   loop=val.7
end
begin loopwrite
   write1u(which.0_6|(loop<<7))
end

Please do tell me what you guys think about this.
Re: Retro Graphics Toolkit
by on (#135489)
You could always embed Lua, which appears to be the go-to language for adding scripting to free software applications.
Re: Retro Graphics Toolkit
by on (#135517)
Alright lua is added now I can see why lua was suggested. As in you can now run a lua script from Retro Graphics Toolkit. Now what I will do is work on providing an api allowing access to internal Retro Graphics Toolkit data and useful functions. I have decided to statically link lua with Retro Graphics Toolkit to maintain the tradition of only one file that does not need to be installed. Adding lua did not increase executable size that much.
Re: Retro Graphics Toolkit
by on (#135547)
I am running Debian, and when I try to build it I get:

Code:
make: *** No rule to make target 'lua/lapi.o', needed by 'RetroGraphicsToolkit'.  Stop.


I have installed the lua development packages, but there is no change. Is there anything specific I ought to be doing here? Some other dependencies I need?
Re: Retro Graphics Toolkit
by on (#135555)
I just pushed a commit that alters the build process. Lua is built locally in order to not mess with your distribution of choice's instillation of Lua. Please read and follow https://github.com/ComputerNerd/Retro-G ... er/INSTALL note that the term 'INSTALL' is a bit misleading instead it should be called Compile however INSTALL is a recognized convention for how to compile the program. You do not need to install Retro Graphics Toolkit it is a portable program. I hope this helps if not please tell me if you get any other errors and I will address them. Also thank you for trying to build it it does help getting these kind of replies as I want this to work on a wide verity of systems.
Re: Retro Graphics Toolkit
by on (#150691)
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.

Image

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/ComputerNerd/Retro-Graphics-Toolkit/blob/master/RetroGraphicsToolkit.exe.7z (for windows users)
The source is located here: https://github.com/ComputerNerd/Retro-Graphics-Toolkit
Re: Retro Graphics Toolkit
by on (#159205)
I have released a minor update: V0.8 RC1.2.

Previously you had a choice for saving as either a binary file, a C header, an assembly file or a BEX file however you could only load a binary file. I added support for loading these text based files. The parser for this does support multiple "arrays" and you will be prompted to selected which one to load if there are multiple "arrays" in the file you are loading.

For assembly the syntax that Retro Graphics Toolkit currently accepts is as follows:
Comments use a semicolon
dc.b = 8 bit
dc.w = 16 bit
dc.l = 32 bit
A US dollar sign ($) in front of a number means that the number is hexadecimal.

If you use an assembler with a different syntax you will need to modify filereader.lua.

Also the offline manual has been improved by replacing some links which used to link to the Github wiki with references to other sections of the offline manual and some minor text changes which also affect the online wiki.

I also tested compiling Retro Graphics Toolkit with Clang and made a few minor source code changes so that it can build with both Clang and GCC.

I also did a previously unannounced release. In that release some bugs were fixed and PNGs were exported with a 256 color palette. Also you can now selected which palette table is used for the Sega Genesis.
Re: Retro Graphics Toolkit
by on (#172272)
Want a command line tool to convert images using multiple palette rows? Read this post to find out how.

i just added a new headless mode, fixed a bug, and improved the UI for the palette generation frame.

The headless mode means that the Retro Graphics Toolkit window is not created. Instead what happens is a Lua script is executed. This opens up a world of possibilities such as using Retro Graphics Toolkit with your Makefiles.

To use the new headless mode do:
Code:
RetroGraphicsToolkit --headless scriptName.lua

Any arguments following the script name will be passed to the Lua script.
You can also run scripts in the headlessExamples directory regardless of where Retro Graphics Toolkit was invoked by using --headless-examples

I wrote a command line image converter which is invoked as such:
Code:
RetroGraphicsToolkit --headless-examples imageConverter.lua

To learn how to use it do:
Code:
RetroGraphicsToolkit --headless-examples imageConverter.lua --help

Also you can convert as many images as you want by specifying multiple images as arguments. I make use of the chdir() function so that relative paths will work as expected (as in if there is a file in the directory you are in you can read it as ./file regardless of where you are in relation to Retro Graphics Toolkit).

Windows users will need to re-download to take advantage of these features: https://github.com/ComputerNerd/Retro-Graphics-Toolkit/blob/master/RetroGraphicsToolkit.exe.7z