SFML Game Development by Example - 4th SFML book

[seyuup]

The first project (snake) uses a fixed timestep, unlike the last two that rely on a variable timestep. The first bouncing mushroom example actually wasn't capped or adjusted in any way, and was later used to underline the issue of different execution times between varying systems. It was then adjusted to use delta time in order to run at a constant speed near the end of Chapter 2, so if you noticed that behavior before, you were absolutely correct.

So, the platformer game and the RPG-styled game both run in variable timestep, correct? I ask because I'm currently trying to make a platformer game following your example. Could you explain your reason for using a variable timestep method for your platformer example over the other methods (fixed timestep, minimum timestep)?

[OrderNexus]

The first project (snake) uses a fixed timestep, unlike the last two that rely on a variable timestep. The first bouncing mushroom example actually wasn't capped or adjusted in any way, and was later used to underline the issue of different execution times between varying systems. It was then adjusted to use delta time in order to run at a constant speed near the end of Chapter 2, so if you noticed that behavior before, you were absolutely correct.

So, the platformer game and the RPG-styled game both run in variable timestep, correct? I ask because I'm currently trying to make a platformer game following your example. Could you explain your reason for using a variable timestep method for your platformer example over the other methods (fixed timestep, minimum timestep)?

Correct. The main reason behind using variable time-step is performance. Using a fixed time-step across multiple machines would produce different results. Variable time-step allows the simulation to remain the same, even if the application is running at a lower framerate.

[eXpl0it3r]

Using a fixed time-step across multiple machines would produce different results. Variable time-step allows the simulation to remain the same, even if the application is running at a lower framerate.

Then you misunderstood the concept, because it's the other way around. A fixed time step provides a consistent time frame for the simulation across any machine. If one machine has a weaker CPU the simulation will run the same, but the FPS might drop.

[OrderNexus]

Then you misunderstood the concept, because it's the other way around. A fixed time step provides a consistent time frame for the simulation across any machine. If one machine has a weaker CPU the simulation will run the same, but the FPS might drop.

What I meant was that FPS is directly tied to the simulation in a case of a variable time-step. If it goes down, the simulation will be advanced just that much more in between the frames, which would produce consistent results across different hardware. Depending on your fixed time-step implementation and setup, you may get slightly different results on different machines (ex. 2 updates per frame, then 3, then 2 again), assuming the frame time is still being accumulated and used to determine how many updates should take place in case of lag. I've also seen games that do not accumulate the frame-time at all, in which case the simulation is entirely dependent on the hardware it's being executed on.

While the variable time-step may not be ideal for physics simulations, it can keep the results slightly more consistent. That's not to say it doesn't have problems of its own, of course.

[Jesper Juhl]

Read this: Fix Your Timestep!

[OrderNexus]

Read this: Fix Your Timestep!

I have. Like I said, the results depend heavily on the implementation. It's a good resource to reference though

[Hapax]

Read this: Fix Your Timestep!

I have. Like I said, the results depend heavily on the implementation. It's a good resource to reference though

The "fixed time step" that people are (I hope) referring to is the one seen in the part of that article labelled "Free The Physics" (not "Fixed Delta Time"). This creates a time-step that is fixed and regular which effectively means that you always use the same time-step and the results are the same on all machines (and is identically repeatable).

[seyuup]

The "fixed time step" that people are (I hope) referring to is the one seen in the part of that article labelled "Free The Physics" (not "Fixed Delta Time"). This creates a time-step that is fixed and regular which effectively means that you always use the same time-step and the results are the same on all machines (and is identically repeatable).

Would this (fixed time step) not be the preferred method of choice for all applications? For a simple platformer game like Super Mario Bros. would this method be the ideal? I may be misunderstanding, as I am new to certain aspects of game development.

[Hapax]

The fixed time-step described in "Free The Physics" would indeed be ideal for all applications. It helps to secure the reliability of your logic and physics.
If you would like a small library to help with using this (or just to help visualise what's going on), feel free to have a look at my Timestep class in my Kairos timing library.

[nicox11]

Interesting book. It is good for theory that the last book didn't cover like the Entity Component System, the Event and Messages delivery between system and the network. But, the implementation is quite huge and really hard to follow, it would be much better focusing on detailed examples instead of a full compilable project (that's my opinion).

On the other hand, it seams less modern than the previous book, not always using modern feature (Still raw pointer, i don't really know why). For example the tilemapping system doesn't use vertex, but even the Laurent's tutorial demonstrate how to gain perfomance with it.

To conclude, it's for me a great book to go further after the previous one and try to elaborate greater architectures, but only try to follow the architecture instead of the code presented.

[seyuup]

Is there a reason why when falling vertically past the maximum map height, the map will be recreated (tiles will be placed) except for the leftmost tiles?

I assume it has to do with the tile map variable within the Map class.

I'm sorry if the description did not make sense. I'll try to provide pictures when I can.

[OrderNexus]

Is there a reason why when falling vertically past the maximum map height, the map will be recreated (tiles will be placed) except for the leftmost tiles?

I assume it has to do with the tile map variable within the Map class.

I'm sorry if the description did not make sense. I'll try to provide pictures when I can.

The player should die if they fall outside the boundaries of the map, and get respawned at the beginning shortly. The console will print out a message every time that happens. Assuming this check is taken out, the map being repeated would have to do with the way tile indexes are represented in the tile container.

[FloatPeasant]

is the ebook on packtpub different from the one on playstore?
on packtpub it says 44.98€ for the ebook and 44.99 for printed + ebook?
google play store basically has it for half the price.

[OrderNexus]

is the ebook on packtpub different from the one on playstore?
on packtpub it says 44.98€ for the ebook and 44.99 for printed + ebook?
google play store basically has it for half the price.

I don't think it is. Try switching the prices on packtpub to US dollars. For me, it currently states that the e-book is $39.99 and the print + ebook is $49.99. Either way, I highly doubt that any content would be stripped from the copy on playstore.

[FloatPeasant]

still says 49.98$ for just the ebook, on the other hand it would be pretty sweet to have a printed copy.