its pretty simple. find image size, select video mode best covering it, decode image into a buffer, copy it to video memory (or decode + display it on the run)

your best bet is probably to go with using vesa. so you'll want to look at the vesa spec.

https://pdos.csail.mit.edu/6.828/2018/reading … rdware/vbe3.pdf

I'd start with some simple like bmp, which is simple enough to writer a decoder yourself. Then it's a case of setting up a video mode (as above, vesa gives you more flexibility), then copying from the decoded image in memory to the vesa framebuffer. If you don't have a linear framebuffer then you have to do things like copying the image to the screen in 64k chunks.

Bonus points to write an image decoder that streams the image from file to screen a line of pixels at a time, and doesn't need a full copy in ram.

A JPG reader is going to be much more complex than a simpler format. First you have the compression, then the color conversion (full RGB to 256 indexed?). It's also a bad format for storing sprites if you plan to use it like that.

Anyways, whomever wrote that decoder most probably didn't read it from an instructional book in the style of Andre's books. Rather, he relied on the JPG format documentation amd reference source code. If you're up for this, search for "JPG format spec". Same goes for any other format you want to go for (e.g. PCX).

Game programming books rarely go into details of loading sophisticated image formats. They typically explain simple formats (e.g. BMP) because it doesn't bore the reader to death, and if they want to support advanced formats, they leave it in the sample code without full documentation in the book.

Manage your expectations 🙂

http://petesqbsite.com/sections/tutorials/graphics.shtml

As above, I definitely wouldn't use jpg or other 'modern' compressed formats. There's too much overhead and code complexity.

Bmp, pcx and good to start with, but if using images as data in games, I'd be tempted to convert them to some format native for your game that doesn't require untangling header fields, RGB remapping etc. in a couple of things I am working with I simply store them as fixed length strings of bytes in a larger image data file. Then I just seek to (size of image * image_id) - it makes the code needed in your game much simpler, smaller and therefore quicker.

Here's a working bmp reader for you.

https://github.com/megatron-uk/pc98launcher/b … ob/master/bmp.c

It is only written to support 8bpp files, but can extract the palette table and you can use it to remap your VGA palette later if necessary.

Even with the 'simple' format of bmp, you can see there are a lot of fields to extract and some peculiarities to deal with (bmp stores the image in reverse row order).

To deal with any eventuality of bitmap you would have to extend the code to deal with 1, 4, 16 and 24bpp, as well as compressed formats. As I said before though, I wouldn't use 'raw' images like that in a game; convert them to an easier to handle format first.

The code gets you the pixels in a buffer, you'd then need to either write it out to a linear framebuffer with h the correct line length stepping, or pad/crop the output depending on screen size.

pcx also has bit planed version, 8bit vga with palette versions, then 16/24bpp versions. the format can get quite crunchy if you only expect plain vga style with palette information.