Jump to content
IGNORED

Getting the right palette using sprpck


LordKraken

Recommended Posts

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!

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

(I'm using a text file to do all the sprites conversion, would be tedious without that option :D)

 

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 by LordKraken
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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,
};
Link to comment
Share on other sites

@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 by LordKraken
Link to comment
Share on other sites

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 :D)

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 9 months later...

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.

  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...

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.

Link to comment
Share on other sites

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 by karri
  • Like 1
Link to comment
Share on other sites

  • 6 months later...
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.

 

Link to comment
Share on other sites

  • 5 months later...
  • 2 months later...

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

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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