zeckensack wrote:

Kaminari,
That updated Tomb Raider screenshot of yours ... a Geforce card, right? Should be fixed now, or at least I hope so. That's the "lose hardware palette during close/reopen sequence" issue I think.

Sorry Zeck, I'm a bit in a hurry but I gave a quick test to GW 0.80c and boy does it run fast! NFS2 SE (demo) is unbelievably smooth on my P3@667 and GF2 Ti compared to OpenGlide and dgVoodoo. Only thing is, I can't seem to force the gamma I want, GW will automatically use a fixed (too bright) value with this game. Congrats otherwise for a job well done.

The weird messed-up textures in TR1 (Glidos) have been corrected, but the RGB 96-64-32 colour (used for transparency) still doesn't work, it appears as a plain brown colour. Another problem with this 0.80c release is that the keyboard and the joypad aren't working at all with TR1 + Glidos (other Windows games like NFS2 SE work ok). It used to work with previous releases and it definitely works with others wrappers 😕

I didn't test 0.80d yet but chances are these specific issues haven't been fixed.

Kaminari wrote:

Sorry Zeck, I'm a bit in a hurry but I gave a quick test to GW 0.80c and boy does it run fast! NFS2 SE (demo) is unbelievably smooth on my P3@667 and GF2 Ti compared to OpenGlide and dgVoodoo. Only thing is, I can't seem to force the gamma I want, GW will automatically use a fixed (too bright) value with this game. Congrats otherwise for a job well done.

Thanks. The included config overrides gamma for nfs2sea.exe to 1.7 and locks it. I'm sure you can set gamma, if you remove that override 😉

Kaminari wrote:

The weird messed-up textures in TR1 (Glidos) have been corrected, but the RGB 96-64-32 colour (used for transparency) still doesn't work, it appears as a plain brown colour. Another problem with this 0.80c release is that the keyboard and the joypad aren't working at all with TR1 + Glidos (other Windows games like NFS2 SE work ok). It used to work with previous releases and it definitely works with others wrappers 😕

I didn't test 0.80d yet but chances are these specific issues haven't been fixed.

It may be. I'm constantly wrestling with basic GDI functionality (window focus, keyboard focus, mouse focus, "active" vs "foreground" window, WS_VISIBLIE vs ShowWindow, etc, yadda, yadda). The seemingly irrelevant change that caused Dethkarz to run without sound might have affected Tomb Raider as well ... I've reverted that in 0.80d.

Anyways, I'll go and give Tomb Raider on Glidos another shot. Thanks for testing 😀

I hate to be the bearer of bad news but I just ran Manx TT SuperBike with 0.80d and there are random polygons flickering through the track, as if some polygons of the background are drawn in front of the foreground.

There's also no CD-audio in the main menu (in game works fine).

Ice

zeckensack wrote:

Reckless,
you seem to know a lot on the subject, and I'm glad you're sharing. For a moment I feared I just might have p**sed you off too much ...
This is an integral design decision, and I want it to be right, so maybe you can see why I get so defensive about it. Sorry.

I'm definitely not hacked off 😀

I'll have a think about what could be done but I don't see an all-in-one solution at the moment 😢

zeckensack wrote:

The included config overrides gamma for nfs2sea.exe to 1.7 and locks it. I'm sure you can set gamma, if you remove that override 😉

Hehe 🙄 Now NFS2 SE just looks perfect 😎

I pushed my luck and tried Croc's demo, which works well with dgVoodoo but freezes on startup screen with OpenGlide, and I unfortunately get the same result with GlideWrapper 0.80d. I may have to play around with the Render To option and see if it makes any difference.

