Reverse engineering of Wipeout

[Xpand]

For the correct bounce you can just invert the velocity component along the triangle's normal (you need to project your velocity vector onto the triangle's normal) (the triangle where the ship hit the ground).


In terms of projection, if "a" is your velocity vector and "b" your triangle normal, "a1" will be the velocity component along the triangle normal.

However, to simplify things you can just do what you're doing by just using the vertical component of your velocity (y in your case). Although in steep hills the ship will behave a bit odd.

You do like: velocity=-velocity*damp_factor. The damp factor is a number between 0 and 1, it defines the bounciness of the ship when it hits. A damp factor of 1 means the ship will bounce back up with the same velocity it hit the ground, 0 means it won't bounce, it'll just hit and stay there.

If you chooe to go with the projection method you then have to "move back" and rebuild the velocity vector with the new inverted component, you can do that by adding the modified component "a1" to the other component "a2".

[aybe]

Excellent, going to study that thoroughly

Thanks

[aybe]

Hi guys ! It's been a while ... I haven't abandoned the project and plan to get back to work on it ASAP

How are you guys doing ? Xpand did you get your exam/graduation ?

Last status was :



Basically the constraint needs to be wrote again as for the life of me I've never figured out why when switching from Trigger to Collider makes the ship invariably pitch up ... and surprisingly the old hover method is unaffected.

My plan:

- get this fixed
- get some AI and weapons up
- then the rest

[tigrou]

@Aybe : it's better each iteration, although it does not really feel like the real game.

Have you considered asking help to a professional game developer ? I'm pretty sure the physics as it is now does not need a lot to become really good.
I would like to help but physics is not my cup of tea.

Or, you can put physics on aside and spent time on the rest (adding scene objects, skybox, weapons, ...)

This should not be too hard since all of this has already been documented and I'm confident it should not be a problem for you.

[aybe]

Hi !

It is pretty close to the original feeling, look at how the ship behaves when jumping a section; it's pretty much the same . Remember, it's the 2 months old vid. here, so without any fixes such as collisions and fine tuning the constraint. I think it's the the right design (constraint on top) but it needs to be fine tuned quite a bit.

Regarding pro help I know nobody in the game industry for asking ... I guess I found the best out of web resources, best tips coming from this forum in fact . I've started working back on the project so expect cool news over the next 2 weeks, hopefully. Now I'm helping out bigsnake on Ballistic NG, an input manager that'll end on mine as well and looking to share my ship loading facility as per his request. I might very well get some help from him later at some point ! (haven't heard from BeRo (supraleiter) for quite a while btw)

What I'd like is to nail this thing down to the best I can, then proceed to AI/enemies (I do have the full track scene + skybox btw). I takes quite a bit to get back on feet when you haven't worked on the thing for 2 months, slowly getting back to it by helping BNG through the input mapper and code sharing is a good thing IMO. (what you're seeing consists of nearly +300 classes , it's definitely gonna take me a few days to be comfortable again with the code base )

[Cipher]

