Page 7 of 14

Re: LEV files revisited

Posted: Mon Jul 14, 2014 3:52 am
by SOAP
Krishty wrote:Awesome! Thank you very much (Y)

Image

Now I'll need to figure out the correct texture coordinates so the quads don't rotate …
Nice!
May be other UNK6 and UNK7 flags depends on rotation? It's confusing ))) I didn't have 3D program to view, and didn't decoded textures at all.

Re: LEV files revisited

Posted: Mon Jul 14, 2014 5:30 am
by Krishty
Where do I find the number of objects per terrain tile? Just using 2000 makes my Chicago look a little … shattered :(

Image

Re: LEV files revisited

Posted: Mon Jul 14, 2014 8:41 am
by someone972
I'm back, was on vacation. For finding how many of the position/rotation structs are in the sector, I think for now you will just have to keep reading until you hit a "DES!" block, or until you read 2048 times the size in case there are exactly that number of structs so that no DES padding is used. If it works like Driver 1, there is additional data that actually accesses those structures based on your position, so the game doesn't need to know how many of them there are.


Good work with the level viewing and vehicle extraction!

Re: LEV files revisited

Posted: Mon Jul 14, 2014 9:32 am
by VAIMAHDO
Wow, so much progress! I've never thought the day of extracting game files from Driver 2 would ever come. (Y)

Re: LEV files revisited

Posted: Tue Jul 15, 2014 3:53 am
by Krishty
someone972 wrote:I'm back, was on vacation.
Well, my vacation will be over the day after tomorrow, so I better have all of this finished until then ;)
For finding how many of the position/rotation structs are in the sector, I think for now you will just have to keep reading until you hit a "DES!" block, or until you read 2048 times the size in case there are exactly that number of structs so that no DES padding is used.
Alright, I did so for now.
If it works like Driver 1, there is additional data that actually accesses those structures based on your position, so the game doesn't need to know how many of them there are.
Whenever you find out where that data is, let me know :)

The level looks much cleaner now, but I noticed lots of tiles have their models wrong. E.g. piles of sand instead of roads. I can't implement it right now, but my thoughts:

There is this hierarchy with bundles at the bottom. Bundles bring models and textures. (19 of them in MLEVELS CHICAGO)
Then there are sector definitions. A sector uses a a bundle. Two identical sectors share the same bundle. (10 of them in MLEVELS CHICAGO)
Eventually, there are sectors (384 in MLEVELS CHICAGO).

For each sector, find its sector definition (or FFFF if unused). A'ight. Then for that definition, find the bundle of models and textures. Now here's the point:

Bundles bring a "size of model definitions / 2048" and sector definitions do, too. I suspect only one of them is correct. I'll check if that makes sense.

Re: LEV files revisited

Posted: Tue Jul 15, 2014 4:53 am
by Krishty
Today's progress:
Image
But just like I said, very very many models are wrong.

Re: LEV files revisited

Posted: Tue Jul 15, 2014 8:09 am
by Skylabh
Awesome (Y)

Re: LEV files revisited

Posted: Tue Jul 15, 2014 8:59 am
by someone972
I'm wondering if those piles of sand aren't there to cover the holes between the road sections or something. I've noticed that the height for some of the tiles are wrong, at least in the crap level viewer that I had hacked together from a veeeerrrryyy old Driver 1 level viewer. So it's possible that those sand sections are meant to be underneath the road?

Re: LEV files revisited

Posted: Tue Jul 15, 2014 2:32 pm
by Krishty
No, the heights are alright, but the model indices are wrong: The walls next to the road are mistaken as piles of sand. (The same goes for train lines, which are green-yellow ground tiles.)

But it's difficult to find out why, because MPLAYER looks fine.

Re: LEV files revisited

Posted: Wed Jul 16, 2014 12:01 am
by someone972
Interesting, so this only happens on the regular Chicago and not multiplayer?

Re: LEV files revisited

