Reverse engineering of Wipeout

[aybe]

I am opening this new thread to keep things separated from Reverse engineering of Wipeout 3 SE.

After successfully drawing textured models:

snap0829.png

I found that there's at least 2 new types of polygons : 0x14 and 0x16

But there's also what seems to be a wrongly interpreted header since there are others that have outstanding values.

(been working on COMMON folder)

I'll be back once I made some progress !

[Jonny]

"Antique Repro"
XD

[aybe]

"Antique Repro"
XD

@all

I will only post here stuff of interests, such as models and so on, for those fond of tech details I am reporting them here https://github.com/phoboslab/wipeout/issues as it's probably a better place.

[tigrou]

Hi there,

I’m trying to understand the TRS/VEW files format used in original Wipeout/WipeoutXL game.
I was wondering if somebody could give me some help (aybe maybe?).

Most parts of TRS are now well understood. However the occlusion culling part is still a total mystery.

Here is the content of TRS file. Only what is still unknown is the middle part ("unknown" variables).

They are all, i think, related to occlusion culling or additional track information.

Wipeout.TrackSection = Struct.create(
	Struct.int32('nextJunction'),
	Struct.int32('previous'),
	Struct.int32('next'),
	Struct.int32('positionx'),
	Struct.int32('positiony'),
	Struct.int32('positionz'),

        Struct.uint16('unknown1'), //always = 8?
        Struct.skip(10), //always = 0 padding ?
        Struct.array('unknown2', Struct.uint32(), 15), //PSX RAM addresses to VEW file loaded in memory?
        Struct.array('unknown3', Struct.uint16(), 15), //always values like 2, 4, 6, 8. VEW file data offset/length ? 

	Struct.array('unknown4', Struct.uint16(), 2),  //section indexes or scene objects (PRM) indexes, or offsets inside VEW file ? seems to start near zero then keep increasing
        Struct.array('unknown5', Struct.uint32(), 1),  //always = 0 padding?
        Struct.array('unknown6', Struct.uint16(), 2),  //very similar to "unknown4"
        Struct.int32('unknown7'), //always = 0 padding ?


	Struct.uint16('firstFace'),
	Struct.uint16('numFaces'),
	Struct.int16('unknown8'), //always = -1?
        Struct.int16('unknown9'), //always = -1?
	Struct.uint16('flags'),
	Struct.skip(4) //always = 0 padding?
);

To debug/use it just copy that section into wipeout.js of Phoboslab model viewer.

The VEW file seems to be simpler structure, I think contains only a bunch of indexes, all unsigned 16bit.
Probably indexes to sections or PRM scene objects ? (view lists?)

So it should be something like this :

Wipeout.TrackView = Struct.create(
	Struct.uint16('unknown') //indexes to track section/PRM objects?
);

Also: there seems to have some reference to "track radius" and "east/south/west/north view lists" on game CD.

Here is a short passage from BETA.OUT file (from TRACK02 folder)

Starting track radius pre process

Section 0 :: north 32 south 10 west 32 east 41 all 41
Section 1 :: north 34 south 10 west 32 east 43 all 43
Section 2 :: north 35 south 10 west 32 east 44 all 44
Section 3 :: north 37 south 10 west 32 east 46 all 46
Section 4 :: north 38 south 11 west 33 east 48 all 48
Section 5 :: north 39 south 12 west 34 east 50 all 50
…

Again, some related stuff found in WIPEOUT.EXE file (left by compiler) :

radius.c::TrackRadiusCheckNew: Global View List Full ( North )
radius.c::TrackRadiusCheckNew: Global View List Full ( South )
radius.c::TrackRadiusCheckNew: Global View List Full ( West )
radius.c::TrackRadiusCheckNew: Global View List Full ( East )

Track radius is, I think some information related to how large a given track section is (how far the track extends sideways).

Any help will be appreciated.

[aybe]

Hi!

Yesterday I've been trying to look at it, the best pattern coming seems to be a 84 bytes length:

snap0848.png

However there seems to be variable-length structs as the picture above is skewed at times ... Next thing I did is to disasm Wipeout 2 for PC and found this:

snap0849.png

