Page 5 of 14

Re: LEV files revisited

Posted: Mon Jun 23, 2014 5:03 am
by VAIMAHDO
This is soo cool! Driver 2, earthquake edition! Who else would jump those? xD Perhaps one day we can optimize Driver 2. I've seen how Driver 2 draws up polygons and it's horribly optimized. It draws by faces per distance, which is why the PS1 struggles with this game and the game engine struggles itself. If more modern optimization (Such as each road containing 2 faces (although simulating 1, triangle meshes is the correct way to draw polygons). And maybe we would one day see this game hit a solid 30FPS without a sweat!

Re: LEV files revisited

Posted: Fri Jun 27, 2014 6:58 am
by SOAP
Also contributing here
Looks like Driver 1 PSX and Driver 2 model formats are exactly same

Tanner, pedhead, jeri_head, notferry, greencone and bomb
Image

Car models (havana.lev LUMP_CAR_MODELS ofs=77952 size=131412) lump is still being too mystical :D

P.S. Maybe github, guys?

Re: LEV files revisited

Posted: Fri Jun 27, 2014 7:25 am
by someone972
Driver 2 models are indeed the same format as Driver 1 it seems, perhaps with a few differences that I can't quite remember atm. I've gotten models to render with textures in a severely hacked up DLE, so maybe I can upload the relevant code or something. It's been a while since I've touched it so I don't remember how much of the Driver 2 lev file format I had figured out. I don't think I was loading any of the model positions like some of the previous images show. Maybe it will be useful to some of you guys though, since you all seem to be doing more work on it than I'd have time for.

Re: LEV files revisited

Posted: Fri Jun 27, 2014 11:06 pm
by kierowca12
Any source code is very important to me. GitHub is a good idea. In upcoming days I'm going to create repository on github with my code.

In previous post I made a mistake. Proper struct looks like:
unsigned short int x;
short int z;
unsigned short int y;
short int{
6 bit: rotation;
10bit: nrObject;
}
Offset: 0xce000(from chicago multiplayer map). Noumber objects: 2234. But I still don't know where is structure to connect this pieces of map.

Piece map:
Image

Re: LEV files revisited

Posted: Sat Jun 28, 2014 12:17 pm
by VAIMAHDO
THIS IS SO AWESOME! How are you converting these?

Re: LEV files revisited

Posted: Sat Jun 28, 2014 1:35 pm
by Klancnik777
awesome work!

btw what do them arrows mean? a polygon or something else? (i seriously doubt its a vertex. but i realy wonder :P)

Re: LEV files revisited

Posted: Sun Jun 29, 2014 12:07 am
by VAIMAHDO
I'm pretty sure the arrows indicate traffic direction, which way a model should face on spawn, or so on.

Re: LEV files revisited

Posted: Sun Jun 29, 2014 4:28 am
by PostalDude
DaRkProDucTioNs00 wrote:I'm pretty sure the arrows indicate traffic direction, which way a model should face on spawn, or so on.
Not possible.

Re: LEV files revisited

Posted: Sun Jun 29, 2014 11:55 pm
by kierowca12
I uploaded my source code. Loader displays arrows like I showed on the screen above (probably position and rotation object on map ;) ).

source code: http://speedy.sh/kkwVr/loader.rar
(required library: irrlicht)

Re: LEV files revisited

Posted: Mon Jun 30, 2014 3:38 am
by Wheels
kierowca12 wrote:
Piece map:
Image
This (I have a feeling) is the Player and Cop driving routes. A player could drive through and ally and have the cop chase him on the same route the player is moving.

Re: LEV files revisited

Posted: Mon Jun 30, 2014 5:15 am
by Krishty
I'm sure these are the tiles' Z axes (i.e. the direction a tile faces when spawned). The X axis is (-z.z, 1, z.x) and the Y axis is always (0, 1, 0).

You can see pretty clear the roads are mirrored and the buildings always face the roads. Just instantiate the object at the 10-bit number at that position and rotation, and all should be fine.

Re: LEV files revisited

Posted: Mon Jun 30, 2014 6:20 am
by someone972
Looking at your code it looks like you're on the right track. I apologize for not uploading my research into Driver 2 level formats, it's just that documentation is no fun and my code rapidly changes to test the newest hack. I'm currently writing up a file spec with what I know so far, but if you have any pressing questions on the format that I might be able to answer, you can hit me up on Skype (pm me for my username (EDIT: Actually, you can probably just enter my Driver Madness username into the search and find me)). Once I'm done with what I know of the spec, you all can add in all the missing pieces that you've figured out and maybe we will get the file format mostly figured out.

