Hello!
Can someone help me with exporting palette from RGAS to firmware (or hardware) values which I could then automatically embed in (cpctelera) code?
I have found where the palette info is stored in .rgas file:
"Inks": {
"$type": "System.Byte[], mscorlib",
"$value": "AAkTGQ8FEBcUAwYCBwEEGg=="
}
but I did not manage to reverse engineer it... :)
Quote from: teopl on 22:52, 16 February 19
I have found where the palette info is stored in .rgas file:
"Inks": {
"$type": "System.Byte[], mscorlib",
"$value": "AAkTGQ8FEBcUAwYCBwEEGg=="
}
but I did not manage to reverse engineer it... :)
Looks like base64 encoding, you can use ie. this online converter to decode it into hex values: https://cryptii.com/pipes/base64-to-hex
Which will return:
00 09 13 19 0f 05 10 17 14 03 06 02 07 01 04 1a
For your above "value".
Thanks Duke, that is exactly that!
And if someone needs a bash one-liner for this:
base64 -d <<< AAkTGQ8FEBcUAwYCBwEaBA== >foo.bin && cpct_bin2c foo.bin -an g_palette >palette.c && rm foo.bin
Result:
// File foo.bin converted using cpct_bin2c
const unsigned char g_palette[16] = {
0x00, 0x09, 0x13, 0x19, 0x0f, 0x05, 0x10, 0x17, 0x14, 0x03, 0x06, 0x02, 0x07, 0x01, 0x1a, 0x04
};
When I wanted the palette I just copied down the hex values on the Ink Select screen (standard palette) and then plugged them into a program I wrote to convert them to the correct values to put into cpctelera but your way might be easier.
Well, I really like automation :)
There is a lot of info (maybe all?) which you can extract from .rgas file easily since it's a text file.
I used this to detect output format, mode, palette, sprite dimensions...
Also, I am using rgas.exe from command line to generate .c source with graphics and (as of today) even levels! (didn't know levels can be drawn and exported in rgas, very cool)
./rgas/RGAS.1.2.5.EXE ${SPRITE_INPUT} ${SPRITE_OUTPUT_C}
One thing which bothered me is why rgas is generating 2 times more data then needed, but I solved it by removing it...
So, for example this:
const unsigned char G_round_01[34] = {
0x04, 0x08,
0xCC, 0x30, 0x33, 0xC0,
0x88, 0x70, 0x11, 0xE0,
0x11, 0xE0, 0x88, 0x70,
0x33, 0xC0, 0xCC, 0x30,
0x33, 0xC0, 0xCC, 0x30,
0x11, 0xE0, 0x88, 0x70,
0x88, 0x70, 0x11, 0xE0,
0xCC, 0x30, 0x33, 0xC0};
is an 8x8 pixels sprite in mode 1, so there should be 4 pixels per byte i.e it should take 64/4=16 and not 4*8=32 bytes...
(first two values are sprite dimensions - width in bytes, height in pixels)
So I just removed every second column...
Or maybe I don't understand this fully, there may be some alpha channel or something else... Anyway, it works, so I will leave it for now :)
Automation is great ;D , I don't think I've ever had enough time to consider it for my projects.
I've always used rgas in a very manual way, same for when I've built an editor I manually save the output .c and .h files and put them into the project.
However I do refer that it makes the code very easy to distribute and build as opposed to requiring a bunch of utilities to build the thing.
Doesn't look like the author of rgas has been around lately unfortunately.
http://www.cpcwiki.eu/forum/programming/retro-game-asset-studio-beta/ (http://www.cpcwiki.eu/forum/programming/retro-game-asset-studio-beta/)
I have though about whether I could contribute to development when I feel like something different but I guess he isn't around at the moment so that stops that as as I gather rgas is in a private repo somewhere so not quite public open source.