So that's what they call a view list, hintful but not so helpful ... I've found the sections were they load vertices and so on and I think I've seen were they unpack each of the component (4), for the VEW however there seems to be many more things being read but since I don't know ASM ... Also I've found they use the CDQ mnemonic (http://faydoc.tripod.com/cpu/cdq.htm) so there might be real numbers in there.

There is another problem, recent Windows version, if someone could find a way to run WOXL on it, at least we could use a debugger and step through, I'm pretty sure with a memory viewer we could find how the values are being decoded. I've been trying this http://www.wipeoutzone.com/forum/sho...layer-tutorial, the game goes black screen then I do get couldn't initialize the desired resolution. This game is from the DirectX 3 era , consequently they rarely work like many pre-DirectX 7 games on newer PCs. Unfortunately there isn't much to be done as the best emulator for these versions do not work on Windows (WineD3D), go figure ! However the game will run fine under Wine in Linux. On a Win98 PCEM virtual machine, the game will load but PCEM will crash ... (unimplemented opcode or whatever). There is another hope : VirtualBOX which uses WineD3D for acceleration, needs to be tested though.

I still do have my P200 + 3DFX where I used to play it, but the problem is rather is a software one, can we find a convenient debugger for Win98 ? BTW, I've used IDA. Otherwise have you tried no$psx ? It might help though it lacks many of the facilities IDA provides and targets MIPS instead of x86.

Other than that don't you think we can do without it as we already have the essentials bits (TRF,TRV,TRS) ? I mean regarding culling and so on, we don't necessarily need to understand the VEW.

PS: beside this failed attempt, I wrote a WAD unpacker to see whether the files in the PC version were identical to the PSX one and they are. So whatever progress you'll make through the PC version will apply to the PSX game data.

[aybe]

Some (not so good) news about the VEW format

I've disassembled the code with IDA and CodeExplorer and here's where a VEW is parsed,

struct s0 {
    signed char[6] pad6;
    int16_t f6;
};

/* zFOPEN? */
int32_t zFOPEN_(int32_t a1, int32_t a2, int32_t a3);

int32_t ga2afa4 = -1;

struct s1 {
    signed char[8] pad8;
    int32_t f8;
    signed char[8] pad20;
    void* f20;
    int32_t f24;
};

struct s1* ga25644 = (struct s1*)0xffffffff;

void zFATAL_ERROR(int32_t a1, ...);

void sub_411A1E(struct s0* a1, int32_t a2, signed char a3);

void sub_401980(int32_t a1, signed char a2);

void zTRACK_VEW(struct s0* a1) {
    uint48_t v1;
    uint56_t v2;
    int32_t edi3;
    int32_t eax4;
    int32_t eip5;
    signed char v6;
    int16_t v7;
    int32_t edx8;
    int32_t eax9;
    signed char v10;
    void* v11;
    int32_t v12;
    int16_t v13;
    int16_t v14;
    int32_t v15;
    int32_t v16;
    int32_t v17;
    int32_t v18;
    int32_t eax19;

    *(struct s0**)&v1 = a1;
    *(int32_t*)&v2 = *(int32_t*)((int32_t)*(struct s0**)&v1 + (*(struct s0**)&v1)->f6 * 4 + 8);
    eax4 = zFOPEN_(ga2afa4, *(int32_t*)&v2 + 32, edi3);
    ga25644->f24 = eax4;
    if (ga25644->f24 == 0) {
        zFATAL_ERROR("Track.c:InitViewList: Failed to allocate memory for view list", "Track.c:InitViewList: Failed to allocate memory for view list");
    }
    *(int32_t*)((int32_t)&v2 + 3) = eip5;
    sub_411A1E(*(struct s0**)&v1, ga25644->f24, v6);
    v7 = 0;
    while (*(int32_t*)&v2 - edx8 >> 1 > (int32_t)v7) {
        eax9 = (int32_t)v7;
        sub_401980(eax9 + eax9 + ga25644->f24, v10);
        v7 = (int16_t)(v7 + 1);
    }
    v11 = ga25644->f20;
    v12 = 0;
    v13 = 0;
    while (ga25644->f8 > (int32_t)v13) {
        v14 = 0;
        while ((int32_t)v14 < 3) {
            *(int32_t*)((int32_t)v11 + v14 * 4 + 36) = ga25644->f24 + v12 * 2;
            v15 = v12 + *(int16_t*)((int32_t)v11 + v14 * 2 + 96);
            *(int32_t*)((int32_t)v11 + v14 * 4 + 48) = ga25644->f24 + v15 * 2;
            v16 = v15 + *(int16_t*)((int32_t)v11 + v14 * 2 + 0x66);
            *(int32_t*)((int32_t)v11 + v14 * 4 + 60) = ga25644->f24 + v16 * 2;
            v17 = v16 + *(int16_t*)((int32_t)v11 + v14 * 2 + 0x6c);
            *(int32_t*)((int32_t)v11 + v14 * 4 + 72) = ga25644->f24 + v17 * 2;
            v18 = v17 + *(int16_t*)((int32_t)v11 + v14 * 2 + 0x72);
            *(int32_t*)((int32_t)v11 + v14 * 4 + 84) = ga25644->f24 + v18 * 2;
            v12 = v18 + *(int16_t*)((int32_t)v11 + v14 * 2 + 0x78);
            v14 = (int16_t)(v14 + 1);
        }
        v11 = (void*)((int32_t)v11 + 0x9c);
        v13 = (int16_t)(v13 + 1);
    }
    eax19 = v12;
    if (eax19 + eax19 != *(int32_t*)&v2) {
        zFATAL_ERROR("track.c::InitViewList():problem with view list", "track.c::InitViewList():problem with view list");
    }
    return;
}