Posted: Wed Jul 16, 2014 3:07 am
by Krishty
Multiplayer Chicago is alright, and so is multiplayer Havana and multiplayer Rio (fantastic multiplayer map btw, it's a pity I never played that one).

Image

Single-player levels are all f***ed up. Havana and Rio are fubar, their model indices are just sooooo wrong. Chicago isn't perfect but you can tell what it *should* be like.

Can't say anything about Vegas, because – no joke – I can't find it. My tiling is wrong. I know Chicago and Havana are 320 tiles with 16 tiles in X, but I don't know where to find the X dimension of Vegas or Rio. Now Vegas is scattered out so far that I can't see a single tile.

Edit: Found Vegas! It's the only singleplayer map where models are alright. Strange …

Image

Re: LEV files revisited

Posted: Wed Jul 16, 2014 5:12 am
by Krishty
By the way: What is the 4th component in model vertices for?

Re: LEV files revisited

Posted: Wed Jul 16, 2014 5:28 am
by Clutch
In model vertices?... Maybe merging? Static/moving flag? What is range of values? I don't know how it looks... I'm kinda not initiated.

Re: LEV files revisited

Posted: Wed Jul 16, 2014 5:59 am
by Krishty
Static/moving flag may be an option. It's mostly zero, but sometimes it's a big number. Might even be two 8-bit numbers.

I found a problem with models: 10-bit model indices are wrong. Just think about it: There are 1207 models in single-player Chicago, but a 10-bit number can only hold 1024 values. So when there's a "3" in the 10-bit index, what it really means is "1024+3". I think. It's something about that.

So now the walls around highways are alright, and everything that was wrong before now looks fine. Except that also everything that looked fine before is now wrong :shock:

Crazyness.

Re: LEV files revisited

Posted: Wed Jul 16, 2014 6:48 am
by Krishty
I tried what I could, but I can't find the 11th bit. I can only tell models 0, 1, 2, and 3 are really 1024, 1024, 1026, and 1027. I have no idea how the game finds the 11th bit. Of course the problem does not show in multiplayer maps because there are far less than 1024 models.

The quad texture coordinate problem is also unsolved.

Finally: Driver 1 had flags whether textures had transparency, whether polygons were sprites (always towards viewer). I also need these two for my visualization. Are they still the same?

Thanks to kierowca12, SOAP, and of course someone972 for your help and for sharing your findings. I'll PM you my main source file. (I'd like to post it here but there is no "spoiler" button and I don't know where to otherwise upload it … it's public domain, so feel free to share and copy.)

Re: LEV files revisited

Posted: Wed Jul 16, 2014 10:15 am
by Fireboyd78

Re: LEV files revisited

Posted: Wed Jul 16, 2014 2:06 pm
by kierowca12
Thanks for your source code.
ps. I would like create open game engine for driver 2 in the future. :)

Re: LEV files revisited

Posted: Wed Jul 16, 2014 4:18 pm
by Krishty
kierowca12 wrote:I would like create open game engine for driver 2 in the future. :)
If so, I strongly recommend NOT to use LEV files directly with your engine. Rather build a converter which will, upon installation, transform user's LEVs into a representation your engine can handle more easily and faster (like I did for my viewer). Anybody having to clone Driver 2's rendering engine would certainly lose their mind.

Anyway: This is my last spare day and whatever I don't get done today won't get done for years :( Any idea where the 11th bit is hidden?

Re: LEV files revisited

Posted: Wed Jul 16, 2014 5:04 pm
by SOAP
Krishty wrote:
kierowca12 wrote:I would like create open game engine for driver 2 in the future. :)
If so, I strongly recommend NOT to use LEV files directly with your engine. Rather build a converter which will, upon installation, transform user's LEVs into a representation your engine can handle more easily and faster (like I did for my viewer). Anybody having to clone Driver 2's rendering engine would certainly lose their mind.

Anyway: This is my last spare day and whatever I don't get done today won't get done for years :( Any idea where the 11th bit is hidden?
Need to check spoolinfo for this "11th bit", or check how model indexes are ordered (1021, 1024, 1, 3, 5 or something).
I'll also check it later

Re: LEV files revisited

Posted: Thu Jul 17, 2014 2:44 am
by Krishty
Your dmodel_t::unk:
Code: Select all
enum ModelFlags1 :uint16_t {
	everything    = 1,
	dontKnow0     = 2,
	walls         = 4,
	dontKnow1     = 8,
	dontKnow2     = 16,
	planarGround  = 32,
	dontKnow3     = 64,
	dontKnow4     = 128,
	dontKnow5     = 256,
	dontKnow6     = 512,
	ground        = 1024,
	dontKnow7     = 2048,
	dontKnow8     = 4096,
	street        = 8192,
	tree          = 16384,
	anythingToHit = 32768 // walls, poles, fences; but not trees or buildings
};
dmodel_t::unk2:
Code: Select all
enum ModelFlags2 : uint16_t {
	dontKnow9    = 1,     // empty in Chicago
	sandy        = 2,     // ??? lots of sandy stuff, but not everything
	dontKnow10   = 4,     // ??? (just one roof in Chicago)
	dontKnow11   = 8,     // ??? (empty in Chicago)
	dontKnow12   = 16,    // many sidewalks, some grass
	medianStrips = 32,
	crossings    = 64,
	dirt         = 128,   // lots but not everything
	dontKnow13   = 256,   // parking lot in Chicago
	chair        = 512,
	walls2       = 1024,  // don't know the difference to 'walls'
	destructable = 2048,
	dontKnow14   = 4096,  // ??? (empty in Chicago)
	greenTree    = 8192,  // don't know the difference to 'tree'
	dontKnow15   = 16384, // ??? again: many sidewalks, some grass
	sidewalk     = 32768
};

Re: LEV files revisited

Posted: Thu Jul 17, 2014 4:32 pm
by SOAP
I was wrong about texture coordinates from atlas (or missed some details) because some models have completely wrong mapping

Image

Just for information: I remembered that when i've taken a ride in Havana and played too long time I saw bug on curved roads - walls appeared on road (but they didn't have collisions) This is probably a model index bug

P.S. Level viewer from Krishty
http://www.mediafire.com/download/qhygf ... 4-07-16.7z

