Minor fixes to the OP, small enhancements to icons.

[virtualjaguar] / src / op.cpp

diff --git a/src/op.cpp b/src/op.cpp
index 2978c6dc9541b4ea8e48ce5f9a1cf56b621bcbff..73fc330010dced9a3a83a71f345d33dbbc54369c 100644 (file)
--- a/src/op.cpp
+++ b/src/op.cpp
@@ -318,8 +318,6 @@ void DumpFixedObject(uint64 p0, uint64 p1)
 //
 // Object Processor main routine
 //
-//Need to fix this so that when an GPU object IRQ happens, we can pick up OP processing
-//where we left off. !!! FIX !!!
 #warning "Need to fix this so that when an GPU object IRQ happens, we can pick up OP processing where we left off. !!! FIX !!!"
 void OPProcessList(int scanline, bool render)
 {
@@ -342,7 +340,7 @@ bool inhibit;
 int bitmapCounter = 0;
 // *** END OP PROCESSOR TESTING ONLY ***
 
-       uint32 opCyclesToRun = 10000;                                   // This is a pulled-out-of-the-air value (will need to be fixed, obviously!)
+       uint32 opCyclesToRun = 30000;                                   // This is a pulled-out-of-the-air value (will need to be fixed, obviously!)
 
 //     if (op_pointer) WriteLog(" new op list at 0x%.8x scanline %i\n",op_pointer,scanline);
        while (op_pointer)
@@ -454,7 +452,8 @@ WriteLog("    --> List end\n\n");
                                ypos = TOMReadWord(0xF00046, OP) / 2;                   // Get the VDB value
 #endif
 // Actually, no. Any item less than VDB will get only the lines that hang over VDB displayed.
-// So we need to fix this somehow... (and it has... in tom.cpp :-P)
+// Actually, this is incorrect. It seems that VDB value is wrong somewhere and that's
+// what's causing things to fuck up. Still no idea why.
 
                        uint32 height = (p0 & 0xFFC000) >> 14;
                        uint32 oldOPP = op_pointer - 8;
@@ -783,6 +782,15 @@ void OPProcessFixedBitmap(uint64 p0, uint64 p1, bool render)
        if (!render || iwidth == 0)
                return;
 
+//OK, so we know the position in the line buffer is correct. It's the clipping in
+//24bpp mode that's wrong!
+#if 0
+//This is a total kludge, based upon the fact that 24BPP mode puts *4* bytes
+//into the line buffer for each pixel.
+if (depth == 5)        // i.e., 24bpp mode...
+       xpos >>= 1;     // Cut it in half...
+#endif
+
 //#define OP_DEBUG_BMP
 //#ifdef OP_DEBUG_BMP
 //     WriteLog("bitmap %ix%i %ibpp at %i,%i firstpix=%i data=0x%.8x pitch %i hflipped=%s dwidth=%i (linked to 0x%.8x) Transluency=%s\n",
@@ -798,8 +806,12 @@ void OPProcessFixedBitmap(uint64 p0, uint64 p1, bool render)
        // Not sure if this is Jaguar Two only location or what...
        // From the docs, it is... If we want to limit here we should think of something else.
 //     int32 limit = GET16(tom_ram_8, 0x0008);                 // LIMIT
+//     int32 limit = 720;
+//     int32 lbufWidth = (!in24BPPMode ? limit - 1 : (limit / 2) - 1); // Zero based limit...
+//printf("[OP:xpos=%i,spos=%i,epos=%i>", xpos, startPos, endPos);
+       // This is correct, the OP line buffer is a constant size... 
        int32 limit = 720;
-       int32 lbufWidth = (!in24BPPMode ? limit - 1 : (limit / 2) - 1); // Zero based limit...
+       int32 lbufWidth = 719;
 
        // If the image is completely to the left or right of the line buffer, then bail.
 //If in REFLECT mode, then these values are swapped! !!! FIX !!! [DONE]
@@ -876,6 +888,7 @@ if (depth > 5)
                clippedWidth = startPos - lbufWidth,
                dataClippedWidth = phraseClippedWidth = clippedWidth / phraseWidthToPixels[depth],
                startPos = lbufWidth + (clippedWidth % phraseWidthToPixels[depth]);
+//printf("<OP:spos=%i,epos=%i]", startPos, endPos);
 
        // If the image is sitting on the line buffer left or right edge, we need to compensate
        // by decreasing the image phrase width accordingly.
@@ -891,7 +904,11 @@ if (depth > 5)
 //     uint32 lbufAddress = 0x1800 + (!in24BPPMode ? leftMargin * 2 : leftMargin * 4);
 //Why does this work right when multiplying startPos by 2 (instead of 4) for 24 BPP mode?
 //Is this a bug in the OP?
-       uint32 lbufAddress = 0x1800 + (!in24BPPMode ? startPos * 2 : startPos * 2);
+//It's because in 24bpp mode, each pixel takes *4* bytes, instead of the usual 2.
+//Though it looks like we're doing it here no matter what...
+//     uint32 lbufAddress = 0x1800 + (!in24BPPMode ? startPos * 2 : startPos * 2);
+//Let's try this:
+       uint32 lbufAddress = 0x1800 + (startPos * 2);
        uint8 * currentLineBuffer = &tomRam8[lbufAddress];
 
        // Render.
@@ -1242,7 +1259,8 @@ if (start_logging)
        // From the docs, it is... If we want to limit here we should think of something else.
 //     int32 limit = GET16(tom_ram_8, 0x0008);                 // LIMIT
        int32 limit = 720;
-       int32 lbufWidth = (!in24BPPMode ? limit - 1 : (limit / 2) - 1); // Zero based limit...
+//     int32 lbufWidth = (!in24BPPMode ? limit - 1 : (limit / 2) - 1); // Zero based limit...
+       int32 lbufWidth = 719;  // Zero based limit...
 
        // If the image is completely to the left or right of the line buffer, then bail.
 //If in REFLECT mode, then these values are swapped! !!! FIX !!! [DONE]