It does really strange things, reads an offset then somewhere else in the file and so on, doesn't make much sense to me. Also the code does check for invalid data and will fail it finds some. Seems to emit a 16 bytes structs (s1) by reading 5 items ... Note that there also VEWs not only for tracks but also for objects. Could this be the path points of the camera when it is rendered ???

I've been able to run WOXL with the latest dgVoodoo2 in Win8.1 However it will crash as soon as Alt-Tab is invoked so debugging is impossible... the other good news is that it runs fine in the latest VirtualBox though it is way too fast. One should try remote debugging that VM with IDA.

The content of a VEW seems to be unsigned integers (indices ?), but for what ?

I've also tried to figure out the texturing issue in Gare d'Europa but all my tests failed ... there is clearly something that is being done we're not aware of, maybe the TTF is misleading after all. There also the TRACK.TEX file which I've tried to grab things from, but there are outstanding values beyond texture count. Basically on the track there are 0xD textures, most of the bytes are in this range but rendering doesn't get any better. Also tried to use the unknown bytes from each face...

EDIT: also, it seems that files inside TRACK.WAD are being used for WOXL, so maybe other files are misleading

EDIT: I've debugged WOXL through VirtualBox, and it works quite well though an exception happens and you must pass it to the game and it will continue.

And that's what I said, this thing reads somewhere with an offset, and write somewhere else with an offset, I couldn't understand any of what it was doing/writing

[tigrou]

@aybe :

about WOXL gare d'europa and Spliskinanke texture issue : this has been fixed since a long time, see https://github.com/phoboslab/wipeout/pull/16

about your VEW disassembly : thanks for this, this is quite helpful. Anyway i'm doing some good progress with understanding VEW files, something might come in days to come. Stay tuned !

[aybe]

I should have read better your commits, thanks, going to give it a try right now

I'm pretty close to get my whole thing as featured as the WebGL experiment, got track/scene/texturing up, need to merge all this and I guess I'll be done

It was not as straight-forward as I thought (especially implementing your booster animations), but it ended up well, basically I wrote a scene along meshes/material just like THREE does; it is clean IMO and both things are independent. Then I will use BEPU for the physics as it looks great and is the only viable/recent option BTW.

Once I'm happy with the results, I will look at the next 2 things, the ability of picking scene elements and get the real data from game files so hopefully RE-ing will progress. My first target would be to get these billboards animations working.

---

For IDA, I'll go and have another look, basically I ran through all flavors of Wipeout : 1/XL, demo/retail. There are two things of interest I've seen and will try to get and share : there are 4 variable names for the TRS in the strings, the length and the count of the VEW file. Hopefully these will help ! Interestingly, the DOS code produced is more pleasant to read but it cannot be debugged ...

