EDIT: Maybe you should initialize SDL as 8 bpp? nSDL handles 8 bpp on CX, and as you're only dealing with 8 bpp stuff it would maybe be easier to concentrate only on one bit depth?

Yeah, I can try that, but I don't know how to

It's kinda strange in fact. If I try to just blit my gif image (exactly the one I attached above) to the screen it's ok :



But if I access it with my getPixel function I get that with 16 bpp :



And that with 8 bpp :



That's kinda strange

I attached all that is needed to compile and test the program. But please, you who are watching this topic, don't use any of the code I posted, it's all full of unoptimized stuffs.

8 bpp helps compatibility with Clickpad/Touchpad, although the screen is so bad that the game would hardly be playable anyway on those models, and I'm not convinced that we need much more than 256 colors for a F-Zero game on a platform without hardware acceleration... so I'd suggest using 8 bpp mode as well.

Alrighty a few things here.

1. When compiling your program, use -Wall -Wextra to spot things that could cause issues. For instance, you're freeing tempBitmap and sky but they've never been initialized.

2. Don't do stuff like this: screen->format = SDL_PIXELFORMAT_RGB332;. SDL should take care of the pixel format automatically.

3. Here's why the color was messed up: when you're using 8 bpp depth, each pixel is stored in a single byte. That byte isn't enough to store the RGB value directly, and so a palette is used to map each value to a certain color. I don't know why SDL_image would do it, but seems like the palette isn't the same on bitmap and screen (maybe you used GIMP to save it? Dunno). That's why you need to make them same, by copying bitmap's palette to screen's palette using SDL_SetColors(). Just do SDL_SetColors(screen, bitmap->format->palette->colors, 0, bitmap->format->palette->ncolors) just after loading the GIF (look up the function on google so you understand what you're writing). That way both palettes match, and here's the result:



It sucks at first but that's the way 8-bit displays work.

EDIT: When I saved that GIF again on Paint, it grew to 2.1 MB, but with that one colors were correct without changing the palette at all. What program did you use to save the GIF and how'd you get it down to 800 kB? It might be the program that has a palette completely different from everyone else.

4. SDL_SetColorKey(shipSurface, SDL_SRCCOLORKEY, SDL_MapRGB(screen->format, 0xff, 0, 0xff)); should be SDL_SetColorKey(shipSurface, SDL_SRCCOLORKEY, SDL_MapRGB(shipSurface->format, 0xff, 0, 0xff));, as you're mapping that RGB(255,0,255) using shipSurface's bpp (which might very well be different from that of screen).

nSDL 1.1.0 Anniversary Edition is here!

The 23rd of this month it will be one year since the creation of this thread and the beginning of nSDL!

Right away, here's the changelog:

• Added (fastish) nSDL_GetPixel(), nSDL_SetPixel()
• Added nSDL_EnableRelativePaths()
• Added nSDL_EnableFontMonospaced()
• Fixed result from nSDL_GetStringWidth() in some special cases
• Fixed bug with stuff sometimes not showing up because of bit depth issues
• nSDL_LoadImage() now always returns a 16-bit surface
• Removed nSDL_DrawStringInRect(); very little use, complexifies code unnecessarily
• Removed nSDL_SetFontFlags()
• Changed nSDL_LoadFont() prototype to nSDL_Font *nSDL_LoadFont(int, Uint8, Uint8, Uint8)
• More accurate timer
• Cleaned up a lot of code (aka fixing what's not broken), (e.g. the font system is much simpler and easier to maintain)
• Smaller static library resulting in smaller executables
• Apart from nSDL itself, added SDL_image
• Added sample to build

As usual, the download is available on the nSDL website. For more information about the new function prototypes and whatnot, check the wiki.

As mentioned earlier, this will most probably be the last update before a very long pause!

Oh wow, well I'm glad I found out about this before leaving. There was one big issue with 1.1.0; I'll quote:

BTW, about the SDL_GetTicks() issue you mentioned earlier, it was my fault. I had completely forgotten to uncomment a line in nSDL that enabled bus access for the timer, and consequently it worked on the emulator but not one the actual hardware (i.e., it returned always 0). It was extremely dumb and careless from me, but I've updated it now, SDL_GetTicks() should work now (I've tested it on both physical calculators, everything runs smoothly).

Let's just pretend that 1.1.0 never existed.

Anyway, updated, download available on the website, you know the drill.

EDIT:

Oh, by the way, I also wrote an online image-to-NTI converter. It does exactly the same thing as the program included in nSDL, except it's faster for massive images and does no formatting whatsoever (which means a smaller source file): http://hoffa.franceserv.fr/nti/

Oh wow, well I'm glad I found out about this before leaving. There was one big issue with 1.1.0; I'll quote:

Quote from: hoffa on January 29, 2013, 03:35:16 pm

BTW, about the SDL_GetTicks() issue you mentioned earlier, it was my fault. I had completely forgotten to uncomment a line in nSDL that enabled bus access for the timer, and consequently it worked on the emulator but not one the actual hardware (i.e., it returned always 0). It was extremely dumb and careless from me, but I've updated it now, SDL_GetTicks() should work now (I've tested it on both physical calculators, everything runs smoothly).

Let's just pretend that 1.1.0 never existed.

Woo, glad to here that issue is fixed! I guess I can start a (not so) secret porting project again!