DC now and forever!

[darkblu]

hope you don't mind the silly topic, but i felt like being a fanboi for a moment today : ) but aside from that, this thread has little to do with fanboism, it's rather an inquiry.

i spent last weekend with both my dc's and my home 17" vga crt. native progressive over a good vga is a something one can only feel sorry that it did not find its place in later consoles.. ah, nevermind.

now, of all my dc titles SC is the one which seem to have an issue with the vga output - the game plays insanely fast over the vga (faster than over 60Hz tv). has anybody here experienced anything similar with this or other DC titles?

 

[Panajev2001a]

I have never tried Dreamcast games with VGA monitors so I canot help.

I liked the Dreamcast a lot I have to say ( I did buy it when it fell to $149 ), but to be more of a fanboy as you are... well it would require IMG PVR team to unlock Modifier Volumes and DOT3 Blending in KallistiOS ( I am really a broken record on thsi issue ).

 

[Simon F]

I have never tried Dreamcast games with VGA monitors so I canot help.

I liked the Dreamcast a lot I have to say ( I did buy it when it fell to $149 ), but to be more of a <bleep> as you are... well it would require IMG PVR team to unlock Modifier Volumes and DOT3 Blending in KallistiOS ( I am really a broken record on thsi issue ).

That's a bit strong! Modifier volumes are easy to describe and I'm sure I must have done so at some time on the DC mail list. The bump mapping would require me to do some searching through docs that I don't have handy.

 

[darkblu]

I have never tried Dreamcast games with VGA monitors so I canot help.

I liked the Dreamcast a lot I have to say ( I did buy it when it fell to $149 ), but to be more of a <bleep> as you are... well it would require IMG PVR team to unlock Modifier Volumes and DOT3 Blending in KallistiOS ( I am really a broken record on thsi issue ).

haven't followed kallistios for a while. are MV and dot3 the only missing bits?

 

[Panajev2001a]

I have never tried Dreamcast games with VGA monitors so I canot help.

I liked the Dreamcast a lot I have to say ( I did buy it when it fell to $149 ), but to be more of a <bleep> as you are... well it would require IMG PVR team to unlock Modifier Volumes and DOT3 Blending in KallistiOS ( I am really a broken record on thsi issue ).

haven't followed kallistios for a while. are MV and dot3 the only missing bits?

YES.... sigh sob..... and they are two of the best features the Dreamcast had ( stencil shadows + normal mapping on Dreamcast... yummmy )... sigh sob....

Siiiiiiimooooooooooooooooooon!@!!!!!!

 

[Panajev2001a]

I have never tried Dreamcast games with VGA monitors so I canot help.

I liked the Dreamcast a lot I have to say ( I did buy it when it fell to $149 ), but to be more of a <bleep> as you are... well it would require IMG PVR team to unlock Modifier Volumes and DOT3 Blending in KallistiOS ( I am really a broken record on thsi issue ).

That's a bit strong! Modifier volumes are easy to describe and I'm sure I must have done so at some time on the DC mail list. The bump mapping would require me to do some searching through docs that I don't have handy.

Void complain ( bool &amp; VM, bool &amp; DOT3, char * IMG_PVR_eng ) {

cout &lt;&lt; "\nbuaaaaaaaaah, siiiigh, sooooooooob\n";

ask ( IMG_PVR_eng, VM, DOT3 );

if ( VM == 0 &amp;&amp; DOT3 == 0 ) return ( complain ( VM, DOT3, IMG_PVR_eng ) );

return;

}

I will have to test it... just wrote it in a sec

I looked at that mailing list but more than a full description there were some discussions about how to modify some fields here and there to get VM set-up, but it was a bit criptic and not a full solution.

Maybe I have not looked well, but I did search for volume modifiers and looked at the results of the search...

If you could expand on the VM issue it would be great

Thank you anyways though, I know you guys are busy.

With DOT3 and VM the Dreamcast scene could soar... I do not know why it wouldn't as the system reads CD-Rs quite easily and the hardware is not a complex beast to code ( CPU + VU + GPU ).

 

