Messages

Cas, I am sorry, but I completely disagree with your points. It would be a really big oversight if a variable (which keys are pressed down) which is used at least in two places (computing next position of a car and saving a replay string) could be modified in the middle of the process. If the variable is modified outside this critical section all is fine (because nothing is done at that portion of time). Furthermore your points do not explain discrepancy between fast-forwarding and playing a replay. But.. all of that text and Frieshansen's magic DOSBox behavior got me thinking..

And I did some testing. First of all, there is an sub-menu "Options" -> "Set graphic level" which contains some magic text and options I do not understand. I tried to play with them in the past - no change. But after reading last comments.. I did try to lower the DOSBox's CPU speed - to cycles=fixed 2500 (Stunts visibly stutters). Lo and behold - playing a replay with Play button (or Play Fast button) produces the same result as fast-forwarding!!! !!! !!! I was pleasantly surprised. Then I tried pretty high cycle speed (150000) so my machine does not catch up - same result as during normal speed - de-sync and crash. Then I tried to lower cycles gradually and the magic happens. And somewhere between 4000 and 5000 cycles there is a magic area where a replay plays "correctly" (that means does not crash) or fails depending on graphical settings. Higher graphical settings means a simulation is not catching up and is skipping some drawing routines - maybe. That draws me to a conclusion that when there is a pause between frames the Stunts' drawing routine somehow messes with "world's state (car rotation/car position/random number generator function/whatever)". Maybe it is enough that the drawing routine finishes once, maybe twice, maybe it corrupts the state after running 100 times (not to get into politics but also changing a government is considered a good thing).

These observations somehow fits into my imagination of what is/should be "a correct/valid replay". I am repeating myself - I think that only "weird/incorrect" behavior is produced by playing a replay with "Play" button (now I can add) with high-enough cycle speed, and that 1. driving a new drive 2. replaying a replay with fast-forward 3. playing a replay with Play button with low-enough cycle speed (4. repldump) produces the same result (and should be accepted as valid).

Btw - while testing I always rewinded/rewound my replay at around 1:33:10 - so I assume that there is no accumulative error from the beggining but rather the section from 1:38:00 to 1:46:10 produces something magical. Also - it is something very consistent/deterministic so I would assume that the drawing routing corruption is also pretty deterministic and we could spot it in the code/debugger.

My proposal is the simplest reliable validation procedure there is. It is done entirely in-game, and takes around 20 to 30 seconds per replay.

And I agree and fully support this if - if we can prove that it is the same thing as driving it from the menu or at least it is the most coherent thing in case that everything (a new drive, re-Playing a replay, fast-forwarding a replay, RH handling) behaves differently. But first I would like to know for sure/I would like to check the code.

Repldump still can be a valuable tool - similar to RPLInfo - verification before posting. In fact Repldump validation can be as a section in RPLInfo output (another feature request maybe? ).

New feature proposal - mark invalid replays as invalid and do not delete them.
New feature proposal - have a list of your own replays (maybe only for current race is enough) and have an ability to mark them as invalid (in case of uploading incomplete replay).
Wishful thinking - Q symbol in a yellow circle looks like Qualified mark in sports competition (track and field). Make it.. less evocative of that. Although I do not have any specific proposal what is less evocative.

Hm.. there is a good argument about what a person see at evaluation screen should be valid. Then again - if it is a result shown only on somebody's machine and not reproducible anywhere else - should it be valid? In very extreme case - after memory manipulation - it can end badly as a verification tool.
Because we do not know what is causing inconsistencies I would propose to have validation procedure as Overdrijf proposed - if replay finishes in any way successfully on (let's say) 3 independent machines (pipsqueaks from 3 different teams) it should be valid. And apply this only on questionable replays (someone brings that up let's say max. 3 days after race).

How often this thing happens? Once in a year/two years? Agreeing on a difficult validation process seems not worthy to me.

My problem with DOSBox is that it plays some replays differently on different computers despite having the same version and config. That's why it's out of the question for me for a predictable system.

I've never heard about this. Do you have such replay/config?

Firstly, the result of such a validator is not truer than the in-game experience of the pipsqueak: as per my argument above, the evaluation screen rules supreme, and the accuracy of a validator is a matter of how well it can reproduce it.

It is not any truer but from what I saw and it seems other experienced too it is not less useful than the in-game experience and having something independent seems like a step forward.

Secondly, to the best of my knowledge a repldump validator will give the same results as the streamlined verification procedure that I'm proposing.

I would love to be sure that this is true. That's why I would like to see/understand/debug code/program. I assume that when you start a new drive and start driving you get the same result as while RHing and replaying the file with fast-forwarding. I would like to have that confirmed.

Because of my assumption - I think that when you press Play when replaying there is something different going on than when you start driving from menu.

Daniel's comment about driving with opponents triggered a memory supporting my assumption - I think there were cases when re-Playing a replay (saving a replay, loading, rewinding to start and pressing Play) with opponent ended with a premature crashing. But I/we did not bother to rewind a little bit to see if it is "for real". Maybe that is another case where simply Playing a replay is something different than driving. And - I think that opponent's behavior is deterministic (as a developer you would want it to be deterministic when you have a replay system). Which is another thing which would be great to verify.

