LordKraken Posted January 9, 2018 Share Posted January 9, 2018 Hi all, I have been struggling with a tiny but annoying palette problem the last couple of days. Nothing really important but solving it would help me saving memory (and we all know this is a scarce resource on the lynx!). Here is the problem: I export my fullscreen image to "spr" format to be able to load them from the cartridge directly into a buffer. During the conversion, sprpck creates a palette that I have to use with this image. This works just fine! The problem is that the image is originally created with my game palette but during the conversion, sprpck messes up with the color order. So because I can't reuse my single game palette, I need to store an extra palette definition for each and every fullscreen image! There is a -Ppalettefile parameter to force sprpck to use the given palette, but I haven't been able to make it work. Any clue? Thanks a lot! Quote Link to comment Share on other sites More sharing options...
LordKraken Posted January 9, 2018 Author Share Posted January 9, 2018 The only method so far I could find to "control" the palette is to define the 16 first pixels of the image (on the first line) with my palette colors. That way, I can force the palette to be ordered the way I want. Quote Link to comment Share on other sites More sharing options...
Fadest Posted January 9, 2018 Share Posted January 9, 2018 Never noticed this behaviour. You could put all your pictures in one single BMP file (for example 160x1020 file for 10 background) and use sprpck to generate all your .spr via a text file file in parameter as you can specify the offset of your sprite in the picture. This way, it would generate a single palette file suitable for all your .spr files. 1 Quote Link to comment Share on other sites More sharing options...
LordKraken Posted January 9, 2018 Author Share Posted January 9, 2018 (edited) (I'm using a text file to do all the sprites conversion, would be tedious without that option ) So yes I could do that indeed, but the problem is that I have small sprites compiled (as .obj) and linked against the executable, and fullscreen images that are converted to spr (and loaded dynamically). Two "different" sprites compilations that lead to different palettes (with the same color but a different order). (To add some context, my scene loads a fullscreen picture and then adds sprites on it) Edited January 9, 2018 by LordKraken Quote Link to comment Share on other sites More sharing options...
Fadest Posted January 9, 2018 Share Posted January 9, 2018 That's also what I am doing on most of my games. I mix background (converted to .spr) and sprites (converted to .obj) in the same graphical file, and there is no problem. But I'm pretty sure that in some games I use 2 graphical files with same palette and didn't notice problems, but it was years ago. Quote Link to comment Share on other sites More sharing options...
sage Posted January 9, 2018 Share Posted January 9, 2018 sprpck has some "-P" command line option to fit its palette ordering to a predefined palette Quote Link to comment Share on other sites More sharing options...
+karri Posted January 9, 2018 Share Posted January 9, 2018 One way to solve this would be to have a giant canvas and let sprpck cut out the stuff it needs. Another is to convert the bitmaps to pcx format and let sp65 turn the images into C-files. You can then compile these to .obj files and link them in as you wish. Here is a 16x16 tile from On Duty. The command takes a slice from the bitmap and turns it into a packed sprite in C-language. sp65 -r tiles.pcx --slice 0,0,16,16 -c lynx-sprite,mode=packed -w tile00.c,ident=tile00 /* * This file was generated by sp65 2.13.9 from * Slice of tiles.pcx (16x16, 15 colors, indexed) */ #define tile00_COLORS 15 #define tile00_WIDTH 16 #define tile00_HEIGHT 16 const unsigned char tile00[] = { 0x07,0x1B,0x42,0x4A,0xD0,0x81,0xB0,0x0A,0x9B,0x43,0x41,0x1A,0x10,0x13,0x0A,0x84, 0xC0,0x0B,0x0B,0x42,0x04,0xD9,0x85,0x3A,0x53,0x53,0x5C,0x00,0x0A,0x1B,0x4A,0x1D, 0x82,0x76,0xC5,0x3A,0xCA,0x50,0x0B,0x0B,0x42,0x02,0xD7,0x53,0x5A,0x3C,0xA5,0x14, 0x80,0x0B,0x8B,0x40,0x5A,0x0A,0x13,0x92,0xCA,0x8E,0x63,0x94,0x0A,0x0B,0x59,0xD8, 0xF2,0x8D,0x49,0x31,0xA5,0x00,0x09,0x0B,0x66,0x18,0xD6,0x56,0xA7,0x28,0x72,0x0A, 0x9B,0x43,0x28,0x8E,0x0A,0x19,0x85,0x12,0x40,0x07,0x13,0x54,0xF2,0x94,0xD4,0xD2, 0x08,0x13,0x4C,0xE9,0x70,0x34,0x69,0x00,0x09,0x0B,0x46,0x14,0x27,0x2A,0x95,0x34, 0x80,0x0A,0xAB,0x43,0x9D,0x48,0x54,0x32,0x1A,0x1C,0x80,0x09,0x13,0x4C,0xE5,0x4C, 0x53,0x1A,0x51,0xC8,0x09,0x9B,0x43,0x28,0x4E,0x4B,0x2A,0x69,0x00,0x09,0x1B,0x55, 0x4E,0x94,0xD4,0x93,0x05,0x00,0x00, }; Quote Link to comment Share on other sites More sharing options...
LordKraken Posted January 9, 2018 Author Share Posted January 9, 2018 (edited) @fadest: do you remember if you were using bmp only or pcx only or a mix of both? -> If I save a bitmap file with my desired palette, convert it to pcx, and then pass it through sprpck, my palette order is intact. -> If I use that same bmp and convert it directly with sprpck, the palette order will be based on when sprpck encounter a color for the first time (which is why this workaround works: add a "fake" line at the top of the sprite with the 16 first pixels colorized with my desired palette). Problem is that I can't convert my fullscreen sprite to pcx since sprpck will generate an obj file and not a spr file. @sage: I tried it but while the palette order was changed it was not the one I expected. Not sure if I was using it correctly (was feeding it a .pal file, seems both asm and lyxass format were accepted). By the way, he palette file is deleted at the end. @karri: this part works for me That's the compilation to spr that messes up the palette order. (I'm *still* using newcc65 and loading file with, correct me if I'm wrong @sage, your code from one of your example). Edited January 9, 2018 by LordKraken Quote Link to comment Share on other sites More sharing options...
Fadest Posted January 9, 2018 Share Posted January 9, 2018 Only BMP, I never used PCX I know I add some problems with some BMP format that were not managed by sprpck, but I don't remember problem with palettes (apart my stupids mistakes when I tried to play with pen order in sprite controler and forgot to put them right after ) Quote Link to comment Share on other sites More sharing options...
sage Posted January 9, 2018 Share Posted January 9, 2018 @sage: I tried it but while the palette order was changed it was not the one I expected. Not sure if I was using it correctly (was feeding it a .pal file, seems both asm and lyxass format were accepted). By the way, he palette file is deleted at the end. I dont understand, why should it be deleted? I am using this feature w/o porblems. But I am using the "big canvas" method, too Quote Link to comment Share on other sites More sharing options...
LordKraken Posted January 9, 2018 Author Share Posted January 9, 2018 I don't understand it either but the palette file I'm passing as a parameter is deleted indeed (I keep it open in an editor to recreate it on the fly). Maybe I have a weird version of sprpck... I'll try to see if there is another one out there. Also I'm probably gonna switch to a sprite sheet (big canvas) so that whatever palette is created, it is the same for all images. Quote Link to comment Share on other sites More sharing options...
LordKraken Posted January 10, 2018 Author Share Posted January 10, 2018 Hej guys, So following your suggestions I got rid of the mix of pcx and bmp and moved all my sprites for a given scene in a single sprite sheet. This works perfectly (and I could also removed a lot of unecessary palete definitions and save a few hundred bytes ) Quote Link to comment Share on other sites More sharing options...
Nop90 Posted November 4, 2018 Share Posted November 4, 2018 Managed to fix palette output in sprpck. The code assumes the use of windows bmp v1, that has a fixed header size, but since the time sprpck was originally coded micosoft evolved the bmp format adding other bmp versions with variable header size and optional data after the header. To fix the code I read the some data from the header itself to locate the starting point of the palette. Didn't tested it with every possible bmp format, but at least with the files generated from GIMP it now works fine. If someone is interested in using sprpck instead of SP65 i can upload the fixed code on my github. 1 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 29, 2018 Share Posted November 29, 2018 The only method so far I could find to "control" the palette is to define the 16 first pixels of the image (on the first line) with my palette colors. That way, I can force the palette to be ordered the way I want. Thats exactly my trick in my own Gfx converter to get the right order. I used that for all gfx in Elements demo. Quote Link to comment Share on other sites More sharing options...
+karri Posted November 29, 2018 Share Posted November 29, 2018 (edited) If you are using Gimp for editing you can also re-arrange the order of indexed colours in the colormap window before saving it. At least it works with pcx images (on sp65). Another neat trick is to open two images. One with the desired order another with the new graphics. Once you are ready with the new image convert it to RGB. Then convert it to indexed and ask Gimp to use a pre-defined palette. Choose the palette of the desired colour image (it is usually the 1st on the list most up). Now both images use the same indexes for colours. Edited November 29, 2018 by karri 1 Quote Link to comment Share on other sites More sharing options...
enthusi Posted November 29, 2018 Share Posted November 29, 2018 The last idea only works if your 'reference' image uses all 16 colors already. I also used the 'colorbar in gfx' approach since sprpck is a tool I have not written myself yet (and probably I wont either) Quote Link to comment Share on other sites More sharing options...
jum Posted June 24, 2019 Share Posted June 24, 2019 On 11/4/2018 at 2:54 AM, Nop90 said: Managed to fix palette output in sprpck. The code assumes the use of windows bmp v1, that has a fixed header size, but since the time sprpck was originally coded micosoft evolved the bmp format adding other bmp versions with variable header size and optional data after the header. To fix the code I read the some data from the header itself to locate the starting point of the palette. Didn't tested it with every possible bmp format, but at least with the files generated from GIMP it now works fine. If someone is interested in using sprpck instead of SP65 i can upload the fixed code on my github. Thank you Nop90. I have also had this "bad palette" problem with sprpck and BMP files (generated using GIMP). Please add a link to your github with fixed sprpck. Thanks. Quote Link to comment Share on other sites More sharing options...
Nop90 Posted June 24, 2019 Share Posted June 24, 2019 It's faster if I post it here. sprpck - nop90 palette fix.zip 1 Quote Link to comment Share on other sites More sharing options...
jum Posted June 25, 2019 Share Posted June 25, 2019 20 hours ago, Nop90 said: It's faster if I post it here. sprpck - nop90 palette fix.zip 82.04 kB · 1 download Thanks - much appreciated Quote Link to comment Share on other sites More sharing options...
Nop90 Posted December 2, 2019 Share Posted December 2, 2019 Sprpck with my fix is on my github (https://github.com/nop90-atari-lynx/sprpck ) and added a new fix from kezak (OCEO team) that makes it work with files exported by GIMP and files generated via devIL library. Quote Link to comment Share on other sites More sharing options...
LordKraken Posted December 2, 2019 Author Share Posted December 2, 2019 I actually have a palette I need to fix manually after generation, goind to try your fix see if...well... fix it Quote Link to comment Share on other sites More sharing options...
LordKraken Posted February 6, 2020 Author Share Posted February 6, 2020 Ok I'm bumping this topic for a slightly different issue I have just encountered with sprpck. I started generating a lot of very small sprites on 1-bit using the literal mode. All works fine except for the bug where the sprites apparently miss some end-0, something like that. So when I'm rendering them, nothing crashes but I just get weird artifact. This is apparently a know bug. Buit how do I fix that? Manually I guess, but what would be the simplest way? thansk a lot Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.