VOGONS

Search

Common searches

Eduke16 - Eduke32 for DOS

Topic actions

First post, by DosFreak

Posted on 
User metadata
Rank l33t++
Rank
l33t++

Just noticied this today:
https://gitlab.com/NY00123/eduke32-dos/
https://forums.duke4.net/topic/6378-introducing-eduke16/
https://www.youtube.com/watch?time_continue=1 … 3&v=gt5I_r_4rV4

Considering all the old machines we have here would be nice to get alot of people testing it on real hardware instead of just DOSBox.

Time for a bump :) While somewhat different technically (a 32-bit DOS app built with DJGPP's GCC port), I think that I'm ready t […]
Show full quote

Time for a bump 😀
While somewhat different technically (a 32-bit DOS app built with DJGPP's GCC port), I think that I'm ready to show a demonstration here.

I must say in advance that your mileage may vary. In particular:
- Better assume that no support of any kind is offered for EDuke32-DOS, and that you're on your own.
- There are good chances that the DOS port will crash or malfunction in any other way. It may actually fail after enough memory allocations.
- Support for OGG and FLAC files was disabled, due to issues related to memory management. There's also no reason to support VPX with the lack of GL modes. The XMP code is enabled, though.
- You'll probably want at least 128MB of RAM for the DOS environment; That is, unless you want to enable paging, and there are good chances that you really don't. This might actually increase the chances of a crash related to memory management, although I'm not sure at this point. But maybe it'll work better with paging under certain circumstances (when DOS emulators are involved).

How To Ask Questions The Smart Way
Make your games work offline

Reply 1 of 5, by Hendricks266

Posted on 
User metadata
Rank Newbie
Rank
Newbie

Just a quick note - EDuke16 was the name of my April Fools' Joke from several years ago. NY00123's port is named EDuke32-DOS while it is a fork. If/when we merge it into mainline it will simply be EDuke32, running on DOS.

Reply 2 of 5, by NY00123

Posted on 
User metadata
Rank Member
Rank
Member

Additionally, the aforementioned caveats, like the requirement to have 128MB of RAM, are still intact.

You might be able to run this under an unmodified DOSBox build with 63MB of RAM reserved for it, *if* you're using CWSDPMI.EXE and paging. Even then, there might be greater chances of an unexpected crash, at least as a maybe.

Furthermore, I've recently noticed that the game may significantly slow down as multiple voices (sound effects) are concurrently playing. This is especially noticeable for me while walking in the outdoors area of E1L2 under Come Get Some. It does seem to be way more noticeable with slower emulation speeds, and/or by using DOSBox-X, possibly due to the state of FPU emulation.

Lowering the max. amount of concurrently playing voices will maybe assist.

As a side-note, I've been using DOSBox-X to bypass the 63MB limit. I found some patch for the original DOSBox (How to increase maximum memsize in DOSBox source code?), but I'm not sure that it always works as expected. It's also understandbly limited to 383MB.

Thanks for checking this unofficial DOS port out 😀

Reply 4 of 5, by Revolter

Posted on 
User metadata
Rank Member
Rank
Member
xjas wrote:

Will it support Ion Fury? That would be amazing!

Literally the first thought I had when I read the thread title 😀

Celeron 800, 512MB, GeForce2 MX, ES1938S/DB S2, Windows ME/DOS 6.22

Reply 5 of 5, by Hendricks266

Posted on 
User metadata
Rank Newbie
Rank
Newbie

Ion Fury already runs with EDuke32-DOS, but performance is very poor, RAM usage is astronomical, and there are critical showstopper bugs that prevent it from being fully playable. The README.TXT in NY's GitLab repository has more to say.

Go to top of page Go to top of page
Back to Release Announcements
Close window
Close window