Uses too much RAM! (warning: joke issue)

[20kdc]

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]

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]

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.