BEEN_Nath_58 wrote on 2023-08-23, 04:30:

I will try the fix a while later. […]
Show full quote

I will try the fix a while later.

Btw what do you intend to do with running I76 and Mech2 directly. Mech2, as far as I know, will need patching in CPU scheduling, GDI BitBlt tweaking, some FirstFindFileA API tweaking, some 8.3 pathname tweaking, a custom heap and the most problematic - the mission loading exceptions (yes I had to manage all that when I worked on it in 2021 Q4 - 2022 Q4).

Interstate 76 has IDIV0 exceptions that MS can handle, but on my machine there are other ones too (for which I need DxWnd).

Also how do you intend to limit the FPS: for I76 is designed to run at 25FPS over which physics start breaking (notable at over 30).

There's a framerate limiter in RReady. Just add MaxFPS=nn to Rendition.cfg and it will approximate the frame rate.

I'd rather not reinvent the wheel. But realistically I don't think I can distribute DxWnd or dgVoodoo with my wrapper (or both).

The Microsoft app store for instance doesn't allow open source software to be sold, even in combination with a closed source stuff. MS bundles plenty of open source stuff, but other vendors can't.

sharangad wrote on 2023-08-23, 04:37:

feda wrote on 2023-08-22, 23:08:

BEEN_Nath_58 wrote on 2023-08-22, 15:53:

The black screen problem seems to be a DirectDraw problem fixable by dgVoodoo2, DxWnd or DDrawCompat. Maybe its a generic issue.

Yup, Dgv2 fixes it. I previously thought it couldn't work in conjunction with RReady, but it actually does.

Ideally though, this wrapper should include its own fixes to avoid having to use extra wrappers 🤣

What settings do you use to get rid of the black screen?

Everything is at default with "dgVoodoo Virtual 3D Accelerated Card" selected in the control panel and the Rendition renderer chosen in the game. Dgv version 2.81.1.

sharangad wrote on 2023-08-23, 04:05:

Heavy Gear 1 default constant fogging value fix: […]
Show full quote

Heavy Gear 1 default constant fogging value fix:

https://1drv.ms/u/s!As-dKk-N73dSlWqrlXPcYGyXkQZD?e=eotpUA

MD5: 7c6771be2976016c49c1cfd79d1d03fe

This should fix the corruption in Heavy Gear 1.

That did it 😀

feda wrote on 2023-08-23, 07:32:

Everything is at default with "dgVoodoo Virtual 3D Accelerated Card" selected in the control panel and the Rendition renderer chosen in the game. Dgv version 2.81.1.

That works for me with Myth TFL but not Heavy Gear 1. I get a black screen on mission exit. 🙁

feda wrote on 2023-08-23, 07:32:

That did it 😀

Phew!

BEEN_Nath_58 wrote on 2023-08-21, 13:20:

For Myth TFL, I enabled the 4 "Limit ..." flags present in DxWnd's Compatibility tab. You can manually change the memory values in Menu bar ->Global settings ->Defaults, but probably it won't be required.

That doesn't work for me. I still get an "out of memory" error.

I had a deeper look in Heavy Gear, and it turns out both dgVoodoo2 and DxWnd someway gives the black screen. So I guess I will have to dig better.

Update: The game would sometimes crash on startup due to failure in building the Primary Surface, and for getting an undefined color depth (it was an AMD bug, not NVIDIA). Lets see...

BEEN_Nath_58 wrote on 2023-08-23, 13:15:

I had a deeper look in Heavy Gear, and it turns out both dgVoodoo2 and DxWnd someway gives the black screen. So I guess I will have to dig better.

Update: The game would sometimes crash on startup due to failure in building the Primary Surface, and for getting an undefined color depth (it was an AMD bug, not NVIDIA). Lets see...

I really need someone to test the SODA menus on an AMD GPU. Goh's having issues and I think he's on AMD.

sharangad wrote on 2023-08-24, 04:04:

BEEN_Nath_58 wrote on 2023-08-23, 13:15:

I had a deeper look in Heavy Gear, and it turns out both dgVoodoo2 and DxWnd someway gives the black screen. So I guess I will have to dig better.

Update: The game would sometimes crash on startup due to failure in building the Primary Surface, and for getting an undefined color depth (it was an AMD bug, not NVIDIA). Lets see...

