When you find these sorts of issues they really need to be reported to us. I've personally played through the game many times with this configuration and haven't seen any kind of weird precision errors. But if you are seeing them we need to know so they can be addressed.

The commit has a line about the bug in the newer gcc version: "ref_soft/r_model.c (Mod_LoadTexinfo): fix undefined behavior [-Waggressive-loop-optimizations]". Also, the graphical corruption was vertical lines that appear interspersed throughout the video display.

There are other issues, but I didn't want to distract you from your core work.

Do you mean that the entire displayed looked like scanlines?

ggorts wrote:

There are other issues, but I didn't want to distract you from your core work.

Well, I'm about where I want to be with the project except for the few ASM issues and the Whale's WOD X mysterious crash. There's no plans for super extended protocols as I'm no ASM whiz and I'm not interested in badass particle effects taking away from the original look of the game and you would really need a 3D GPU for such things.

It was a while ago and in my own branch, so I recall there were lines and possibly slowdown in video output. But I had no reason to upgrade gcc at the time because there are other reports I read that discussed bugs and features missing in later versus earlier versions of gcc.

Could you think about inclusion of the Rogue bot only? It's an important mod because the bots support an expansion pack with many new gameplay features. It would mirror acebot code that is already included, so it wouldn't require much updating.

I also have a couple of other questions about the current code base, but the bot is a new feature concern.

I haven't benchmarked the game comparing GCC versions but I haven't seen any gross slowdown. You can still upgrade to 2.05 and keep the older GCC I believe.

In any case, at one point the ogg vorbis libs were still the GCC 2.9.5 versions and it worked fine in q2dos so compiling your custom mods may work okay from an older version. You could test it by posting a dxe of the core gamex86.dxe and I'll test it out.

I would only be interested in something like a mod named roguebots or something to this effect, but I'm not interested in injecting bots into all the game dlls. Something that might be worth doing at a later date would be expanding the game DXE itself it to load a separate DXE like bots.dxe and add bot ability as a drop in and keep the code bases separate. I don't know how hard it would be to do however. The import/exports might get out of hand doing it this way.

What are the concerns? Most of this code is from yamagi quake 2 which has for the most part been tested pretty well and has a lot of sanity checks that prevent complete meltdown of the game and in DOS that could be a real concern.

The roguebots would be great, just that single separate directory. It wouldn't involve any other game directories.

I also tried intermixing dxe and q2 versions, and it didn't work for me.

The other concerns/questions are about the malloc/free and the timing code. These are more questions than changes.

The game binary itself uses double time because UCLOCK was reporting as such from Q1 code. I converted everything over but it may have been unnecessary. I don't see a performance hit from doing so and in theory should allow longer uptimes, but nobody has hosted a q2dos server that long enough to find out...

the malloc and free stuff works perfectly for me. I don't know what the specific issue you have with it is. There is less memory being used and I even see it fixed some small memory leak between switching maps. With the old rhapsody code you lost about 2mb per map transition, this is now resolved.

Thank you for the reply on the timing code. The other question is expanded from before. The realloc() command seems ~8x slower than malloc/free -- according to tests by djgpp people. The web page is available and I can find the link again.

If you find the link let me know. You can also try profiling the code. The only time hunk_end is ever called is during the load of models in mod_numforname and if it's already loaded it skips past it.

I only test in dosbox which is probably not a good test of the hunk management, but it does also show some slowdown. I'll find the link, but mainly wanted to provide the information and let the experts judge.

Also, realloc() wasn't a standardized function until relatively recent (such as in posix) and it is recommended in hunk management to call new hunks in uniform large sizes only.

Here are the tests: http://www.delorie.com/djgpp/malloc/.

Can you submit a bug report with this information to the bitbucket site so sezero can take a look at it?

My thoughts are theoretical and not backed by profiling results. Since the current code was already profiled, I see no reason for looking at it other than curiosity. :)

Thank you for patiently answering my questions!

The q2 binary from "q2dos_new_fov.7z" pagefaults where accessing the video menu, similar to the issue mentioned earlier in the thread. Did sezero build the binary by an older gcc version along with the static array outside the function?

Edit: tested in dosbox.

I'm building a new binary right now... but when I used his binary from that 7z earlier it worked OK in DOSBox for me.

I uploaded a new binary, and tested the vid menu in DOSBox works OK.