Reverse engineering of Wipeout

**tigrou** · 19th May 2015, 08:41 PM

@aybe : about previous post : not sure to understand what you mean

Also : WipeoutXL/2097 contains WAD files which in their turn seems to contain TRS/TRF/TRV files.

Are they exactly the same as the files contained in the folder themselves ?

**aybe** · 20th May 2015, 11:57 AM

Originally Posted by tigrou

@aybe : about previous post : not sure to understand what you mean

Also : WipeoutXL/2097 contains WAD files which in their turn seems to contain TRS/TRF/TRV files.

Are they exactly the same as the files contained in the folder themselves ?

Remember, I said I was after doing a remake of the first 2 games : https://github.com/aybe/WXX-Rebirth

So the rendering is okay though there are a few things I've encountered such as the need of writing my own renderer, just by the fact that transparent objects are not rendered correctly ... hopefully this is not too hard as I did peek into THREE.js and all that (seems to be) needed is the sorting of opaque/transparent entities.
This also raised two concerns, the ability to individually pick items to render which will be useful in RE-ing and the integration of a physics engine as the examples I've seen in BEPU do make use of their scene model but what if I stop using it mid-way ? Those should be separate.

WADs

I have implemented the following logic to blindly load a track either from WO1 or WOXL:

1. If there is TRACK.WAD in folder, load all the following files from it :

Code:

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

Else load them individually.

2. If TRACK.TEX is here, load it and patch TRACK.TRF with it.

That logic loads any track from any game ... So that's all that seems to be needed in WOXL : TRACK.WAD/TRACK.TEX.