I really need someone to test the SODA menus on an AMD GPU. Goh's having issues and I think he's on AMD.

Check on SourceForge again...

BEEN_Nath_58 wrote on 2023-08-24, 06:22:

sharangad wrote on 2023-08-24, 04:04:

BEEN_Nath_58 wrote on 2023-08-23, 13:15:

I had a deeper look in Heavy Gear, and it turns out both dgVoodoo2 and DxWnd someway gives the black screen. So I guess I will have to dig better.

Update: The game would sometimes crash on startup due to failure in building the Primary Surface, and for getting an undefined color depth (it was an AMD bug, not NVIDIA). Lets see...

I really need someone to test the SODA menus on an AMD GPU. Goh's having issues and I think he's on AMD.

Check on SourceForge again...

I posted this there:
SODA menu corruption possible fix (untested on anything other than recent nvidia):
https://1drv.ms/u/s!As-dKk-N73dSlWtpmA4bsjVRY0Ga?e=SjI8ys

MD5:9edebef8ad9d6f2e83f3b961b73d0e30

Need to find out if soda's level select menu works on amd gpus.

Your original post still mentions that Myth and I76 doesn't work. You could change that.

Btw I noticed that the crash when using DxWnd, happens only with RReady. No other APIs crash in such a manner. It is likely a DxWnd problem, but you could analyse better. Gho mentioned he fixed "historical bugs" before this problem came up, so I don't know if RReady is also working correctly over a "bug". You could try his wip23 release and test a game with RRedline: Mech2, I76, Soda OFF Road Racing, Quake 2,...

I had some suggestions about the RReady Launcher:

• You said that the requirement to have the launcher open would go away in the later release. That's good.
• You should replace it with a configurator, like dgVoodoo2 or nGlide does.
• The new RReady Configurator could open straight to the application control panel, instead of "Information" tab.
• In Application setting, you probably can remove the resolution list beside "Force fullscreen". There is already a resolution list beside the "Remap all fs resolutions", that could be used in both cases simultaneously.
• The "Force fullscreen" becomes an option to the above.
• You could trim the frame rate part from the resolutions. RReady would use some OpenGL method to enumerate all possible render resolutions.
• The frame rate part is set to another setting. This is to ensure the resolution list doesn't get flooded with frame rate variants of a single resolution.
• RReady can also have a fallback resolution and frame rate list if enumeration fails. It is unlikely, but who knows, in some years...

Since you are working on OpenGL, I had this question: is it possible to output OpenGL on 16-bit color mode? I always see OpenGL output at 32-bit now, it used to do on 16-bit, but that was a Riva 128 accelerator.

An extra news: I used to have a black screen at launch. This could be fixed using DXPrimaryEmulation -DisableMaxWindowedMode shim. Enable it with ACT or Compatibility/Disable max windowed mode in DxWnd. With RReady I also needed to have single core affinity and it was fine.

BEEN_Nath_58 wrote on 2023-08-26, 15:09:

Your original post still mentions that Myth and I76 doesn't work. You could change that.

I intend to do an interim release soonish. Will update that entire post. The laucher seems to have an acquired a nasty bug where the sdk/rredline demos populate the wingames tab.

BEEN_Nath_58 wrote on 2023-08-26, 15:09:

Btw I noticed that the crash when using DxWnd, happens only with RReady. No other APIs crash in such a manner. It is likely a DxWnd problem, but you could analyse better. Gho mentioned he fixed "historical bugs" before this problem came up, so I don't know if RReady is also working correctly over a "bug". You could try his wip23 release and test a game with RRedline: Mech2, I76, Soda OFF Road Racing, Quake 2,...

Crash with which app? I'll test with Wip 23. Do you have a link?

BEEN_Nath_58 wrote on 2023-08-26, 15:09:

I had some suggestions about the RReady Launcher: […]
Show full quote

I had some suggestions about the RReady Launcher:

• You said that the requirement to have the launcher open would go away in the later release. That's good.
• You should replace it with a configurator, like dgVoodoo2 or nGlide does.
• The new RReady Configurator could open straight to the application control panel, instead of "Information" tab.
• In Application setting, you probably can remove the resolution list beside "Force fullscreen". There is already a resolution list beside the "Remap all fs resolutions", that could be used in both cases simultaneously.
• The "Force fullscreen" becomes an option to the above.
• You could trim the frame rate part from the resolutions. RReady would use some OpenGL method to enumerate all possible render resolutions.
• The frame rate part is set to another setting. This is to ensure the resolution list doesn't get flooded with frame rate variants of a single resolution.
• RReady can also have a fallback resolution and frame rate list if enumeration fails. It is unlikely, but who knows, in some years...