Also I've been trying to get the game running and made good progress, beside running it in VirtualBox : I've got the 2 demos running every time in Win8.1 without any funny stuff, thanks to the latest dgVoodoo. There are 2 issues now, game runs too fast and if you Alt-Tab it will crash. Other than that it works really well see @ Running Wipeout 2097/XL in Windows 8.1

Next objective is to get the retail games running as they are behaving different, working on it

---

Can't wait to see progress you're talking about !

---

EDIT: just got retail ver working (see thread above for instructions), it does not crash anymore when using Alt-Tab, the mouse is hidden though ... we might eventually get debugging running on the same OS

[aybe]

---

EDIT 2

I've been debugging a bit

The instructions that I've put for running it in Win8.1 are pretty good as I've debugged locally

Not sure but the exception that sometimes occur may come from dgVoodoo (unimplemented opcode), it occurs less often whenever I navigate with the gamepad...

Anyway, I've got a log being output from the game the whenever it loads a track :

CDMusicStop
CDMusicStop
-Loop number-  3
Mem load       35
Total phys     -1
Avail phys     -1
Total pagefile -1
Avail pagefile -1
Total virtual  2147352576
Avail virtual  1884729344
d:\Wipeout 2097\track08\track.wad
Track load start
d:\Wipeout 2097\track08\tracktex.cmp
attempting malloc
Track load finish
searching for pit lane
creating new instance of light beam 
trying to alloc mem for particles
init particle table
init particle done
doing init explode
init explode done
terminated controlled sounds
start controlled sound
Playing track = 10

So it seems like all we'll ever need to use is in the WAD (basically FYI I've checked a WAD content, it is identical to other files; maybe all these files are simply misleading after all...)

Here's the content of one, haven't checked them but I'd guess they're all similar ...

library.cmp   
library.ttf   
scene.cmp     
scene.prm     
sky.cmp       
sky.prm       
track.trf     
track.trs     
track.trv     
track.vew

The format of the WAD is really simple if you'd want to base yourself on it in the experiment :

Roughly, the name of each item is variable, you have to adjust accordingly, then the next 2 values should be packed/unpacked length -> I assert these are equals; finally extract each item.

        private static void Unpack(Options options)
        {
            using (var stream = File.OpenRead(options.InputFile))
            using (var reader = new BinaryReader(stream))
            {
                // read header
                var itemCount = reader.ReadUInt16LE();
                var items = new List<Tuple<string, uint, uint>>();
                for (var i = 0; i < itemCount; i++)
                {
                    var name = reader.ReadStringAsciiNullTerminated();
                    stream.Position += 16 - name.Length - 1;
                    var length1 = reader.ReadUInt32LE();
                    var length2 = reader.ReadUInt32LE();
                    stream.Position += 1;
                    items.Add(new Tuple<string, uint, uint>(name, length1, length2));
                }


                // check data
                var all = items.All(s => s.Item3 == s.Item2);
                if (!all)
                {
                    throw new InvalidDataException("Compressed items not supported");
                }

                var sum = items.Sum(s => s.Item2);
                if (sum > stream.Length - stream.Position)
                {
                    throw new InvalidDataException("Not enough bytes left");
                }

                // extract
                var outputDirectory = options.OutputDirectory;
                if (string.IsNullOrEmpty(outputDirectory))
                {
                    outputDirectory = Environment.CurrentDirectory;
                }

                var directoryInfo = new DirectoryInfo(outputDirectory);
                if (!directoryInfo.Exists)
                {
                    directoryInfo.Create();
                }

                foreach (var item in items)
                {
                    var itemName = item.Item1;
                    var itemLength = item.Item2;
                    var itemBytes = reader.ReadBytes((int) itemLength);
                    var itemPath = Path.Combine(directoryInfo.FullName, itemName);
                    File.WriteAllBytes(itemPath, itemBytes);
                }
            }
        }

If by some magic we could lower the frame rate and play it ... actually I'm as impressed as I was 15 years ago when I used to play it with a 3dfx, it is so smooth and 480p compared to the PSX

[tigrou]

Hi there,

I had a look at VEW files and get it working : see my commit https://github.com/tigrouind/wipeout...vew/wipeout.js

