⠀

[SOAP]

I ask again. Where are the full cities put together coming from?

Check for LEVELMODEL.obj in program working directory

[SOAP]

Compiled tool, now should work proper
http://www.mediafire.com/download/gcig7 ... l_tool.rar

- fixed obj/mtl for world
- added mtl for models
- corrected some bugs
- correction for texture coordinates by 1/2 texel

+world [1/0] - turn on/off world extraction (see <file.lev path>/<LEVELNAME>_LEVELMODEL.obj)
+models [1/0] - turn on/off model extraction (only extracts global non-swap models)
+carmodels [1/0] - turn on/off vehicle model extraction (extracts clean and lod models)
+format [1/2] - LEV file format, set to 1 to extract Driver 1 levels (be sure to disable '+world')

all generated files now located in <file.lev path>/*

---------------------

How to load ALL global textures? I've got missing some vehicle textures

[Fireboyd78]

Thank you! I'm going to test this out now

UPDATE:
Tested! Is there still an unknown texture format? I'm missing quite a few textures, for example the GSX in Chicago. It's a unique texture, 256 X 256 with no palette. The OBJ files are aware of these textures, however. Are they not being exported?

Also, is it possible for you to make it so the offsets are relative to the absolute position in the file? It's really difficult trying to figure out where data is, and they're not updated frequently.

UPDATE 2:

Meanwhile, at Caine's Compound...

[VAIMAHDO]

I ask again. Where are the full cities put together coming from?

Check for LEVELMODEL.obj in program working directory

Thanks. I always miss the simple things
And dam, I see why the PS1 struggles with this game.
EVEN MY LAPTOP struggles with a horrid 1fps when rendering a small area.
LOTS of Z fighting and overlapping polygons..

[PostalDude]

I ask again. Where are the full cities put together coming from?

Check for LEVELMODEL.obj in program working directory

Thanks. I always miss the simple things
And dam, I see why the PS1 struggles with this game.
EVEN MY LAPTOP struggles with a horrid 3fps when rendering a small area.

[VAIMAHDO]

Nice toaster?
I loaded Rio at night

Post edited by Skylabh.
Reason: picture no longer available.

Dam, just gotta admire the beauty of this game

[SOAP]

LOTS of Z fighting and overlapping polygons..

Yes, this was assumed before I've written tool. More Z fighting with the curved roads

Thank you! I'm going to test this out now

UPDATE:
Tested! Is there still an unknown texture format? I'm missing quite a few textures, for example the GSX in Chicago. It's a unique texture, 256 X 256 with no palette. The OBJ files are aware of these textures, however. Are they not being exported?

All texture formats are known for me, I don't know how to load them properly
Textures for vehicles like bus, firetruck and even GSX are non-preloading textures, but they are located at same offset (LEV block 1)
I've tried to understand Krishty's code of texture loading, and only got code working with textures of type 1

Krishty, help me if you reading this!

my way of texture loading:
https://github.com/SoapyMan/driver_psx_ ... xtures.cpp in function LoadGlobalTextures, and you can see junk code

[Krishty]

I've seen your code yesterday and I wondered why the "goto read_again" was commented out. Had a look at my code and now I know what's wrong. This is pseudo code on how I do it:

Code: Select all

currentFlag = PAGE_FLAG_PRELOAD;
atlasIterator = atlases.begin();
repeat {

  // Skip all atlases of different mode. Driver 2 also ignores empty atlases.
  if(atlasIterator->flags != currentFlag || atlasIterator->regions.empty()) {
    ++atlasIterator;
    if(atlasIterator== atlases.end) { // If the end is reached, switch to the next mode, if possible.
      atlasIterator = atlases.begin();
      if(PAGE_FLAG_PRELOAD == currentFlag) {
        currentFlag = PAGE_FLAG_GLOBAL2;
      }
    }
  }
  // God I just noticed that spaghetti code could be much simpler

  load_texture();

  ++atlasIterator ;
  if(atlasIterator == atlases.end()) {
    if(PAGE_FLAG_PRELOAD == currentFlag) {
      atlasIterator = atlases.begin();
      currentFlag = PAGE_FLAG_GLOBAL2;
    }
  }

  // Align to next higher texture block. Simple alignment computation won't do here: One texture in "MLEVELS/RIO.LEV" ends just on a boundary, and it is zero-padded.
  repeat {
    read_one_byte();
  } until zero padding is skipped;

} until end of lump;

I.e. read all textures with flag PAGE_FLAG_PRELOAD, then read all textures with flag PAGE_FLAG_GLOBAL2 (which means the same thing, I guess). Stop if the entire lump has been parsed. Always continue in the atlas where you left off. Skip zero padding but don't do it by the usual +2047 / 2048 * 2048 'cause that would fail on Rio. In my own source code it's the LEV::read_globalTextures() method if you want to have a look.

[VAIMAHDO]

Yes, this was assumed before I've written tool. More Z fighting with the curved roads

A bit of developer knowledge lack or just lack of advanced tools. The roads could have been simply made as one mesh to avoid any overlapping, then split up each triangle to count as individual meshes. I don't see how that couldn't have been done
But of course it would have changed Driver 2 forever

[Krishty]

One mesh would have consumed too much memory, I guess. PlayStation does not know Z fighting because of painter's algorithm so it's not an issue anyway. One could instead call it a clever optimization

[VAIMAHDO]

It is, but as I've said, split every triangle of the mesh up to have the same optimization effect. I see how the optimization works. Rather then load a really dense file, splitting up into blocks makes it easier to draw up a more precise area, but it does eventually add up to consume more processing power and video memory. Thus creating the effect of Driver 2 running poorly on the PlayStation.
Because instead of one long street that is straight being drawn normally as 2 polygons (But appears as one to our eyes), the road would be split up into perfect cubed plates, making the amounts of polygons needed to be drawn 100, rather then just 2 faces and texture mapping or repeating.
I don't understand how this is less spacious, since it's the same thing but drawn more dense and separated... (To a certain extent)

[PostalDude]

Going to sound like an asshole here, but it lags because, quite frankly - your computer is a toaster.

[VAIMAHDO]

Don't try to bag on everyone else's crap.
It's indeed not a toaster.
And it's amazing it can ever run exactly 550567 polygons all at once at all in a really poorly optimized OpenGL window.
And it's all I have.
Also, there is no need to restate the absolute obvious yet again about my laptop being weak. Just about everyone here already knows.
Also, a toaster doesn't process anything. Your argument is far invalid.


Back on topic:
The PS1 can draw 180,000 polygons with textures, shades, and lighting per second.
So to run a game at around 30FPS, it would have to have at or under 6000 polygons with textures, lighting, and shading. That's where the limits show.
While my laptop can run Windows 7, have 5 internet tabs open, and can run around 550567 polygons per 1.01 second(s)
I also can see why the PS1 struggled on D2, too many polygons being drawn and loaded into the RAM even off screen. About 2 Chicago school busses is how far behind the player's view the polygons drawn are stopped. That's a bit much. The PS1's main struggle was it's small amount of RAM. Computers had much more RAM then a PS1. Just trying to pin point why the PS1 struggles with the game.

Update

I've reincarnated a Rio area running in the game. (Deleted all of the city but what was to be drawn in the screenshot and things behind the camera the PS1 would draw)
and the results are not too surprising.
On average, the game pushes the PS1 to draw around 6564 polygons! That's on average 564 polygons too many! This makes a HUGE difference when dealing with a simpler console.
Example scene:

Post edited by Skylabh.
Reason: picture no longer available.

Damit looking at PS1 games like this makes me want to make one myself!
Does anyone else like to drive full speed on those slanted corners in the dam?

[Krishty]

Because instead of one long street that is straight being drawn normally as 2 polygons (But appears as one to our eyes), the road would be split up into perfect cubed plates, making the amounts of polygons needed to be drawn 100, rather then just 2 faces and texture mapping or repeating.

You can't use one big polygon: texture coordinates need perspective correction upon interpolation, but the Driver 2 has very low precision on that. The hardware does only support affine interpolation, so any bit of precision slows down the rendering process. See an example of affine interpolation here: http://en.wikipedia.org/wiki/Texture_ma ... orrectness

Very small tiling does not save memory indeed, but it does reduce overdraw considerably. Considering there is no depth buffering and all culling and back-to-front sorting needs to be done upfront by the CPU, tile-based culling is the best compromise of accuracy and speed.

[Clutch]

You know, maybe it is known as a defect, but I really like affine interpolation. It puts me in something like nostalgia... I suppose I'm the only person here, who run Driver 1 without antialiasing, 25fps and resolution 540x360. You can call me sick.

[Klancnik777]

Just trying to pin point why the PS1 struggles with the game.

IF and IF that would be the case, Driver: You are the Wheelman would lag too since it uses the exact same technique as D2.

[VAIMAHDO]

You can't use one big polygon: texture coordinates need perspective correction upon interpolation, but the Driver 2 has very low precision on that. The hardware does only support affine interpolation, so any bit of precision slows down the rendering process. See an example of affine interpolation here: http://en.wikipedia.org/wiki/Texture_ma ... orrectness

Very small tiling does not save memory indeed, but it does reduce overdraw considerably. Considering there is no depth buffering and all culling and back-to-front sorting needs to be done upfront by the CPU, tile-based culling is the best compromise of accuracy and speed.

Hm, that does make sense, if I was a developer on the PS1, I would have to see what worked out for my games myself. Small tiliing is heavy on everything, but does help with overdraw, but does have a lot more code being pushed into the PS1's processor and RAM and video chip. This is sort of a win/loose situation. Overall, tile-based culling is pretty much the only thing we could have done in that era. That console IS in fact technology of 1994. It's impressive that it runs Driver 2 how it does. When I was younger I still noticed the slowdown, but didn't mind. I've never minded lol

I suppose I'm the only person here, who run Driver 1 without antialiasing,

Nope, you're not alone there.
There isn't 1 dam game I run on this computer with anti-aliasing enabled.

Just trying to pin point why the PS1 struggles with the game.

IF and IF that would be the case, Driver: You are the Wheelman would lag too since it uses the exact same technique as D2.

Not necessarily Klancnik, Driver 1 has significantly less detail then Driver 2, and also, Driver 2's curved roads are more dense then the simple gird-like streets of Driver 1. Therefore taking up more power on curved roads. (And if ran in DirectX or OpenGL, would have Z-fighting rape). Also, by looking at the cities, there are much more details that we didn't even notice like power lines and the rocks in Rio's canyon are VERY dense, especially for the PS1 era.

It seems like the only thing that could have been done was to increase the tiling size by 2, but would cause issues in certain areas.

Also, by this information you can see why Minecraft is a really heavy game. Tiles. too many dam tiles and each face of a cube has 2 faces since everything is actually being drawn as triangles.

[Krishty]

IF and IF that would be the case, Driver: You are the Wheelman would lag too since it uses the exact same technique as D2.

Not necessarily Klancnik, Driver 1 has significantly less detail then Driver 2

Anyone can prove this with actual numbers? I have only extracted Driver 1 for PC and it has twice as many textures but half as many polygons. Anyone has the PSX version's polygon count? Was the viewing range farther in Driver 1 or 2?

[VAIMAHDO]

I've ripped the PS1 version running in real time before, I have no clue how I did, but I remember a ridiculous amount of faces. I'm going to see what I can do about ripping the game again to give exact numbers on the side of studying C++. Already, the render I had done a few posts up was pretty accurate to hinting what the PS1 is running. Not exact, but very close.

[PostalDude]

Driver 2 lags because of a memory leak. End of discussion.

[Klancnik777]

to add to that

http://drivermadness.net/forum/viewtopic.php?f=5&t=3151

[VAIMAHDO]

I've ripped the very first mission where you spawn in the alley, in this part is the only place you will ever fell a smooth framerate in the game.
The amount of polygons in that area at that time is 1770.
The average amount of polygons being rendered while running around Chicago is 2700-3944. This is definitely poor code optimization or too much code or a memory leak.
But in Rio's canyon, far more polygons are being drawn. (Unless I cut the draw distance too far)
Here's proof:

Post edited by Skylabh.
Reason: picture no longer available.

But here's the trick question.


How is it that after importing it into a 3D viewing program...

I have performance issues with the tiny 3949 polygons?
When my laptop can run 35000 just fine?
Something is wrong here.




Every face is split and counted as it's own mesh....

[someone972]

Just popping back in to say that I unlocked the spec (I forgot to do that before) so feel free to add to it or fix it. Great work with everything!

[SOAP]

Just updated your specs. Added world info, and described model defs a little.

Time to think about visibility data, heightmap, bridged model defs. According to Driver 2 demo debug output they called Straddlers.

Heightmap data (at spooldata + 2048 * (sector->offset + sector->contentsNodesSize + sector->contentsTableSize + sector->modelsSize))
I only know that first int32 depends on heightmap data (It may be size. If you zero it, heightmap and it's materials will be set to default and you can't go underwater)
Some next data also depends on visibility , it may contain offsets to some structures. After changing values game will display sectors incorrectly and "shifted", no collision processed, and performance heavily goes down (could be less than 1 fps )
So, it's possible that we have some structure here, and then heightmap data (due big range before DES! padding)

And about LUMP_CHAIR: what does really means "chairs"? (may be I didn't strong in English)

[Olanov]

And about LUMP_CHAIR: what does really means "chairs"? (may be I didn't strong in English)

A chair?



Maybe one of the chairs Tanner could sit down on.

[someone972]

I'll have to take a look and see if the visibility data and heightmap data is the same format as Driver 1. The visibility data is particularly tricky to get right if you don't know the format already.

[VoitureDemolique]

I am way out of my depth here (Excellent work by the way guys), but there is one thing I noticed being different in terms of detail from driver 1 to driver 2 (aside from most of the map being cubes in d1).
The LOD changes much closer to the player vehicle in d1 - you can see clearly distant vehicles turning into cuboids in d1, whereas I cannot see any change in vehicle detail at distance in d2. This might just be the d2 far LOD models looking far more similar to their higher detailed counterparts though.

[PostalDude]

Playing D2 on a PS1 emulator makes it really easy to see the vehicle LODS pop in and out.

[1974]

Thank you! I'm going to test this out now

Meanwhile, at Caine's Compound...

Well then .

[aerom]

SOAP, I downloaded your encoder from your github. But I can't compile it because some header files are missing. Could you publish them?
PS. I saw your project, Driver Syndicate, great job. Are you going to include original cities in your game? If you don't, I can try.