Trials: evolution. [xbla]
- Thread starter RobertR1
- Start date
Two new videos of the latest development build (cam at DigiExpo 2011):
Single player: http://www.youtube.com/watch?v=7ClrZ10ak8w&feature=player_embedded
Multiplayer: http://www.youtube.com/watch?v=2wzsdTkdDbI&feature=player_embedded
In the development build you can see yellow debug text at upper screen showing the CPU usage (for all six HW threads), GPU usage, frame statistics (fps, skipped frames, tearing, etc). And in the multiplayer there's a lot of extra network specific information shown (latencies, etc). The game manages constant 60 fps in most tracks, but there's still some optimizations left I am working on. It's 2 AM here, and I just got home from work... I just had to hunt down the last LHS (load hit store) stall in the visibility culler (added lots of new vector code to keep the data in VMX128 registers). We have fully dynamic visibility determination (for main camera, sunlight and all spot lights). Main camera also uses a hierarchal depth buffer (full pyramid down to 1x1) for dynamic occlusion culling. We generate the occlusion culler depth min/max pyramid from our low res virtual texture page request camera results (that renders ahead of time using predicted camera properties).
If you look closely at the single player footage, you can see the player missing a jump in the Suspense track. The player drops down a few kilometers to the ground. It's not a fake backdrop. In the editor you can fly freely around the 16 square kilometer world, and start building your own tracks where you like.
Single player: http://www.youtube.com/watch?v=7ClrZ10ak8w&feature=player_embedded
Multiplayer: http://www.youtube.com/watch?v=2wzsdTkdDbI&feature=player_embedded
In the development build you can see yellow debug text at upper screen showing the CPU usage (for all six HW threads), GPU usage, frame statistics (fps, skipped frames, tearing, etc). And in the multiplayer there's a lot of extra network specific information shown (latencies, etc). The game manages constant 60 fps in most tracks, but there's still some optimizations left I am working on. It's 2 AM here, and I just got home from work... I just had to hunt down the last LHS (load hit store) stall in the visibility culler (added lots of new vector code to keep the data in VMX128 registers). We have fully dynamic visibility determination (for main camera, sunlight and all spot lights). Main camera also uses a hierarchal depth buffer (full pyramid down to 1x1) for dynamic occlusion culling. We generate the occlusion culler depth min/max pyramid from our low res virtual texture page request camera results (that renders ahead of time using predicted camera properties).
If you look closely at the single player footage, you can see the player missing a jump in the Suspense track. The player drops down a few kilometers to the ground. It's not a fake backdrop. In the editor you can fly freely around the 16 square kilometer world, and start building your own tracks where you like.
Last edited by a moderator:
Awesome stuff. Can't wait.
If you look closely at the single player footage, you can see the player missing a jump in the Suspense track. The player drops down a few kilometers to the ground. It's not a fake backdrop. In the editor you can fly freely around the 16 square kilometer world, and start building your own tracks where you like. The curved path can be also made very long, so the track can circulate the world in any way you like. We even have one track so long that the sun goes gradually down during it
The multiplayer reminds me of Micro Machines v3, where if you dropped off the screen you lost a point. This is not a bad thing, as I loved that game to bits and is still one of my favorite couch multiplayer games of all-time.
For the single player, will you get proper servers this time for sharing and rating user made levels? Maybe this was mentioned already somewhere, but as the first game was a big success, I would think you'd get them this time around?
Yes, in the local multiplayer (four players on a single console + single TV screen) players do fail when they get dropped off screen. In online multiplayer the rules are pretty much similar to the normal single player game rules.
Yes, the game will feature "Track Central". Players can upload tracks there, download tracks, rate/search tracks, etc. All user created tracks also have online leaderboards. User created tracks can also be used in online multiplayer matches.
Sounds and looks awesome sebbbi. Any chance we can view friends' replays this time around (i.e. if they are mere mortals and not in the top 1000 or whatever )?
Very much looking forward to this.
)?Very much looking forward to this.
Trials HD has 2 million players, and 100 different track leaderboards (each player has score on each leaderboard). Lets assume the replay clip takes 2 KB to store. Multiply the values, and you get 400 terabytes of data (without counting backups or replication). With top 1000 on each track we get 1000 * 100 * 2000 KB = 200 megabytes. Much more manageable.Sounds and looks awesome sebbbi. Any chance we can view friends' replays this time around (i.e. if they are mere mortals and not in the top 1000 or whatever
Very much looking forward to this.
In Trials Evolution we encode approximate 3d path of all players directly in the leaderboard database rows (all the bits in leaderboard database row are used). The path is less than 100 bytes of data, but we crammed a compressed spline curve inside it (it took a while time to create the compression algorithm for that, but the results are pretty good). With the 3d spline data, we can visualize the 3d positions of all your friends while you are riding the tracks. So you can basically play against your friends "ghosts" any time you like (or select any players from the leaderboards to play against).
Last edited by a moderator:
Right yeah I'm not ignorant of the storage, but it's a pretty nice feature to have since while the top 1000 players are basically irrelevant to me, competing with my friends and watching their runs isn't
Thought experiment wise though, it seems like if you stored input (assuming the engine is deterministic, which I imagine it is) and compressed it with RLE/arithmetic/delta encoding, I could imagine getting the replays down to a pretty small size.
Thought experiment wise though, it seems like if you stored input (assuming the engine is deterministic, which I imagine it is) and compressed it with RLE/arithmetic/delta encoding, I could imagine getting the replays down to a pretty small size.
Yes... down to 2 KB. A run can last for 30 minutes (extreme tracks can be tough), and we have analog gas, brake and leaning (left/right). If we had just digital inputs and much shorter replays it could be possible to get the perfect (controller based) replays under 100 bytes.
But then there would be this another issue. Controller based replays are only good for replays, but not for ghost racing, since you have to wait for the game to simulate the ghost rider first (we do not have the memory or processing power to simulate two worlds at the same time). Waiting is always boring... especially if you have to wait for the game to simulate a 30 minute replay
[OFF TOPIC]
Spent three straight days optimizing our visibility culler... It's time to celebrate. First time in my life I see a thread that doesn't list cache miss as #1 penalty in profiler. Actually there's only two minor cache misses in the top 10 penalty list... and that thread goes though all our scene objects and visible octree nodes
Last edited by a moderator:
Hey Andrew, the last two lines of your post sound like a very graceful of a statement to me... not used to technical terms. When it comes to those matters I feel very intellectually introspective and I just have a really difficult time communicating what I would like to say, but it's always good to read and learn from others.Right yeah I'm not ignorant of the storage, but it's a pretty nice feature to have since while the top 1000 players are basically irrelevant to me, competing with my friends and watching their runs isn't
Thought experiment wise though, it seems like if you stored input (assuming the engine is deterministic, which I imagine it is) and compressed it with RLE/arithmetic/delta encoding, I could imagine getting the replays down to a pretty small size.
Regarding watching friends playing, YES PLEASE, I want that. Even so, just competing with my friends -watching their runs or not- was very fun.
At some point I gave up, the two friends who played the original Trials -both of whom I know in real life too- and am best friends with one of them IRL, were a lot better than me. They tried to encourage me to beat their times but my skills were limited, and my mind was in another place.
Currently only one of them has Forza 4, and Rivals mode is quite similar -however I wonder how does Turn 10 storage the replays now that I look at the humongous numbers sebbbi posted- but I think that there they can't get past me in FM4...
Maybe the way they are saving storage explains why some Ghosts in Rivals mode seem to do weird things, like going fast in some areas and then overly slow so suddenly. Perhaps I am wrong and those were the actual laps they did.
They must be compressing the data heavily. If you fit an approximate mathematical curve (spline) over the exact sampled position data, you will get some errors. But it's worth doing, since the uncompressed data could take over 100x more space.
From Xbox Live (UK) dashboard (captured by a fan):
http://vimeo.com/35248176
http://vimeo.com/35248176
Official YouTube version: http://youtu.be/EKjlFqwKaPE?hd=1 (seems to be only 30 fps. I wish we get some 60 fps vids online soon)
Last edited by a moderator:
Yes, we use conditional vsynch (or "swap-tear" as id Software seems to call it). If our engine detects a frame that takes longer than 16.6ms to render, we make sure the next rendered frame is cheaper (*) to compensate. This allows us to return to the tearless rendering as fast as possible. So I'd say 99.9% of the time we are fully v-synch locked 60 fps. If there's a big sudden performance drop (for example a huge particle effect crosses the camera) our new engine will tear for a few frames instead of slowing down to 30 fps (like Trials HD did). Consistent frame rate is very important for us.
(*) We can make single frame rendering cheaper for example by skipping virtual texture update or reusing our shadowmaps for slightly longer time. We also use other methods to reuse data.
