Outstanding dosbox performance on custom built dosbox with optimisations for Pyra.


So, I worked on my glshim to make TexCoord handled internally using all 4 coordinates (instead of 2).


The screenshot speak for themself :)


There is still some shadow issues on TR, but I suspect it to be something else (there are some hack for TR for the shadow, I have to check that first).

View attachment 12677

screamer2_3.png

View attachment 12679

screamerally3.png

trub2.png
 
Looking good :)


Even tomb raider is looking better, particularly that environment/background - it's still perhaps a bit more tessellated than it originally was, but it's a lot better than it was, meaning that game apparently had two problems, one of which is now sorted.  Now it just looks like some of the gouroud shading seems to be done upside down or back to front or something.  Wonky normals or a fritzed lightmap would be my guess.
 
Wow that look realy good.


I have here a Dosbox Win95 Image.


When you release a TestPND with Dosbox 3DFX then i would be glad to test some early 3dfx Windows Games like RedlineRacer :)
 
This does mean that dosbox is making use of the pyra gpu. Or this is only being tested on the pandora?


Anyhow, impressive work, this is very promising.
 
This does mean that dosbox is making use of the pyra gpu. Or this is only being tested on the pandora?


Anyhow, impressive work, this is very promising.

I believe Pandora only at the moment. Still need GPU drivers for the Pyra.
 
Depends which 'this' you're talking about.  I suspect Wally's testing on an OMAP devboard, but Ptitseb's 3dfx changes he's testing on his Pandora only.  I'm not sure though.
 

Linear Frame Buffer. On the 3Dfx, you can get access to the Frame Buffer (the actual 2D picture that will be shown), using gruLock function. You can then draw on it like if it was a 2D screen, then you gruUnlock (or you forget it in the case of Caramgeddon) to release the LFB. This is use for all GUI / 2D elements (like tachometer, position, mini-map for racing games).


On OpenGlide, those effect are quite expensive, even when not doing the read (that is emulated using a glReadPixel that kill all performances on mobile GPU), the LFB (that is 565 BGR format) is 1st converted to BGRA (using a colorkey to get transparencie), and then the changed zone is drawn on the screen. The LFB is 2048x2048 so even just the "write" process is quite cpu intensive.


I have to work on that, but I would first like to fix TR glitchy shadows.
 
I have a question now, If you managed to fix the problem with carma/glide on dosbox, Is there a reason why they do not make it on the official release?

The fix is well known (I'm not the author of it). And in fact, if you use "-vrush" as a parameter to launch the 3dfx verison of carma, it just works preperly (but I patched openglide anyway).
 
Thank you for all the information! Then it's pretty strange they don't implemented the fix officially yet. Maybe this fix make other things to fail.

I realized that we may not speak about the same glitch.


I assumed you where talking about the "black screen" glitch that can happens with carmageddon on 3dfx (and so my anwser) but may be you where talking about the black strippes that happens on mostly everything in caramaggedon sofware (as can be seen in Wally's video of it). In that case, the 3Dfx fix doesn't touch this one. I have not seen any fix for that one, but I suspect it's x87 issue, with some block copy using 80bits operations maybe. I'm not sure at all, but I may spend some time to try fix it one day.
 
I have not seen any fix for that one, but I suspect it's x87 issue, with some block copy using 80bits operations maybe. I'm not sure at all, but I may spend some time to try fix it one day

That is generally what I gathered from a lot of reading on the issue as well.
 
Last edited by a moderator:
Back
Top