Re: LEV files revisited

Posted: Mon Jun 30, 2014 6:40 am
by someone972
Here's a link to the start of the spec. I've locked it for editing since it's being actively updated, but you will be free to edit it once I'm out of it.
http://driver.wikia.com/wiki/User:Someo ... cification

Re: LEV files revisited

Posted: Tue Jul 01, 2014 12:13 am
by SOAP
Made very correct lump identifiers using Driver 2 demo and coding
Code: Select all
// known lumps indexes
#define LUMP_MODELS			1
#define LUMP_MAP				2
#define LUMP_TEXTURENAMES		5
#define LUMP_MODELNAMES		12

#define LUMP_SUBDIVISION		20
#define LUMP_LOWDETAILTABLE		21
#define LUMP_MOTIONCAPTURE		22
#define LUMP_OVERLAYMAP		24
#define LUMP_PALLET				25
#define LUMP_SPOOLINFO			26
#define LUMP_CAR_MODELS		28

#define LUMP_CHAIR				33
#define LUMP_TEXTUREINFO		34

#define LUMP_LEVELDESC			35
#define LUMP_LEVELDATA			36
#define LUMP_LUMPDESC			37

#define LUMP_STRAIGHTS2			40
#define LUMP_CURVES2			41
#define LUMP_JUNCTIONS2			42

/*
Still unknown
LUMP_ROADMAP
LUMP_ROADS	
LUMP_JUNCTIONS
LUMP_ROADBOUNDS
LUMP_JUNCBOUNDS
LUMP_ROADSURF
*/

Re: LEV files revisited

Posted: Tue Jul 01, 2014 1:31 am
by SOAP
So, here compiled executable and some exported models:
http://www.mediafire.com/download/fe3ca ... _level.rar

Also uploaded code of this app
https://github.com/SoapyMan/psx_driver2_lev

