for those working on dos quake ports

[revelator]

http://code.google.com/p/realm/download ... z&can=2&q=

my own build. optimized a bit better and uses ncurses for the terminal emulation. has a built in menu for ease of use.
compiled with mingw64 + dragonegg (llvm backend).

try it out and let me know how it works for you.

[qbism]

Ahh, it's not DOS Quake but a DOSBox! Works with Engoo DOS Quake but not Super8. Engoo does not work with -mem 46, although it does work on DosBOX 0.74 with that setting. Super8 won't work on any setting. Possibly not able to use memory above 16Mb? Wild guess. Yes, I did set DosBOX to 64Mb.

Engoo has detailed error reporting and reports a segfault with -mem 46. (also with -mem 31). Super8 just kicks out back to the prompt.

Anyway the menu is great.

[leileilol]

I stole some of FTE's memory functions if that helps.

The earliest part of engoo development was actually trying to get Quake to run in 4-6mb - not much luck.

[qbism]

It's possible that Super8 is bloated above 16Mb minimum memory requirement, just by allocating more memory than standard DOS Quake.

[mankrip]

The skybox code allocates enough RAM for 6 512x512 textures, even if no skybox is ever loaded. This alone consumes 1,572,864 bytes.

I've rewritten the code to only allocate RAM for skyboxes when loading them, but the code for freeing that memory (when the skybox is turned off, or when a different one gets loaded, or when (re)loading maps) doesn't seem to work, as the memory usage reported by Windows only goes higher. Maybe it's OS-dependent.

[Baker]

[Spike]

a modern malloc implementation will generally have an alignment of 16 bytes as this is the alignment required for the largest register size (sse registers). aligning to 4 bytes would be slow for such registers (although if you use the faster instructions it'll outright crash).
misaligned access is slower, as for any writes, the cpu must read the two blocks to each side, replace the central bytes, and write the whole thing back. on arm, you'll get an exception and the kernel will emulate this really really slowly (or just outright crash).
if you're using random access, like linked lists, you would generally want to ensure that all your data fits within a single cache line.

large global objects are bad in terms of code design. they wreck modularity and if you use them for passing data around then you're really evil. but in terms of memory use, they're not that bad.
Remember that in any system with virtual memory (ie: anything running windows or non-crippled linux) the system will only allocate memory when those pages are actually poked. if you do not poke them, they consume no physical memory even if they consume 100mb of your address space.
the actual problems only come when you no longer need that data (switching from some really huge map to a really tiny one), but for games the working set's maximum capacity is the only real concern.
I repeat though... AVOID USING GLOBALS! THEY'RE EVIL.

progressively reallocing larger and larger blocks of memory has its own issues. malloc+free are slow, as is the memcpy required to move all the data into it.
if you have such allocations coupled with smaller allocations, you can find that you run out of chunks large enough, as each free block has some small chunk of data sitting in the middle which cannot be moved (java has the upper hand here!).
Thus for both reasons, you should always over-allocate and consume the extra as needed, to avoid excessive reallocs.

[Baker]

[Spike]

theoretically yes, but tracking such allocations is a nightmare unless you have some sort of quake-hunk design where the order of frees is directly related to the order of mallocs (ie: all at once). otherwise its a bit of a pain to manage.
implementing malloc on top of malloc is also a bit futile... but if you can avoid calling malloc by allocating 50 objects in the same block (by being really lazy with your frees), then you'll use less memory in tracking each individual allocation, and less cpu in allocating memory (and freeing).

from a code design perspective, having to explicitly free each chunk of memory allows the code to be more dynamic and reusable, etc.

back in the dos days, there was no virtual memory. any pages which were allocated stayed allocated. any paging was purely to work around dos weirdness, otherwise it wouldn't have used any paging at all.
large reallocs would have required large blocks of memory. a big gap could not be released back into any unused pools, thus fragmentation within your small 8mb of ram was a very real concern.
A hunk is thus really useful to avoid such issues. Doesn't help when you have external objects stored in there though (like file handles).

[revelator]

blood also bitches about mem even if i allocate 64 mb and allow it to use dos high mem (it does run though). maybe the daum gui code does not pass the setting correctly since if using my build with another gui frontend it works with no problems ?.
btw it also happens with the standard daum build so seems to be a bug.

[Baker]

[Spike]

if you trap interrupt 14, you could implement your own disk-backed virtual memory system. this would allow you to run using less memory at least, but you'll need to decide which pages to purge from memory.
you will need to know how to edit the page tables that your dos extender sets up...

[mh]

Generally you'll reserve 64k pages at a time and commit from that. When each 64k page is full you get another. Reserved address space is not the same as actually using physical memory - it's just preventing other allocations from coming from it so that the allocator that reserved it can use it. You can reserve gigabytes of address space if you want and see no impact at all on physical memory usage, and the physical memory that you don't commit will still be available for use by other apps. Memory = reserve + commit. The Quake hunk is actually a rather crude homegrown version of this (as a challenge: mod Quake to have multiple hunks); a modern OS will (should!) have a grown-up memory API that lets you do it a lot more flexibly (and also get extra safety by marking pages as read-only, write-only, no-execute, no-access, etc).

I seem to remember that some old DOS apps had a nasty habit of just malloc'ing all the memory in your system on startup (the joy of no multitasking!) which would of course cause colossal problems when you try to run them on Windows. Might be one reason why DOS Box limits the memory available.

On Windows malloc and free are just wrappers around the native API (HeapAlloc, which in turn uses VirtualAlloc, AKA the big daddy of Windows memory management). You may as well use the native API and get the extra flexibility (multiple independent heaps! free all memory with one HeapDestroy and no allocation tracking needed! automatic thread-safety! defragmentation!) unless you've got a real reason to recreate all the code needed yourself (learning and having fun is a real reason). Dunno about Linux.

With this implementation the biggest bottleneck is going to be linked-list walking during free-all operations. Like any other memory allocator, it's going to be prone to "lots of small allocations" syndrome but that's a common failing, not a specific flaw; it's best if you know the size of your objects in advance and allocate them all in one go, but if not you can allocate a 64k page and reuse that for subsequent allocations until it fills up.

Your Memory_Free doesn't do what you think it does, by the way, and you're modifying some const params in other functions. Not sure if that's a big deal here (const rules make my brain melt - a lot of modern code seems to be just a wall of "const" noise that it's difficult to pick much signal out of, plus they're only compile-time safety that can be circumvented if you get tricksy so I'm naturally suspicious of a false sense of security here - C++ 11 should have really defaulted to const for everything with needing to explicitly specify non-const, but I suppose the damage was done there a long time ago).

[Spike]

[frag.machine]