Yes, SDL and similar tools makes game developing easier, but I'm still too green for this and I just use basic Lazarus possibilities for games in first times.
You will always be ”to green” for this until you finally try — nobody was born with such knowledge and skill.
When I decided to make a game using SDL myself, I didn't really know how to use this library either. However, it is so easy to use that I had no problems programming other things. At most once in a while, by trial and error, I slowly came to a solution. I suggest not to waste your time on LCL to build games, because it is not suitable for creating games for many reasons, including the most important:
- no Direct3D and OpenGL support
- unable to use GPU for rendering textures
- no exclusive video mode support and available screen resolutions
- absolutely no support for sound mixer and playing multiple sounds at the same time
- lack of support for game controllers and their full functionality
- lack o V-Sync support
What I mentioned above are the basics, without which creating even a simple game will be inconvenient, the game itself will be very limited, and its performance will be very low (software rendering is horribly slow in compare to GPU rendering). As you can see, it doesn't make much sense.
Whether you want to make a tiny game or a bigger one, use the library dedicated to their creation. It does not have to be SDL, but it is important that it has all the functionality to create full-fledged video games. However, if you are interested in creating a 2D game, I strongly advise you not to use 3D engines for this purpose, because it will significantly complicate the implementation, and you will get discouraged very quickly.
Use something small, light, functional and, above all, supported at all times. I suggest SDL because it meets all the requirements and is great, but it can also be Allegro, because it's the same shelf. In case you ever get tempted by SDL and have questions, I will be happy to help. I've learned a lot over the last year so I'll be able to help a bit, especially when it comes to basic (key) issues.
Is there an optimal value to correct speed at all computers?
You have several solutions.
The first is to use delta to calculate motion using interpolation. Thanks to this, the game will run at the same speed on every computer, but the very big downside is that it will eat up all the available power of the CPU core. In the case of small games that do not have complicated logic and long-lasting frame rendering, this solution is weak.
The second way is a constant framerate and pauses between generating frames. The current time is taken, the frame is generated along with the rendering, and the time is retrieved again. Based on the two times, the number of milliseconds it took to generate the frame is calculated, the waiting time for the next frame is calculated and the function is called, which freezes the thread (
Windows.Sleep,
FPNanoSleep,
SDL_Delay, etc.). This allows you to easily handle logic (no delta), frames are generated at regular intervals, and the process only uses as much power as it needs. It is a simple, energy-saving solution, but not very precise.
The third solution is V-Sync support, i.e. generating and displaying frames in accordance with the screen refresh rate. In this case, you also need to use delta-time, but timing and waiting for the generation of next frames is implemented on the API side of the GPU, so you do not have to program anything yourself — the intervals will be performed automatically. The solution is easy to implement (e.g. using SDL) and energy-saving and solves the screen tearing problem.
The fourth solution is a constant framerate (independent of the screen refresh rate), no delta-time, but precise measurement of the time between generating frames. Similar to the first one given, but the difference is that the intervals should be performed with more precision than the millisecond. After measuring the waiting time between frames, a larger portion is waited first using eg
SDL_Delay (milliseconds) and the remainder waited using busy waiting. Thanks to this, the framerate will always be what we want (super-precise), no matter how little time you have to wait between frames. If you need inspiration, I implemented such a clock in my game called
Fairtris (unit
Fairtris.Clock.pp). This solution is also simple and energy-saving.
Of course, there are more ways and it all depends on what we really care about.
It should be noted that no matter if we want a constant framerate or a variable (matched to screen refresh rate or completely dynamic), using delta is a good idea if we want to use the slow motion (or accelerated motion) effect in the game. Without delta, it cannot be done other than changing the game framerate or doing strenge things with game logic, which is a very poor solution. The playback speed of the game should be independent of the framerate and programmed in such a way that it is easy to manipulate it.