Saturnin WIP thread

I don't have much time to work on Saturnin right now, but I managed to get some more demos from the SGL working :

040111-demo_a.JPG
040111-demo_b.JPG


040111-design3.JPG
040111-sega_2d_1.JPG


040111-sega_3d_1.JPG
040111-sega_3d_2.JPG


040111-sega_3d_3.JPG
040111-s_10.JPG


http://saturnin.consollection.com/private/Saturnin/040111-s_4_5.JPG

http://saturnin.consollection.com/private/Saturnin/040111-s_5_2.JPG

http://saturnin.consollection.com/private/Saturnin/040111-s_6_3.JPG

http://saturnin.consollection.com/private/Saturnin/040111-s_7_6.JPG

http://saturnin.consollection.com/private/Saturnin/040111-s_8_10_1.JPG

http://saturnin.consollection.com/private/Saturnin/040111-s_8_10_2.JPG

http://saturnin.consollection.com/private/Saturnin/040111-s_8_12.JPG
 
Ok, I'm tired looking for this annoying interrupt problem, so I will focus now on getting more demos working ... Hopefully this might fix the problem :)


Here is another demo screenshot, from Vreuzon this time :

040115-stephano.JPG
 
I corrected some palette problem in the VDP2, resulting in a nicer sample program 8.10.2 ... compare with the pic above :)

It's still missing the vertical and horizontal scrollings, but I'm working on it ...

040122-8_10_2_2.JPG
040122-8_10_2_1.JPG
 
I'm slowly correcting bugs in my VDP2 core, that's not an awesome progress but hey, it's still progress ! ;)

040208-mech2.JPG
040208-memory.JPG


040208-rock.JPG
 
Thanks :)


The TEK-1 demo looks better now also :

040211-tek1.JPG



There's still a non aligned memory access problem, but the demo is working.

The main problem preventing fast progress right now is the communication between the 2 CPUs which is far from being perfect.

Improving this will be my main goal during the next weeks ! (It'll be when I'll be back from holidays : 2 weeks off including one for skiing ... I can't wait)

Ok, back to work now ;)
 
I improved a little bit the title screen of Guardian Force :


040227-GuardianForce.JPG



The green color is there because of a transparency problem, and the shadow under the text should be yellow instead of black ...
 
Damn, I'm a moron ... I can't even remember things I did some months ago :rolleyes:

The title screen appears now as it should be, except for the green part that might be related to the back screen ...


040227-GuardianForce2.JPG
 
Thanks racket :)


I did some memory hacking, and I was able to see the beginning of the attract mode :cool:


040227-GuardianForce3.JPG
040227-GuardianForce4.JPG


040227-GuardianForce5.JPG
040227-GuardianForce6.JPG


040227-GuardianForce7.JPG
 
:party

I finally found where was my interrupt problem !!! It was just a little piece of assembly code which was incorrect ...

So I have one more game playable : Baku Baku Animal :cool:

040321-bakubaku.JPG
040321-bakubaku2.JPG


040321-bakubaku3.JPG
040321-bakubaku4.JPG


040321-bakubaku5.JPG
040321-bakubaku6.JPG


And another game is going into the attract mode (start doesn't start the game) : Othello Shiyouyo

040321-othellos.JPG
040321-othellos1.JPG


040321-othellos2.JPG
040321-othellos3.JPG


040321-othellos4.JPG
040321-othellos5.JPG


040321-othellos6.JPG
 
Cool! Things seems to be advancing, and graphics looks good.

Hmm... there's something I'd like to discuss... it's not a request of any for, just some random ideas for future consideration.

Runik, do you think it might be possible, someday, to get around the perspective correction problem?

040321-bakubaku2.JPG


I know that you're splitting the quads into two triangles so the PC GPU can work with it, and that HW perspective correction is unavaliable when you're sending pre-transformed tris to the screen without Z values. Satourne and GiriGiri have the same problem.

Do you think it could be feasible to split the quads into four polygons instead of two? Like this:

Code:
+-----+  +-----+

|\  |  |\  /|

| \  | -\ | \ / |

| \ | -/ | X |

|  \ |  | / \ |

|  \|  |/  \|

+-----+  +-----+

(excuse the horrible ASCII art)

The vertex at the center would be assigned a [0.5, 0.5] UV coordinate, and positioned at the quad's center. That way the UVs would be more evenly distributed across the quad surface, and it would look less distorted. To support the rare cases of convex quads, you could calculate the center point by calculating the mid points for both of the quad's diagonals, and pick the one that is inside the quad.

Of course that requires a little bit extra CPU work, but the amount of quads on screen is nothing by the today's standard polygon counts, and I take that the emulator bottleneck is in another areas, so that should be possible.

I'm in no way asking you to implement such thing into Saturnin at such point, where you have loads of more important stuff to concentrate at, but it could be a good addon when it reaches advanced levels, don't you think?
 
Unfortunalely, you're mistaken on this one : to draw the quads, I'm using the OpenGL primitive GL_QUAD. I only specify 4 coordinates. I guess it's the OpenGL driver of the graphic card that splits the quad into 2 triangles.

And I suppose it's the same thing for Satourne and GiriGiri ...

Maybe it could be possible to split the original quad into 4 triangles, but I'm not good enough at OpenGL right now to be sure.

I will do some research in this direction, and discuss with Fabien also so see what he thinks about this ...

That girl in the screenshot is damn ugly for sure :lol:
 
Yea, GL_QUAD will split the quad into two triangles automatically, since videocards have long forgotten what a quad is ;)

I don't know how the plugin system works, but probably it should possible to leave up to the VDP1 plugin to decide how it'll handle the Saturn quads. That way people could make OGL/D3D plugins with options for perspective correct or not, and someone could always come up with a software plugin that mimics the Saturn quad engine to perfection.

The distortion is really visible in games where you get too close to big polygons, or simply in 2D games that just distort quads at will. Playing Daytona USA on Satourne feels like playing the PSX port of it, if it ever existed :D

Anyway, another plus to adding a vertex at the quad center would be making the gouraud shading evenly distributed across it's surface. Right now in the HW-based emulators, the gouraud shading gets biased towads the endpoints of the quad's diagonal, since it's actually two triangles.

Anyway, I wish you and Fabien good luck with your emulators. Maybe when the Saturn gets a good, fully functional and highly compatible emulator, it'll get the popularity it deserved (that can be both a good and a bad thing).
 
Just got a mail from Fabien about this problem, here is what he wrote (it's a rough translation
smile.gif
)

M3d10n said:
The vertex at the center would be assigned a [0.5, 0.5] UV coordinate, and positioned at the quad's center. That way the UVs would be more evenly distributed across the quad surface, and it would look less distorted. To support the rare cases of convex quads, you could calculate the center point by calculating the mid points for both of the quad's diagonals, and pick the one that is inside the quad.

Fabien said:
Doing so will result in the same rendering : OpenGL is already doing a linear interpolation for U and V.

The perspective problem comes from a lack of precision in the geometric transformation calculations.

To have a better result you should recalculate all the 3D objects, which should be feasible if we could access to the 3D data (by doing some HLE ie emulating the SGL accessing to the 3D data)

The same problem exists on the PS1, try to play Gran Turismo to see what I mean ...

EDIT:

Some more infos:

Fabien said:
Here is the exact source of the problem : on the Saturn the lack of calculation precision results in a quad (which should be on the same plane in space) being changed into something that isn't a quad but 2 bound triangles, i.e.

the 4 vertexes forming the quad aren't in the same plane anymore.

I hope the translation is understandable
smile.gif
 
Back
Top