you could just recompile q2dos static and replace the game c files with the dday ones in VS6 and debug it a lot easier on windows.

I think there is a hint to the issue in dday. I ran dosbox at very slow speed with "developer 25" (as you showed me earlier). The issue occurs before a msg about "video/ntro.cin" missing. I added an empty file by that name and it exits about a read error instead of a pagefault.

You should really be using pcem or another accurate emulator. I'm not interested in supporting emulators.

Also a quick and dirty hack would be checking the init routine for the mod in g_save.c (I think this is where it is) and if deathmatch is set to 0 then error out.

Thank you for the suggestion. If the video file doesn't fix it, then I'll definitely boot up VS6.

I agree on the emulation. I mainly reported it for information only. I'll follow both your suggestions on the other thing. I also appreciate the updates to q2dos! I tried them today, including the mouse changes and such.

also the game tends to default ntro+base1 if you run "game" "mod" from console as opposed to q2.exe +set game <mod>

That's very helpful, thanks again. I also just saw this post with a possible file (which I'd prefer to bypass altogether!): http://www.ddaydev.com/forum/viewtopic.php?f=7&t=8476.

It must have the video file named "ntro.cin". I wonder if my LFN support is not so good, as you noted!

Edit: I changed ddayintro.con to ntro.cin and it showed video and no error.

Edit2: I'll try the g_save.c method next since it showed the error after video.

part of the issue is things wont load properly in single player. I'm working to block it out

That's very good of you. I am putting "abort()" commands in the init as you suggested, but probably avoiding the single player is the simplest, given your know-how. I would have to figure out the structure of loading more than I know at present. :)

Edit: verified that the error occurs before "void InitGame (void)" in g_save.c, since the "abort" embedded in that function was never reached.

Edit2: I see now, as you said, something like this requires the static compile. I think it would then give a line#.

Edit3: I can see in the win32 client it allows the single player dday, but it has a bunch of load file errors in q2 console and then just loads up vanilla q2. The stricter dos model probably didn't like those errors as much, but there is definitely no single player dday mode.

I already have a static compile. There are types of entities that won't spawn because of deathmatch being set and it crashes the game. It's hard to find a fix from within the game engine because it goes to the binary for spawning the server.

Brilliant. At least the cause is known. It's nothing more than the mod is not meant for single player mode, or at least nothing apparent from another part of the code. Thank you, too, for debugging it!

Edit: A new mTCP is available! (mTCP 2015-07-05) (new mTCP package)

I just pushed a fix to block starting a server without deathmatch being set for d-day. There's also a static vs6 project file for convenience.

Thanks! I'll definitely use the update and try out the static build.

I show a pagefault where the attached patch is applied (djgpp 204/gcc45), but there is no error otherwise. I wonder whether the array is read-only where placed outside the VID_MenuInit function, combined with compiler specific behavior (since only my version presumably has the issue).

I'm using 2.05 with gcc 4.84 and it seems to work ok. I placed the array inside the function (which is where it was supposed to be anyways)

I forgot to mention you're totally free to include that aspect stuff in this post to the tree (merged with that KM 1280x1024 bit), i'm not signing up to another repository site to do it. 😀

(or at least I can't figure out how to do it from Github)

leileilol wrote:

I forgot to mention you're totally free to include that aspect stuff in this post to the tree (merged with that KM 1280x1024 bit), i'm not signing up to another repository site to do it. 😀

(or at least I can't figure out how to do it from Github)

Does this code work for all resolutions? If so, then I will gladly add it. 😀

To be honest I haven't seen what it does to 1280x1024 (I lack a 5:4 monitor to tell anymore)... but should be fine for the rest of the 4:3's (I only posted the code just after I saw it looking okay for 320x240/640x480/800x600). If something's horribly broken in it somehow, sezero would fix it. 😀

Is there any widescreen res plans in the works? Horz+ expansion in software is much trickier, but should be relatively easier than Q1 since there's no obscuring status/inventorybars to deal with affecting the refdef.