[Cyberman]

Hello all..
anyone know of PSXemuPro plugin testing software of any sort?
IE polygon sprite memory to GPU GPU to memory
texture testing..etc.


Cyb

 

[Lewpy]

Err, what's wrong with using it in an emulator?
Seriously though, that's the only testing environment I have ever used.

 

[Cyberman]

That's what I'm using now.. the big impedance is the amount of time I have to wait to see if one function (in this case gaurad shaded textured 3 vertice polygon) works properly.

However I'm not sure what I'm doing wrong with it.

I think texture caching should be my next priority after getting that to work. The thing is rather slow with textures at the moment.

After that the addition affects like subtractive filtering (shadows) etc. Anyhow.. I was hoping someone had a standard test suite I could use to see if the basics worked right

Cyb

 

[Lewpy]

Believe me, I know where you are coming from
The amount of times I've had to load up games, and take them through to a certain point, just so I can check one small item in a DMA Chain :/
From that point-of-view, save-states are a God-send You can create a save-state just before the point you want to check, and you can get straight back to it time and time again Wonderful stuff.

As to your problems, what is your problem? I may be able to help, and if I can't I am sure Pete is lurking here watching

I always put the emphasis on getting things looking right, before trying to tackle speeding things up. The way I see it, you've got to get the algorithm right before you optimise it. If you try to optimise a half-finished algorithm, you are probably wasting time as you will need to re-write it to get the algorithm correct. Well, something like that, anyway My point is, until you know the full scope of what you need to do, be careful spending time optimising what you have, as you may have to alter it later: altering optimised code is much harder than un-optimised ... in general.

 

[Cyberman]

Hmmm good idea.. I need a game I can test that won't conflict with my actual game playing states

My current problem is gourad shading a texture.

I am modifying Dudies old soft GPU and I have the textures working mostly now the biggest problem I have is with shading the textures.

 

[Pete Bernert]

Mmm... g-shaded textured polys are not much harder to do than solid colored
textured ones...

You just have to calculate the final pixel out of the g-shaded color and the
texel color instead of the solid color and the texel... that's all!?!

 

[Cyberman]

Only if you don't have the vertices all backwards.. I'm getting transparent edges too, that isn't good. However I fixed the thing. Still too dark but it works.. VERY SLOW (sigh) and some of the textures are just wrong oh well time will fix that stuff. I noticed that if the textures go off the edge of the screen then there is a problem (IE the cliping area).

On thing at a time I guess.

Next is to fix the artifacts in the cliping area.

 

[NickK]

Good luck in software cyb! I can give you some tips if you need 'em

 

[Cyberman]

My current problem is semi transparency mode.

I know how to read the mode specified for the textures but I don't know how to know if they are on or off. IE if I have to do semitransparency applications to EVERYthing?

There doesn't seem to be an OFF transparency mode I just have the following listed in my docs:

ABR
0 0.5xB+0.5 x F Semi transparency mode
1 1.0xB+1.0 x F
2 1.0xB-1.0 x F
3 1.0xB+0.25 x F

Yet there is no NON transparency mode.. it's like it's always on.. this normal or am I missing something?

 

[NickK]

For some primitive headers, there will be flags to tell if the primitive uses semi trans mode or not. You should check that out. You'll also need to do a little bit of working inside of the primitive code too

 

[NickK]

This should help!

--------------------------------------------------------------------------
Command Packets, Data Register.
--------------------------------------------------------------------------
Primitive command packets use an 8 bit command value which is present in
all packets. They contain a 3 bit type block and a 5 bit option block of
which the meaning of the bits depend on the type. Layout is as follows:

Type:
000 GPU command
001 Polygon primitive
010 Line primitive
011 Sprite primitive
100 Transfer command
111 Environment command

Configuration of the option blocks for the primitives is as follows:

Polygon:
| 7   6   5 | 4 | 3 | 2 | 1 | 0 |
| 0   0   1 |IIP|3/4|Tme|Abe|Tge|

Line:
| 7   6   5 | 4 | 3 | 2 | 1 | 0 |
| 0   1   0 |IIP|Pll| 0 |Abe| 0 |

Sprite:
| 7   6   5 | 4   3 | 2 | 1 | 0 |
| 1   0   0 | Size  |Tme|Abe| 0 |


IIP      0 Flat Shading
         1 Gouroud Shading
3/4      0 3 vertex polygon
         1 4 vertex polygon
Tme      0 Texture mapping   off
         1                    on
Abe      0 Semi transparency off
         1                    on
Tge      0 Brightness calculation at time of texture mapping on
         1 off. (draw texture as is)
Size    00 Free size (Specified by W/H)
        01  1 x  1
        10  8 x  8
        11 16 x 16
Pll      0  Single line (2 vertices)
         1  Polyline    (n vertices)

 

[NickK]

You might also want the rest of the GPU docs

 

[NickK]

I'm actually going through now and documenting all of the possible combonations that can take place... Flat, abr: on ... Flat, abr: off, etc.. It takes a bit of time

 

[Cyberman]

Geeze I feel dumb

Oh well it's encoded into the instruction not the texture info.