Some apps have to be launched with a specific command line line, like "Team Apache." So the launching part probably won't go away. The others are good suggestions and I will implement them as soon as I get Apache going. It's not going very well at the moment.

Rready uses a Win32 API call to enumerate resolutions and refresh rates. The refresh rates are per resolution, which is why I grouped them together. Yes, they could be separated, but it's not a priority at the moment.

BEEN_Nath_58 wrote on 2023-08-26, 15:09:

Since you are working on OpenGL, I had this question: is it possible to output OpenGL on 16-bit color mode? I always see OpenGL output at 32-bit now, it used to do on 16-bit, but that was a Riva 128 accelerator.

When an opengl context is created you can specify the bit depth including if necessary individually for rgb channels. That's how 30 bit colour contexts are created R10G10B10A2 (2 bit alpha). The 16 bit capability (I think) is emulated. Back in the 90s the gpus physically supported 16 bit framebuffers R5G6B5. OpenGL still supports 16 bit textures natively. RReady uses that support for a lot of RRedline games, even though it could convert everything to R8G8B8A8 internally. On modern GPUs all textures are converted to 32 bit RGBA (with the exception of floating point textures. I've not dealt with them much).

You can still request 16 bits, but deep down the framebuffer will be 32 bit. Windows 16BITCOLOR compatibility feature just reports 32 bit modes as 16 bit. The actual modes when switched will be the 32 bit ones.

BEEN_Nath_58 wrote on 2023-08-26, 15:09:

An extra news: I used to have a black screen at launch. This could be fixed using DXPrimaryEmulation -DisableMaxWindowedMode shim. Enable it with ACT or Compatibility/Disable max windowed mode in DxWnd. With RReady I also needed to have single core affinity and it was fine.

Is this with Heavy Gear 1?

sharangad wrote on 2023-08-26, 17:27:

I intend to do an interim release soonish. Will update that entire post. The laucher seems to have an acquired a nasty bug where […]
Show full quote

BEEN_Nath_58 wrote on 2023-08-26, 15:09:

Your original post still mentions that Myth and I76 doesn't work. You could change that.

I intend to do an interim release soonish. Will update that entire post. The laucher seems to have an acquired a nasty bug where the sdk/rredline demos populate the wingames tab.

BEEN_Nath_58 wrote on 2023-08-26, 15:09:

Btw I noticed that the crash when using DxWnd, happens only with RReady. No other APIs crash in such a manner. It is likely a DxWnd problem, but you could analyse better. Gho mentioned he fixed "historical bugs" before this problem came up, so I don't know if RReady is also working correctly over a "bug". You could try his wip23 release and test a game with RRedline: Mech2, I76, Soda OFF Road Racing, Quake 2,...

Crash with which app? I'll test with Wip 23. Do you have a link?

BEEN_Nath_58 wrote on 2023-08-26, 15:09:

I had some suggestions about the RReady Launcher: […]
Show full quote

I had some suggestions about the RReady Launcher:

• You said that the requirement to have the launcher open would go away in the later release. That's good.
• You should replace it with a configurator, like dgVoodoo2 or nGlide does.
• The new RReady Configurator could open straight to the application control panel, instead of "Information" tab.
• In Application setting, you probably can remove the resolution list beside "Force fullscreen". There is already a resolution list beside the "Remap all fs resolutions", that could be used in both cases simultaneously.
• The "Force fullscreen" becomes an option to the above.
• You could trim the frame rate part from the resolutions. RReady would use some OpenGL method to enumerate all possible render resolutions.
• The frame rate part is set to another setting. This is to ensure the resolution list doesn't get flooded with frame rate variants of a single resolution.
• RReady can also have a fallback resolution and frame rate list if enumeration fails. It is unlikely, but who knows, in some years...

Some apps have to be launched with a specific command line line, like "Team Apache." So the launching part probably won't go away. The others are good suggestions and I will implement them as soon as I get Apache going. It's not going very well at the moment.

