the worst level ever!!

the worst level ever!!

Postby sinisa3games » 09 Mar 2019, 10:16

this is the future of bad levels!!!
Attachments
level3.stl.zip
(1.78 KiB) Downloaded 58 times
'Ello
User avatar
sinisa3games
 
Posts: 116
Joined: 08 Feb 2018, 20:45
Location: Right over there

Re: the worst level ever!!

Postby manuel » 09 Mar 2019, 14:41

I request a checkpoint after each jump :lol:
manuel
 
Posts: 188
Joined: 19 Sep 2017, 09:03

Re: the worst level ever!!

Postby divVerent » 10 Mar 2019, 17:55

Gotta try it out soon, but it can't be the worst level ever if it does not somehow dump you on a previous checkpoint.
divVerent
 
Posts: 15
Joined: 03 Mar 2019, 02:22

Re: the worst level ever!!

Postby sinisa3games » 10 Mar 2019, 21:28

divVerent {l Wrote}:Gotta try it out soon, but it can't be the worst level ever if it does not somehow dump you on a previous checkpoint.


the thing is... there are ZERO checkpoints
'Ello
User avatar
sinisa3games
 
Posts: 116
Joined: 08 Feb 2018, 20:45
Location: Right over there

Re: the worst level ever!!

Postby divVerent » 11 Mar 2019, 01:06

Hehe, this is a level in style of hammy: https://supermariomakerbookmark.nintend ... e-selector

I have my doubts that you have ever cleared it from beginning to end (or you're REALLY good), but from looking through it in the editor it seems theoretically clearable.
divVerent
 
Posts: 15
Joined: 03 Mar 2019, 02:22

Re: the worst level ever!!

Postby sinisa3games » 11 Mar 2019, 15:58

i mean most of it isnt skill since you basically need luck to do the jumps
'Ello
User avatar
sinisa3games
 
Posts: 116
Joined: 08 Feb 2018, 20:45
Location: Right over there

Re: the worst level ever!!

Postby divVerent » 11 Mar 2019, 22:20

I am a bit unsure there. _I_ certainly couldn't ever beat it except with a lot of luck.

But with frame accurate timing all jumps should be possible. Something like TASBot should succeed reliably - if not, that is a bug in SuperTux that needs fixing, and this level would be a good test case ;)
divVerent
 
Posts: 15
Joined: 03 Mar 2019, 02:22

Re: the worst level ever!!

Postby sinisa3games » 13 Mar 2019, 19:07

there would be a really low chance for a bug, the jump really depends on how fast you are, how high you jump, etc... if there even would be a bug it would probably be an issue with the spike's hitbox
'Ello
User avatar
sinisa3games
 
Posts: 116
Joined: 08 Feb 2018, 20:45
Location: Right over there

Re: the worst level ever!!

Postby w_laenger » 13 Mar 2019, 19:32

There is no frame accurate timing in SuperTux. I removed it in favour of liquid camera movement: https://github.com/SuperTux/supertux/issues/910
w_laenger
 
Posts: 31
Joined: 20 Sep 2018, 15:58

Re: the worst level ever!!

Postby sinisa3games » 14 Mar 2019, 21:06

is this only in 0.6.0 or earlier?
'Ello
User avatar
sinisa3games
 
Posts: 116
Joined: 08 Feb 2018, 20:45
Location: Right over there

Re: the worst level ever!!

Postby divVerent » 15 Mar 2019, 04:26

Maybe should be changed "halfway back"... like some other games do, fixed fps game logic but variable fps display by either interpolating between two previous states (lag!) or extrapolating or simulating from latest state (tricky to implement).

Otherwise people like me could create a level that is only bearable at some fps numbers (or maybe only while the system is lagging). "Compile kernel to win".
divVerent
 
Posts: 15
Joined: 03 Mar 2019, 02:22

Re: the worst level ever!!

Postby w_laenger » 16 Mar 2019, 20:36

If the graphics were decoupled from the game logic, heavy collision calculations (or similar things) would no longer reduce the frame rate and the player input would be handled independently of graphics lag. It could be difficult to do a visual update if the same time gamelogic is updated at the same time (thread safety).
Before my changes, now and then a frame was skipped. This caused the player's keyboard input to be used for two frames I think.
w_laenger
 
Posts: 31
Joined: 20 Sep 2018, 15:58

Re: the worst level ever!!

Postby divVerent » 18 Mar 2019, 01:08

Yeah, I know doing such a change to an existing code basis will be rather hard - the absolute minimum would probably be finding a way to decouple rendering and game logic, which is half the work of making it an online multiplayer game.

Unless you go for this "lazy but hacky" approach: game objects have an associated RW mutex, and two operations on thier state:

- Think() (basically what we have right now): handles input, collision etc. and updates fields. Uses a write lock. Gets invoked at fixed fps.
- Predict() const (the new operation): takes input and time delta as an argument, and returns what would have happened with this input. Uses a read lock. Gets invoked once per render frame.

The main problem with this approach is that it introduces on average half a logic frame of input lag. And this simple lazy design does not handle interaction of objects with other objects correctly, so there will be mispredictions even in local games. Because of this, sounds cannot be safely sources from the prediction phase and this would lag behind a little as well.

The "proper" solution OTOH is more like splitting all objects up into their logic and rendering parts, and in regular fixed fps, run the game logic. Then you serialize that, and for display you work off the two last serialized game states and interpolate (like Quake style games do). Cost: lots of complexity AND 1.5 phyics frames of input lag. In SuperTux, it may be smarter to work off the last serialized game state together with its velocity and acceleration values, and extrapolate from there; however between two gameplay frames there will always be some small error, so we then may need one or two render frames to interpolate between old and new predicted state. Cost: similar complexity, but input lag should become more like 0.5 physics frames.

That, or do what the NES did: actually run at fixed fps... however that's simply unreliable on desktop machines (and be it just because we do not control display refresh rate), and the reason why SuperTux doesn't do that anymore is actually a good one.

So yeah, I see why it currently does what it does (and all possible fixes would be a huge overhaul) - at the same time I consider it a rather important bug that levels could be made that are only beatable at some refresh rates.

I should BTW add: QuakeWorld and successors (including e.g. Xonotic) have their own bug there too: they run fixed fps physics for objects, but variable fps physics for players to fight input lag and to enable smooth prediction on the client.

Of course this means that there are subtle differences in jump height and length depending on your system - which we have fought there in three ways:

- Avoid clearly fps-dependent math. E.g. friction should not be "velocity = velocity * (1 - frametime * factor)", but "velocity = velocity * exp(-frametime * factor)".
- Provide at least an option to run all physics at fixed fps, so players can test levels in a "reference" style setup.
- Still try to ensure a loosely fixed player physics fps by rate limiting the player physics updates to 60 Hz. So typically they will be rather close no matter how your GPU actually renders.
divVerent
 
Posts: 15
Joined: 03 Mar 2019, 02:22

Who is online

Users browsing this forum: No registered users and 1 guest