Entering movements (driving!) via keyboard, mouse, joystick or replay file appears to be equivalent. The fast-forward option used when loading a replay (without the lap actually appearing on screen) seems to handle things differently.

How do you know that the first sentence is true? That is what I am asking - there are two options - either driving the same inputs as in a replay produces output either 1. as during replay (load replay, rewind to beginning, press play) or 2. as during "fast-forwarding" (even with one-step/0.05s forwarding - load replay, rewind to beginning, press fast-forward for one frame, repeat pressing fast-forward for one frame until finish). The point of my question is that I would personally prefer if the final ruling on valid replays was based on (what would be the result of) inputs from replay driven during a new drive (because ultimately they were driven and input during racing). That would result in: if my 1. option is true then I would agree with current ruling, if my 2. option is true then I would agree with the new proposal (load replay+rewind 1.05s).

But for that I would like to know how engine works. Not only guessing. We as community have Stunts code reversed so I would assume that there are some folks who know answer for this question for sure/can debug code to prove either option. (And I would be glad to learn this magic so if you can teach me I am ready to listen. )

But we need a well-defined way to determine that.

I would say if the folks who know how Stunts code works answer than we would have pretty deterministic way. I have pretty strong feeling that if it is a rounding error/overflow this is either 100 percent reproducible on all machines (it is some kind of forgotten register which is not re-set in assembly when you press play instead of fast-forwarding) or 100 percent different on different real-life machines (I can only assume different execution of operations in a given processor/overflowing of registers on different systems) thus there is no "ultimate true system" (even with PCem) so we would end up with one arbitrary chosen and in that case I would choose DOSBox packed in official .zip file not because of accuracy but because of accessibility - even checking if a replay is valid on my computer was PITA - handling it via some API would be ridiculous for me.

... an issue that is (exclusively?) related to RH PG replays.

Maybe there are some high speed magic carpets which behaves differently?

It is option two.

Are you sure? How do you know? That would mean that current rule does not match "reality" - state that would be reached if "a replay would be driven".

But, when you are Replay handling you basically are constantly time traveling. So the game has to recalculate from the point you enter the timeline.

I was under impression that when you are doing RH the position is recomputed always from the beginning - at least when you rewind backwards (that's the reason why it is slower to rewind than to move forward).

That can produce a slight offset, that is different when replaying the replay.
That little difference can be the difference between finishing and crashing.

What exactly is producing a slight offset and a slight offset related to which other event?

I am sorry about asking so much but I would really like to understand different ways of simulation/how Stunts engine works.

So, I would like to repeat the question from ZakStunts's Shoutbox: If you would start a new drive and input exact same inputs as in a replay - do you think/know that result of that driving is such 1. exactly as it would play in a replay from beginning/2. exactly as last position of replay when loaded from a file?

For me the answer is a key for my stance of this topic. I would like to have a rule in accordance of what would happen if the input from a replay was driven during gameplay (and I silently hope it is the second option ).

Until the confirmation of what would happen I would like to relax the rule to Overdrijf's proposal - "counting any replay that can be played in any way as valid".

Very good track. Thanks for making it and thanks all of you who implemented what I imagine would be possible (namely 270 elevated road skip, banked road speed gains and corkscrew mid-panel jump).

MY winning time prediction: 1.55.XX with the GTO.

You heard it first! 

Here comes this month's teaser. (It is probably as useful as the MCLaren one from January  )

What is your winning prediction right now?

Minor addition: each car on the car coefficients page now links to the corresponding wiki page.

Thanks to @Friker for the suggestion!

Thank you very much for a very quick implementation. Actually, the information I was looking for on Wiki was how new cars behave at power gear speeds. To my surprise information about the category (one of Bug-free, Flexible PG, Rigid PG, Regular, Anti-PG) is not at the car's summary. I suppose I can add this information to Wiki by myself (if anyone else would do that I wouldn't mind) but - is there that information for new cars?

Ok, it does work (maybe it is faster). I did not know it is banned. I though it is a part of a desing (third equally quick path). Good thing is I asked about it.

I would be curious to see whether that route is faster indeed. 

Then do not ban it.

It's not my decision. I trust the judgement of dreadnaut and Duplode who have much more experience. Imagine, I would suggest not to ban it and it turned out to be 10 seconds faster! 

To be honest.. at least I wouldn't be driving a straight line most of the time. Unfortunately, this type of track is completely out of my possibilities (I like to spend the least amount of time to produce half-decent result).

Ok, it does work (maybe it is faster). I did not know it is banned. I though it is a part of a desing (third equally quick path). Good thing is I asked about it.

I would be curious to see whether that route is faster indeed. 

Then do not ban it.

Ok, it does work (maybe it is faster). I did not know it is banned. I though it is a part of a desing (third equally quick path). Good thing is I asked about it.

Why this "shortcut" does not work?

What would be benefit of scaling polygons in game over some of DosBox's scaler (normal2x, hq2x)? Since you are talking mainly about running Stunts in Dosbox it seems to me that DosBox's scaler is more than enough for Stunts' limitations.

Anyway - I looked at this topic because of collision part of a title. How is collision code related to graphics code? These occurs to me as a two different things clearly separated in code.