Have you tried setting hard caps on the pitch calculator? if(m_Pitch < PI_DIV8 && m_Pitch > -PI_DIV { *pitch code here*}
Because honestly, you could never pitch that high even if you wanted to, nor that low, π divided by 8 might still be too much in fact the calculations should probably be based on last known collision normal as well so you don't have that weird angle with the track at certain parts

Unless that's what you meant with "constraint on top"

And hehe, i know what you mean with coming back to old code, it's always a "scratch your head"- kinda moment xD
Good luck!! Looks good though

Cipher

[aybe]

Actually I have an 'angle' caps but it's pretty high for the sake of testing

I found it quite pleasant while playing even if it's a bit excessive; the real problem I do have in fact is that all this tightly intertwined : pitch, constraint, collision. Pitch is influenced by the old hover code as well as the constraint, but the former one does not play nice at all when enabling colliders for collision (which is the next route as basically I can't get a reliable homemade collision detection (Unity's one always works no matter the speed)).

So it needs a complete rewrite for which I'll have to split myself in two for it as there are multiple and interdependent parts to rewrite (still scared a bit by it to be honest )

And by constraint I mean that : http://www.wipeoutzone.com/forum/sho...479#post244479 this is how I'm keeping the ship in place. On the next video, I'll enable gizmos and you'll get a pretty good picture of how that (magic) constraint works (thanks to BeRo) with all the debug geometry.

Thanks

[Cipher]

I understand the constraint on top now and it's an interesting approach i must admit ^^

I think you should go with raycasting for manually overriding unity's collision with your current purpose, as it relies on just vectors and matrices which are exactly what you're dealing with
Do you want me to shoot you over 2 documents on collision in games and their formulas? (they're a bit schematically represented, but i think they should be readable if you have enough math knowledge)

I'm actually surprised you have no troubles with the default unity collisions, back when our team made a unity platformer we encountered a couple of bugs in unity itself (with collision), we mailed them about it and they confirmed it saying they would patch it, but we couldn't wait for that because of our deadline and had to write our own collision (they did eventually patch it though XD)

Cipher

[aybe]

Well, anything that can be helpful is really welcome ! So yes, feel free to post them

For the homemade collision detection, the problem I have is that at (even not so) high speeds, the ship passes through the track. Now there's a thing I haven't yet tried but others suggested : to put a thick and invisible floor under the track to alleviate that problem. Up to now my philosophy is as follows : to try as much as possible to use OOB features of Unity and if only really needed work out my own.

Regarding your collision issue, from memory I haven't used 'defaults' as they are not foolproof. Rather I've used this suggestion and it made things inpenetrable. Also it's very possible that I've already benefited of that bug fix since I did it relatively recently ...

[Cipher]

Check your PMs

There's 2 ways to solve collision problems due to update interval, 1 is to thicken the collision walls, the other is to increase the physics update interval (you can do that in unity as well) and well, there's kind of another way, which is to separate collision from physics, but that's rarely done
And yes, the problem had to do with RigidBody collisions IIRC, it's been a while ^^

Cipher

[aybe]

Very cool, going to try digest these very interesting docs

Thanks

[aybe]

Hi! Here are the latest discoveries from game files

3453c1a0-859a-11e5-820a-c64a5f72eef0.jpg

5b2259d2-8841-11e5-97d3-aa2f187bcb3b.png

eca6a21c-882f-11e5-9664-5e73e0c19353.png

ade9366c-88ab-11e5-9d80-6d57debe5d32.png

about a dozen new polygons have been discovered, more details here:

https://github.com/phoboslab/wipeout/issues/21
https://github.com/phoboslab/wipeout/issues/23
https://github.com/phoboslab/wipeout/issues/24
https://github.com/phoboslab/wipeout/issues/25

do you guys know where in the game the 3rd model can be seen ?

[Xpand]

What do you mean by camera paths? Is it the animation of the rescue drones around the track, or the game's camera motion, because I'm pretty sure the game camera's motion is calculated in real time.

[vincoof]

I don’t remember if WO1 used those, but sometimes you have a camera lurking around the map before the race starts. Had I to guess, I’d say the camera path is meant for this. It’s been a long time tho (20 years more or less :p) so I may imagine things.

[bigsnake]

I wonder if those paths are even used at all, like Xpand said the camera for chasing the ship is most likely calculated at runtime.

WO1 doesn't have an overview camera for the tracks, the game dumps you straight into the very start of the race. Maybe that was to be a feature though. Aybe, have you tried rendering the path with the track? Maybe that will help make what they are used for more apparent.

[aybe]

Hi !

Sorry for the late reply, been pretty busy and forgot actually.

For the paths there's a strong possibility these are the roads the rescue ships are wandering in, we'll know for sure once they're rendered !

Other than that ...

I advanced somewhat on WXX-Rebirth (though not as much as I wanted). I should soon be done with that level editor and after that, scenes should magically appear: tracks with animated scenery/billboards, illuminated objects in the various menus etc ... Basically it's a custom editor window in Unity where I build scenes, add behaviors and so on, then the resulting content is produced as an XML file that gets consumed by the game



It seems that we have reached the point where all of the game models are readable by now, since every PRM asset used in the game are now loading and rendering properly, including previously undecipherable models such as classes logos. Discovered nearly a dozen new polygons -> https://github.com/phoboslab/wipeout/issues/25 (the colors are indeed correct, shots are too bright because Unity lighting is enabled)

I also made significant progress on the installer part which will not only install the game but also pre-process many things such as videos, audio files, and billboards which by now has become mandatory and couldn't be done entirely in Unity as invoking some external libs somehow randomly crashes/hangs it.

Actually I've been pretty busy with reading files directly from the CDROM actually, including special files in a XA Mode2 Form2 (videos).

C++ has now joined the party since a couple of libs are only available in this language and I do not wish nor have the time to re-invent the wheel using C#

In short, the final form of the game will be really user-friendly : insert your Wipeout CDs and wait for installation and voila !

Sooner or later I will ask the mods whether I can open a dedicated thread for WXX-Rebirth

( and I'll try to post regular updates by then )

[wirehang]

Awesome work! Found my old login just so I could to say that

[aybe]

Thanks

[Varsh]

This is amazing stuff! All of the programming discussion has gone right over my head. :

Are you going to be continuing this? It would be interesting to try out completely different tracks with your physics.

[aybe]

I am actively working on it, right now

Your suggestion is something that I do have on schedule, though it's not likely to happen soon. Currently the game strictly works against Wipeout and Wipeout XL file formats (which are identical), but since I do plan to attack Wipeout 3 file formats once I'm done; the representation of a track/scene will have to become generic which in turn will allow to throw any valid level at it. This is not really difficult per se but not a priority for now.

And while I'm on it, here's a quick update of what's been done since my last post:

The reading of the CDROM content, (lost an arm in the process btw )

I was previously using 'libcdio' which is a well known library but simply couldn't afford it anymore : lots of time wasted in the C++ to C# bridge along all its peculiarities.

So I've just decided to do everything by myself, which means :

• talking directly to a CDROM drive using IOCTL and SCSI MMC commands (this method will always work as previous method would work only against real drives, not Daemon Tools and such which I heavily use and guess many users do as well)
• implementation of the CD-ROM XA and ISO9660 standards, i.e. getting from the bits in a CDROM to concrete files : regular files as well XA files (MDEC movies)

Needless to say that it was painful to go through the standards ECMA 119/130 and SCSI MMC-3, nearly 1000 pages but it's finally here ! I'm about to be finished as I'm in the polishing phase.

Right after that I'll resume the work on the level editor and after that the next update you should get from me will be a video showing every levels of the game with all the features (animated scenery, billboards, lighting etc ...) I am really eager to work on this part as that low-level CD stuff was painful though it's quite interesting. Truth is I really want to put the emphasis on 'easy access' as I said before: run the installer, insert your Wipeout CD and press Next, wait a few seconds and you are ready to get your Wipeout fix !

I started that project in April 2015, we are now reaching 8 months of work, I expect this to not last longer than 12 months, or 1 year if you prefer (hopefully) => should be ready for spring season

EDIT

Bit of clarification, while some might underestimate this part, it actually became a necessity over time. While the reading of regular files from a CDROM as well as CDDA tracks is easily done, it is not the case for XA files as Windows will grant you with an Incorrect Function error. Also, there are certainly differences between editions of Wipeout in regards to the layout of files/tracks, but this won't be a problem with the current approach. Note that as I'm not that 'sadomasochist', the actual decoding part of MDEC movies to a format usable with Unity will be done with two great pieces of software: jPSXdec and FFmpeg, the interpretation/transformation alone of an MDEC movie to Ogg Theora video from scratch would have taken centuries ...