ExportDMODELToOBJ procedure is reading model, decoding faces 99% correct by their bitflags (the only thing i can't check is vertex normal and colors)

DkCore sources not included for now, but you can easily replace some stuff by std and cstdlib

Re: LEV files revisited

Posted: Tue Jul 01, 2014 3:59 am
by someone972
Wow, your face handling code is really nice. I can't believe how hard I had made it when the type is apparently just a bit-field. I'm at work now, but when I get back I'll try and get the format for the Car Models lump and some more texture stuff.

Just for reference, here are the lumps that I mostly know the format for:
Spool Info (sort of)
Palettes
Map (maybe)
Texture Info

You'll need the spool info lump if you want to load all the textures/models in the level, as they are scattered around in section 4.

Re: LEV files revisited

Posted: Tue Jul 01, 2014 5:16 am
by VAIMAHDO
This is so awesome once again! Nice work guys!

Re: LEV files revisited

Posted: Tue Jul 01, 2014 6:20 am
by SOAP
Also I have analysed kierowca12 sources, and I think he discovered a PACKED_CELL_OBJECT structure (this name also came from D2 Demo debug output):
Code: Select all
struct dcell_t
{
	ushort		x;
	short		y;
	ushort		z;

	short		cellprops;	// 6 bit rotation and 10 bit model index
};
Also the similar structure (but not size) have PSX_ModelDef from your psx_code.zip (attachment from this thread)

Need to find pointers to cell data, i think they should skip 4x 2048 byte padding (maybe LUMP_SUBDIVISION or LUMP_MAP points to them?)

Re: LEV files revisited

Posted: Tue Jul 01, 2014 6:29 am
by someone972
Its a bit of an involved process to find that sort of stuff. I'll try and explain it a bit here.

The majority of the "cell" (I referred to them as sectors) data is in section 4. There is some of those "cell object"/"model def" entries in the MAP lump I think, but only for models that bridge cell boundaries. In order to read the last section you have to read the spool info lump. This contains two main things (and a bit of unknown data): Shared data group info, and sector data info. The shared data group info tells what offset to find textures and maybe models. The sector data info tells what offset and size each of the different bits of data for a sector are. All the offsets and sizes need to be multiplied by 2048 to get the actual offset/size, which is why they have 2048 byte boundary padding. I mostly figured out the format for Driver 1's PSX levels, but the specifics changed a bit for Driver 2.

That's just a quick overview, but let me know if you have questions about it. I'll try and get the format up on the wikia page after work.

EDIT: It looks like I won't have time to write up a spec tonight, but I'll try and get to it as soon as possible.

Re: LEV files revisited

Posted: Tue Jul 01, 2014 9:59 pm
by kierowca12
someone972 wrote:Here's a link to the start of the spec. I've locked it for editing since it's being actively updated, but you will be free to edit it once I'm out of it.
http://driver.wikia.com/wiki/User:Someo ... cification
Thanks for wiki. Do you know more about Sector Info(0x1a)?
How association model names with models?(I have name model and I want find correct model.) Model names is more than models.

I loaded piece of map but in my opinion something is wrong:
Image Image

Re: LEV files revisited

Posted: Wed Jul 02, 2014 1:25 am
by someone972
The names are associated based on the occurrence of the null ('\0') character. So if you had TREE\0BOAT\0\0\0SIGN\0 as the string, it would associate to the following model indices:

0 - TREE
1 - BOAT
2 -
3 -
4 - SIGN

There may be more null's in the names block than there are models, simply due to padding.

Re: LEV files revisited

Posted: Wed Jul 02, 2014 1:27 am
by SOAP
kierowca12 wrote: I loaded piece of map but in my opinion something is wrong:
Seems like rotation is wrong (+/-90 degrees) along with scaling

Re: LEV files revisited

Posted: Wed Jul 02, 2014 1:37 am
by someone972
I forgot to mention (which you've probably already figured out), but some of the models have a 0 size and are contained in the forth section. So unless you've gotten lucky and found them, some of the models will be missing. You can find them from the sector info block, which I'll spec out later today. Last night I was figuring out what order the data comes in etc, and I got enough so that you'll at least be able to load textures, models, and the model positions that you're loading now.

Re: LEV files revisited

Posted: Wed Jul 02, 2014 5:53 am
by VAIMAHDO
Hey guys, I tried to give it away on Free Chat but didn't seem to work. Thanks to all of your guy's work, exporting some Driver 2 models has been done, and earlier on was textures. So, with those materials, I was able to start re-constructing Driver 2 thanks to you guys, Driver 2 animations is possible!
[youtube]
[/youtube]
Although quite simple, the idea is that this is now possible :)

Re: LEV files revisited

Posted: Wed Jul 02, 2014 4:15 pm
by SOAP
DaRkProDucTioNs00 wrote:Hey guys, I tried to give it away on Free Chat but didn't seem to work. Thanks to all of your guy's work, exporting some Driver 2 models has been done, and earlier on was textures. So, with those materials, I was able to start re-constructing Driver 2. I got strongly motivated that my first C++ game should be Driver 2 for PC. (With some graphics enhancements available if I get that far) But thanks to you guys, Driver 2 animations is possible!
{cut video}
Although quite simple, the idea is that this is now possible :)
LOL!

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

By the way, i've found that some faces in some models have some indices out of range, i can't understand why this was done.

Also i need other lump specs

Re: LEV files revisited

Posted: Wed Jul 02, 2014 5:41 pm
by someone972
Alright, it's 1:00 AM and I've been up all day doing work and making a quiche, but I said I was going to get the spec up and so I will. It's going to suck being up so late, but look for it soon.

EDIT: I updated the spec to have the sector info and more of the texture info blocks. The writeup is rushed and terrible, and there's massive amounts of unknown data, but it should at least get you on the right track. I'd post more information about some of the other sectors but it's late enough as is. Like always, you can contact me on skype if you have questions about the spec. Be sure to update this thread with your findings so that we don't do as much duplication of work.

I'll have to work with you to figure out the model indices thing sometime if you don't figure it out. I've never had any trouble with it, but I'm also loading the models differently.

Re: LEV files revisited

Posted: Thu Jul 03, 2014 3:02 am
by kierowca12
someone972 wrote:Alright, it's 1:00 AM and I've been up all day doing work and making a quiche, but I said I was going to get the spec up and so I will. It's going to suck being up so late, but look for it soon.

EDIT: I updated the spec to have the sector info and more of the texture info blocks. The writeup is rushed and terrible, and there's massive amounts of unknown data, but it should at least get you on the right track. I'd post more information about some of the other sectors but it's late enough as is. Like always, you can contact me on skype if you have questions about the spec. Be sure to update this thread with your findings so that we don't do as much duplication of work.

I'll have to work with you to figure out the model indices thing sometime if you don't figure it out. I've never had any trouble with it, but I'm also loading the models differently.
You have done good job. This information is very important to me. I begin implement this to my program. If I figure something out I will tell you.

Re: LEV files revisited