Rready uses a Win32 API call to enumerate resolutions and refresh rates. The refresh rates are per resolution, which is why I grouped them together. Yes, they could be separated, but it's not a priority at the moment.

BEEN_Nath_58 wrote on 2023-08-26, 15:09:

Since you are working on OpenGL, I had this question: is it possible to output OpenGL on 16-bit color mode? I always see OpenGL output at 32-bit now, it used to do on 16-bit, but that was a Riva 128 accelerator.

When an opengl context is created you can specify the bit depth including if necessary individually for rgb channels. That's how 30 bit colour contexts are created R10G10B10A2 (2 bit alpha). The 16 bit capability (I think) is emulated. Back in the 90s the gpus physically supported 16 bit framebuffers R5G6B5. OpenGL still supports 16 bit textures natively. RReady uses that support for a lot of RRedline games, even though it could convert everything to R8G8B8A8 internally. On modern GPUs all textures are converted to 32 bit RGBA (with the exception of floating point textures. I've not dealt with them much).

You can still request 16 bits, but deep down the framebuffer will be 32 bit. Windows 16BITCOLOR compatibility feature just reports 32 bit modes as 16 bit. The actual modes when switched will be the 32 bit ones.

BEEN_Nath_58 wrote on 2023-08-26, 15:09:

An extra news: I used to have a black screen at launch. This could be fixed using DXPrimaryEmulation -DisableMaxWindowedMode shim. Enable it with ACT or Compatibility/Disable max windowed mode in DxWnd. With RReady I also needed to have single core affinity and it was fine.

Is this with Heavy Gear 1?

I meantioned the games that crash with wip23 in my text: mech2, i76,...

The DXprimaryemulation suggestion was for Heavy Gear 1

Windows 16-bit color compatibility doesn't work for everything. For example D3D9Ex isn't supported through this. But DxWnd allows and enumerates 16bit modes created throgh D3D9Ex.

Same for D3D8 backbuffers: they aren't handled in the Windows 16bit color mode.

I asked this because I saw on Quake 2, color banding: a symptom of 16bit color usage; and on native OGL there's no color banding. So I guessed RReady would output with RGB565 textures and Windows would do ARGB8888 or without Alpha. I would need the 16bit output for Half Life, a game which changes to D3D/DDraw mode and utilises 16bit color, when initially running with OGL (32-bit color, and color switching to 16bit causing problems).

Wip 23
Interstate '76 renders perfectly (well done, run through Rlauncher or dxwnd runhooked), but the game is erratic. The training level in my youtube video runs differently. When I previously tested it the car drove along a pre-defined sequence).

In the intro sequence the car now wobbles horribly like it's on a bumpy surface and drives all over the place including off the road. With Wip16 it always drove along the main road before stopping with the precise stopping point varying by less than a quarter of the length of the car. The actual gameplay seems fine. There's also a bit where the buffer swap doesn't appear to be working with a previous frame overlaid on the current (intro seq. interior HUD of car appearing during external view for a few frames).

Mech Warrior 2 Titanium Mercenaries, runs perfectly hooked only (With the current build of RReady, which I plan to release soonish). After exiting a mission the exit briefing doesn't appear on screen unless the <Windows> key is pressed.

Overall nice work guys.

BEEN_Nath_58 wrote on 2023-08-26, 18:36:

Windows 16-bit color compatibility doesn't work for everything. For example D3D9Ex isn't supported through this. But DxWnd allows and enumerates 16bit modes created throgh D3D9Ex.

Same for D3D8 backbuffers: they aren't handled in the Windows 16bit color mode.

I asked this because I saw on Quake 2, color banding: a symptom of 16bit color usage; and on native OGL there's no color banding. So I guessed RReady would output with RGB565 textures and Windows would do ARGB8888 or without Alpha. I would need the 16bit output for Half Life, a game which changes to D3D/DDraw mode and utilises 16bit color, when initially running with OGL (32-bit color, and color switching to 16bit causing problems).

vQuake 2 actually uses 8 bit, 256 colour textures and performs the palette look up using RRedline's VL_Lookup (v1k_surfacelookup =1 in baseq2/config or autoexec) or the host CPU (v1k_surfacelookup =0). Doing this using RRedline with RReady is slow, because it takes a ridiculous number of API calls to setup the call (load palette texture, set render to texture, a whole bunch of parameters and finally VL_Lookup). vHexen II can also use it, but it's configured by another parameter. vHexen II uses actually multiple formats, not just RGB565 with alpha channels.

