Details about file formats, structure and contents in the original Master of Magic
3 posts • Page 1 of 1
NOPE the bmps are 20x18 not a power of 2Ortemus wrote:256 color .GIFs take up less space than .BMPs
wouldn't it make the game/engine run faster to use 256 color .GIFs
so the gifs would take the same time to load
but remember once the image is loaded there is no
factor involved in displaying the contents
once in the video card memory they are both just 1 and 0's
now if animation was present in file or if it ws a 3d object , file type
would become an issue.
Not to mention he would have to convert every bitmap into a gif and repackage it and then most likely alter several parts of his program to render a map and play the game. For what would end up to be
no significant change
- Site Admin
- Posts: 433
- Joined: Fri Feb 24, 2006 3:35 am
- Location: Newfoundland, Canada
I don't use either? The only reference anyone made to BMPs is that is what the LBXExtract program saves off - there aren't any GIFs or BMPs used by the game, it reads 90% of the graphics straight from the original MoM LBX files (to save me pointlesslly extracting and repacking graphics into a new format), and the new graphics I've had to produce I encode with my own encoding scheme (which I call .NDGBMP for want of anything else... NDG being my initials). It is non-lossy, uses a 24-bit colour palette and run length compression, so it compresses photos terribly, but does a great job on game graphics.Ortemus wrote:256 color .GIFs take up less space than .BMPs
For game graphics, personally:
I hate GIFs because a) they only store each colour with 18 bit precision (each value is 0-63 instead of 0-255), and b) they're limited to only 256 colours.
I hate 8 bit RLE encoded BMPs because limited to only 256 colours.
I hate 24 bit colour BMPs because they have no compression so are HUGE.
So I came up with something myself which while not enormously clever or offering very high compression rates, it does the job I need it for :)