Posted: Thu Jul 03, 2014 7:46 pm
by SOAP
LUMP_SPOOLINFO is something mystical, but tried to decompile function that loads offsets
It's difficult to understand MIPS assembly sometimes :D

Procedure is directly taken from driver 2 demo executable, and decompiled to C
It loads spool info (may be partial, because cell allocation function call is next after this)
Code: Select all
struct struct_0 {
    int32_t e0[4];
    int32_t e1;
};

int32_t * g1; // 0xa41e8
struct struct_0 g2; // 0xa41f8
struct struct_0 g3; // 0xa4620
int32_t g4 = 0; // gpregs4 - initially lump data pointer

void function_40000(void) {
    int32_t v1 = g4; // 0x40000
    int32_t v2 = *(int32_t *)0x94ec0; // 0x40010
    g4 = v2;
    int32_t v3 = 2048 * *(int32_t *)v1; // 0x40014
    *(int32_t *)3076 = v2;
    int32_t v4 = v1 + 4;
    int32_t v5; // 0x4002c
    if ((int32_t)(v3 > 0xffff) == 0) {
        // 0x40024
        v5 = 0x10000;
        // branch -> 0x4002c
    } else {
        // .dec_label_pc_4002c_crit_edge
        v5 = v3;
        // branch -> 0x4002c
    }
    int32_t v6 = g4 + v5; // 0x4002c
    int32_t v7 = v6;
    int32_t v8 = 0xa41e8;
    *(int32_t *)0x94ec0 = v6;
    *(int32_t *)3068 = v4 + 4;
    int32_t v9 = *(int32_t *)v4 + 4 + v4; // 0x40074
    g4 = *(int32_t *)v9;
    *(int32_t *)3020 = v9 + 4;
    int32_t v10 = 16 * g4; // 0x40084
    int32_t v11 = (v10 | 4) + v9; // 0x4008c
    *(int32_t *)3088 = v11;
    int32_t v12 = v10 + v11; // 0x40094
    *(int32_t *)3040 = g4;
    g1[v8] = v7;
    int32_t v13 = 0; // 0x400a4
    int32_t v14 = 0xa4620;
    g3.e0[v14] = v13;
    int32_t v15 = 0; // 0x400a8
    int32_t v16 = 0xa41f8;
    g2.e0[v16] = v15;
    int32_t v17 = v12; // 0x400ac
    int32_t v18 = v8 + 4; // 0x400c4
    int32_t v19 = 2; // 0x400c8
    int32_t v20 = *(int32_t *)v17 + v13; // 0x400cc
    int32_t v21 = *(int32_t *)(v17 + 16) + v15; // 0x400d0
    int32_t v22 = v7 + (*(int32_t *)(v17 + 32) + 2047 & -2048); // 0x400dc
    // branch -> 0x400a0
    while (v19 > 0xffffffff) {
        // 0x400a0
        g1[v18] = v22;
        v13 = v20;
        v14 += 4;
        g3.e0[v14] = v13;
        v15 = v21;
        v16 += 4;
        g2.e0[v16] = v15;
        v17 += 4;
        v18 += 4;
        v19--;
        v20 = *(int32_t *)v17 + v13;
        v21 = *(int32_t *)(v17 + 16) + v15;
        v22 += (*(int32_t *)(v17 + 32) + 2047 & -2048);
        // continue -> 0x400a0
    }
    // 0x400e0
    v4 = v12 + 48;
    g3.e1 = v20;
    g2.e1 = v21;
    *(int32_t *)0x94ec0 = v22;
    *(int32_t *)3048 = v4 + 4;
    *(int32_t *)2968 = 2 * *(int32_t *)v4 + 4 + v4 + 4;
}
Looks like i've found a nice MIPS translator at http://decompiler.fit.vutbr.cz (code structure only, data types and numbers may be wrong)
Other decompilers which i've tried aren't capable to generate valid code (even asm in IDA didn't look good while i've tried to translate it manually)

I think this code might be helpful. I'll test it soon to load lump properly

Re: LEV files revisited

Posted: Fri Jul 04, 2014 1:33 pm
by someone972
I've updated the spec to have the Car Palettes block (LUMP_PALETTE). Here's the link to the spec again so you don't have to go searching: http://driver.wikia.com/wiki/User:Someo ... cification

Re: LEV files revisited

Posted: Sat Jul 05, 2014 5:59 pm
by kierowca12
I discovered something out. If you add to sectorInfo.sectorDataInfo.offset*2048 + 2048*5 you get piece of map(not always). I don't know the position of this pieces map on the whole map so I can load only multiplayer map becouse it has little pieces map.
Image