someone972 wrote:Ya, that's probably the "modelDefs" offset. If you seek 2048*contentsTableSize+2048*contentsNodesSize instead of 2048*5, I think it should probably get you to that spot reliably. Note for Driver 2 you'll have to add an offset to each sector if you are drawing them, because it stores the model def positions relative to the sector origin so that it can use shorts instead of longs for position. Let me know if using the offset I said above gets you to the right spot or not.
Note on Driver 2 demo version: The 4th byte after contentsNodeSize gives another offset (at least that works fine for me). So it's
Border models are problematic because models are usually defined relative to the sector center. But without a specific sector, we cannot use relative positions, and the numbers in the model definitions are too small to be absolute. So I guess there is some bit magic going on, where a sector index is defined and then an offset relative to the positive or negative border. Just guessing here.
It's a pain to find that out just by looking at numbers, so I visualized the bits in the demo's Havana level. Left to right are global model definitions; top to bottom are bits from most significant to least significant (read from four little-endian 16-bit ints); white means a bit is set:
There's a big white bar in the middle. If you count it, it's starting at the 16th bit and is 10 bits long. Let's assume this is a number.
There's a black bar right below, one bit wide. On some very rare occasions, it's set. Together with the 10 bits above, This is a good candidate for the 11-bit model index. Seems like it's stuffed into two parts.
Below, another white bar, four pixels wide.
890 pixels from the left, at the very top, there is a perfect binary tree with a depth of six bits. So that's 64 numbers being perfectly consecutive there. At this point, we can be sure the first six bits form a number.
… and so on.
My impression is, the entries are divided into 6-10 - 10-1-4 - 10-8 - 10-1-4 bits. Now I'll generate the according data structure, print the numbers, and see if I can find more patterns. 10+1 bits seems very promising because it's the number of bits required for a model index.
Welcome back! I know quite a bit about the sector border models for PC, I forget if I ever got it sorted for PSX or not. Regardless, it should be very similar. I'd take a look but I'm currently at work. Very interesting using an image to help determine structure!
In Driver 1 PC, the global instances used global 32-bit positions. I don't know how it was in the PSX version.
I'm pretty sure now the global data is in the same format as the local data. It's just too similar. The white band in the middle definitely is Y, and X and Z look familiar, too. 16 bits is too few for a global position, so where's the other eight to sixteen bits? I'd be glad to hear from you. In the meantime, I'll dig through old source code for loading Driver 1 PSX levels, maybe I'll find a clue …
Edit: Driver 1 PSX, according to your code ("bridged models"), also uses three 32-bit integers for XYZ
Edit 2: The 16-bit X and Z are indeed local positions; I measured some distances in multiplayer Chicago and they match astonishing well. It's just, the additional bits for the correct sector are hidden somewhere. Assuming Driver 2 maps have a sidelength of 64×64 sectors max, that's 6+6 bits to find …
Sidenote to model flags: flag & 1024 denotes whether the model is lit dynamically.
This is important at night: The ground cannot be textured dark because it would remain dark even with street lights illuminating it. So it's textured with daylight textures, the flag is set, and the engine dims the brightness when there is no light source nearby.
Chicago at night:
Some severe texture interpolation problems showing up there …
I'm suspecting that the position for the bridged models might be related to what I called contents lists. If you aren't loading these lists, and going straight from the model position definitions, then I suspect that you will have trouble with the bridged defs. My suspicion is that the contents lists have references to whatever bridged defs they contain, then they offset them by the current sector position. This is just a theory though, I do not have things set up enough to test it at the moment. Perhaps you can try and figure out the format, although it's quite tricky. You may be able to look at the PC level format for help.
RacingFreak wrote:This is an amazing work. Keep it up!
Thanks … we're doing it for the fans
someone972 wrote:I'm suspecting that the position for the bridged models might be related to what I called contents lists. If you aren't loading these lists, and going straight from the model position definitions, then I suspect that you will have trouble with the bridged defs.
Yeah, that's exactly what I'm doing
someone972 wrote:My suspicion is that the contents lists have references to whatever bridged defs they contain, then they offset them by the current sector position. This is just a theory though, I do not have things set up enough to test it at the moment. Perhaps you can try and figure out the format, although it's quite tricky. You may be able to look at the PC level format for help.
Okay. I the Driver 1 PC format, everything is stuffed into the world header, but it's scattered in Driver 2 PSX. I see two lists which consist of sorted 16-bit numbers, interrupted with 0xFFxx in irregular intervals.
In the Driver Level Editor, you do nothing with the lists other than read and write them. What's their purpose? I assume you know something I don't, because you gave them names
At least in Driver 1, they specify all the models in a certain visibility tile. What I call visibility tiles are essentially just a grid with smaller dimensions than the heightmap (in Driver 1, a vis tile is about 2x2 models, while the heightmap is 1x1). Hopefully that makes sense. Anyway, there's a visibility lump (at least in Driver 1) where for every position on the grid, it specifies which tiles are visible, and it uses those contents lists to draw the models. This is why when loading model defs from driver 2 there is no count of how many there are, and you have to read until padding. Since it uses the lists, there is no need for it to load the model defs, they are just referenced from the contents list.
Damn. You guys are so amazing! I didn't believe what I was reading on the start, but now.. wow! Simply wow! On the end, we're gonna have PC version of Driver 2 all those numbers, and that stuf.. Keep it up!
StifleroGamingHD wrote:Damn. You guys are so amazing! I didn't believe what I was reading on the start, but now.. wow! Simply wow! On the end, we're gonna have PC version of Driver 2 all those numbers, and that stuf.. Keep it up!
.....That isn't even close to what's going on. He's ripping the D2 levels, that's all.
"all those numbers, and that stuf."
And there already is a "PC version of Driver 2", it's called "Play it on EPSXE."
Krishty wrote:Sidenote to model flags: flag & 1024 denotes whether the model is lit dynamically.
This is important at night: The ground cannot be textured dark because it would remain dark even with street lights illuminating it. So it's textured with daylight textures, the flag is set, and the engine dims the brightness when there is no light source nearby.
Chicago at night:
Some severe texture interpolation problems showing up there …
Skylabh wrote:If the tool could extract properly all the vehicles and the cities without missing polygons, that would be awesome
Yes, but this requires proper handling of the visibility lists, which is a rather huge task. I'm too involved with other projects and real life to do it right now
Krishty wrote:Yes, but this requires proper handling of the visibility lists, which is a rather huge task. I'm too involved with other projects and real life to do it right now
I understand , it's not an easy thing to do. However what you guys succeeded to achieve until now is amazing.
Mouse wheel moves forward; held left mouse button for left/right/up/down; hold right mouse button for rotation
In case one of you comments YouTube videos: I don't have access to my Google accounts any more, so if someone could provide the link to the commenters of this video, that would be nice.
Last edited by Krishty on Tue Aug 29, 2017 6:05 am, edited 1 time in total.
Hello community. I have been playing Driver 2 since early 2000s and I must say that it is one of the best games I have ever played. As a tribute to that game I designed and assembled (without using original models extracted from the game; I built this model all myself!) of 58 Dodge from Havana:
Under construction...
Finished, in front of two genuine Cuban license plates. (I am a license plate collector too.)
I have one question to you. I am really into modding and adding custom material to the game. On this board I have found a tool which lets me extract models and textures in editable formats. (A big thank you to the author of Driver Level Tool, whoever you are.) Now, I would like to replace all cars in one of cities with custom made ones. Is it possible (I mean, is a tool available) to pack the modified data back to a LEV file and use in the game?
Also, where can I find models of damaged vehicles? Or are they rather a set of instructions how to distort the default models (together with changing texture map coordinates)?
Nice replica
As for your question, there's no tool to put back modified datas.
Probably the clean models are distorted at runtime, by a set of instructions like you said.
francof514 wrote:Will be possible to use demo levels into final release??
There is no hard encryption involved, so everything is possible; but you’d rather ask, is it possible with a realistic amount of work?
And the answer is, I don’t know. Sucking the level data out of the demo was possible with just a few changes. However, the game needs loads of other data, too:
collision data (polygons + heightmaps)
traffic description
that linked-list visibility data that I have yet to decode in order to fill the terrain holes
I suspect the last one being different in the demo (this would explain the performance/quality difference), so it’s probably a lot of work.
I personally won’t do anything of that kind in the next one or two years due to time constraints, sorry.
@arklas: This is indeed a fantastic replica!
arklas wrote:(A big thank you to the author of Driver Level Tool, whoever you are.) Now, I would like to replace all cars in one of cities with custom made ones. Is it possible (I mean, is a tool available) to pack the modified data back to a LEV file and use in the game?
I may be wrong, but I think the author is someone972. As Skylabh says, there is no tool readily available. If you’re ready to put in some programming effort, SOAP has pretty awesome LEV tools (looks to me like he designed the level format of his Driver Syndicate game to be compatible to Driver’s to some amount), but don’t get your hopes too high.
Also, where can I find models of damaged vehicles? Or are they rather a set of instructions how to distort the default models (together with changing texture map coordinates)?
According to this video, there is a tool Driver Damage Viewer that is not public, but it can display the damage data of Driver 1 cars (1:19):
It looks to me like a displacement vector and a damage zone (front, left, rear, …) are assigned to each vertex, so it’s nothing hard-coded. Hopes are high that Driver 2’s car format is similar, but you’ll have to ask SOAP about it (he’s much more familiar with the LEV format than me).
Driver Madness is the world's largest fan-site for the game series Driver, created by Reflections. Come and join us if you would like to talk about the game series, or any game, or even if you just want to chat!
all those numbers, and that stuf.. 
Keep it up! 
- By viinasieni
- By Stedly
- By BD7
- By Zombie2358