VL_Lookup converts 8 bit palettized data into whatever format the render target required (which for RReady is always RGBA8888).

The reason 8 bit textures are used is that Quakes 1 & 2 were designed to on VESA SVGA cards with software rendering, so the game limited the palette to 256 colours, which was what was most performant with sofware rendering. Yamagi's yquake2 has a 16 bit software renderer, but this won't run on 90s era hardware.

August 27, 2023:

Please see 1st page for fixes.

https://1drv.ms/u/s!As-dKk-N73dSlXDCLw7avRY8WPHv?e=eTNacg

MD5:d80770f61ea3d9aec1168345d024c784

You told MW2 Titanium works perfectly with wip23 but it crashes for me

BEEN_Nath_58 wrote on 2023-08-27, 19:26:

You told MW2 Titanium works perfectly with wip23 but it crashes for me

Untick windowed and it should work.

You need to do the same for interstate. You may have to run the game from RLauncher. I don't know why this would make a difference, but it runs every single time from the launcher.

RReady no longer fails on resolution change. It'll ignore it and carry on.

The cutscene in i76 has issues now. The car bounces up and down and no longer sticks to the road.

sharangad wrote on 2023-08-28, 03:56:

Untick windowed and it should work. […]
Show full quote

BEEN_Nath_58 wrote on 2023-08-27, 19:26:

You told MW2 Titanium works perfectly with wip23 but it crashes for me

Untick windowed and it should work.

You need to do the same for interstate. You may have to run the game from RLauncher. I don't know why this would make a difference, but it runs every single time from the launcher.

RReady no longer fails on resolution change. It'll ignore it and carry on.

The cutscene in i76 has issues now. The car bounces up and down and no longer sticks to the road.

DxWnd windowed? Already unticked.

Car problem is probably due to CPU uptime. Restart the computer or set Timing/Clear uptime setting in DxWnd (if latter fails, it needs to be run from DxWnd directly)

Grand Prix Legends Release:

https://1drv.ms/u/s!As-dKk-N73dSlXzOy7Ry7FjpSxh2?e=VX9RGb
MD5:
6eea4dfda7f78fc4d5b9948f12aa91a6
- Adds support for GPL (RLauncher's resolution settings should be set at default. Higher resolutions should be selected from the in-game options menu).
- Fixes performance regression with tdhdemo.
- Team Apache still has glitchy front buffer updates.

With this release all RRedline v2.0 games should be supported either standalone or with dgvoodoo/dxwnd. F1 '97 (RRedline v1.0) being the sole WIndows Rendition game that currently doesn't work.

Fogging Fix (Not fully tested):

https://1drv.ms/u/s!As-dKk-N73dSlgSzhPpxv1WwOOye?e=dzlOev
MD5: f1142836cb6fef31ff43265f45f38a42

- Fogging fixes. Fogging inputs in the range 0-255 were scaled down to 0.0-1.0 in the vertex shader. Now it's done in the fragment shader preventing a loss in precision in fog interpolation. This is very noticeable in Sub Culture.
- Heavy Gear 1 fogging issues. Per vertex fog info now updates the constant fog value (used when fogging is enabled without per vertex data). This caused noticeable sudden polygon colour changes in distant mountains and objects. The last vertex's per vertex info for colour, fog and alpha (when available) is used to update the complementary constant value. On an actual Rendition board this value is indeterminate after passing per vertex data.

Heavy Gear makes a habit of enabling fogging without per vertex data and often not setting the constant value. This should massively improve distant objects.

vHexen II /Heavy Gear fogging Build (September 10 2023)

https://1drv.ms/u/s!As-dKk-N73dSlggPsgIQ_q5Pdr-i?e=EgruKV

- Memory allocation for surfaces and buffer groups have been moved into a custom heap. As a result vHexen II no longer requires DxWnd or Win98 compatibility.
- Should finally fix Heavy Gear 1 fogging. Constant fogging was being set when per vertex fog info was unavailable, but the command buffer numeric property update was disabled during testing and never reenabled.
- This will probably (barring bugs reported) be the final release of RReady until F1 is supported.