this thing is going to be REALLY slow because of all the overhead.
I can see why Pete said it's pretty hard to emulate the PSX GPU with graphics cards made for the PC.

I'm still amazed at how fast Kazzuya's GPU is

Cyb

 

[NickK]

It's not really that hard. Infact, it can be done fast if you setup everything right. For example, I assume that you're using the dma chain procedure and the general primitive setup that was found in Pete's frame work and Duddie's soft GPU, right? Well, all of thoes numbers and function call tables only have to be modified slightly here and there to get the desired effect. This is OK for most primitives and commands, but you'll have to work something special into that processing to get the poly lines to work correctly!

Good luck, cyb!

 

[NickK]

Um, guess I didn't completely think about what I was meaning to say again

You CAN check out to see if the different states are set! The command (the last byte of the first dword) contains the same exact information that's in the header!

If you notice, 0x20 - A flat triangle, will have these bits set:

+---+-+-+-+-+-+
|001|0|0|0|0|0|   = 0x20
+---+-+-+-+-+-+

Bits 5 - 7 = 001 (Polygon)
Bit 4 = 0 (Flat shading)
Bit 3 = 0 (3 points)
Bit 2 = 0 (No texture)
Bit 1 = 0 (No semi trans mode)
Bit 0 = 0 (Use original color, of course!)

Well I had an idea to have a function call for different states, which would be faster, but much messier and take up some extra memory that could be used for other things. So I've decided to go with the bit operations instead. Shouldn't be too bad on most systems!

* Update! *
As a matter of fact, I've been using the command data all of this time. Haha. I make myself laugh soo hard sometimes because I forget these little things

Have fun with this!

 

[Cyberman]

Yeah.. I have transparency working somewhat but it looks weird in some cases (heh)

As for doing a function for each of the primitives in that table.
Yeah.. I'm adding them in that way but now I know why Kazzuya's and Pete's soft gpu's are so BIG hehehe lots of things to put in there.

Furtunately it's not so bad adding new things in I add the name in the table and when I add the actual code in I undefine the define and it works IE

#define primPolyGTS3 primPolyGT3
#ifndef primPolyGTS3
#endif

When I have the code done I just comment the #define there.
And poof it in there. (S for semi transparency).

It seems I need to add a lot of functions still

more fun

As for the polyline.. that shouldn't be TOO hard to implement (looks) unless you are doing the shaded one (grin).

 

[Cyberman]

I am having troubles with some of the transparency modes looks like. Namely some textures don't seem to be too transparent or have edge problems. In fact all my poly's have edge problems.

It seems a popular choice for lighting special affects is using a 4sided poly that's textured and gaurad shaded and has semitransparency.. This is killer to process unfortunately.

The image is horribly dark too.. not much you can do there at the moment so here there are from Tomb Raider 4 last revelation. First one is my GPU the second is from Kaz's

 

[Cyberman]

This is with Kazzuya's GPU
Almost identical position in the game

 

[NickK]

Make sure you're processing each pixel's color correctly. Here's some code for doing some (slow) semi transparency:

*colDest is a pointer to the destination RGB colors
*colSrc is a pointer of the screen's RGB color

void processSemiTrans(unsigned char sTransMode, unsigned char *colDest, unsigned char *colSrc)
{
   int r, g, b; //For saturation (up/down) SLOW (but not with MMX :)

   //Float -> Color value
   //1.0f -> 255
   //0.5f -> 128
   //0.25f -> 64

   //Where B is the source (screen) and F is current color that you
   //want to apply transparency to.

   r = colDest[COL_R];
   g = colDest[COL_G];
   b = colDest[COL_B];

   switch (sTransMode)
   {
      case 0: //0.5 x B + 0.5 x F
         r >>= 1;
         b >>= 1;
         g >>= 1;

         //Add unsigned with saturation
         r += colSrc[COL_R] >> 1;
         g += colSrc[COL_G] >> 1;
         b += colSrc[COL_B] >> 1;
      break;

      case 1: //1.0 x B + 1.0 x F
         r += colSrc[COL_R];
         g += colSrc[COL_G];
         b += colSrc[COL_B];
      break;

      case 2: //1.0 x B - 1.0 x F
         r -= colSrc[COL_R];
         g -= colSrc[COL_G];
         b -= colSrc[COL_B];
      break;

      case 3: //1.0 x B +0.25 x F
         r += colSrc[COL_R] >> 2;
         g += colSrc[COL_G] >> 2;
         b += colSrc[COL_B] >> 2;
      break;
   }

   //Simulated saturation
   if (r > 255)
      r = 255;
     else if (r < 0)
         r = 0;

   if (g > 255)
      g = 255;
      else if (g < 0)
          g = 0;

   if (b > 255)
      b = 255;
      else if (b < 0)
         b = 0;

   //Store result to be used when drawing to the screen
   colDest[COL_R] = (unsigned char)r;
   colDest[COL_G] = (unsigned char)g;
   colDest[COL_B] = (unsigned char)b;
}

So I hope this gives you a better idea of what you should do?
I could also code this in ASM using MMX (Faster!)