Revisiting Extreme Assault 3Dfx

General information and assistance with dgVoodoo.

Revisiting Extreme Assault 3Dfx

Postby kjliew » 2018-10-06 @ 08:14

I found that Extreme Assault 3Dfx is quite different between the demo and the retailed version. In fact, I think a lot of us were working to get the demo working with Glide wrappers but indeed the demo version looked to be broken version from the traces of QEMU 3Dfx Glide pass-through.

3Dfx Demo Version E 1.1.1
glidept: grSstWinOpen called, buf 0 aux 2
window 640x480
Retailed CD Version E 1.1.0
glidept: grSstWinOpen called, buf 0 aux 2
window 640x480
Retailed CD patched E 1.2.0 til 1.2.2
glidept: grSstWinOpen called, buf 3 aux 0
window 640x480
Retailed CD patched E 1.2.3
glidept: grSstWinOpen called, buf 2 aux 0
window 640x480

So the demo and the un-patched retailed version are obviously wrong in the invoking of Glide API as the 3Dfx Glide 2.4 specification clearly mentions in grSstWinOpen() buf must be 2 or 3, while aux must be 0 or 1. Both buf and aux are taking invalid arguments. It was funny that since most of us typically started out with the demo and we somehow we made this work. DgVoodoo2 works despite taking invalid arguments. Performance is normal, on my system around 25~28FPS flying around in the "Network Play->Training->City".

Once patched, this includes version 1.2.0, 1.2.1 and 1.2.2, grSstWinOpen() now takes sane arguments, but it breaks dgVoodoo2 rendering. Objects (buildings, roads, items) are missing. The game is not playable with dgVoodoo2. On the other hand, OpenGlide now works. Objects are rendered correctly, performance is normal (25~28FPS) and game is playable.

The final patched version 1.2.3, both dgVoodoo2 and OpenGlide render the objects correctly. Unfortunately, dgVoodoo2 takes a big hit on performance with correct HUD transparency. Flying around in the same "Network Play->Training->City" recorded ~9 FPS. This makes it slower than software rendering, and software rendering does render HUD transparency. OpenGlide seemed unaffected and performance was normal but it did not render the HUD transparency.

So in practice, dgVoodoo2 works with the demo, the unpatched and the final version 1.2.3 but it is too slow to be playable with the final version. OpenGlide works with any versions from 1.2.0 and above, but it did not work with the demo.
kjliew
Member
 
Posts: 255
Joined: 2004-1-08 @ 03:03

Re: Revisiting Extreme Assault 3Dfx

Postby Gamecollector » 2018-10-06 @ 12:28

kjliew wrote:3Dfx Glide 2.4 specification

Well, only the 1.2.3 version is Voodoo2 compatible. Maybe 3dfx added the strict syntax for _grSstWinOpen around/after the Voodoo2 release date?

P.S. Interesting. Can you test Dreams to Reality, Prost Grand Prix and Tie Break Tennis for grSstWinOpen parameters? These 3 games not work with Voodoo2 too.
Asus P4P800 SE/Pentium4 3.2E/2 Gb DDR400B,
Radeon HD3850 Agp (Sapphire), Catalyst 14.4 (XpProSp3).
Voodoo2 12 MB SLI, Win2k drivers 1.02.00 (XpProSp3).
User avatar
Gamecollector
Oldbie
 
Posts: 1311
Joined: 2010-10-06 @ 22:17

Re: Revisiting Extreme Assault 3Dfx

Postby kjliew » 2018-10-06 @ 19:46

I think the game was shipped with Voodoo1 GLIDE2X.OVL, and it was put in the same folder as the game EXE. This could render your Voodoo2 GLIDE2X.OVL useless if you had the Voodoo2 GLIDE2X.OVL placed in WINDOWS folder during Win9x driver installation. XA_A123.EXE only patched 2 files, XA_3DFX.EXE and GLIDE2X.OVL. Perhaps, version 1.2.0, 1.2.1 and 1.2.2 would run with Voodoo2 if you remove the GLIDE2X.OVL in the game folder or explicitly replace it with the copy from your Voodoo2 drivers.

What Version 1.2.3 does is deleting GLIDE2X.OVL in the game folder and updating XA_3DFX.EXE. The game bundled GLIDE2X.OVL is pretty outdated, 2.31. The official 3Dfx Glide SDK 2.4 shipped with 2.43.

