[FEATURE] Support different sprite sizes (e.g., 8x8 and 32x32)

[jesse-wei]

Reference issues

20

Summary

Want to support sprites of different sizes (e.g., 8x8 and 32x32).

Basic examples

The VGA resolution is 640x480. For 32x32 sprites, the screen would be 20 sprites x 15 sprites. Therefore, smem.mem would contain 300 lines (as opposed to 1200 lines for normal 16x16 sprites). The program would need to be able to parse this and render the 32x32 sprites correctly.

The sprite size would be automatically computed based on the number of lines in smem.mem, similar to the above calculation.

If the number of lines is not valid, the program should print a useful message and quit.

Drawbacks

No drawbacks, besides making the code more complicated.

Additional context

The most relevant file is VGADisplayBMPController.java (screen logic). Additionally, as mentioned above, there needs to be some code (run during initialization) that gets the number of lines in the ScreenMemory file to set the sprite size.

Specific notes about VGADisplayBMPController.java:

1. There is currently lots of hardcoding since we did not originally plan on supporting sprites that aren't 16x16. This would need to be removed.
2. The BMP header would need to change. Specifically, rows 7 and 8 which specify pixel size.

    private static final byte[] BMP_HEADER = new byte[]{
            0x42, 0x4D,
            0, 0, 0, 0,             // file size (B), set to 0 because JavaFX doesn't need this information and with parameterization, file size is variable
            0, 0,
            0, 0,
            0x36, 0, 0, 0,          // offset until actual pixel data (B)

            0x28, 0, 0, 0,
            0x10, 0, 0, 0,          // width (px), indices 18-21 (inclusive), must be a multiple of 16, default value 16
            0x10, 0, 0, 0,          // height (px), indices 22-25 (inclusive), must be a multiple of 16, default value 16
            0x01, 0,
            0x10, 0,                // bpp (bits per pixel), currently set to 16 bpp (5 bits per color)
            0, 0, 0, 0,
            0, 0, 0, 0,
            0, 0, 0, 0,
            0, 0, 0, 0,
            0, 0, 0, 0,
            0, 0, 0, 0
    };

3. We have to use BMP for performance reasons. We had originally used JavaFX's Rectangle, but this ended up being unusably slow. For some reason, the BMP approach is much faster. In the current approach, instead of displaying 40x30 Rectangles, we generate and display one .bmp image.

[jesse-wei]

We have to use BMP for performance reasons. We had originally used JavaFX's Rectangle, but this ended up being unusably slow.

I had to have done something wrong... there's just no way a good implementation that uses Rectangle would be slower than literally saving BMP files to disk and reading them into memory. Also, as shown above (hardcoded BMP fields), BMP is not maintainable. This should be looked into.