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
Car models (havana.lev LUMP_CAR_MODELS ofs=77952 size=131412) lump is still being too mystical
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:
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 )
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 ).
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.
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):
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:
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
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)
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
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.