[Rodéric]

OpenGL API on the Dreamcast ?

I'm interested in writting a Renderer for the Dreamcast then, depending how hard it is... (I mean missing features/extensions).

 

[cthellis42]

Jeez, is it MV or VM already?

 

[Lazy8s]

GMV, General Modifier Volumes.

Nope, darkblu, I've never had any problems or issues with any DC game in VGA, including Soul Calibur. I've never heard of that particular problem happening before with DC either, though someone mentioned some accelerated speed issue with a PS2 soccer game a while back I believe. Not sure if they figured out what was going on.

 

[darkblu]

Nope, darkblu, I've never had any problems or issues with any DC game in VGA, including Soul Calibur. I've never heard of that particular problem happening before with DC either, though someone mentioned some accelerated speed issue with a PS2 soccer game a while back I believe. Not sure if they figured out what was going on.

i'm still trying to figure out what's happening myself. the game runs at street fighter speeds on my VGA. i got the VGA box only recently, and last weekend was my first extensive exposure to DC over a VGA. every title i threw at it ran as smooth as one would expect (on both my PAL and NTSC-U DC's), except for this speed issue with SC (NTSC-U). for the record i have to note that i spent my last 1-2 months of SC playtime on a 50Hz tv set, but that time is still insignificant compared to the total time i've spent in this game @ 60Hz, so i'm positive it's not a psycho effect.

OpenGL API on the Dreamcast ?

I'm interested in writting a Renderer for the Dreamcast then, depending how hard it is... (I mean missing features/extensions).

you can get the relevant docs from here
http://gamedev.allusion.net/docs/kos/kos-1.1.8/
(kos docs refer to the os API altogether and kgl docs to the openGL implementation)

and kos project's homepage is at http://gamedev.allusion.net/softprj/kos/

 

[Rodéric]

ermh... no Vertex Array neither VBO not even Display list.... only immediate mode... ugly.

 

[darkblu]

ermh... no Vertex Array neither VBO not even Display list.... only immediate mode... ugly.

from what i comprehend from the docs, there is support for strips in the DirectRender layer, but i don't have a clue if the ogl layer on top of it attempts to 'stripisize' (hope that word makes sense) the immediate-mode data ..come to think of it, unlikely.. especially having in mind the performance results reported at the end of the kgl doc. anyways, check out the KOS general API documentation, section 6.9 "Tile Accelerator"

 

[Simon F]

, check out the KOS general API documentation, section 6.9 "Tile Accelerator"

I guess you mean this link

Oooh! There are a few mistakes in that. I'm rather busy at the moment (just dropped in to take a quick break) but in summary:

The TA takes the primitives (preferably strips) sent to it and automatically creates the display lists for each tile by determining which tiles the primitives are in.

It was correct in stating that there are several sub-lists per tile, however, modifier volumes (for the opaque lists) are quite fast. (There is also a modifier list for translucent objects but that is much slower for reasons that will be obvious).
"Punch-through polygons" are simply those with an On/Off alpha texture.

So it is really a fancy 2D accelerator with perspective correction support for textures, and z-buffering."

Arggh. By that definition, any current 3D system is 2D!

Coordinates in the PVR start at 0,0 (all coordinates are floating point numbers) and go to 640,480, in the normal mode. Any coordinates outside this will work but will be clipped. Z coordinates start at 0 and move out of the screen towards the viewer. As far as I can tell, in normal mode, it wants Z and not 1/Z (W). I may be wrong of course. I'm no 3D hardware expert.

Heck no. It wants 1/w, in floating point. It can be any +ve value with smaller values (usually) being further away, but you can set the depth compare however you like.

Anyway, got to dash.

 

[[maven]]

Don't tell us, tell them...

 

[darkblu]

I guess you mean this link

yup

Oooh! There are a few mistakes in that. I'm rather busy at the moment (just dropped in to take a quick break) but in summary:

The TA takes the primitives (preferably strips) sent to it and automatically creates the display lists for each tile by determining which tiles the primitives are in.

It was correct in stating that there are several sub-lists per tile, however, modifier volumes (for the opaque lists) are quite fast. (There is also a modifier list for translucent objects but that is much slower for reasons that will be obvious).
"Punch-through polygons" are simply those with an On/Off alpha texture.

is what is said there true that 'punch-though' tris are stored in their separate list? does that mean they are handled more optimally compared to the general transparent tris?

So it is really a fancy 2D accelerator with perspective correction support for textures, and z-buffering."

Arggh. By that definition, any current 3D system is 2D!

apparently the author belives 'real' 3D is not to be projected on 2D displays as we do today

Coordinates in the PVR start at 0,0 (all coordinates are floating point numbers) and go to 640,480, in the normal mode. Any coordinates outside this will work but will be clipped. Z coordinates start at 0 and move out of the screen towards the viewer. As far as I can tell, in normal mode, it wants Z and not 1/Z (W). I may be wrong of course. I'm no 3D hardware expert.

Heck no. It wants 1/w, in floating point. It can be any +ve value with smaller values (usually) being further away, but you can set the depth compare however you like.

Anyway, got to dash.

your drop-ins are appreciated : )

 