Another bit of bad news is that GW 0.80d still has the 'no working input device' issue with Glidos (I only tested TR1, I'll have a go at Redguard later).

0.80e should have fixed the last remaining regression from 0.78b: Unreal engine games are working again 🙄
changelog

Note that I've changed hosting. In the unlikely event that any of you had bookmarked my old place ... 😈

w00t!

This is the first version that supports transparency in TR1 via Glidos 😀 It looks very decent, but there's a slight remaining problem. GlideWrapper seems to apply transparency to the colours close to the RGB 96-64-32 one, which means some transparent spots appear in some textures which colours are too close to that magical colour 😢 I'll take a screenshot tomorrow to explain it a bit better.

I've found an interesting thing about the input devices loosing focus under Glidos. Actually the pad and the keyboard work fine with GlideWrapper, unless I left-click on the TR1 title screen with the mouse -- in which case the pad and keyboard become inoperative until I do Alt+Tab and reselect Glidos.

Great job otherwise 😎

To Zeckensack: I noticed your report on Jane's blurry cockpits (http://www.zeckensack.de/glide/) - perhaps this is the same issue affecting Boss Rally (in your wrapper the textures appear to be twice as low-res compared to Dege's wrapper/real Voodoo).

Incidentally I can supply you with a cut-down demo-ish test version of Boxx Rally for about 15mb if you're interested (basically the game will work without the CD-ROM except for Championship mode so you can run time trial mode to test wrappers with!)

Ice

VirtuaIceMan wrote:

To Zeckensack: I noticed your report on Jane's blurry cockpits (http://www.zeckensack.de/glide/) - perhaps this is the same issue affecting Boss Rally (in your wrapper the textures appear to be twice as low-res compared to Dege's wrapper/real Voodoo).

No, that can't be it. The blurry cockpit issue is because
a)the game renders some stuff (text, apparently) as bunches of point primitives
b)the game reads the frame buffer, modifies it, and writes it back every frame

(Btw, B is the root cause for the huge performance problems people are having with the game.)

Now, this blurriness only appears in "high res" mode. High res causes the wrapper to render points at twice their normal size. This is done to make them appear to be the original, intended size. In combination with the doubled resolution on both axes, they would be too small otherwise. It also wouldn't be possible to render text as bunches of points, because the (small) points wouldn't touch each other and you'd get gaps.

This larger point size thing was in fact a fix I've made specifically for a "faint text" issue in the game 😜

The "new" issue is a result of the combination of A and B. A framebuffer readback in high res mode returns a downfiltered version of the "true" framebuffer (2x2 box filter), because I can't, in any useful way, hand a 1280x960 framebuffer to a game that expects to see a 640x480 framebuffer.

Unfortunately, the game doesn't render the points on exact pixel centers (eg (x;y)=(100.5;60.5)), but on pixel corners ((x;y)=(100.0;60.0)). The large points sit exactly in-between the pixel quads that end up being a single "emulated" pixel after the box filter. So during downfiltering, they get blown up to twice their intended size again (while getting dimmer).

This in itself wouldn't be much of a problem, but then the game adds some stuff to that buffer and just writes it back. The wrapper upsizes the buffer again at this point so it fits the screen, but the points are still "diluted".

The fix I've made "corrects" point coordinates so that they get rendered on exact pixel centers. This gets them through the box filter unharmed.

Conclusion: This has nothing to do with texturing. Sorry.

VirtuaIceMan wrote:

Incidentally I can supply you with a cut-down demo-ish test version of Boxx Rally for about 15mb if you're interested (basically the game will work without the CD-ROM except for Championship mode so you can run time trial mode to test wrappers with!)

Ice

Yup, many thanks for that 😊
Unfortunately I can't run it at all ... any special precautions to take?

BRally.exe is the Boss Rally game exe. You need Win98 compatibility mode on it.

BossRally.exe runs the opening video then calls BRally.exe

SetVideo.exe lets you change the graphics card. Direct3D doesn't detect my ATI Radeon 9800XT so I use the following in SetVideo.exe to use Glide:

- I know the chipset on my 3D video card...
- 3Dfx Voodoo (use Glide)]

