Closed axx0 closed 10 months ago
Yes, there is a lot of work to do in image loading, might need seperate code paths for each version. Some of the TOT bmp files don't even load in the current version, no idea why Raylib just returns a null pointer.
I'll see what I can do. Basically we could check if the file is gif87a and then use palette data to seek transparent colours or otherwise just interpret the image as 15-bit high color. This could be done independently of mge/tot, which would enable us to use high colours in MGE also. I've also noticed before some bmp files don't load in mge. I'll open an issue in raylib repo if that's the case.
Bmp reading is not enabled by default in raylib. We'd need to enable a flag and then build raylib manually. So instead I'll try to manually make Image from bmp.
Not a bad idea, might allow us to do the transparency on reading as well which would save doing it later
BMP files for MGE should work now. But only the 8-bit images, I haven't added support for 16 bit BMPs (for TOT) yet. I moved definition of locations of rectangles (for subimages) to the interface files.
Hey, I've finally had a chance to load up the changes you made, I can't open gif files at all now... is this somthign you're working on or should I look into it?
Does the error occur with LoadImage
method (it returns an empty image)?
I'll try to fix that soon. In the meantime just rename the images extensions to lowercase (GIF-->gif).
I'll also add support for 16 and 32 bit bmps and I'm also finishing work on reading TOT sav files.
Okay, so the problem was you're using RayLib.LoadImage with fails for uppercase names, which is what created the other LoadImage implementation above to fix by loading the files first and then loading the images from memory. I swapped bak in the fixed load image call and now it's working.
I did note you're only reading the image sizes from the header and assuming 256 colours not there a reason no to read the header value for colour table size etc?
I forgot LoadImage is sensitive to uppercase. I would rather not use that method in that class, but I need it since otherwise I'd have to write LZW decompression manually.
Unlike BMPs which can be 8, 16 or 32 bpp, all the gif files used by civ2 and scenarios are exclusively 8bpp, so I always assume gifs are 256 colours (at least I haven't stumbled upon high colour gif used in civ2 yet). Anyway we can always make it more flexible to read the number of colours if we want.
It can now read higher colour bmps. You can replace gifs with bmps from TOT to see if it works. There are some bugs with 24bpp images, I'll have to figure it out.
We've hardcoded transparency colors but this can give bad results. These colors vary in scenarios. For Civ2gold the last 3 colors in image palette define transparency. For TOT the last bit in every 16-bit color seems to set transparency. Anyway based on this we'll have to set alpha in our images.