Paul, please can you update your decoder???
i've been waiting a month.

I think thats very rude. Why should he. It would take him a long time to decode something and he hasn't even said what he is currently working on, just what he would like to do. Most of us following this thread have been waiting over 2 years for just a decoder, and you are complaining that it has been a month! Thats just rude.

EDIT: you didn't even say please.
EDIT: ok, now you have

One month from last reply and i make my question.

I've forget that.

I've figured out the collision mask structure. Included is a color coded collision mask imported from the first area of Abe's Exoddus. It includes 2 grids, one that splits it to screens and one that splits it to steps. The colors should be pretty obvious, except for the red zones, which probably deal with shadows. Red shadows have 4 more parameters which are ignored in the renderer, which probably explains it.

It should be noted that the game does not use pixels, but it uses units which are defined by:

Each screen (640x240 or 640x480, depends on how you look at it) is 375x260 units big. (Note the fact that 375x260 is not in a 4:3 ratio!). The X positions are in a grid of 25, i.e. every step of Abe or anyone else is exactly 25 units. The collision mask included is in the ratio of 1 unit - 1 pixel.

Very, very interesting. Was this map automatically generated, and if so, how did you do it?

It took me a while to get my bearings, so I'll be point out that the very first screen is two from the bottom and three from the left, with the white lines being foreground floors. Everything makes sense from that, although what's the difference between purple and orange lines? I can see that one is usually on the left and the other usually on the right, but since neither is penetrable from either direction, is there a difference, or is it a distinction you've made for clarity?

What's the big blue square? As it's a shadow in-game, shouldn't it be red?

And perhaps most importantly, if you can now interpret all this information from level files, can you edit it successfully? ;)

Both Red and Cyan are both shadows, red have more parameters though. Purple and orange lines are just as you said, and it's coded in game. It's important for the Sligs' bullet-on-wall graphics.

The map was only half-automatically generated, as I haven't created a reader for the BND format used for paths (And animations, it's some format of an uncompressed zip file)

Editing the information is very easy actually, the format is very easy to understand, other than the red shadows. :)

Very awesome :D Do you know how the grid structure works? This is one thing I don't know anything about other than the 25 pixel grid? And that the gird in no way matches the actual pixels on screen.

The psx game has a lower resolution of 384x240 or something, perhaps its based on that and just scaled up for the pc version?

Did you find this into in the path, or in the copied parts of the path that are in the game saves? Very interesting stuff :)

Also there won't be another decoder version for a while, if you look at open source alive engine thread im doing some stuff related to that first, plus I dont have tons of free time these days :(

I never knew the save file had parts of the path file! :O Where is it stored exactly?

The format goes like that:
In the path file. There's the obvious array of screens (Nulls and MIP**C**s).
Right after that comes another array which represents the collision mask.
Each item is 20 bytes big and represents a rectangle:

short x1
short y1
short x2
short y2
short type (The color used in the rendered image)
short[5] unknown (unknown, probably used for shadows. The first 4 are usually FFFF)

I'm not sure how the list is delimited yet.

Not sure exactly where it is, but I'm very sure it just dumps part of the memory as the save file which contains the part of the loaded path.

Maybe if you search for your slig id's or whatever if in the right path file you'll find part of the file is that is almost exactly like the save file. It won't be exactly the same cause it changes some bytes to mark it as "loaded" and whatever else it might do.

How do you know where the array of screens end? I found this offset is hard coded into the game exe for every path :( So I guess you just manually look for it?

I manually looked for it, however, even if the address is hard coded, once you find the array of screen the end is easy to find. Just loop the array until you reach a value that isn't null or in the pattern [A-Z][A-Z]P[0-9][0-9]C[0-9][0-9]. Dirty and slightly risky, but should work. :)

Did you happen to notice if the AO screen have the same collision format?

Haven't tried it, but it shouldn't be different. If any change, it'll the shadows.

Hmm not looked at AE, but in AO it appears to look like this:


4508
3B01
030B
3B01
0000
0000
FFFF
FFFF
FFFF
FFFF

========

F709
D600
010B
D600
0000
0000
FFFF
FFFF
FFFF
FFFF

So the second byte appears to be a counter or Id for the platform / collision item? I'm wondering if there is a magic type of collision item that tells you which group of items are for which given screen? Every screen has an Id in the file that it could be linked to..

No, there are no IDs as there are some big zones which take more than one screen.
There are no counters in AE as far as I know.
Where are the screen IDs stored though?

In the cam files

We have just enough information about the path format to add, replace, remove and modify any object. :)
Mudokon, you're mine! Literally! :)

What are the blue lines? Is it to do with a location where Abe must roll?

Right walls for the background layer ("small" layer).
Must roll is yellow.

Edit: Btw, has Paul made an Exoddus bmp to cam converter already?

Another fine creation. I call it Mine Hell. All mines have different patterns. :)
I had to give up some of the objects in the screen such as the LCD and the alerts, and some objects that are responsible for syncing with the Sligs on the other screens (Entering this screen will reset the Sligs to their default position - Sleeping), but that's only because I didn't want to extract the .lvl and .bnd files and recombine them, which I have to do when resizing.

The structure for mine btw is:

Mine:
short magic;
short size=0x1C00;
long id=0x19000000
//x%25=0 so it fits on the grid.
short x;
short y;
//Not sure what are these and what they do exactly, but they should be x+24 and y+24.
short x2=x+24;
short y2=y+24;
//Apparently there are quite a lot of patterns!
short pattern;
short unknown;
short unknown;
//0 is active, anything else is not.
short state;

Hmm, if you guys have successfully been able to (and are on almost on the verge of) create(ing) a level editor, do you think you might be able to move on to (maybe) upgrading the resolutions of the games?
We've all seen how good those preview shots were for AO and AE before they were required to bring them down immensely,
and if you could bring the Resolutions up from 375x260 (<< right?), I can honestly see a full fledged Homemade remake of the original two games :D
I'd bet both of you would get snatched up by OddMob or JAW in a heartbeat :D ^_^

1. The resolution is 640*240, not 375*260. 375*260 is a screen size in game units.
2. The high quality images are fakes made by Oddworld for an unknown reason, they never existed in game.
3. It's impossible to upgrade the resolution without completely recreating the games.
4. Even if it was technically possible, we don't have the source high quality graphics to do it,

Isn't the odd 375x260 resolution caused by fact, that Abe/Somebody can go sometimes a little bit outside the screen without background change? The outside area needs paths as well...

Is this possible???
http://img822.imageshack.us/img822/387/dln.png

Does the MineCar have its own collision paths?

I quite like that Mine Hell scenario LIJI - it's a nice demonstration!

Not unless whoever's already inside that minecart gets out so Abe can use it.

Holy testicles it's Kaizo Abe :D xD

Yes, with a few exceptions:
Mine cars might be possible to add, but they're not likely to be compatible with just any layout.
I'm not entirely sure how well Scrabs and Paramites will interact with each other. They would probably ignore each other, or worse - crash.

Ive thought of a way to get around the hard coded offsets problem, each index can point to data *after* the end of the file. Then you can add as much new data as you like! The only thing that might be fixed is the collision data. I'm going to start working on an editor so its easy to try these things out.

The structure of the screen array is also a bit problematic- the width of the path (in screens) is not constant.

I was thinking maybe that is found by finding the max width of all of the collision items, left most and right most / screen size in units = number on screens on X?

Edit: And of course same for Y, then fill in the screens from the array? I'm pretty sure this works for R1 of rupture farms, maybe this how its done for all of them apart from the menu screen which have no collision items?