Reply 700 of 862, by __ggorts
It doesn't require the particles command after all, just this:
stubedit dqfx.exe minstack=1M
dqfx -mem 46 -heap 100000
I'll report on the minstack.
It doesn't require the particles command after all, just this:
stubedit dqfx.exe minstack=1M
dqfx -mem 46 -heap 100000
I'll report on the minstack.
you dont need -heap 10000 either. Just something like dqfx.exe -mem 96. It may need 64mb I haven't tested what it the absolute minimum it will allow.
Perhaps something like this: int _stklen = 256000;
But 1 megabyte is something to try to start with.
I'll return later, thank you!
QDOS has an odd early history for me. It's the first project I've ever really sunk my teeth into so there's some crappy stuff going on, but most of has been slowly being fixed. In any case. There is a serious issue with possibly loading a bad mod that crashes the game and reloading quake from the sessions (even a soft reboot wont fix it!) where the entire allocated memory for taht region is corrupt. As such, neozeed wrote that small piece that forces the memory to clear the entire range it allocates at start for itself. You can bypass it with -noclear. It's also why I have it just grab 32mb at startup instead of the entire available memory like in Quake 2.
I can't specifically recall what mod it was or what the situation was. It may be possible that i'll just remove that whole part entirely someday and just allocate all available memory like quake 2
Anyways, unsigned int _stklen = 1048576; /* need a 1MB stack */
this work perfectly. Also default 32mb RAM is enough to load DM1 properly.
Thanks for solving this one. It's good to know my effort didn't go to waste! When we were porting Q2DOS I spent a whole day trying to get the audio to wokr and it ended up being a conflict with s_khz and the loadas8bit cvars, hah. Not sure if you saw the blog when we were developing it but it goes into more detail. Reminds me of this situation
Your hints pointed toward the stack. Also, it's exciting to read all your (and sezero's) changes to q2dos on a daily basis!
I have to read the blog again on the audio issue, it's all interesting to me. 😀
I'll return to my building of "period correct hardware" and look forward to using q2dos to playthrough the expansion packs and a bunch of single player levels I now have. I hope to ask advice if I get stuck because I've never undertaken such a project from components on ebay. If you release a gl version of qdos, then I'll try that, too!
QDOS with 3dfx seems to work OK. Have to recompile to test the bsp2 changes. I just got them working in windows, so they should work in DOS too. Software QDOS already has this capability.
Okay, bsp2 works. You can grab and compile for yourself over at https://bitbucket.org/maraakate/qdos/branch/MesaGL
"sourcecode to a minigl driver has never been obtained"
this sounds like my sort of challenge *files the idea away for later* 🤣
"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen
Stiletto
wrote:"sourcecode to a minigl driver has never been obtained"
this sounds like my sort of challenge *files the idea away for later* 🤣
You'd have to get in touch with ex-3dfx employees who would be willing to release it, if they even have it any more.
Regardless, as is, it's a pretty nice feature to finally have in DOS. Would have been really cool to have 10-15 years ago. Though MesaFX and all that was aroudn back then with DJGPP just nobody though to try it compiling into Quake or porting Quake 2 to DOS.
wrote:Your hints pointed toward the stack. Also, it's exciting to read all your (and sezero's) changes to q2dos on a daily basis!
I have to read the blog again on the audio issue, it's all interesting to me. 😀
I'll return to my building of "period correct hardware" and look forward to using q2dos to playthrough the expansion packs and a bunch of single player levels I now have. I hope to ask advice if I get stuck because I've never undertaken such a project from components on ebay. If you release a gl version of qdos, then I'll try that, too!
A cool machine that would be able to play these at some really nice speeds IMO would be a P3 ~1.0ghz that still has an ISA slot so you could add an SB16/SBPro clone or my favourite a Gravis UltraSound, but the GUS cards are starting to get out of control on prices again. They tend to go in spikes when they sell for $100+.
Don't bother with a P4 with AGP if you plan on using a Voodoo card AGP card because the they won't fit, they use the older AGP specification and voltages. There's discussion around here about that before. I don't know what specific combos work/don't but I just avoid it entirely. If you really wanted to you could drop some money on a PCI Voodoo 5 but that's pretty expensive... though there'd be no stopping you on what you could put it in 😈. They even make motherboards with ISA slots still (an expensive proposition though, about $350) for "industrial" purposes so you really could have it all with a modern DOS pc.
And maybe stilleto knows... but I could have swore I read before that putting Voodoo 2 PCIs into fast computer may cook the cards because they are really dependant on CPU speed. This seems to be the case though with all 3dfx cards. Just swapping the V5 from my p2 400 to p3 550 box for Q2DOS made a difference in speed. If the motherboard accepted it I'd rather find a 800mhz or somewhere around that range to get the best out of it.
Okay, got QuakeWorld now working with it too 😀. You won't be able to test that in an emulator unless it emulates an NE2000 card or something with a packet driver.
Also, regarding your P3 build... Get a Linksys LNE100TX PCI NIC. They're practically worth nothing on ebay, packet drivers are easy to find and they work well at reasonable speeds in DOS.
Excellent news on the stability of qdos/fx and also the bsp2 support! I am eager to try the recent maps released by a couple of well known map authors. It will be very cool to run this in dos. Thank you for the release of it!
I also appreciate the thorough guide to a vintage computer system. I'll price out the components and use your helpful suggestions to keep the price down.
I'll see if I can test qwdos/fx, too. 😀
Well, I noticed that qdos/fx is much slower than q2dos which is funny. The opengl used in original quake must be pretty terrible.
I'll try later at some point to try compiling fitzquake with the dos drivers, maybe it will be a little faster who knows.
I'll compile your latest build, but I thought I noticed it was building with -O0 instead of -O2. Perhaps I remember wrongly.
Similar performance with the different -O values of optimization, but either way it seems ~20% off from minigl glquake, at least if dosbox/V1 is considered accurate. That may not be unexpected given the minigl versus mesafx? Also, there may be added features in the qdos versus vanilla quake? (For example, I heard some clients have some sort of interpolation of frames for smooth movement).
wrote:wrote:"sourcecode to a minigl driver has never been obtained"
this sounds like my sort of challenge *files the idea away for later* 🤣
You'd have to get in touch with ex-3dfx employees who would be willing to release it, if they even have it any more.
I've pulled off stuff that crazy before.
I wonder if anything MiniGL-related is in the infamous leak, probably not. OpenGL ICD stuff was, though, IIRC.
Anyhow, much more likely to acquire it via former Metabyte employees than 3dfx, but either way...
wrote:Regardless, as is, it's a pretty nice feature to finally have in DOS. Would have been really cool to have 10-15 years ago. Though MesaFX and all that was around back then with DJGPP just nobody though to try it compiling into Quake or porting Quake 2 to DOS.
Oh agreed on all counts. (Was Quake 2 source released back then? How long's it been now?)
"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen
Stiletto