BTW, the differences between WOXL PSX/PC is that for PC, textures are in TRACKTEX.CMP (library.cmp for PSX) and they are the 128*128 version so no need to make a collage. I've been trying to compare WADs using FC, there seems to be identical except that there's a few bytes offset ... TBC though. (Haven't tried to parse PC files in my classes, only PSX)

.CHK (checkpoint)

Confident enough I decided to give a try to the only remaining files on track folder in WOXLPC : CHKs

snap0876.png

I failed somehow, thought I would find a position in the track and tada but it wasn't that

Then I thought about your last performance

could these be PSX offsets ? Been trying to look for such code but I failed again, so when you have a minute or two

**tigrou** · 20th May 2015, 06:52 PM

about CHK files : it does not seems to be PSX ram addresses, since only addressable range is 0x00000000 - 0x001FFFFF (2MB)

Most of the time, 0x80 is added in front of them. Eg : 80 44 0B 1D (so PSX address is 0x001D0B44)

I think those checkpoints are either specify directly by section index (eg : check point is at track section 142). the other values would be lap times (depending the class).

or maybe they are defined using a sphere bounding box : sphere position (XYZ = 4 * 3 bytes) + radius (2 or 4 bytes?)

The time in this game is encoded this way : 9:59.9 = (9*600+59*10+9)*5 = 29995 (maximum possible remaining lap time)

Here is one thing you can try (it helped me in my previous searches) : you start a PSX emulator (eg : psxjin r726). Then you search for the content of CHK file in RAM (for TRS they were in memory just like on the filesystem so i just had to search some bytes pattern). You can use cheat search functionality for that or use a lua script (in case of psxjin). Be aware that the byte order can be different than files on CD (big vs little endian).

Then, once you find where the data is (in memory window), you modify it directly in RAM while the game is running and you check how it change the game (in case of checkpoint it could different remaining time for checkpoint OR modify checkpoint position.

You can also (as alternative) rip your game CD to an ISO file (if not already done

), then modify the ISO directly (open it in a hexadecimal editor and search for a given byte pattern and change it). This is, anyway, a slower iteration than changing in RAM

About WAD files : yep the way you did it is how it work for most game with containers (eg : doom). Anyway you did not answer my question : are the file in the WAD binary different from other files in track folder ?

About VEW files: i give it another try yesterday : there was a minor bug. now the track culling (using VEW files) works perfectly and exactly like on the PSX. Check this branch : https://github.com/tigrouind/wipeout/tree/culling_vew. VEW files have no more secret for me. Check my post from 16/05 on first page of this topic for more info (i edited it). What is still unknown is how culling is performed on scene objects. It seems the game performs culling per object polygon ! (instead of per object). Would this information be contained in the "unknown" fields of the many polygon types the game use ?

**aybe** · 20th May 2015, 08:00 PM

Thanks, I'll work further according your hints and see if I can get any result using a PSX debugger and the TRS as well

this is going to keep me busy for a while !

For the files in the WAD they are binary identical ... at first I was wrong and I did compare with the content of the WAD for the PC but we can draw extra conclusions from that :

Code:

 66,976 LIBRARY.CMP 
 76,636 library.cmp1
    504 LIBRARY.TTF 
    588 library.ttf1
 32,728 SCENE.CMP   
 55,438 scene.cmp1  
380,280 SCENE.PRM   
382,360 scene.prm1  
  9,648 sky.cmp1    
  1,488 SKY.PRM     
    624 sky.prm1    
 28,120 TRACK.TRF   
 37,240 track.trf1  
 50,076 TRACK.TRS   
 66,924 track.trs1  
 27,824 TRACK.TRV   
 36,912 track.trv1  
 29,196 TRACK.VEW   
 40,440 track.vew1

The files ending with 1 are from the WAD from the PC, looks like the geometry has been updated or something

What I'll do is that I'll integrate these PC files in my pipeline and see if I visually spot any differences and whether they first load without any hitch.

For the VEWs I can only admire the inside you've had with it, I'm quite left out with this hacking/asm part as it's an entirely new topic to me, so well done

Actually I did notice this morning that the zeppelin in Gare d'Europa is affected by the culling as well ...

FWIW here's the data of it I've quickly extracted :

Code:

index1: 0x2452
unknown1: 0x27
unknown2: 0x0000, 0x0000, 0x0000, 0x0000, 0x1c0c, 0x0000, 0x0000
unknown3: 0x1c2c, 0x0000, 0x0000, 0x0fb5, 0xa230, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000
unknown4: 0x0000, 0x0000, 0x0000, 0x0000, 0x1000, 0x0000, 0x0000, 0x0000, 0x1000, 0x0000, 0x0000, 0x0000, 0x1000, 0xae6e
unknown5: 0x1000, 0x0000, 0x0000, 0x0000, 0x1000, 0x0000, 0x0000, 0x0000, 0x1000, 0x5518
unknown6: 0x0001, 0x1c0c, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 0 (type: TexturedTrisFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 1 (type: TexturedTrisFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 2 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 3 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x1008	unknown2: 0x0090	polygon 4 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 5 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x9298, 0x0000	unknown2: 0x0000	polygon 6 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0003, 0x0000	unknown2: 0x0000	polygon 7 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 8 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x006b, 0x0000	unknown2: 0x0000	polygon 9 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0xaaa8, 0x1008	unknown2: 0xbbb4	polygon 10 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 11 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 12 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 13 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 14 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 15 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 16 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0001	polygon 17 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0006	polygon 18 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 19 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0xae80	polygon 20 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x1008	unknown2: 0xe220	polygon 21 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0xa230, 0x0000	unknown2: 0xae80	polygon 22 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 23 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 24 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 25 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 26 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x1008	unknown2: 0x0090	polygon 27 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 28 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 29 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0006, 0x0000	unknown2: 0x0000	polygon 30 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 31 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x006b, 0x0000	unknown2: 0x0000	polygon 32 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0xab28, 0x1008	unknown2: 0xbbb4	polygon 33 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 34 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 35 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 36 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 37 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 38 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x00e1, 0x0000	unknown2: 0x0000	polygon 39 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0001	polygon 40 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0005	polygon 41 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 42 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0xae80	polygon 43 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x1008	unknown2: 0xe250	polygon 44 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0xa2f0, 0x0000	unknown2: 0xae80	polygon 45 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 46 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 47 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 48 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 49 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x1008	unknown2: 0x0090	polygon 50 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 51 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 52 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0005, 0x0000	unknown2: 0x0000	polygon 53 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 54 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x006b, 0x0000	unknown2: 0x0000	polygon 55 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0xaba8, 0x1008	unknown2: 0xbbb4	polygon 56 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0xafe8, 0x0000	unknown2: 0x0000	polygon 57 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 58 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 59 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 60 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0xb0c0, 0x0000	unknown2: 0x0000	polygon 61 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 62 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0001	polygon 63 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0006	polygon 64 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 65 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0xae80	polygon 66 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x1008	unknown2: 0xe280	polygon 67 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0xa3b0, 0x0000	unknown2: 0xae80	polygon 68 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 69 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 70 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 71 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 72 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x1008	unknown2: 0x0090	polygon 73 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 74 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 75 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0006	unknown2: 0x0000	polygon 76 (type: TexturedTrisFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x00ea	polygon 77 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0xae80, 0x0001	unknown2: 0xbf20	polygon 78 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0xe298, 0x1008	unknown2: 0xac58	polygon 79 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0xae80, 0x0000	unknown2: 0x0000	polygon 80 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0001	unknown2: 0x0000	polygon 81 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 82 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 83 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0001	unknown2: 0x0000	polygon 84 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0090, 0x0000	unknown2: 0x0000	polygon 85 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 86 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 87 (type: TexturedTrisFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 88 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 89 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0xac88	polygon 90 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0xac98, 0x31d3	unknown2: 0x0000	polygon 91 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 92 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 93 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 94 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 95 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0xae80	polygon 96 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 97 (type: TexturedTrisFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 98 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0001	unknown2: 0x0005	polygon 99 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 100 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0xae80	polygon 101 (type: TexturedTrisFaceColor, subtype: 1)
unknown1: 0x0000, 0x1008	unknown2: 0xaca8	polygon 102 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x1008, 0xa4d0	unknown2: 0x00f0	polygon 103 (type: TexturedTrisFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 104 (type: TexturedTrisFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 105 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 106 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 107 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 108 (type: TexturedTrisFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 109 (type: TexturedTrisFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 110 (type: TexturedTrisFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 111 (type: TexturedTrisFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 112 (type: TexturedTrisFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 113 (type: TexturedTrisFaceColor, subtype: 1)
unknown1: 0x006b, 0x0000	unknown2: 0x0000	polygon 114 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0xacf8, 0x1008	unknown2: 0xbbb5	polygon 115 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 116 (type: TexturedTrisFaceColor, subtype: 1)
unknown1: 0x0000, 0x0001	unknown2: 0x0000	polygon 117 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 118 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 119 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0001	unknown2: 0x0000	polygon 120 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0090, 0x0001	unknown2: 0x0000	polygon 121 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 122 (type: TexturedTrisFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 123 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 124 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 125 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0xad58	polygon 126 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0xad68, 0x31d3	unknown2: 0x0000	polygon 127 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 128 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 129 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0x0000, 0x0000	unknown2: 0x0000	polygon 130 (type: TexturedQuadFaceColor, subtype: 1)
unknown1: 0xd060, 0x0000	unknown2: 0x0000	polygon 131 (type: TexturedQuadFaceColor, subtype: 1)

**tigrou** · 20th May 2015, 09:29 PM

FYI here is the lua script I use with psxjin r726

good luck!

Code:

--search whole PSX memory range (change 4 to 1 if pattern is not 32bit aligned)
for readposition = 0x00000000, 0x001fffff, 4 do
	--search for a pattern (be careful of big/little endianess)
	if (memory.readdwordunsigned(readposition) == 0xff1d10aa) then
		print(string.format("%08x",  readposition))
		
	end
end

one more thing : the ASM decompile from PC version (using IDA) was (for me) a big waste of time. the only useful part what the disassembly you posted some days ago. the rest i could not make anything useful with it.

most stuff has been discovered by playing with emulator and RAM.

**aybe** · 20th May 2015, 10:37 PM

Thanks, I'll give it a try !

- - - Updated - - -

Ok for IDA, well the thing is that the environment is great but I reckon it might be overkill

Have you done anything particular with psxjin ? here it runs like the PC version does at 200 fps, no matter which setting I try I can't get normal speed !

**tigrou** · 20th May 2015, 10:51 PM

Yes the emulator is full of bugs. Except things like sound or video that disappear after alt-tab, freezes or crashes.

I was never able to fix the "too fast fps" (there is an option for that in video settings but it just dont work).

I have this piece of code (from some psxjin experiments

) that should more or less fix it (big hack!)

Code:

--framerate lock
framecount = 0
starttime = os.clock()

while true do
	
	--lock framerate at 30 fps
	elapsed = os.clock() - starttime

	while elapsed < framecount / 30 do
		elapsed = os.clock() - starttime
	end
	
	framecount = framecount + 1
	
	emu.frameadvance()
end

**aybe** · 21st May 2015, 11:35 AM

Alright, thanks, I'll see if I can make it thru. I've tried again yesterday and I got sound, it's too bad because that LUA facility is really a good thing.

Desperate I've been looking at IDA and continued the renaming of subs ...

The code does funny things like :

Code:

  qmemcpy(a1, v7, 0x24u);
  for ( i = 0; i < 6; ++i )
    *((_BYTE *)a1 + 6 * i + 4) = -1;

These positions in the CHK are already 255 ... I'll continue digging on this and see if I do any progress.

**tigrou** · 21st May 2015, 06:36 PM

From code you gave it looks like data is 6 bytes length, starting at offset +4

so if we took check point data you posted in screenshot and align it that way :

Code:

05001E00
FFF78B001400
FF3AFFFF0A00
FF7FFFFF0A00
FF00FFFF0A00
FF00FFFF0A00
FFC6

It looks like we have sort of pattern

could the last part be actually a piece to add to the first part ? (to be checked)

so it becomes :

Code:

FFC605001E00
FFF78B001400
FF3AFFFF0A00
FF7FFFFF0A00
FF00FFFF0A00
FF00FFFF0A00

**aybe** · 21st May 2015, 08:12 PM

From what I could see, there are 6 entries in a CHK each being 6 bytes and they are UINT16. But their value is quite puzzling ...

Other than I've been trying to slow down WOXLPC but I can't get anything that lasts ... I think I've found where the time calculation is being done but I don't really understand how it works.

snap0880.jpg

Tried to change these bit-shifts and modulo but it works for a small amount of time.

Crossing fingers that it's a standard update() loop as we know it by today

I will continue the renaming of subs, I have done a couple already and this will grow over time.

Also, I think I've found a struct for some unknown parts of a TRS but it's too early IMO, however, can you confirm that a TRS.FirstFace is never greater than 65535 ? I think so as regarding the models size this should be enough. If it is then we have a refined struct.

EDIT been writing while you've been !

sorry but I don't understand what you mean regarding the CHK, can you elaborate a bit ?

EDIT1

for the code I've put, I've tried locally with a small program and it seems to do nothing as it sets bytes in the CHK that are already 0xFF ... haven't checked with all CHKs though.

EDIT 2
Ok I got it, actually I've seen that pattern you are talking about but I was not really convinced by it but maybe you're right after all !

I haven't yet tried to patch a CHK and see what it does, going to try ...

- - - Updated - - -

EDIT 3

I've made a simple test, replaced all the checkpoints by the latest and it seems that I do have less time to reach a checkpoint

EDIT 4

Byte 1 does nothing beside setting time to 20s
Byte 2 crashes if not 0

Next byte do change the seconds but it's erratic

Now the next 4 bytes at offset 2 do change the time indicator !

snap0881.png

Seems a bit more complex than expected

EDIT 5 and last

At byte 2, set the number of seconds desired minus 20 (UINT16LE), it will set the time when starting.

The other files and checkpoints don't do anything, I always get 40secs.

Not sure it is worth pursuing this thing, it's not essential after all !?

**vincoof** · 22nd May 2015, 07:19 AM

Reordering data is always dangerous.

IMHO this:

Code:

05001E00
FFF78B001400
FF3AFFFF0A00
FF7FFFFF0A00
FF00FFFF0A00
FF00FFFF0A00
FFC6

should be viewed as:

Code:

05001E00FFF7
8B001400FF3A
FFFF0A00FF7F
FFFF0A00FF00
FFFF0A00FF00
FFFF0A00FFC6

my2c

**aybe** · 22nd May 2015, 11:51 AM

Well, didn't want to revive this thing but you just gave me an idea :

Index1, Seconds - 20, Index2 (all UINT16BE but seconds) (Indices in TRS, when 0xFFFF ignore, makes sense to me as game crashes when it's wrong, access denied or so ?)

5 entries since max lap count is 5

4 files, one per class

But I won't spend any more time on this

, there are more important things IMO

**tigrou** · 22nd May 2015, 06:59 PM

But I won't spend any more time on this , there are more important things IMO

Yep, probably.

Anyway : did you noticed there is no checkpoint / startup objects in phoboslab model viewer ? (eg: near repair zone, there is a big white arrow on red background).

Same goes about red/amber/green lights at startup.

They are not rendered. Could it be explained because these are set dynamically by the game depending what is found in the checkpoints files?

**aybe** · 22nd May 2015, 08:27 PM

That's an interesting theory, I didn't notice.

snap0883.png

These bytes doesn't point to a decent index nor look like a light color, btw that's in light.prm that the model is.

Things are going to stall quite a bit here, have to advance on the game itself, there's enough material to keep one busy and build one. Have started looking for physics, a ground is a ground now !

snap0884.png

Still looking for a good arch. as there's the graphics but the physics as well and I need to come up with something easy to handle ...

We might discover new things over time but I expect the discovery rate to be pretty low though !

**Cipher** · 22nd May 2015, 08:54 PM

Originally Posted by tigrou

They are not rendered. Could it be explained because these are set dynamically by the game depending what is found in the checkpoints files?

This is most likely the case, from a game dev point of view it makes sense to load the object once into memory and place it multiple times, instead of wasting verts left and right by creating it into the track model

Great work in here!

Cipher

**tigrou** · 22nd May 2015, 11:38 PM

@aybe : what language are you using ? three.js ?

about physics: it seems this is what devs used to model the collisions of the ship against the track :

see ALCOL.PRM file.

It would be a lot easier if you use a physics engine that roll your own.
Unity might be a good candidate for this.

**Xpand** · 23rd May 2015, 11:06 AM

Those collision models make sense. That's the same technique I'm using in my AG physics engine (programmed in C, no 3rd party physics libraries).

I was thinking about importing WO1 models into it, when I get the basic physics stuff done, like detecting the ship's height above the track's surface, which I'm working on right now.

I would advise you to use unity too. It takes a huge load of programming mesh collision detection and other physics stuff, unless of course, you use a physics library, like Bullet Physics.

**aybe** · 23rd May 2015, 01:22 PM

@tigrou

I use C# and MonoGame.

Thanks this will be very useful ! Yesterday I was wondering on what to use and opted for a cone but this seems to be the thing to use ... once I figure out how to handle collisions according this shape. I opted to use BEPU for the physics, as this is the only recent and free engine I found that supports MonoGame as well.

I have been tempted to use Unity but there are 2 problems with it : the import of models, thought about using Autodesk FBX SDK to convert PRMs but another problem arises -> the game data is shipped by default and IMO this opens the door to those copyright infringement seekers ...

@all

I think BEPU has the potential to realize the physics of the game as it's quite featured, once I figure it out ! I will probably get good support as the author is really involved in helping people as you can see in their forum.

For BulletPhysics, unfortunately the only port for .NET I've found is bullet-xna but it seems unmaintained and I don't really know whether it will work with MonoGame.

I am open to any suggestion if you think there's a better route than the one I've said, Unity is very appealing but I've laid out the above 2 issues, let me know if I'm wrong !

Also, regarding physics, this is an entirely new topic to me and suggestions are welcome. My preliminary search about physics for a craft brought the usage of spring physics and/or a raycast stick below the ship ... I am not too worried for now by the exactitude of either approaches, my near future goal is to get physics and rendering in place and decoupled as much as possible. Once this foundation is in place and trustworthy, the refinement of the game will take place and eventually a physics engine change mid-way.

**tigrou** · 23rd May 2015, 04:02 PM

I have been tempted to use Unity but there are 2 problems with it : the import of models, thought about using Autodesk FBX SDK to convert PRMs but another problem arises -> the game data is shipped by default and IMO this opens the door to those copyright infringement seekers ...

Even if import of models is something supported by Unity (as well as asset management) i wouldn't do it that way but rather read the PRM files from the wipeout directory and build model directly at runtime (i have done this previously in Unity this is pretty easy). I would read the other files as well that way (sound, textures,...) . So you solve the 2 problems (copyright stuff) at once. You can take a look at phoboslab viewer code (how to build the models) because you will probably need something similar. The whole JS code to create models is about 70 lines, not a big deal.

Here is a good start for dynamic mesh generation : http://docs.unity3d.com/ScriptReference/Mesh.html

Also : i would not do all the fancy stuff at first (texures, sound, menus or whatever) but rather build a simple prototype with the bare minimum :

- the main track build from TRF/TRV files (no texture, no object around), just a single gray flat polygon stuff
- The ship (from the collision model i give you above)
- Some basic ship physics (collide with the track, push force from behind, accelerate, decelerate, steering, airbrakes)

Then try to get something that feel close to the original and publish for testing. Get feedback and improve until it is good enough. This is the real challenge. Gameplay is everything.

Then you have all the time necessary to add the rest (and get help from other devs because you have a "proof of concept").
That's probably how the first Wipeout game was done, they build a first prototype then tested it : "hey guys this is cool" then add some more graphics and all the rest to make it a real game.

**aybe** · 23rd May 2015, 08:34 PM

Sounds like a good idea but ... here's what happened here :

After getting hold of Visual Studio Tools for Unity and trying to debug the Roll-a-ball tutorial, a simple thing such as the game receiving input while VS has the focus didn't work. This resulting for instance in the inability to debug that PlayerController that moves the ball, as obviously I have to put a breakpoint in VS and the Unity Editor doesn't receive any input ... Also I did not find a single thing about using Unity by code, seems like I'm missing something !

Can you explain how to get started / how you would do it ? thanks

Thread: Reverse engineering of Wipeout

Thread Tools

Display

Posting Permissions