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


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?
 
3xcl4m4t10n said:
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?
Click to expand...

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.
 
3xcl4m4t10n said:
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.
Click to expand...

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.
 
ptitSeb said:
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
Click to expand...

That is generally what I gathered from a lot of reading on the issue as well.
 
Last edited by a moderator:
ptitSeb said:
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.
Click to expand...





Yeah, sorry if I wasn't very specific but I was talking about the black stripes glitch, because the screenshot you shown haven't this glitch. But you was running the 3DFX version, that's my fault :p.
 
Last edited by a moderator:
I have messed around with dosbox sourcecode to try fix the graphical issue with carmageddon (non-3Dfx version). I found a workaround.
Basically, the issue is that the game use the FPU to do it's blit. And it use FLD I64 and FST I64 for that (loading from an int 64 and storing to an int 64). On pure x87, with the internal 80bits precision, this doesn't seems to be en issue. But on ARM (and probably any other FPU in fact), the rounding that occure I64 -> DOUBLE -> I64 make it loose some bits (for thoses who remember, Xash3D has the same issue with the Weapon selection bug, and it was in some HalfLife code where something similar was done). So, I applied an hugly patch (really hugly), and I have clean video now.
Carma1.png
Carma2.png

If you insist (that patch is really hugly, you've been warned), here is the diff, that should apply to latest DosBOX.
Code: 
Index: src/fpu/fpu_instructions.h
===================================================================
--- src/fpu/fpu_instructions.h  (revision 3955)
+++ src/fpu/fpu_instructions.h  (working copy)
@@ -16,8 +16,9 @@
  *  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
  */

+static FPU_Reg         hackfpu_fregs[9];
+static FPU_Reg         hackfpu_iregs[9];

-
static void FPU_FINIT(void) {
        FPU_SetCW(0x37F);
        fpu.sw = 0;
@@ -96,8 +97,8 @@
        } test;
        test.eind.l.lower = mem_readd(addr);
        test.eind.l.upper = mem_readd(addr+4);
-       test.begin = mem_readw(addr+8);
-
+       test.begin  = mem_readw(addr+8);
+
        Bit64s exp64 = (((test.begin&0x7fff) - BIAS80));
        Bit64s blah = ((exp64 >0)?exp64:-exp64)&0x3ff;
        Bit64s exp64final = ((exp64 >0)?blah:-blah) +BIAS64;
@@ -170,9 +171,9 @@

static void FPU_FLD_I64(PhysPt addr,Bitu store_to) {
        FPU_Reg blah;
-       blah.l.lower = mem_readd(addr);
-       blah.l.upper = mem_readd(addr+4);
-       fpu.regs[store_to].d = static_cast<Real64>(blah.ll);
+       blah.l.lower = hackfpu_iregs[store_to].l.lower = mem_readd(addr);
+       blah.l.upper = hackfpu_iregs[store_to].l.upper = mem_readd(addr+4);
+       fpu.regs[store_to].d = hackfpu_fregs[store_to].d = static_cast<Real64>(blah.ll);
}

static void FPU_FBLD(PhysPt addr,Bitu store_to) {
@@ -240,9 +241,17 @@

static void FPU_FST_I64(PhysPt addr) {
        FPU_Reg blah;
-       blah.ll = static_cast<Bit64s>(FROUND(fpu.regs[TOP].d));
-       mem_writed(addr,blah.l.lower);
-       mem_writed(addr+4,blah.l.upper);
+       if (hackfpu_fregs[TOP].ll == fpu.regs[TOP].ll)
+       {
+               mem_writed(addr,hackfpu_iregs[TOP].l.lower);
+               mem_writed(addr+4,hackfpu_iregs[TOP].l.upper);
+       }
+       else
+       {
+               blah.ll = static_cast<Bit64s>(FROUND(fpu.regs[TOP].d));
+               mem_writed(addr,blah.l.lower);
+               mem_writed(addr+4,blah.l.upper);
+       }
}

static void FPU_FBST(PhysPt addr) {
@@ -357,6 +366,13 @@
        fpu.regs[other] = fpu.regs[st];
        fpu.tags[st] = tag;
        fpu.regs[st] = reg;
+
+       reg = hackfpu_iregs[other];
+       hackfpu_iregs[other] = hackfpu_iregs[st];
+       hackfpu_iregs[st] = reg;
+       reg = hackfpu_fregs[other];
+       hackfpu_fregs[other] = hackfpu_fregs[st];
+       hackfpu_fregs[st] = reg;
}

static void FPU_FST(Bitu st, Bitu other){
 
Last edited:
Awesome ptitseb!, too bad it's an ugly hack, but hey it's something.
 
A proprer hack would require more profound changes in some basic structure (like the FPU_rec) or add too much overhead (it's hugly also mainly because I try to minimize the overhead and try to get 0 side effect).
 
Wally said:
Anyone got anything they'd like me to test?
Click to expand...
First and foremost thanks for working on this. On to some recommendations for you, or anyone else who'd like to try:
  • Air Power: Battle in the Skies (Q: Does the SVGA mode work? Couple of years ago DOSBox still had problems with it.)
  • MechWarrior 2: 31st Century Combat (plus Ghost Bear's Legacy, if possible)
  • Mission Critical (the adventure game with Worf)
  • Strike Commander CD (or, as alternative, Wings of Glory)
  • Stunt Island
  • Wing Commander: Privateer CD
  • Wing Commander IV: The Price of Freedom
Wally said:
I did have a TIE Fighter video too but yeah it was pretty crappy.
Click to expand...
What went wrong? I'd love if you'd try this one again once you have a proper set-up; I'm interested if the screen size and controls, especially the analog nubs, work for this game. Provided it runs, or could run, smoothly in the first place.


BONUS: I know this is strictly about DOS games, but if someone has the Linux or Windows version of Terminus, and ExaGear (plus Wine), I'd love to know how well that game performs on the Pyra.
 
Last edited:
You must log in or register to reply here.

Similar threads

SAS
still waiting for the Pyra ....
Replies
7
Views
3K
superatarian
superatarian
bsp
  • Sticky
[announce] c64_tools (DSP loader and IPC)
31 32 33
Replies
648
Views
137K
Magic Sam
Magic Sam
Stuckie
Advanced Filesystem Hackery
2
Replies
33
Views
10K
Stuckie
Stuckie
mcobit
Just For Fun
Replies
12
Views
3K
Sphinxter
Sphinxter
Trip
Pimping The Manuals :)
Replies
9
Views
5K
Trip
Trip
Back
Top