What is the benefit in TR1 using this new dll? I didn't see any differences (well, other than slower rendering and various video problems).

This is the first version. Don't expect advantages. 😁

Actually, on my X800, I do see some advantage. I was getting objects at far distance peeking through others. That doesn't happen with this dll for me.

I think you are right about the slower rendering, but I'm surprised you can tell. Is it not managing TR's 30fps? And what are the video problems you are seeing? Screen shot would be interesting. What graphics card do you have?

Maybe the slowness isn't real but perceived because you'd already mentioned it. I'll take a closer look at that.

The problems I encountered were when going to the passport ingame. The screen wnet bonkers with great difficulty in rendering the black mask over the screen -- was all broken up and flashing. When I then selected an option (Load, exit, etc) the game crashed with a runtime C++ error. I'll have to recreate it to post a screenshot tonight.

My card is nVidia GeForce Ti 4600. I'm using the Omega drivers v 66.93.

Ta. Contents of psVoodoo.log would be interesting too.

Here's the psvoodoo.log file

And here's two screenshots of it in action.

Ignore the bown lettering -- that's a consequence of my incomplete texturing and not the new .dll. And I've brightened up grab 1 in photoshop, it was too dark otherwise.

In the one with the black mask, you don't see the flashing effect obviously. When going to the passport, the screen goes all flashy and weird. If you then escape back to the game, the flashing continues but it has retained a 'screenshot' of the previous view so if you then move the view by moving lara, the screen flashes between the saved 'screenshot' and the new view.

Going into the passport again and choosing Exit to title causes the C++ error. The game will eventually then crash and there's a tiny Glidos error box that appears saying "Read failure".

Hope that helps!

That's great thanks. Not sure what's going on, but that is very probably enough info to track it down.

I've tested the wrapper with Croc 1's demo and it works smoothly but with a number of graphical glitches, mainly chromakeying issues and polygons displaying on top of each others (certainly due to the lack of z-buffer emulation).

Does psVoodoo use any configuration file?

Thanks. Useful test. Chromakeying for 16bit texture formats isn't implemented yet, so that explains that part. Is there a warning about z-buffering in psVoodoo.log? w-buffering is handled but not z yet.

There's no config file yet.

Gambit37, if you have time sometime, could you try out the two versions attached. I haven't really got to the bottom of the crashes you were experiencing, but these ones may behave differently.

Glidos wrote:

Is there a warning about z-buffering in psVoodoo.log?

Yes indeed, Paul. "Warning: z buffering not yet implemented."

The demo is available at C|Net. Below is the full log if you need it.

Kaminari, ah right. Shouldn't be hard to sort out then... actually I might have a copy of Croc that another kind friend from vogons sent me. 😁

Gambit37, on second thoughts, trying those experimental versions may be a waste of time. I now think they are unlikely to be any better, and I've just discovered I can reproduce exactly the problem you describe on my GF3, so I can now track it down really easily.

I'm back, being very busy... 😁 🙁

I've just tested psVoodoo, good work Paul!!! 😉
Tried with Unreal/Unreal Tournament so far on a GF5700 and ATI X600.
No graphical glitches. About speed problem: yes, indeed not so smooth, but I dont think it's slow (especially with A X600)! I'm sure that some slight improvements will make it far better!! Just a quick look at the source: always use indexed triangles, less geometry data to copy to hw, and the hw itself prefers indexed prims to nonindexed beacuse of less vertex geometry processing.

shader version of gr{Alpha,Color}Combine seems to work ok, but I still haven't found the secret of fast update of textures.

Altough I haven't tested it with a game doing heavy use of paletted textures (like Red Baron 3d), but the trick of using hw regeneration isn't fast enough?
(I also didn't used D3DX functions from DX utility lib, but, I don't think MS optimized the texture loader functions for speed: they are for pre-loading textures at some kind of init phase, like loading all the textures for a new level in a game or something like that, but I may be wrong. 😀 ).

1Static Log log;

in log.cpp breaks compilation of Fog.cpp line 27.
(Compiles with logl.)
Seems to work ok with my 9800XT, albeit a little slow...

I didn't see any noticable visual differences from openglide, so here's my question: what exactly do you try to achieve?

Great! Thanks for the feedback.

Dege, I'll look into the indexed triangle thing. If the game is using indexed, its daft that I don't pass the geometry on in the same way. For paletted textures, the hardware regeneration method is a great improvement, and makes Red Baron smooth, but still Blood is very lumpy (far more lumpy than with dgVoodoo). Still a bit of a mystery.

Markus, thanks for pointing out the log thing. I wonder how I get away with it here!! Strange. As for what I'm trying to achieve, that's a difficult one. Some of my initial aims look like they aren't going to work out as I hoped. I was hoping to make it fast, particularly for palette tricks on cards with no paletted texture support, but I've certianly not managed that - so far at least.

The other main aim was to use shaders to provide more accurate emulation of the combine functions. That's sort of worked out. The way OpenGLide works, the values are correct at the vertices, but linear interpolation doesn't always give the right results on the rest of the triangle. Using shaders you can get it right over the whole triangle. If you look at detail texures in Unreal, I think you can see a difference. On the other hand, its only going to be the more rarely used combine functions that show the difference.

Not sure where its going now. It may end up just gathering dust on sourceforge. In any case, its been fun so far, so I shalln't regret the effort, either way. I've always wanted to write a wrapper from scratch.

A quick warning. psVoodoo doesn't work very well with Glidos at the moment. There's a nasty bug in Glidos to do with frame buffer reading. OpenGLide tolerates the bug, but psVoodoo doesn't at the moment. I completely forgot about this because I fixed my local copy of Glidos. I'm not expecting to release another version of Glidos for a while, so I'll make a more tolerant version of psVoodoo soon, but until then best not use it with Glidos.

Gambit37, this is what caused the crash you experienced

OK, no problem, I'll stick with the original Glide dll for now.

Also, a small point, the psvoodoo dll doesn't go into windowed mode when specified, it's always full screen.

Just released psVoodoo v0.2 http://psvoodoo.sourceforge.net/

Croc works ok now, except for one strange bit of text on the initial screen, and the problem with TR's ring menu is fixed.

psVoodoo 0.2 doesn't seem to work here. Need for Speed 2 SE demo complains that it requires a Glide2x library, and Croc demo displays a message about d3dx9_27.dll missing 😕