Hi people,
I don't know if it's generally accepted that the engine should succeed with loading only files that have the same colors-depth as the current game. But just in case. Here is a small test to reproduce the issue :
1. Open MS Paint, create some random drawing.
2. Save it as a 24-bits BMP (name it "bmp24.bmp", for example). Save it again as a 256-colors BMP (name it "bmp8.bmp").
3. CReate a 32-bits game in AGS. Put the BMP files in its "compiled" folder.
4. Go to the "room after fade-in" script and add this :
DrawingSurface* ds = Room.GetDrawingSurfaceForBackground();
DynamicSprite* s = DynamicSprite.CreateFromFile("bmp8.bmp"); //...or bmp24.bmp, as you wish.
ds.DrawImage(0, 0, s.Graphic);
ds.Release();
You'll see that the images are unproperly rendered.
Just sayin'. (it's not vital, but it would have saved me some trouble with a module I'm currently writing, that reads and writes 8-bits BMP files, to work with the AGS feature that loads walkbehinds/Walkareas/etc. masks from 8-bits files)
EDIT: Forget it. Every time I get pawned by the same old trick: The game was 32-bits, but the 9-verb template's sample background was still 16-bits. Hence the issues. After I exported it and re-imported it, effectively turning it into a 32-bits background, everything went fine.
That said, the "DrawImage" function might want to throw an error when the source and target sprites don't have the same color depth. OR The Editor might want to throw warnings for every sprite in the game that doesn't have the same color depth as the game itself.
I'm reasonably certain that the engine does write a warning to the log file if this happens, but that might not be very obvious... I think that the editor raising a warning (not an error -- e.g., it won't prevent compilation) would be a good idea in this case.
Quote from: monkey_05_06 on Thu 16/10/2014 05:59:58
I'm reasonably certain that the engine does write a warning to the log file if this happens, but that might not be very obvious... I think that the editor raising a warning (not an error -- e.g., it won't prevent compilation) would be a good idea in this case.
Well, considering AGS fails to render a 32-bits image into a 16-bits surface, and produces an unpredictable result, I think an error wouldn't be a problem.
Would not that be a better solution if engine converted all loaded bitmaps, whether from package or created dynamically, to game color depth?
Quote from: Crimson Wizard on Sun 19/10/2014 21:41:56
Would not that be a better solution if engine converted all loaded bitmaps, whether from package or created dynamically, to game color depth?
Yes, yes it would. I suppose that in the past that wouldn't have been a satisfying solution for everyone, because some game makers would have used low-color-depth in large sprites, on purpose, to reduce resources usage.
But nowadays, your suggestion seems pretty obvious and most efficient.