Do you observe performance hit on real Voodoo2 on version 1.2.3?

I found that dgVooodoo2 performance hit on version 1.2.3 is due to transparent HUD. By removing the HUD (PgDn) or disable transparency (Shift-F8), dgVoodoo2 FPS improved to normal performance level.
Last edited by kjliew on 2018-10-06 @ 21:09, edited 1 time in total.
kjliew
Member
 
Posts: 255
Joined: 2004-1-08 @ 03:03

Re: Revisiting Extreme Assault 3Dfx

Postby Dege » 2018-10-06 @ 19:46

Extreme Assault renders the transparent HUD by the technique of 'active pixel pipeline during LFB writes'.
Also, it's LFB-access is not too optimal (and poorly coded), you may need 'Force emulating true PCI access'.

I don't know which version of the game I'm having but probably an unpatched version that works only with a virtual Voodoo card model up and including to Voodoo2 (because LFB-access code needs tiled memory layout). I've just gave it a go but it runs at a constant 30 fps.
Dege
Oldbie
 
Posts: 1315
Joined: 2003-9-04 @ 11:06

Re: Revisiting Extreme Assault 3Dfx

Postby kjliew » 2018-10-06 @ 21:49

Dege wrote:Extreme Assault renders the transparent HUD by the technique of 'active pixel pipeline during LFB writes'.
Also, it's LFB-access is not too optimal (and poorly coded), you may need 'Force emulating true PCI access'.

With "ForceEmulatingTruePCIAccess = true", dgVoodoo2 rendered transparent HUD in all versions, but frame rate dropped from 25+ to 17+ in all versions, and version 1.2.0 - 1.2.2 still have missing objects. It was an improvement though for version 1.2.3 which frame rate improved from 9+ to 17+. The moment transparency was disabled, the frame rate shot up to 25+.

Dege wrote:I don't know which version of the game I'm having but probably an unpatched version that works only with a virtual Voodoo card model up and including to Voodoo2 (because LFB-access code needs tiled memory layout). I've just gave it a go but it runs at a constant 30 fps.

I think it makes a lot of sense to figure out the version as we are discussing version discrepancies here. You can get the version from the opening scene with the helicopter and missiles, the version is printed on the lower left corner. Un-patched is version 1.1.0. Did you run the game from DOSBox? Can you patch the game to check out the missing objects?
kjliew
Member
 
Posts: 255
Joined: 2004-1-08 @ 03:03

Re: Revisiting Extreme Assault 3Dfx

Postby kjliew » 2018-10-07 @ 01:01

Gamecollector wrote:Can you test Dreams to Reality, Prost Grand Prix and Tie Break Tennis for grSstWinOpen parameters? These 3 games not work with Voodoo2 too.


Prost Grand Prix is fine. It is the typical standard on invoking _grSstWinOpen()
glidept: grSstWinOpen called, buf 2 aux 1
window 640x480
OpenGlide and psVoodoo both worked fine, which kind of implies that its LFB semantics are sane and Voodoo2 should work. DgVoodoo2 worked with ""ForceEmulatingTruePCIAccess = true" with reduced performance. Without the "ForceEmulatingTruePCIAccess = true", it brought down QEMU with it when entering race circuits, an indication that some faults had occurred somewhere during emulation.

How did you run Tie Break'98 in 3Dfx Glide mode? It didn't seem to call into GLIDE2X.OVL although the installation did install a copy into the game folder.
kjliew
Member
 
Posts: 255
Joined: 2004-1-08 @ 03:03

Re: Revisiting Extreme Assault 3Dfx

Postby Gamecollector » 2018-10-07 @ 15:24

kjliew wrote:Perhaps, version 1.2.0, 1.2.1 and 1.2.2 would run with Voodoo2 if you remove the GLIDE2X.OVL

Already. I always delete glide.dll/sst1init.dll/glide2x.dll/fxmemmap.vxd/glide2x.ovl installed by a game itself.

Do you observe performance hit on real Voodoo2 on version 1.2.3?

No.

How did you run Tie Break'98 in 3Dfx Glide mode?

Dosbox Daum (26 Jan 2014) + nGlide 2.00:

TBT1.JPG