You'll need a Direct3D 11-compliant GPU. There's a blue screen when you start it. With the RIGHT mouse button, click into the center and drag to the right (this is how you rotate) until you see the city. Then use mouse wheel to zoom in. Press mouse wheel down to move top/left/bottom/right.

Re: LEV files revisited

Posted: Thu Jul 17, 2014 6:02 pm
by Krishty
SOAP wrote:I was wrong about texture coordinates from atlas (or missed some details) because some models have completely wrong mapping
Oh no you weren't! This is what it looked like without texture coordinates from atlas:
Krishty wrote:Image
Compared to the current result, it is a great improvement; we just need to get the rotation right.

The planes are one bad case, but there are 600 good cases. It likely has a different reason, just some detail we missed.

Re: LEV files revisited

Posted: Thu Jul 17, 2014 6:43 pm
by Skylabh
Nice viewer and nice maps (Y)

Re: LEV files revisited

Posted: Thu Jul 17, 2014 7:06 pm
by Krishty
If there is any interest, I could also deliver the Driver 1 PC levels tomorrow.

Re: LEV files revisited

Posted: Thu Jul 17, 2014 11:13 pm
by Clutch
Yeeeeees!!! :D

Btw... Sorry for stupid questions, I'm still not up-to-date with modding/editing/viewing news, but... is any hope for converting D2 maps to D1?

Re: LEV files revisited

Posted: Fri Jul 18, 2014 2:38 am
by SOAP
Image

This is valid Vegas sector positions (updown). % 32 instead 16

Re: LEV files revisited

Posted: Fri Jul 18, 2014 2:45 am
by Krishty
Strange. Any idea where we can find that information in the LEV?

Btw, your FACE_HAS_NORMAL flag is set only for ground tiles the car can drive on. No buildings, no other objects, nothing. So I suppose it's actually collision information for the tires. Looking into some other flags right now

Edit: Same for the UV_FROM_FILE flag.

Edit2: I've found the building texture coordinates:
Code: Select all
if(UV_FROM_ATLAS & result.flags) {
	result.texcoord[0][0] = result.color[0];
	result.texcoord[0][1] = result.color[1];
	result.texcoord[1][0] = result.color[2];
	result.texcoord[1][1] = result.color[3];
	result.texcoord[2][0] = result.nindex[0];
	result.texcoord[2][1] = result.nindex[1];
	result.texcoord[3][0] = result.nindex[2];
	result.texcoord[3][1] = result.nindex[3];
}
Obviously, we've gotton the flags wrong. Looks a lot better now; I'll prepare for a viewer update.

Re: LEV files revisited

Posted: Fri Jul 18, 2014 3:43 am
by SOAP
Krishty wrote:Strange. Any idea where we can find that information in the LEV?

Btw, your FACE_HAS_NORMAL flag is set only for ground tiles the car can drive on. No buildings, no other objects, nothing. So I suppose it's actually collision information for the tires. Looking into some other flags right now

Edit: Same for the UV_FROM_FILE flag.

Edit2: I've found the building texture coordinates:
Code: Select all
if(UV_FROM_ATLAS & result.flags) {
	result.texcoord[0][0] = result.color[0];
	result.texcoord[0][1] = result.color[1];
	result.texcoord[1][0] = result.color[2];
	result.texcoord[1][1] = result.color[3];
	result.texcoord[2][0] = result.nindex[0];
	result.texcoord[2][1] = result.nindex[1];
	result.texcoord[3][0] = result.nindex[2];
	result.texcoord[3][1] = result.nindex[3];
}
Obviously, we've gotton the flags wrong. Looks a lot better now; I'll prepare for a viewer update.
Excellent! Unfortunately, my function has "WORKING" bug:
if(out->flags & FACE_HAS_VERTEXNORMAL && numComp == 3 && !(out->flags & FACE_RGB))

EDIT: Stuck at face type 9 (only FACE_IS_QUAD | FACE_TEXTURED_ATLAS), reading 16 instead 14 bytes...

Re: LEV files revisited

Posted: Fri Jul 18, 2014 4:21 am
by SOAP
found map dimensions

Parse LUMP_MAP with this structure
(I found it here, http://drivermadness.net/forum/viewtopi ... 905#p51905, function PSX_World::load)
Code: Select all
struct mapinfo_t // undone
{
	int width;
	int height;

	int tileSize;
	int numSectors;
	int visTableWidth; // value is mostly 32

	// 2 ints unknown

	// 4 byte ambient light (Driver1)
	// 4 ints sun direction/angle
};

...
Parse spool info
Code: Select all
int dim_x = g_mapInfo.width / g_mapInfo.visTableWidth;
...
if (i % dim_x == 0) printf('\n')
Rio sector map [14 18]
Image

EDIT: I was right about visTableWidth (Frisco.lev, visTableWidth=30)
Image

Re: LEV files revisited

Posted: Fri Jul 18, 2014 11:08 am
by Fireboyd78
Wow, the amount of progress so far has been incredible. It's so cool seeing you guys work together to help figure out Driver 2!

Keep up the great work! (Y)