IDA Pro is not free, dosbox debugger plug-in version for Ida is free.

There is too much dos extenders
https://en.m.wikipedia.org/wiki/DOS_extender

Quake is using cwsdmpi extender instead of dos4gw

Try latest dos4gw versions, they able run Icr2?
Cmdlune "dos4gw.exe cart.exe"

RaVeN-05 wrote on 2025-02-24, 11:29:

IDA Pro is not free, dosbox debugger plug-in version for Ida is free. […]
Show full quote

IDA Pro is not free, dosbox debugger plug-in version for Ida is free.

There is too much dos extenders
https://en.m.wikipedia.org/wiki/DOS_extender

Quake is using cwsdmpi extender instead of dos4gw

Try latest dos4gw versions, they able run Icr2?
Cmdlune "dos4gw.exe cart.exe"

I'll try and see, but I don't think it'll work. I think it's been embedded differently. The supplied dos4gw produces the same error as dos32a.

Oh that statically compiled/embedded.
What if it's possible to find exactly same dos4gw and try to cutoff it out of Icr2.
Or find a way, maybe there hidden dos4gw functionality that can detach its out from exe, and leave exe without dos4gw.

RaVeN-05 wrote on 2025-02-24, 12:20:

Oh that statically compiled/embedded.
What if it's possible to find exactly same dos4gw and try to cutoff it out of Icr2.
Or find a way, maybe there hidden dos4gw functionality that can detach its out from exe, and leave exe without dos4gw.

I'll try that. That's a job for tomorrow.

DxWnd fake fullscreen is being added, and with that:

Team Apache still doesn't get fake fullscreen since the windowing system is probably OGL based, unlike I76?
Also the game freeze is still constant. DxWnd reports it freezes at a

1glDrawBuffer: mode=0x405

Whatever that meant...

BEEN_Nath_58 wrote on 2025-02-24, 21:49:

DxWnd fake fullscreen is being added, and with that: https://www.vogons.org/download/file.php?mode=view&id=213017 […]
Show full quote

DxWnd fake fullscreen is being added, and with that:

Team Apache still doesn't get fake fullscreen since the windowing system is probably OGL based, unlike I76?
Also the game freeze is still constant. DxWnd reports it freezes at a

Copy code to clipboard

1glDrawBuffer: mode=0x405

Whatever that meant...

Woohoo! I76 is finally stable on your problem machine.

I76 is also opengl based. Team Apache I think locks up around the time the wrapper switches from single threaded affinity to multi - threaded. Because the video decoder isn't thread safe in that game rready switches between single and multithreaded affinity for videos and 3d sections.

I *think* team apache locks up around there. I wonder if the 3dfx renderer still works with TA.

[EDIT]
It might be that the nvidia driver or Windows no longer allows thread affinity to be switched mid-way through the game.

BEEN_Nath_58 wrote on 2025-02-24, 21:49:

DxWnd fake fullscreen is being added, and with that: https://www.vogons.org/download/file.php?mode=view&id=213017 […]
Show full quote

DxWnd fake fullscreen is being added, and with that:

Team Apache still doesn't get fake fullscreen since the windowing system is probably OGL based, unlike I76?
Also the game freeze is still constant. DxWnd reports it freezes at a

Copy code to clipboard

1glDrawBuffer: mode=0x405

Whatever that meant...

Gldrawbuffer is used to set the read or draw buffer to the front or back buffer. Since this is during video rendering it's a switch to the front buffer. RReady switches back to the back buffer after each blit, but that's actually allowed.

TA has some weird issue where front buffer rendering doesn't work or only updates part of the screen (quitting a mission does this) , unless the mouse is moving during the update.

[EDIT] I could probably minimise the number of front back and buffer swaps.

I've also figured why icr2 has stability issues on slower systems, it's because of my implementation of Rendition triple buffering. Originally I started out with a permanent render to texture path but Intel HD graphics had issues with it when using different sized z-buffers and also had performance issues in vquake 2, so switched to direct frame buffer rendering. To implement virtual triple buffering I had to read from the front buffer and cache the frame. This is quite expensive, but games which don't need it are faster on Intel HD graphics with direct rendering. On discrete gpus permanent render to texture has virtually no impact.

In hindsight, only the primary buffer needs z-buffering(in theory this isn't the case, an rredline app could add a different sized z-buffer to any surface) so I could switch back to permanent render to texture for icr2. I can't do that right now unfortunately, but it's on my hit list.

[EDIT] opengl native triple buffering doesn't allow access to the buffers individually, I think.

Yup, it's the thread affinity switching which causes problems with Team Apache.

Leaving it in default mode allows the game to run, but bits of the videos start looping and the 3D sections (HUD) have missing bits (this is probably an RReady bug without dynamic switching with this game).

Running it in single threaded mode produces a black screen with a lockup. Maybe I can run the OpenGL in one thread and the game logic on another using processor affinity for each thread *might* work, the problem is the video decoding api SmackW32 .dll is running in single threaded mode or is using a single threaded build so it can crash the game on a multi-core system.

I have tried replacing the DLL, the compatible versions still have the same problem.

sharangad wrote on 2025-02-25, 00:40:

Woohoo! I76 is finally stable on your problem machine.

I76 is also opengl based.

Then it is that due to a DxWnd bug where the Display resolution change is static after only DDraw changes, so as the initial screen changes to 640x480, it keeps the OGL screen there too. Should improve later to be dynamic to changes, for now it should work with game resolution not being changed by RReady. If you change it, it will go out of the screen without scaling:

sharangad wrote on 2025-02-25, 00:40:

Team Apache I think locks up around the time the wrapper switches from single threaded affinity to multi - threaded. Because the video decoder isn't thread safe in that game rready switches between single and multithreaded affinity for videos and 3d sections.

I *think* team apache locks up around there. I wonder if the 3dfx renderer still works with TA.

Can you share a non-single-threaded build?

RaVeN-05 wrote on 2025-02-24, 12:20:

Oh that statically compiled/embedded.
What if it's possible to find exactly same dos4gw and try to cutoff it out of Icr2.
Or find a way, maybe there hidden dos4gw functionality that can detach its out from exe, and leave exe without dos4gw.

I did a scan, dos4gw, the version that comes with the CD, doesn't occur in the file directory. Even if it were embedded it wouldn't be found because the dos4gw.exe contains extra code to run as an exe, so only a subsection of it would be there, assuming the static linked (embedded) library was built with the same compiler settings as the exe.

I think my best bet is to figure out why embedding this doesn't work, why dos4gw and dos32a can't find the start address the routine runs at.

BEEN_Nath_58 wrote on 2025-02-25, 05:47:

Then it is that due to a DxWnd bug where the Display resolution change is static after only DDraw changes, so as the initial scr […]
Show full quote

sharangad wrote on 2025-02-25, 00:40:

Woohoo! I76 is finally stable on your problem machine.

I76 is also opengl based.

Then it is that due to a DxWnd bug where the Display resolution change is static after only DDraw changes, so as the initial screen changes to 640x480, it keeps the OGL screen there too. Should improve later to be dynamic to changes, for now it should work with game resolution not being changed by RReady. If you change it, it will go out of the screen without scaling:

sharangad wrote on 2025-02-25, 00:40:

Team Apache I think locks up around the time the wrapper switches from single threaded affinity to multi - threaded. Because the video decoder isn't thread safe in that game rready switches between single and multithreaded affinity for videos and 3d sections.

I *think* team apache locks up around there. I wonder if the 3dfx renderer still works with TA.

Can you share a non-single-threaded build?

Swap these two dlls into your RReady folder. Switching between single threaded and multithreaded mode is disabled, so you should be able to force single-threaded mode with DxWnd.

The embedded Dos4gw types that it and sb.exe are looking for occur at file offset (576, 512 byte DOS header + 64 bytes).

sb.exe look for these byte sequences:

1    cmp wptr [edx],'EL'
2    jz  @@1
3    cmp wptr [edx],'XL'
4    jz  @@2
5    cmp wptr [edx],'CL'
6    jz  @@3
7    cmp wptr [edx],'EP'
8    jz  @@4
9    cmp dptr [edx],'1WMP'
10    jz  @@5

Cart.exe has bytes 01, 00 and the 64 byte block it reads ends somewhere inside the Dos4gw id string. Dos4gw appears to occur right at the start of the exe. well 64 bytes beyond the end of the header.

[EDIT] Vanilla replacement won't work, because the subroutine addresses might not be the same in the replaced EXE.

@Been_Nath_58

I think Microsoft or Nvidia don't allow the threading mode to change under OpenGL on Win11 24H2.

It's entirely possible the broken screen updates when Team Apache was working was due to threading issues.

sharangad wrote on 2025-02-25, 05:58:

BEEN_Nath_58 wrote on 2025-02-25, 05:47:

Then it is that due to a DxWnd bug where the Display resolution change is static after only DDraw changes, so as the initial scr […]
Show full quote

sharangad wrote on 2025-02-25, 00:40:

Woohoo! I76 is finally stable on your problem machine.

I76 is also opengl based.

Then it is that due to a DxWnd bug where the Display resolution change is static after only DDraw changes, so as the initial screen changes to 640x480, it keeps the OGL screen there too. Should improve later to be dynamic to changes, for now it should work with game resolution not being changed by RReady. If you change it, it will go out of the screen without scaling:

sharangad wrote on 2025-02-25, 00:40:

Team Apache I think locks up around the time the wrapper switches from single threaded affinity to multi - threaded. Because the video decoder isn't thread safe in that game rready switches between single and multithreaded affinity for videos and 3d sections.

I *think* team apache locks up around there. I wonder if the 3dfx renderer still works with TA.

Can you share a non-single-threaded build?

Swap these two dlls into your RReady folder. Switching between single threaded and multithreaded mode is disabled, so you should be able to force single-threaded mode with DxWnd.

It looks like the thread can't be changed in Team Apache with DxWnd. Can't really figure out what's going here, since it works in other games. I will try some other OGL application

BEEN_Nath_58 wrote on 2025-02-25, 07:35:

sharangad wrote on 2025-02-25, 05:58:

BEEN_Nath_58 wrote on 2025-02-25, 05:47:

Then it is that due to a DxWnd bug where the Display resolution change is static after only DDraw changes, so as the initial scr […]
Show full quote

Then it is that due to a DxWnd bug where the Display resolution change is static after only DDraw changes, so as the initial screen changes to 640x480, it keeps the OGL screen there too. Should improve later to be dynamic to changes, for now it should work with game resolution not being changed by RReady. If you change it, it will go out of the screen without scaling:

Can you share a non-single-threaded build?

Swap these two dlls into your RReady folder. Switching between single threaded and multithreaded mode is disabled, so you should be able to force single-threaded mode with DxWnd.

It looks like the thread can't be changed in Team Apache with DxWnd. Can't really figure out what's going here, since it works in other games. I will try some other OGL application

Actually it might be forcing multithreaded mode for all apps. I'll get you a build in a bit.

I just disabled dynamic affinity switching.

BEEN_Nath_58 wrote on 2025-02-25, 07:35:

It looks like the thread can't be changed in Team Apache with DxWnd. Can't really figure out what's going here, since it works in other games. I will try some other OGL application

Try this. It shouldn't mess with thread affinity at all. I can't really test it now and I'll be away the whole afternoon, got a doctor's appointment.

[EDIT] I can't test this right now, because I'm running a lengthy test on Dos4GW, to see if any of it occurs in ICR2.

sharangad wrote on 2025-02-25, 08:25:

BEEN_Nath_58 wrote on 2025-02-25, 07:35:

It looks like the thread can't be changed in Team Apache with DxWnd. Can't really figure out what's going here, since it works in other games. I will try some other OGL application

Try this. It shouldn't mess with thread affinity at all. I can't really test it now and I'll be away the whole afternoon, got a doctor's appointment.

[EDIT] I can't test this right now, because I'm running a lengthy test on Dos4GW, to see if any of it occurs in ICR2.

Okay this allows changing the affinity. However the game is the issue now, it is slow and the premission video stays black, probably due to the slow rendering.

DxWnd allows disabling the videos, but it disables all the videos.

sharangad wrote on 2025-02-23, 09:14:

Found the memory allocator block in Dos/4GW. Yup the memory code's all there.

Not entirely sure how feasible it is to turn a 16 bit variable into a 32 bit one. The RAM allocated (in KB) is stored at dword[0x0ECC].

oh only if its possible to force use DWORD instead of WORD so you can tell more memory in the registry.

as i remember upper half of enhanced registers is unused? as they can't be directly accessed.

like
[EDX] 32
[NO,DX] 16+16
[NO,DH,DL]16+8+8

any way for safety need to look somehow what upper 16 bit holding.
Or just rush and see at least its works or not. Anyway faster way to see if its right throughts direction.

BEEN_Nath_58 wrote on 2025-02-25, 08:46:

Okay this allows changing the affinity. However the game is the issue now, it is slow and the premission video stays black, probably due to the slow rendering.

Which is why I used dynamic thread affinity to switch the game over to single-threaded mode for videos and back to multi for the game.

RaVeN-05 wrote on 2025-02-25, 10:17:

oh only if its possible to force use DWORD instead of WORD so you can tell more memory in the registry. […]
Show full quote

sharangad wrote on 2025-02-23, 09:14:

Found the memory allocator block in Dos/4GW. Yup the memory code's all there.

Not entirely sure how feasible it is to turn a 16 bit variable into a 32 bit one. The RAM allocated (in KB) is stored at dword[0x0ECC].

oh only if its possible to force use DWORD instead of WORD so you can tell more memory in the registry.

as i remember upper half of enhanced registers is unused? as they can't be directly accessed.

like
[EDX] 32
[NO,DX] 16+16
[NO,DH,DL]16+8+8

any way for safety need to look somehow what upper 16 bit holding.
Or just rush and see at least its works or not. Anyway faster way to see if its right throughts direction.

In fact that's how I got it to allocate the full amount of RAM. It uses queries free RAM and XMS sets EDX to the largest free block. The game then calls XMS function 0x09 to allocate memory with the target size in DX. I swapped function 0x09 to 0x89 which assumes the target RAM is in EDX (which it already is). Before it just ignored the upper 16 bits. The problem is dos4gw only caches free RAM size in a WORD and not a DWORD. So pretty much every single instruction using that needs to be modified AND the code offsets for relative jumps need to remain intact (this I think is hard).