Well, I retest DOS glide titles on my test PC after I re-create my Win98 Boot floppy...
Asus P4P800 SE/Pentium4 3.2E/2 Gb DDR400B,
Radeon HD3850 Agp (Sapphire), Catalyst 14.4 (XpProSp3).
Voodoo2 12 MB SLI, Win2k drivers 1.02.00 (XpProSp3).
User avatar
Gamecollector
Oldbie
 
Posts: 1311
Joined: 2010-10-06 @ 22:17

Re: Revisiting Extreme Assault 3Dfx

Postby kjliew » 2018-10-08 @ 00:03

@Gamecollector
Tie Break'98 did not seem to call into the stub GLIDE2X.OVL on QEMU, so the option to choose 3Dfx didn't show up. It worked fine on DOSBox with gulikoza's stub GLIDE2X.OVL. So far, this is the 1st time I had seen this. Looking into my QEMU stub GLIDE2X.OVL source code, the only possible cause was DPMI int31h call MapPhysicalToLinear had failed somehow. I will have to debug more into this.

The game run fine with OpenGlide and psVoodoo, so that seems like it is a well behaving game. It is unlikely that Voodoo2 failed to support it. It is also shipped with official GLIDE2X.OVL version 2.43, the same copy as in official 3Dfx Glide 2.4 SDK. Although Voodoo2 was shipped with Glide 2.5, there was no update to the SDK to reflect any changes in the API.

Update: OK, I got my QEMU stub GLIDE2X.OVL working now. It seems that this is another poorly coded game. DOSBox has 2 workarounds and I had to do the same. It called _grGlideInit() and _grSstWinOpen() twice during initialization. Perhaps, voodoo1 hardware tolerated such abuses, but not voodoo2. You can try having DOSBox driving a real voodoo2 GLIDE2X.DLL from Windows to see if the game works on voodoo2 or patch the game to remove the redundant calls. That may explain it.

Tie Break '98 runs poorly on QEMU, less than 6 FPS not sure why. It is OK on DOSBox. Even the software rendering 640x480 looked very poor, strange indeed, because QEMU raw VESA rendering should be fast enough for most DOS games.
kjliew
Member
 
Posts: 255
Joined: 2004-1-08 @ 03:03

Re: Revisiting Extreme Assault 3Dfx

Postby Gamecollector » 2018-10-09 @ 20:31

Current testing PC ("MSDOS 7.1"):
P4 3.2E, ASUS P4P800 SE, 2 GB RAM, Radeon HD3850, Voodoo2 SLI, Audigy 2 ZS.
Win98 SE Rus bootable floppy + udvd2.sys, shsucdx and ctmouse from Freedos 1.2.
IDE is in the compatibility mode, HT is disabled, "PnP OS installed" is "No".
No sound, I will try DOS drivers for Audigy later.
Glide2x.ovl is from Voodoo2 w9x 3.02.02 drivers (228196 B, 16 Dec 1999, crc32 - 80ex452a).

Extreme Assault, "MSDOS 7.1":
With game's glide2x.ovl (1.1.0 - 1.2.2) - "_grGlideEnvironment: glide2x.dll expected Voodoo Graphics, none detected" twice.
1.1.0 - quits to the command prompt w/o logos etc.
1.2.0 - 1.2.2 - freezes on the Bluebyte logo.
1.2.3 - works w/o lags or errors.

Tie Break Tennis:
"MSDOS 7.1" - currently the game quits to the command prompt after the intro. I will continue testing. (Replace the videocard? Limit the XMS memory size to 64 MB?) see my next post.
Dosbox Daum + glide2x.dll from w9x drivers 3.02.02 w2k drivers 1.02.00 - there is the 3dfx option but the game freezes after the 3dfx logo.
Last edited by Gamecollector on 2018-10-10 @ 01:39, edited 3 times in total.
Asus P4P800 SE/Pentium4 3.2E/2 Gb DDR400B,
Radeon HD3850 Agp (Sapphire), Catalyst 14.4 (XpProSp3).
Voodoo2 12 MB SLI, Win2k drivers 1.02.00 (XpProSp3).
User avatar
Gamecollector
Oldbie
 
Posts: 1311
Joined: 2010-10-06 @ 22:17

Re: Revisiting Extreme Assault 3Dfx

