@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 : 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 ?
Last edited by tigrou; 20th May 2015 at 10:28 AM.
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 :
Else load them individually.Code:library.cmp library.ttf scene.cmp scene.prm sky.cmp sky.prm track.trf track.trs track.trv track.vew
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
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 ?
Last edited by tigrou; 20th May 2015 at 08:02 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 :
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.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
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)
FYI here is the lua script I use with psxjin r726 good luck!
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.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
most stuff has been discovered by playing with emulator and RAM.
Last edited by tigrou; 20th May 2015 at 10:38 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 !
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
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 :
These positions in the CHK are already 255 ... I'll continue digging on this and see if I do any progress.Code:qmemcpy(a1, v7, 0x24u); for ( i = 0; i < 6; ++i ) *((_BYTE *)a1 + 6 * i + 4) = -1;
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 :
It looks like we have sort of patternCode:05001E00 FFF78B001400 FF3AFFFF0A00 FF7FFFFF0A00 FF00FFFF0A00 FF00FFFF0A00 FFC6
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
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 !?
Last edited by aybe; 21st May 2015 at 10:04 PM.
Reordering data is always dangerous.
IMHO this:
should be viewed as:Code:05001E00 FFF78B001400 FF3AFFFF0A00 FF7FFFFF0A00 FF00FFFF0A00 FF00FFFF0A00 FFC6
my2cCode:05001E00FFF7 8B001400FF3A FFFF0A00FF7F FFFF0A00FF00 FFFF0A00FF00 FFFF0A00FFC6
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
Last edited by aybe; 22nd May 2015 at 12:54 PM.
Yep, probably.But I won't spend any more time on this , there are more important things IMO
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?
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 !
@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.
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.
Last edited by Xpand; 23rd May 2015 at 02:14 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.
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.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 ...
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.
Last edited by tigrou; 23rd May 2015 at 05:28 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