Thanks for aybe disassembly, this was VERY useful to get it working.

Notes :
- This is not very efficient way to perform culling on today GPUs: the whole track (without objects around) is about 3000-5000 faces (triangles) which is nothing. This is maybe even slower than no culling at all (because we send new polygons to GPU every frame). A better way (if needed, eg : on low end hardware) would be to cut the track in big pieces, and the perform some frustum culling on it. This is something already implement by threejs (all objects are frustum culled by default), only needed is to cut the track in separate objects.
- VEW files are only used for the track culling , not for other objects around (eg :train, bridge, trees, ...). For these ones another info (inside PRM file) is probably used. I suspect PRM file to contains some sort of bounding spheres/ boxes , organised as a tree (sort of bounding volume hierarchy).

About VEW files (how it works) :

For each track section, there 15 lists defined.

	north	south	west	east	all
near	x	x	x	x	x
medium	x	x	x	x	x
far	x	x	x	x	x

- north, south, east, west lists : used for default game play, when camera is behind player. depending how player is oriented with the track, one list is selected. default is north list, when riding reverse, south is used.
- all list : a combination of the 4 lists above. this is used for replays, for cameras around the track

near, medium, far : used for mip mapping. for far sections, low quality texture are used.

Each list contains visible track segments (so for a given section , the renderer only renders visible track segments).

One example : player is in section 47, riding forward (not reverse)
for section 47, in north near list, we have two segments : [400,4] [420,2]

So we will render sections 400,401,402,403,420,421

[aybe]

Congratulations, you've nailed it

It's incredible how info. can be hidden on the web yet it's just next to us, (haven't thoroughly checked that repo but I guess it's been helpful to you). I did try to IDA the Amiga version as someone shared it with me, but since it showed only dozen of subs I concluded it was not correct and stopped looking at it. I did look at Demo 1 about a week ago but I wasn't on that IDA thing yet.

One of the thing I found really immersive when I first seen the experiment was the drawing distance, but while seeing your branch I have to say that it's nice as well though as you've laid is not essential. Now we know what VEW is about we can always do it properly later.

What is bugging me is whether we'll be able to find all those scenery animations, I don't know if you've paid attention but actually there's a lot, from the rescue ship to those cameras following you etc ... it popped in front of my eyes with the PC version as while the PSX ver. is great, on the PC it's way more detailed.

Which leads me to this, I finally have a working WOXL with the right speed on Win8.1 + dgVoodoo and there's even 1024*768 basically those patches were around for a while but there's no real clear help for recent Windows; I will inspect better and update a definitive tutorial !

Otherwise I've found the definitive type of polygons : 23
It's kinda hard to interpret those disasms, sometimes they're correct sometimes not, for instance some of types we already render do heavily use maths as you'll see in IDA, we can get a general overview however.

I'll probably spend a last day with IDA then I'll stop because while it's fun, it's really exhaustive and haven't really progressed on the C# side.

PS just PM-d you right now.

[aybe]

Hi !

While started implementing your work and looking for the sizeof(TRS), a GREP search outputted the following:

TOTAL:    29 matches in 29 files  (119 other files without matches are not listed)
...
1 match in C:\Users\Aybe\Documents\Visual Studio 2013\Projects\WXX-Rebirth\.gamedata\WIPEOUT\TRACK14\TRACK.INF
       9  sizeof( Section ) = 156 bytes
1 match in C:\Users\Aybe\Documents\Visual Studio 2013\Projects\WXX-Rebirth\.gamedata\WIPEOUT\TRACK15\TRACK.INF
       9  sizeof( Section ) = 48 bytes // <-------------------- this one
1 match in C:\Users\Aybe\Documents\Visual Studio 2013\Projects\WXX-Rebirth\.gamedata\WIPEOUT2\TRACK01\TRACK.INF
       9  sizeof( Section ) = 156 bytes
...

