HomeForumsWhat's newResources 
 
 
Saturn Texture Coordinate Test
RockinB - Jul 1, 2005

 1  2  3  Next> 

 RockinB Jul 1, 2005
I just wanted to play SEGA GT on Dreamcast to get some fast new cars......but then this idea hit me once again!

Here's the download (binary executable + ISO):

NEW: TC_Saturn_demo3.zip...

OLD:

[attachmentid=1365]

[attachmentid=1356]

Posting screenshots is welcome!

From the README.TXT that I could force me to write:


  
	
	
Texture Coordinate Test

for SEGA Saturn by The Rockin'-B, www.rockin-b.de...

This demo was entirely made on one evening to demonstrate that my

Saturn Game Tutorial & Demo

http://www.rockin-b.de/saturn/SaturnGameTu...ameTu...

is indeed doing a good job.

The Saturn hardware can't do texture mapping with texture coordinates. I'm just trying to do it nevertheless...

About & Controls:

You see the source and target texture (each 128x128 pixel, 16 bit) and furthermore a blue rectangle on the source texture and the coordinates of it's 4 corner points.

The target texture is just what is inside the rectangle.

The control pad buttons

X Y

A B

are assigned to the 4 points of the blue rectangle, just like you see it on the screen.

To change a point's position, select the points to move by holding down the assigned button (X Y A B) and then move them with the D-PAD.

Now how holding down one of the buttons L or R will compute the new target texture from the content inside the blue rectangle.

L - let master CPU do computation

R - let slave CPU do computation

You will notice a slight slowdown when activating target texture computation while moving points.

You can do funny things with it!

Rockin'-B

http://www.rockin-b.de...


 vbt Jul 1, 2005

  
	
	
Originally posted by Rockin'-B@Sat, 2005-07-02 @ 08:41 AM

I just wanted to play SEGA GT on Dreamcast to get some fast new cars......but then this idea hit me once again!

Here's the download (binary executable + ISO):

[attachmentid=1356]

Posting screenshots is welcome!

From the README.TXT that I could force me to write:

[post=136159]Quoted post[/post]



Nice work Rockin' :cheers can I put your samples and help on the Saturn dev section ?

 RockinB Jul 2, 2005

  
	
	
Originally posted by vbt@Sat, 2005-07-02 @ 11:22 AM

Nice work Rockin' :cheers can I put your samples and help on the Saturn dev section ?

[post=136162]Quoted post[/post]



That would be nice, vbt.

 RockinB Jul 2, 2005
Anyone got some 3D knowledge to tell us what could all be done with (in-game changeable) texture coordinates?

I'm thinking of better shadows or reflections of clouds, for example.

I don't know enough about environment mapping, but that could be an option, too.

How are these cool shiny car reflections done that are implemented in a lot of Playstation racing games?

word up!

 vreuzon Jul 3, 2005
(edit: bad thread, talking about rockin'b tutorial)

You really did a very good and usefull work with this demo, conversion tools and tutorial.

About the pcm part, you have this byte in the PCM struct

Uint8 channel ; // PCM Channel Number

I guess it is set by the sgl when you call slPCMon. If it is called two times at the same time with the same PCM*, the channel playing the sound will not be the same, so there is no way to assume that the channel info will be right. So maybe the PCM struct should not be related directly to one sample. This could explain the strange behaviour of slPCMStat, couldn't it.

 RockinB Jul 3, 2005

  
	
	
Originally posted by vreuzon+Mon, 2005-07-04 @ 09:57 AM-->
QUOTE(vreuzon @ Mon, 2005-07-04 @ 09:57 AM)
(edit: bad thread, talking about rockin'b tutorial)

You really did a very good and usefull work with this demo, conversion tools and tutorial.

[/b]



Thanks, vreuzon!

The tutorial will be improved, I think. There was some request. Always good to get feedback from n00bs.

I hope to add depth cueing, linescroll and other stuff once it can be done.


  
	
	
Originally posted by vreuzon@Mon, 2005-07-04 @ 09:57 AM

About the pcm part, you have this byte in the PCM struct

Uint8 channel ; // PCM Channel Number

I guess it is set by the sgl when you call slPCMon. If it is called two times at the same time with the same PCM*, the channel playing the sound will not be the same, so there is no way to assume that the channel info will be right.

[post=136258]Quoted post[/post]



Yes, playing a PCM sound twice will play the second one on another channel and overwrite the channel variable.

The channel is just an input for slPCMStat(), the SGL gets the playing info from elsewhere.