search

foone / VGAPride

An MS-DOS application for showing Pride Flags
GNU General Public License v3.0
138 stars 5 forks source link

Uses too much RAM! (warning: joke issue) #3

Open 20kdc opened 2 years ago

20kdc commented 2 years ago

Warning: This is a joke issue a friend dared me to make. 20kdcs are not liable for forewarned misinterpretations.

VGAPride, at the current time, is a 60KB UPX'd program that decompresses to around 100KB. On our modern systems with 640K of conventional memory, this is a whole 10/64th of memory - around 15%. Obviously, in practice, around 160K of conventional memory is already used by Watcom-"enhanced" DOS replacements.

In addition, the TSRs required to use various additional hardware, like garglbst.exe, cut away from this even further, and of course there's always the in-the-background firewolf.exe, which manages to use a staggering -128% of memory.

This leaves VGAPride with insufficient memory to run.

I presented the problem to the weird scary box thing that the local book club and recreational demonic summoning society happens to have laying around, and it spat out... Well, something.

Now, granted, this print-out may have... a non-zero amount of coffee having been spilled on it, and I don't think it has all the flags, but I'm sure it's readable enough.

What could possibly go wrong?

pegasus.txt

(Tested on FreeDOS x86BOOT.img in PCEM set to emulate an 192k IBM PC with EGA graphics. The mem program won't start, but this will, go figure.)

foone commented 2 years ago

This is actually a known problem I'm trying to fix! I did some ugly hacks to get the compiler to accept the weirdness I was doing, which requires in excess memory usage. Once I can fight the compiler into accepting more sensible C++ code, the memory usage will significantly decrease.

20kdc commented 2 years ago

I kind of thought it was more to do with the graphics abstraction involved here - in the same situation (with trying to do complex graphical flags, i.e. the crab one) I'd probably have just decompressed images from a separate data file. It's worth noting that once the video mode is set (there's a BIOS interrupt for it), if you can either get control of the VGA palette (there's BIOS interrupts for it) or simply consider the default EGA-compatible VGA palette acceptable, then the rest is simply decompressing however many bytes your target video mode would consider relevant. I'm not sure if you have some underlying reason for the vector-based approach I'm not seeing though.