Hope that helps! Compare the results to Dege's wrapper by putting his dgVoodooSetup.exe & glide2x.dll in the game folder - his does higher resolution textures. NOTE: he fixed the black in-car view in the latest beta of his wrapper (the 3 views can be selected by using the keypad with Home, End, Delete etc).

Good luck!

Ice

That was complicated ... I kept getting "Couldn't register EAR blabla" errors. I had to run the iasinst.exe first, but that would complain that I'd need at least *cough* DirectX5. Win95 compatibility on the iasinst fixed that. The game itself runs fine, but the sound system (which this whole iasinst was about) is ... beyond words. Anyway, thanks again.

Confirmed. The issue crops up with "incomplete" mipmaps, e.g. a 64x64 texture that has only three mipmap levels:
64x64 - 32x32 - 16x16
instead of the full seven levels it's "usually" supposed to have:
64x64 - 32x32 -16x16 - 8x8 - 4x4 - 2x2 - 1x1

Glde allows this kind of thing and the wrapper was designed to handle it from the start. I use the TEXTURE_MAX_LEVEL parameter.

For our three level mipmap, I set a TEXTURE_MAX_LEVEL of 2 (you start counting at zero, so that's three levels). This appears to bump down the mipmap selection by two levels, which is definitely not what I want it to do.
Curiosly, for "usual" textures this issue never crops up. I always set a TEXTURE_MAX_LEVEL. If I set it to 6 for a 64x64 texture, it get's displayed at full detail, like it's supposed to. I can't do that in Boss Rally, because the smaller mip levels just aren't there, and OpenGL considers this to be an error and displays the texture as all white.

I suspect a driver bug (currently on a Radeon 9500Pro), but must do some more investigation. I'll try an NVIDIA card and perhaps Mesa, and see what happen's there.

Interesting stuff. Yeah the EAR stuff is weird/annoying - there's a new icon in my Control Panel from this game so I presume bundling the game as I did isn't the most reliable way but at least you managed to test the graphics out!

Ice

I'm confused. It's not a driver bug. In an external "testbed" app, where I use the exact same texture parameters I suspected to be responsible for this, everything works fine. And ATI and NVIDIA cards behave exactly the same, too. So it must be something else, most probably my fault after all, I just don't know what (yet).

Workaround: set lod bias to +2 for BRally.exe. This shouldn't work, in fact it should make the textures shimmer like molasses. But it doesn't 😒

I'll now turn on the backend thread and clean up the inevitable glitches and crashes ... Boss Rally investigation is officially postponed, as we now have a workaround.

Edit: It's all different ...
OMFG. Here's an excerpt from some log file I found:

*grTexLodBiasValue(0,1073741824.000000)

This is what Boss Rally does. The number is insane, it practically forces the smallest available mipmap level, all the time (+8 would already suffice for that).
It's not "some" large number. It's 2^30. I suspect it's some kind of number snapping constant that hasn't be subtracted, like the vertices coming from the Quake 2 mini-GL driver.

And scrap the workaround. The real workaround is to just lock the lod bias at zero, where it belongs anyway.

Edit2:

upcoming changelog wrote:

*wrap around large lod bias values to keep them in the [-8;8 ) range (fixes texture blurriness in Boss Rally)

Zeckensack reports that "Need for Speed 2SE now runs. Perfectly. Yay. Expect a release Real Soon Now."

http://www.zeckensack.de/glide/

There's also a bit of a blog thing going there!

Ice

The reason for the delay is Speed Busters. First things first, it runs smoothly and is absolutely playable. But there are some strange issues with window focus in the game that I really want to get resolved. If you first click on the menu screen, the game will lose focus and minimize. If you then tasksiwtch back, it starts working and you can play. If you do that, it looks like somehow the game manages to cause the wrapper to open multiple render windows, and that just shouldn't be possible. This is not so much about Speed Busters alone. This is a huge bug. I really need to fix it.

It has always been a problem to change window handling related code, because that means that I have to retest every single game in the list. Something always breaks if I don't, and I'm looking at a week worth of testing if I do. And as soon as I find another issue during testing and have to make adjustments to window handling again, I can start over. This sucks.

If I can't get these issues ironed out, I'll probably do some sort of beta release, so that everyone knows they are getting a version with significant known issues.

Man, not both top Glide wrappers hitting problems at the same time!

Anyway it's great to hear you're looking at Speed Busters, however I have one request (to throw into the mix): there is a patch for Speed Busters called "spbaddon.exe" which is about 25MB in size. It adds all the new cars (which are also available as separate packs), improves the detailed textures on the road (etc) and adds in-car cockpits for the cars (a feature I really miss!). You can get the patch (plus others) at www.speedbusters.com

Of course the regular game works in Direct3D mode (as long as you don't touch the 25MB patch or only use the regular ~1.5MB patches)...

I guess it depends on what version of the game you have. If it's a "special" (i.e. non-commercial) version then it might have the big patch packaged into it.

Ice

Are there any news on this long anticipated release?

Are the tests finished?

-Bernd

Zeckensack has a blog for the wrapper here: http://www.zeckensack.de/glide/

Ice

New release! v0.82!

Changes: version 0.82 posted Dec-21-2004 vs version 0.80e posted Jul-21-2004 […]
Show full quote

Changes: version 0.82 posted Dec-21-2004 vs version 0.80e posted Jul-21-2004

* core bugfix: wrap around large lod bias values to keep them in the [-8 ; 8 ) range (fixes texture blurriness in Boss Rally)
* core bugfix: made timing compatible with non-constant processor clock speeds (Intel "SpeedStep", AMD "Cool'n'Quiet" and similar power saving techniques). This fixes the function of the "pedantic" vsync option and the scanline query on such systems.
* core bugfix: now force point x/y coords to pixel centers to avoid filtering/smearing of point primitives during simultaneous read/write locks in high res mode. This is intended to fix bluriness in Jane's F15 cockpit views.
* core: multithreading is here - also added the "thread policy" option to control it
* core: rolled my own mipmap generation. All texture formats. This makes this option actually usable, from a performance point of view, for owners of ATI cards, and glitch-free for the NVIDIA camp, regardless of driver version. NOTE that now using "generate mipmaps" disables hardware palette support (NVIDIA only), and that will cost some performance.
* core: disable the aniso workaround for Catalyst 4.9 (or newer). Catalyst 4.9 fixed the issue that required this workaround.
* core: ignore the "allow_sse" option. The core DLLs now use an automatic (exception-catching based) detection instead.
* core: quite unexplainable texture recycler tweaks
* profile management changes:
o a single profile can now apply to multiple executables, in the most common case to a game and some kind of supplemental setup tool (e.g. Wiz8.exe and 3DSetup.exe for Wizardry 8 ). This mainly helps to avoid clutter in the profile list.
o there can now be distinct profiles for multiple executables that have the same name. The distinction is made by looking for other files in the exe's folder that are specific to a game. E.g. both Diablo 2's and Independence War's main executables are called "Game.exe" and couldn't be distinguished by previous versions of the wrapper (consequently there was no way to make separate profiles for the two). But other files in the same folder can be used for recognition.
NOTE that there's currently no user friendly way to work with this functionality yourself, it's only available through manual ini editing. The premade configuration uses it to cover a few cases.
* configurator: can now rename profiles. Currently ASCII only, no support for unicode characters (e.g. Kanji)
* configurator: as per core change, removed the "allow SSE" option from the user interface.

http://www.zeckensack.de/glide/index.html
http://www.zeckensack.de/glide/archive/GlideWrapper082.exe

Start your testing!

I don't know if this is the place to post it, but he really ought to use CRC/MD5/whatever hashes of the EXE files to recognize them if he wants to distinguish to games with the same EXE filenames. That way it would be clean and easy to provide a wizard to help the user create profiles. The only problem would be if the user installs a patch for the game that alters the EXE file.