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?

Leftmost is irrelevant, the screens always start at 0,0, even if there's not CAM allocated for these. And sometimes the collision data overflows the actual size, and in other times there are some unallocated columns of screens in the end. It might be hard coded, but there might be some number that represents the width or height. I'll try to see if I can find something like that.

Edit: Using a tool I made to split and recombine BND files I've split MIPATH. It seems that the object array size cannot be changed. I believe we're missing something between the collision mask array to the object array. Also, after the object array come 440 bytes of data. I have no clue what they do, but it seems essential, despite being mostly FFs.

Edit 2: Thanks to the knowledge of the games mechanics I've learned, I've found a funny bug! In the first level of AE, go to the second screen, say "Hello, fellow me" to the Mudokon, and move the the next screen (down). Continue in the usual path until you get to the "Hop" sign. Stand by it for a minute or two. Then, continue to the next screen (up). The Mudokon should be in the right side of the road blocker now. :)

http://img59.imageshack.us/img59/641/abe.png - It works, now I can't beat the game :D
Let me guess, the game doesn't recognise road blocker as an obstacle when its not on part of level you're in, is that right?

Actually, the road blocker doesn't exist before Abe visits its screen, so the Mudokon doesn't "know" it's there, so it simply walks through it. When Abe visits the screen, it's already loaded, so even if he leaves the screen, the Mudokon can't pass through it now.

Oh, that explains why I can't make him go back... well, saving Muds from SoulStorm Brewery is now up to him...

The data you speak of is the array of offsets, this is what is hard coded into the game and why you think it can't be changed. What you need to do is put the new data *after* the index array and make the index array point to this data and it works.

You've got me confused, what is that Index Array you're talking about? :P

An array of ints that tells you where the object list starts for each screen

Oh, I get it now! Thanks!
Edit: Notice how the index array has indexes for some screens without CAM files. These are used for pitfalls. There's a pitfall object that handles this. (Forgot its ID, but I've checked it, it exists on "screens" below pitfalls, and also has X and Y values)
Edit 2: To demonstrate it, move left using DDCheat from MIP01C04.

From the collision data how did you figure out how many units one screen is? I don't see any platforms that take up only one screen, so I'm not sure how you know this?

I had to calculate it myself using information from ddcheat.

Edit:
Structure for LCD signs:
short magic;
short size=1C00;
long id=3C00 0000
short xStart; //Left
short yStart; //Top
short xEnd; //Right
short yEnd; //Bottom
short messageIDGreen; //0 to display only red (joke) messages
short unknown;
short messageIDRed; //0 to display only green (instruction) messages

Edit 2:

Portals:
short magic;
short size=2400;
long id=1C00 0000
//x%25=1
short x;
short y;
short x2=x+24;
short y2=y+24;
short direction;
short unknown;
short unknown;
short unknown;
short unknown;
short background;
short type; //0 is stay open, 1 is rescue, 2 is shrykull, everything else is glitchy (yet funny)
short shrykull; //number of muds for shrykull
short unknown; //these probably deal with stay open portals