(they're all 156 bytes as you know)

The TRACK.INF:

TRACK INFO::
============
dbName = /disk2/wipeout/SOFT/TESTS5
sceneName = V3track_A-Lsave.1-0
outName = trak1
total vertex count = 1710
total polygon count = 1378
sizeof( Face ) = 20 bytes
sizeof( Section ) = 48 bytes

I remember seeing this and I've extracted the TRV of it :

snap0862.png

EDIT 1: while plot.ly is cool, I was skeptical of the output and decided to feed my points renderer, makes more sense now !

snap0864.png snap0863.png snap0865.png

EDIT 2: It does look like Terramax but when looking at it from bottom :

snap0866.png

Here's the track gone through my 'official' renderer
(the textures might be okay as I haven't yet implemented the fix you've told for Gare d'Europa)
snap0868.png snap0867.png

Looks like we have another unfinished track but in WO1 this time ! strange

Do you have any infos about it or did I miss something (again) from the repository ?

Thanks

[Xpand]

That's Terramax
http://wipeout.wikia.com/wiki/Terramax

it looks slightly different in yours due to perspective distortion.

[tigrou]

@aybe : interesting finding. looks like a beta track of terramax that was left out.

It feel like the CD content of wipeout is actually a full copy of dev working folder, and they then manually deleted what they don't want to show (eg : source files and such), leaving many stuff there by mistake (eg: in wipeout2 TRACK02, there is a LIBRARY.H file). Also, if you look at PS1 DEMO01 CD, in wipeout folder there is even icons of the track editor they used (as CMP file if I remember well).

About your previous comment, where you mention "scenery animations" : they where probably hardcoded in the exe based on model name (found in PRM file).

Most are too specific to be specified in data files (eg : cameras must look at player, some other object must rotate around Y axis and such...). That would explain all those string references to these models found in EXE file.

There is anyway maybe some generic stuff (eg : texture that must rotate for ads panels near tracks ) that we missed out. There is still many unknown fields in PRM files to be discovered.

These could contains some of these animations.

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

EDIT : oops, i did not saw your thread, let's give it a try

about reversing engineering the game : i found some interesting part. This is the one that load the track sections.

int zLoadSections() //start at 0044D8F5
{
  int result; // eax@2
  __int16 j; // [sp+Ch] [bp-Ch]@3
  __int16 k; // [sp+Ch] [bp-Ch]@6
  __int16 i; // [sp+10h] [bp-8h]@1
  int v4; // [sp+14h] [bp-4h]@1

  v4 = *(word_A296D4 + 20);
  for ( i = 0; ; ++i )
  {
    result = word_A296D4;
    if ( *(word_A296D4 + 8) <= i )
      break;
    zReadInt32(v4);
    zReadInt32(v4 + 4);
    zReadInt32(v4 + 8);
    zReadInt32(v4 + 12);
    zReadInt32(v4 + 16);
    zReadInt32(v4 + 20);
    zReadInt16(v4 + 24);
    zReadInt16(v4 + 26);
    for ( j = 0; j < 3; ++j )
    {
      zReadInt16(v4 + 2 * j + 96);
      zReadInt16(v4 + 2 * j + 102);
      zReadInt16(v4 + 2 * j + 108);
      zReadInt16(v4 + 2 * j + 114);
      zReadInt16(v4 + 2 * j + 120);
    }
    //unknow data
    for ( k = 0; k < 4; ++k )
    {
      zReadInt16(v4 + 2 * k + 126);
      zReadInt16(v4 + 2 * k + 134);
    }
    zReadInt16(v4 + 142);
    zReadInt16(v4 + 144);
    zReadInt16(v4 + 146);
    zReadInt16(v4 + 148);
    zReadInt16(v4 + 150);
    zReadInt16(v4 + 152);
    v4 += 156;
  }
  return result;
}

it confirms what we already know about TRS. the part in bold (which is 4 times two 16 bits integers) is still mystery.

I tried to find reference to that special memory zone in code but did not found anything interesting.

Unfortunatly the game does not run on my machine (because 64 bit OS ?). I tried with the Wipeout2097 PC demo, the installer seems to be 16bit . The exe just hang out (i have to kill the process).

Would be it possible for you to game in an debugger (eg : ollydbg) and check which part of code read to this address (by putting a memory read breakpoint): *(0x00A296D4 + 20) + 126 ?

[aybe]

That's Terramax
http://wipeout.wikia.com/wiki/Terramax

it looks slightly different in yours due to perspective distortion.

yes but it is upside down, we'll get a better view once we render the associated scene

- - - Updated - - -

@tigrou:

Yes and I was hoping that there's a debug mode because there's a ptiDebug string but I don't think so -> it's been compiled as release mode and probably everything has been left out but the OutputDebugString calls that either Windgb or IDA will show (the log I've posted).

For the scenery and animations we'll probably know once we're comfortable enough with the code base, I can't remember but I did find some tiny file and rendered the vertices, it did look like a whirlpool but did not pay much attention then. Looking back this could have been the animation paths of some scene object. Also I really need to get this scene object picker/reporter up, as once we'll know what raw bytes makes a polygon and so on I'm certain we'll progress on these unknown fields.

I don't know what's going on up here, IDA does not work anymore on the VM apparently of this https://support.microsoft.com/en-us/kb/948854, did revert the snapshot but it didn't help ... the thing is locally I have no mouse so I can hardly use IDA. For this and ollydbg I am looking at it now ...

Also the tutorial I wrote seems to need an overhaul, I'll see if I can address that within the next days. Just tried again and it works here, remember to :

• copy CD to a dir
• in this dir copy setup32.exe and set Win95 compat, install, etc ...
• then edit the registry to point not to this folder but to your CD drive (note: it seems that a proper rip is needed with subchannels, as I've tried a bare ISO and it won't work)
• setup dgVooodoo
• then make sure Wipeout2.exe is run as admin but no Win95 compat

This is what works here so you should be in-game ...

Things are getting out of control but we are soon to get the control back

[Xpand]

yes but it is upside down, we'll get a better view once we render the associated scene

That might just mean the track is mirrored vertically. Have you decompiled any other track to see if that happens with every track? Because that type of thing happens a lot in other games too, including models rotated by 90 degrees in some axis.

[aybe]

Thus far it's the only folder that we missed, I haven't thoroughly looked at others but from what I remember in the experiment javascript I've seen nothing in the like, i.e. they're all the same.

Regarding mirroring (EDIT: was thinking of reverse in fact...) that's quite interesting, while trying to play the other way around I found that it is not possible in WO -> jumps. This would definitely be a nice perk in the remake, by now, modifying the track is clearly doable though it remains to be seen whether the UX will play fine.

- - - Updated - - -

@aybe : interesting finding. looks like a beta track of terramax that was left out.

....
Would be it possible for you to game in an debugger (eg : ollydbg) and check which part of code read to this address (by putting a memory read breakpoint): *(0x00A296D4 + 20) + 126 ?

I finally got hold of the issue : VC Redist 2008

This is what I found, it seems to be a byte it is checking for:

int sub_44AF32()
{
  int result; // eax@2
  __int16 i; // [sp+Ch] [bp-8h]@1
  int v2; // [sp+10h] [bp-4h]@1

  v2 = *(dword_A25644 + 20);
  for ( i = 0; ; ++i )
  {
    result = dword_A25644;
    if ( *(dword_A25644 + 8) <= i )
      break;
    *(v2 + 4) = *(dword_A25644 + 20) + 156 * *(v2 + 4);
    *(v2 + 8) = *(dword_A25644 + 20) + 156 * *(v2 + 8);
    if ( *v2 != -1 )
      *v2 = *(dword_A25644 + 20) + 156 * *v2;
    v2 += 156;
  }
  return result;
}

The addresses you gave were different btw, also I haven't really understood how ollydbg works ... when you press X on that dword, all the subs using do appear ... but their name is not evocative -> I suggest that we do get in synch by using the same environment. I think the VM way is the best since you don't lose mouse facilities. Going to prepare something and get in touch, not today though but sometimes this week. Also, I'll try to rename as much as possible so we get a good start with the IDB. There's only one thing not working in the VM, -> retail version complain there's no 3d card; i'll see if I can make it work.

[vincoof]

I’m pretty impressed by the RE you’ve done so far. Keep up the good work guys.

[aybe]

Thanks, support is really appreciated I'm sure we'll get to it

- - - Updated - - -

Slight update,

The TRACK15 will not load properly with the current code as its PRM has an older format ...

[aybe]

Hey,

I'm pretty close to the level of features of the experiment

snap0872.png