HomeForumsWhat's newResources 
 
 
making a 3D racing game for SEGA Saturn
RockinB - Feb 23, 2005

 1  2  3  Next> 

 RockinB Feb 23, 2005
You might know that the DRIVING, DRIVING2, SHOOTING and BIPLANE examples from SGL all use a similar method for handling polygon display:

The 3D world consists of a 2D map of polygons and a corresponding map of collision data.

Now I made a tool which converts arbitrary (amounts of)PDATA and XPDATA structures like

Code:
  
POINT	point_BOX[]={

	POStoFIXED( -16.00, 16.00, -16.00),

	POStoFIXED( -16.00, 16.00, 16.00),

	POStoFIXED( 16.00, 16.00, 16.00),

	POStoFIXED( 16.00, 16.00, -16.00),

	POStoFIXED( -16.00, -16.00, 16.00),

	POStoFIXED( 16.00, -16.00, 16.00),

	POStoFIXED( -16.00, -16.00, -16.00),

	POStoFIXED( 16.00, -16.00, -16.00),

};

POLYGON polygon_BOX[]={

	NORMAL(  0,  50,  0), VERTICES( 0, 1, 2, 3),

	NORMAL(  0,  0,  50), VERTICES( 1, 4, 5, 2),

	NORMAL(  0, -50,  0), VERTICES( 4, 6, 7, 5),

	NORMAL(  0,  0, -50), VERTICES( 6, 0, 3, 7),

	NORMAL(  50,  0,  0), VERTICES( 3, 2, 5, 7),

	NORMAL( -50,  0,  0), VERTICES( 1, 0, 6, 4),

};

ATTR attribute_BOX[]={

	ATTRIBUTE(Single_Plane,SORT_CEN,No_Texture,C_RGB(31, 0, 8),No_Gouraud,MESHoff,sprPolygon,UseClip),

	ATTRIBUTE(Single_Plane,SORT_CEN,No_Texture,C_RGB(31,23, 0),No_Gouraud,MESHoff,sprPolygon,UseClip),

	ATTRIBUTE(Single_Plane,SORT_CEN,No_Texture,C_RGB(31, 0, 0),No_Gouraud,MESHoff,sprPolygon,UseClip),

	ATTRIBUTE(Single_Plane,SORT_CEN,No_Texture,C_RGB(31,23, 0),No_Gouraud,MESHoff,sprPolygon,UseClip),

	ATTRIBUTE(Single_Plane,SORT_CEN,No_Texture,C_RGB(10,10,31),No_Gouraud,MESHoff,sprPolygon,UseClip),

	ATTRIBUTE(Single_Plane,SORT_CEN,No_Texture,C_RGB(10,10,31),No_Gouraud,MESHoff,sprPolygon,UseClip),

};

PDATA PD_BOX = {

	point_BOX,sizeof(point_BOX)/sizeof(POINT),

	polygon_BOX,sizeof(polygon_BOX)/sizeof(POLYGON),

	attribute_BOX

};

to such a 2D map of polygon data.

Being the last tool in the chain, it overcomes size restrictions

that the 3DEditor of SS-SDK for Win95 got.

Conversion is influenced by some options,

such that it can break objects apart at tile boundaries and

merge them together to one inside a tile.

Removal of duplicate points and polygons is partially implemented and will be expanded soon.

Furthermore, I added the possibility to verify the converted data to the original.

Here is the original DRIVING .MDL data together

with 4 different verified and compilable(but DRIVING would need little modification for type MapData) conversions with my tool.

[attachmentid=1073]

Meaning of the filename suffix:

first number is option break_over_tiles,

second is merge_in_tile

The current map format is:

Code:
  
typedef enum {

  IS_EMPTY,

  IS_PDATA,

  IS_XPDATA,

} PdataType;

typedef struct POLYGON_DATA {

  PdataType type;

  XPDATA data;

} PolygonData;

typedef struct TILE_DATA {

  unsigned short nObj;

  PolygonData *obj;

} TileData;

typedef struct POLYGON_MAP {

  // mapSize in tiles

  struct {

    unsigned short x;

    unsigned short y;

  } mapSize;

  // tileSize in world coordinates

  struct {

    FIXED x;

    FIXED y;

  } tileSize, mapOrigin;

  TileData *tiles;

} MapData;

It is superior to that of the DRIVING example, since it allows multiple objects inside a tile, such that (real time gouraud) XPDATA can be mixed with normal PDATA.

The collision system of those examples instead is not fully clear to me. :huh

I've read some stuff about collision detection,

but it lacks explicit formulas like the book