Postby kjliew » 2018-10-09 @ 21:59

Gamecollector wrote:Extreme Assault, "MSDOS 7.1":
1.1.0 - quits to the command prompt w/o logos etc.
1.2.0 - 1.2.2 - freezes on the Bluebyte logo.
1.2.3 - works w/o lags or errors.

I believe that was the results with Voodoo2 GLIDE2X.OVL by deleting the copy in the game folder. 1.2.3 will do that for you, but not the earlier versions. If you're interested, then you can try different versions of GLIDE2X.OVL. Voodoo2 version can range from 2.50, 2.51, 2.56, 2.61. You can obtain the version from your driver package README.TXT if you use the 3Dfx Voodoo2 reference drivers. Usually, the older version tend to be more compatible for old games. It is good to check out the older version from archive http://falconfly.vogonswiki.com/voodoo2.html. Just unpack the single file into the game folder.

Gamecollector wrote:Tie Break Tennis:
Dosbox Daum + glide2x.dll from w9x drivers 3.02.02 - there is the 3dfx option but the game freezes after the 3dfx logo.

Did you run DOSBox from Win9x? I thought DOSBox can no longer work from Win9x.
kjliew
Member
 
Posts: 255
Joined: 2004-1-08 @ 03:03

Re: Revisiting Extreme Assault 3Dfx

Postby DosFreak » 2018-10-09 @ 22:27

Official DOSBox supports Windows 95,NT4+ W/ Active Desktop since Mingw is used to build it although Mingw-w64 works as well (If using mingw-w64 then may need latests MSVCRT provided in KB for 2000).
if the Daum build does work on 9x it's likely because it uses SDL 1.2 and was built with an old ver of Visual Studio likely VS 2008 or below.

Unofficially that I haven't submitted patches for:
SDL - commit after SDL 1.2.13 was released broke DirectInput on 9x. Either rollback commit or add two changes that seems to fix the issue...or just use WINDIB with DOSBox.
95,NT4 without Active Desktop Disable profile config
NT 3.51 DIsable profile config, use WSOCK
NT 3.50 Disable profile config, Use WSOCK, and disable fullscreen support in SDL
User avatar
DosFreak
l33t++
 
Posts: 9969
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: Revisiting Extreme Assault 3Dfx

Postby Gamecollector » 2018-10-09 @ 23:03

kjliew wrote:Did you run DOSBox from Win9x?

WinXpSp3. Have fixed the message.

Ok, fixed Tie Break Tennis crash with my "MSDOS 7.1" setup (files=10 in config.sys, too little).
The 3dfx option is selectable, the game freezes before the simulation.
@kiliew: can you please make patched tennis.exe with disabled 2nd grGlideInit/grSstWinOpen?
Asus P4P800 SE/Pentium4 3.2E/2 Gb DDR400B,
Radeon HD3850 Agp (Sapphire), Catalyst 14.4 (XpProSp3).
Voodoo2 12 MB SLI, Win2k drivers 1.02.00 (XpProSp3).
User avatar
Gamecollector
Oldbie
 
Posts: 1311
Joined: 2010-10-06 @ 22:17

Re: Revisiting Extreme Assault 3Dfx

Postby kjliew » 2018-10-10 @ 02:27

Gamecollector wrote:@kiliew: can you please make patched tennis.exe with disabled 2nd grGlideInit/grSstWinOpen?

Sorry, don't count on me doing that. I am not interested to spend more time on this game. I think DOSBox would have been able to fix it. Gulikoza updated his glide patch to include the fix around 2013 (viewtopic.php?f=41&t=16462&p=297930&hilit=tie+break#p297930). If you are using Daum's build, I am not sure if you have access to the source code that actually produced the build. That way you can verify if the fix was there. nGlide could have fix it within itself, similar to dgVoodoo2, so it won't matter even if Daum's build did not include the fix.

My locally build DOSBox SVN can also run the game with OpenGlide and psVoodoo, but they require Gulikoza's fix, or the game would lose all the textures during simulation. So if you can run Daum DOSBox + openglide/psVoodoo, then it would tell if the glide patch in your DOSBox build has been updated.
kjliew
Member
 
Posts: 255
Joined: 2004-1-08 @ 03:03


Return to dgVoodoo General

Who is online

Users browsing this forum: No registered users and 2 guests