[Simon F]

It was correct in stating that there are several sub-lists per tile, however, modifier volumes (for the opaque lists) are quite fast. (There is also a modifier list for translucent objects but that is much slower for reasons that will be obvious).
"Punch-through polygons" are simply those with an On/Off alpha texture.

is what is said there true that 'punch-though' tris are stored in their separate list? does that mean they are handled more optimally compared to the general transparent tris?

PT tris are (automatically) textured in order from front to back so it terminates early once you get full opacity. Normal transparency obviously has to be done from back to front.

 

[Fafalada]

is what is said there true that 'punch-though' tris are stored in their separate list? does that mean they are handled more optimally compared to the general transparent tris?

PunchThrough tris have two states - opaqe, and fully transparent, which in case of PVR means they can be rendered practically just as fast as normal opaque tris, and they won't incurr large fillrate penalties like semi-transparent stuff (rendering front to back).

Technically they also don't require any kind of sorting to be drawn correctly because you can accurately write Z for opaque pixels and skip it for transparent ones(although in practice that's not entirely true when you use higher then point sample texture filtering) - but that relates to use on all other hardware that doesn't auto-sort polys for ya .

 

[darkblu]

guys, i'm aware how punch-through are handled - i was just asking whether pvr2dc handled them as a separate case : ) apparently something prevented it from handling them as opaque* but instead of passing punch-thru as transparent, pvr handled them separately. thank you both ; )

* i guess pvr2dc did not have a per-tile z-buffer (like pvr3) but used some span-sorting or ray-casting technique, in which case it would have been somewhat complicated to spot the punches, am i right?

 

[Simon F]

guys, i'm aware how punch-through are handled - i was just asking whether pvr2dc handled them as a separate case : ) apparently something prevented it from handling them as opaque*

Well, of course PT tri's have to be handled separately because you don't know if a particular pixel is visible until you perform the texturing. With an opaque triangle every pixel is guaranteed to be opaque and you don't need to texture it to find out.

but instead of passing punch-thru as transparent, pvr handled them separately. thank you both ; )

Yes it was a significant optimisation.

* i guess pvr2dc did not have a per-tile z-buffer (like pvr3) ...

Both series do Z determination in the same way. The only difference between Series 2 and Series 3 in this respect is that Series 3 can write and/or read the Z data to external memory, but only when absolutely necessary (e.g. daft games that want to sample the Z buffer).

 

[darkblu]

guys, i'm aware how punch-through are handled - i was just asking whether pvr2dc handled them as a separate case : ) apparently something prevented it from handling them as opaque*

Well, of course PT tri's have to be handled separately because you don't know if a particular pixel is visible until you perform the texturing. With an opaque triangle every pixel is guaranteed to be opaque and you don't need to texture it to find out.

*slaps forehead*
doh, the famous 'final stage texturing' - how could i forget that! ..thinking in IMR terms again, sorry : )