Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong colors in TGA files from GTA2 #90

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments

Wrong colors in TGA files from GTA2 #90

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments


Copy link

@SDLBugzilla SDLBugzilla commented Feb 11, 2021

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 2.0.0
Reported for operating system, platform: All, x86_64

Comments on the original bug report:

On 2015-01-10 00:11:11 +0000, robotanarchy wrote:

Created attachment 1987
source code to reproduce this, with an example tga file and screenshots

When trying to load a TGA file from GTA2, the colors are all wrong (not inverted, it looks like a completely wrong color palette).


  • SDL2: 2.0.3
  • SDL2_image: 2.0.0

Tested on:

  • Windows 7 (MinGW i686 Toolchain)
  • Arch Linux x86_64

GTA2 can be downloaded legally from:

I've attached a complete example that reproduces this bug (source code and a sample GTA2 TGA file), and a screenshot of how it looks in SDL_Image and how it should look like (libreoffice draw opened it correctly).

Here is the main.c (as in the zip file):

#include <stdio.h>
#include <stdlib.h>
#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>

int main(int argc, char* argv[])
SDL_Window* win;
SDL_Renderer* renderer;
SDL_Surface* img_surface;
SDL_Texture* img_texture;
SDL_Rect dest_rect = { 0, 0, 320, 480 };

    exit(printf("SDL_ERROR: %s\n",SDL_GetError()));

win = SDL_CreateWindow("SDL_Image TGA Display",
    640, 480, SDL_WINDOW_SHOWN);
if(!win) exit(printf("SDL_ERROR: %s\n", SDL_GetError()));

// Load the image into a texture
renderer = SDL_CreateRenderer(win,-1,0);
img_surface = IMG_Load("1_Play.tga");
img_texture = SDL_CreateTextureFromSurface(renderer,

// Show it until the window gets closed
    SDL_Event event;

    SDL_RenderCopy(renderer, img_texture, NULL, &dest_rect);

    if(event.type == SDL_QUIT) break;

// Clean up
return 0;


On 2015-01-13 20:13:19 +0000, Philipp Wiesemann wrote:

Thank you for reporting this problem and providing an example.

It seems that the colors for this image are wrong because the bytes in img_surface->pixels are in the wrong order. There are two bytes for every pixel and if they are swapped it looks correct.

A similar problem was fixed in bug 1886. The changeset which introduced this bug [1] also changed the swapping for little endian platforms. It could be the cause.


On 2015-01-19 21:26:13 +0000, robotanarchy wrote:

Thanks for finding out the exact issue! Do you have any idea when this will be fixed?

On 2015-02-03 19:57:05 +0000, robotanarchy wrote:

I can confirm that Philipp Wisemann's theory is right: When I switch the bytes with the following code, the images are displayed correctly.

char* pixels = surface->pixels;
for(int y=0;y < surface->h;y++)
for(int x=0;x < surface->w;x++)
int left_byte_addr = ysurface->w2 + x*2;
char left_old = pixels[ left_byte_addr ];

pixels[left_byte_addr +0] = pixels[left_byte_addr +1];
pixels[left_byte_addr +1] = left_old;

I've added this workaround code to my project, because the target platforms are x86 and x86_64 only, but it would still be best if this was fixed upstream. Thanks!

On 2015-08-21 09:33:37 +0000, Amit Jain wrote:

Created attachment 2248
Swapping of bits happened for SDL_LIL_ENDIAN system which is wrong. It should be for SDL_BIG_ENDIAN system.

Hi Robotanarchy
Proper solution patch has been attached.

Hi Philipp Wiesemann
That fix given for bug 1886 is not exactly same as this bug. This issue was not fixed with that solution.
That bug was coming for selection of incorrect masking color for 24 bits per pixel image format. But here in this case, it is being selected correctly. But it was swapping for little endian system, that should be big endian instead.

On 2017-09-11 07:17:39 +0000, Pankaj wrote:

Hi Sam,

Any update on this ?

On 2017-09-12 06:42:28 +0000, Sam Lantinga wrote:

Fixed, thanks!

@SDLBugzilla SDLBugzilla added the bug label Feb 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant