IDT results on Creative 3D Blaster PCI CT6240 (V1000-E):

1*(F000:F065) F000F065 (prot. mode)=000000CF
2*(F000:F065) 000FF065 (real mode)=8B3154E8

Thanks Gona.

November 22, 2023 (Fully tested store builld):

https://1drv.ms/u/s!As-dKk-N73dSlwUMo-Zu9Ad0nTvO
MD5: 787425d7a2838f199783f74303be1780

20 November 2023

- Ability to restrict VRAM by setting MaxVRAM=<nn>(Megabytes). The Golems in VH2.exe correctly change colour when VRAM is restricted to between 4-14 MB. Restricting VRAM will severely affect performance and is not recommended. It is also unsupported in other apps.
- RRosetta's renderer switching (using F1-F3) work correctly but for F3 (Direct3D) to work dgVoodo's directdraw/direct3d files need to be copied to the same folder as RRosetta.exe. OpenGL to RRedline switch to work.
- Screenshot capability in games such as WinDie.exe (save game image) or games which have a console command 'screenshot' should work (except VH2.exe. This application appear to do a copy to clipboard and does not currently work.). Screenshot is correctly downsampled now.
- End credits background textures in F1red.exe should work.
- Bilinear filtering (using shaders) is enforced for paletted textures.

Expect this to be live on the store in the next few days, watermark free.

Hello i watching vh2.exe golems bug and it appears call for VL_Lookup is an issue, the asm code here is complex, and if i enforce vl_lookup to be called all time , the golems appears to be working, but i have too many calls of it and FPS drops + it crashes in complex scenes of hexen2.

Is there a way to work around it by calling vl_lookup every 2 seconds maybe to test how it would behave just?

if i disable condition jump at 435665 it renders golems correctly. Yes its vh2.exe bug.

RaVeN-05 wrote on 2023-11-22, 16:47:

Is there a way to work around it by calling vl_lookup every 2 seconds maybe to test how it would behave just?

I think there's a call to VL_PointSurface, to create a fresh surface, which in turn RReady run out of RAM for surface structures.

For VRAM restrictions, I had to enforce reuse of surfaces (checking to see if the passed in vsurface pointer already pointed to an existing structure and resizing it). With 4 MB of RAM it created over 80,000 point surfaces causing a heap overflow. According to spec, VL_PointSurface always creates a fresh structure so I have no idea how it ran on Win98 machines with 4 MB of VRAM.

In Rendition.cfg set ReuseSurface=1

That should force reuse of point surfaces. I think the performance will be as bad as having 4 MB of RAM with your modified binary.

https://1drv.ms/u/s!As-dKk-N73dSlwYMo-Zu9Ad0nTvO
MD5: 13607e018e48204aca4e9a8d46c3a318

I think the condition in that block doesn't trigger for some reason. It could well be an RReady issue, something not being reported correctly. I had trouble following the assembly in that block. What the parameters are is a mystery. One of them is a colour ramp.

well i modified jump at 435665 to "JNZ SHORT 004356CC" its closest "safe?" function overjumping VL_PointSurface , this is extra dirty, it survives against full speedrun demos.
Cost of it FPS drops below 30 , even 10 sometimes. but all the golems effects works.

vl_lookup should be called when golem going to attack. Several times? while pallette changes, it tries to re-pal whole golem texture.

i dunno but it feels like vh2 modifies golem texture but didn't upload to video card that modified texture. did we have two textures ? one is handled by vh2 another is uploaded?

RaVeN-05 wrote on 2023-11-22, 19:33:

well i modified jump at 435665 to "JNZ SHORT 004356CC" its closest "safe?" function overjumping VL_PointSurface , this is extra […]
Show full quote

well i modified jump at 435665 to "JNZ SHORT 004356CC" its closest "safe?" function overjumping VL_PointSurface , this is extra dirty, it survives against full speedrun demos.
Cost of it FPS drops below 30 , even 10 sometimes. but all the golems effects works.

vl_lookup should be called when golem going to attack. Several times? while pallette changes, it tries to re-pal whole golem texture.

i dunno but it feels like vh2 modifies golem texture but didn't upload to video card that modified texture. did we have two textures ? one is handled by vh2 another is uploaded?

With VL_Lookup the current textures is a 256x1 palette texture. A width * height sized data block is passed as the raw data and the bytes are converted into a full bit depth data (using palette daa). This is why there's banding with VL_Lookup. The raw data's only got 256 colours.

At address 435605 it correctly detects the golems even with 128 MB, the blocks after that fail bit by bit:
cmp [eax+90h], ecx (test passes correctly for golem textures), the subsequent blocks fail. Placing a break point here will correctly break execution at particle attack golem textures even with full VRAM.

I have a hard time following or understanding the condition tests which come afterwards. I suspect something rready is or isn't doing is triggering it.

@been_nath. The issue with i76 on my problem machine is that opengl commands don't work, even though the context is valid. It doesn't even produce a failed to initialise 3d hardware error. This is the case with or without dxwnd. Oddly enough HD 4000 can run it just fine. Uhd 6xx fails miserably.

Your problem on an nvidia card is that dxwnd doesn't engage, which is why you get a failed to initialise 3d hardware error.

My problem is an Intel driver compatibility issue. I don't know what's causing yours. Nvidia shouldn't have any issues with it.

RaVeN-05 wrote on 2023-11-22, 19:33:

well i modified jump at 435665 to "JNZ SHORT 004356CC" its closest "safe?" function overjumping VL_PointSurface , this is extra […]
Show full quote

well i modified jump at 435665 to "JNZ SHORT 004356CC" its closest "safe?" function overjumping VL_PointSurface , this is extra dirty, it survives against full speedrun demos.
Cost of it FPS drops below 30 , even 10 sometimes. but all the golems effects works.

vl_lookup should be called when golem going to attack. Several times? while pallette changes, it tries to re-pal whole golem texture.

i dunno but it feels like vh2 modifies golem texture but didn't upload to video card that modified texture. did we have two textures ? one is handled by vh2 another is uploaded?

VL_Lookup is called for a number of textures including the player's arm. If you set r_surfacelookup=1 everything goes through VL_Lookup.

For some reason the the game decides the golem textures don't need to be updated, The initial check at 435605 passes, but it fails later on.

sharangad wrote on 2023-11-23, 01:42:

@been_nath. The issue with i76 on my problem machine is that opengl commands don't work, even though the context is valid. It doesn't even produce a failed to initialise 3d hardware error. This is the case with or without dxwnd. Oddly enough HD 4000 can run it just fine. Uhd 6xx fails miserably.

Your problem on an nvidia card is that dxwnd doesn't engage, which is why you get a failed to initialise 3d hardware error.

My problem is an Intel driver compatibility issue. I don't know what's causing yours. Nvidia shouldn't have any issues with it.

Yes I recognised that it could be a DxWnd problem. But the problem is so inconsistent that it is more difficult to debug. It happens 7/10 times and in any intermediate tests there could be something additional problematic.

DxWnd doesn't hook ENTIRE OPENGL. It could well be that something doesn't hook either?

RaVeN-05 wrote on 2023-11-22, 19:33:

well i modified jump at 435665 to "JNZ SHORT 004356CC" its closest "safe?" function overjumping VL_PointSurface , this is extra […]
Show full quote

well i modified jump at 435665 to "JNZ SHORT 004356CC" its closest "safe?" function overjumping VL_PointSurface , this is extra dirty, it survives against full speedrun demos.
Cost of it FPS drops below 30 , even 10 sometimes. but all the golems effects works.

vl_lookup should be called when golem going to attack. Several times? while pallette changes, it tries to re-pal whole golem texture.

i dunno but it feels like vh2 modifies golem texture but didn't upload to video card that modified texture. did we have two textures ? one is handled by vh2 another is uploaded?

loc_43573D is where the VL_Lookup is called for the golem. The palette texture is loaded using VL_LoadBuffer.

BEEN_Nath_58 wrote on 2023-11-23, 04:05:

sharangad wrote on 2023-11-23, 01:42:

@been_nath. The issue with i76 on my problem machine is that opengl commands don't work, even though the context is valid. It doesn't even produce a failed to initialise 3d hardware error. This is the case with or without dxwnd. Oddly enough HD 4000 can run it just fine. Uhd 6xx fails miserably.

Your problem on an nvidia card is that dxwnd doesn't engage, which is why you get a failed to initialise 3d hardware error.

My problem is an Intel driver compatibility issue. I don't know what's causing yours. Nvidia shouldn't have any issues with it.

Yes I recognised that it could be a DxWnd problem. But the problem is so inconsistent that it is more difficult to debug. It happens 7/10 times and in any intermediate tests there could be something additional problematic.