"Real-Time rendering" got(which I don't have anymore).

It might help if someone else would have a look at the DRIVING source,

especially Collison_put(FIXED x,FIXED y,FIXED z) and tell me what you thing about the those lines:

Code:
  
// what kind of distance is this,

// since it's sx	=(a_collison[aa].cen_x+x)>>16;

// and not sx	=(a_collison[aa].cen_x-x)>>16;

li	=slSquart(sx*sx+sy*sy+sz*sz);

// is this the distance to a plane?

// perpendicular to the plane or to the ground?

col_hight =-(A*((-x-poa)>>16)+B*((-y-pob)>>16))/C-(poc>>16);

// why this fixed point format conversion?

col_x	=A*3;

Any information about ground following(keeping the car flat on the track) would be appreciated, too.

I intent to generate collision info with the tool in the future.

For example the track could be seperated from the rest by texture ids...

 vbt Feb 23, 2005
It's really interesting

 RockinB Feb 24, 2005
Status:

Work on map creation tool finished!

Does now remove all duplicate points and polygons.

Mapping of a polygon/object to a tile is now performed by mapping the middle or mean point(new).

After reading some more, I understood collision detection and ground following and found an appropriate approach.

Compared to DRIVING example, it might be faster(only 2 muls + 2 adds for height computation and per polygon edge check, as well), but may consume some more memory for collision data. Depends on how much precomputation I do.

I will now implement automatical collision data computation to the tool.

help needed:

Is there anyone who could convert tracks and cars of racing games to DXF file format with BMP/JPG textures?

There is the free Zanoza Modeller which imports cars from a lot of games. The racing game scene is full of tools and import filters for 3D modelling software.

If someone who got more experience in that could try to find a way(the right tools) to convert tracks and cars....

it would be cool.

 SeGaFrEaK_NL Feb 24, 2005
Cool, but personally I'd just as much like to see a 2D racing game ala Micro machines.

 RockinB Feb 26, 2005

  
	
	
Originally posted by SeGaFrEaK_NL@Thu, 2005-02-24 @ 10:33 PM

Cool, but personally I'd just as much like to see a 2D racing game ala Micro machines.

[post=130441]Quoted post[/post]



A top-view camera should be no problem .

Status:

- computation and printing of collision and ground following data implemented

- polygon search implemented

- map of pointers to tiles

(since most tiles are empty and a NULL pointer needs less memory

than an empty tile, it saves memory)

- adapted to saturn coordinate system

(HELP ME: the DRIVING map data is NOT in saturn coo.-system)

- added option to automatically generate a polygon map

for every possible flag setting

(fastly see what fits your needs)

- runtime collision check routine implemented

The polygon search serves for generating ground data.

Example from DRIVING:

All polygons with textures [attachmentid=1079] and [attachmentid=1080] are considered as road. Maybe grass and gravel could form 2 other ground categories.

This way, you know where your driving on at runtime.

Such a polygon category is made up of as much attribute constraints as you like, not restrikted to texture id.

For testing the collision/ground following, I implemented a little testbench and found an error in a formula I got from the net.

It's been fixed, but more complicated test data will have to be verified next.

Tool usage is now like this:

1. define PDATA, XPDATA, various flags of choice and ground category definitions in a single .C file

2. compile the .C file and link it to the tool's stuff

3. execute the binary

4. use the .MDL file in saturn game

I can't wait to modify the DRIVING example to use my generated maps.

Untill that, I have to figure out why the original DRIVING map data seems to not have the Z-axis as depth like the SGL tutorial says.

This is the space is occupies:

min(-3578.000000, -2534.000000, 0.000000),

max(-96.000000, 0.000000, -1.997361)!

Furthermore, I must investigate how to compute some more collision information, like the collision angle

or how to rotate the car just like the polygon it stands on.

 vbt Feb 26, 2005

  
	
	
Originally posted by Rockin'-B@Thu, 2005-02-24 @ 10:27 PM

If someone who got more experience in that could try to find a way(the right tools) to convert tracks and cars....

it would be cool.



I hope it can help you, when I worked to replace the track I used some tools to generate suitable DXF for DXF2SG3 and then edit the SG3 file with the SEGA 3D Editor.

My prefered tool was Deep exploration 3 because it was able to open many 3D files (.x,.3ds,.dxf,...). I used it to convert any file to DXF. After I used 3Dto3D to make a DXF for DXF2SG3. When the track was too big I used 3DS MAX 1.2 and its optimizer to reduce the vertices.



I remember I've checked for a lot of 3D tools but didn't find better Anyway the files can be read with the Sega tool.

 vreuzon Feb 28, 2005

  
	
	
Originally posted by SeGaFrEaK_NL@Thu, 2005-02-24 @ 11:33 PM

Cool, but personally I'd just as much like to see a 2D racing game ala Micro machines.

[post=130441]Quoted post[/post]



Good Idea. Do you know any free implementation of such a game (micromachine, superoffroad, etc.) ?

 SeGaFrEaK_NL Feb 28, 2005
I think it would be the easiest to have some sort of tiles system just like MM. You see the way it was contructed in MM96 (which has a track editor).

Good tiles could be easily made.

 RockinB Mar 1, 2005
Status:

- binary output added(in addition to C sourcecode)

- flags added to choose outputs of your choice

It's raw Saturn format with correct alignment and endianess. Very memory and CPU efficient, since it needs only a single pass for pointer conversion and no additional memory.

Binary size of the original DRIVING map is between 104-128 KByte. GZIP compression is good with < 32KByte.

Binary loading is also supported by the tool.

The correctness of the binary format has been veryfied by .MDL -> .BIN -> .MDL conversion, which results with exactly the same file.

Note: Few minutes ago, I recieved The King Of The Spirits(jp)/High Velocity! :banana


  
	
	
Originally posted by vreuzon+Mon, 2005-02-28 @ 12:35 PM-->
QUOTE(vreuzon @ Mon, 2005-02-28 @ 12:35 PM)
Good Idea. Do you know any free implementation of such a game (micromachine, superoffroad, etc.) ?

[post=130665]Quoted post[/post]

[/b]



Porting a free MM clone might be a better approach, since I don't enjoy MM like games that much like the Need For Speed style.

QUOTE(vbt @ Thu, 2005-03-10 @ 07:50 PM)
My track is horrible

Do you want some other tracks that works in the 3DEditor ? I had the Jerez track but there are too many polygons.

[post=131180]Quoted post[/post]

[/b]



Of course I do. Size is not the problem anymore, as you can split it up and feed it to 3DEditor piecewise. Later it can be put together with my tool.