DxWnd doesn't hook ENTIRE OPENGL. It could well be that something doesn't hook either?

I think it's not hooking at all. OpenGL isn't initialised until a short while after the game starts up. DxWnd needs to hook before then or the app will fail. Timing maybe.

RaVeN-05 wrote on 2023-11-22, 19:33:

well i modified jump at 435665 to "JNZ SHORT 004356CC" its closest "safe?" function overjumping VL_PointSurface , this is extra […]
Show full quote

well i modified jump at 435665 to "JNZ SHORT 004356CC" its closest "safe?" function overjumping VL_PointSurface , this is extra dirty, it survives against full speedrun demos.
Cost of it FPS drops below 30 , even 10 sometimes. but all the golems effects works.

vl_lookup should be called when golem going to attack. Several times? while pallette changes, it tries to re-pal whole golem texture.

i dunno but it feels like vh2 modifies golem texture but didn't upload to video card that modified texture. did we have two textures ? one is handled by vh2 another is uploaded?

When a golem beam attacks, the same texture is VL_Lookup'd with different palette data.

1) Palette is loaded with VL_LoadBuffer (gets progressively greener and after the attack more neutral)
2) VL_Lookup with constant (depending on MIP map size) data

Before this point VL_InstallDstBuffer would've been setup with the target golem texture and contains the result of VL_Lookup. So it's a render to texture operation. VL_installTextureMap sets up the golem texture after that.

When the golem isn't attacking, the function calls VL_InstallTextureMap without doing anything else.

The problem here is the condition test at the location you modified fails Why does it fail and what're the two parameters it's comparing?

One more for @Raven-05:

In Quake 2's ref_v1k, the window creation follows two paths. One path for windowed and another for fullscreen. The fullscreen window creation fails because of an issue with the window style (CreateWindowEx @10011F06 in ref_v1k).
10011F06 jz short loc_10011F0C
If that branch isn't taken I think it should work.

I *think* this should be called always:
10011F08 mov [esp+4Ch+dwExStyle], edi

I'm having trouble patching it because of instruction size mismatches.

Does anyone know why the heavy assembly logging dump in dosbox staging doesn't appear to match register state changes?

Excellent find! the fullscreen works, v1k_ref reports 800x600 FS (not W) mode which is fullscreen

W00t! Works, can toggle fullscreen now in vQuake2!

Need to update RLauncher.

Thanks Raven!

RaVeN-05 wrote on 2023-11-22, 19:33:

well i modified jump at 435665 to "JNZ SHORT 004356CC" its closest "safe?" function overjumping VL_PointSurface , this is extra […]
Show full quote

well i modified jump at 435665 to "JNZ SHORT 004356CC" its closest "safe?" function overjumping VL_PointSurface , this is extra dirty, it survives against full speedrun demos.
Cost of it FPS drops below 30 , even 10 sometimes. but all the golems effects works.

vl_lookup should be called when golem going to attack. Several times? while pallette changes, it tries to re-pal whole golem texture.

i dunno but it feels like vh2 modifies golem texture but didn't upload to video card that modified texture. did we have two textures ? one is handled by vh2 another is uploaded?

Are you sure the palette lookup occurs for the golems? When I put a breakpoint in at VL_Lookup, it never stopped there. This suggestd to me the palette cycling never happens with more than 14 MB of RAM. With 14 MB or less the breakpoint is triggered.

yes, with this modification it works

RaVeN-05 wrote on 2023-11-22, 19:33:

well i modified jump at 435665 to "JNZ SHORT 004356CC" its closest "safe?" function overjumping VL_PointSurface , this is extra […]
Show full quote

well i modified jump at 435665 to "JNZ SHORT 004356CC" its closest "safe?" function overjumping VL_PointSurface , this is extra dirty, it survives against full speedrun demos.
Cost of it FPS drops below 30 , even 10 sometimes. but all the golems effects works.

vl_lookup should be called when golem going to attack. Several times? while pallette changes, it tries to re-pal whole golem texture.

i dunno but it feels like vh2 modifies golem texture but didn't upload to video card that modified texture. did we have two textures ? one is handled by vh2 another is uploaded?

@Raven-05, if you modifiy
00433A59 shl eax, 9
to
00433A59 shl eax, 4
Does the game render correctly at full speed even the golems?
Try this instead:
00433A59 shl eax, 3

No is the answer. 🙁