The plumps - a small RTS game in Lazarus

[furious programming]

All you need to know is that the SDL library you advertise is simply connected to the LCL and used. But apparently you don't know...

Great link — problem solved partially. As I wrote, random links from Google, no experience.

And everything that you wrote just collapses into collapse, about your own statements. And the fact that other engines are just as easily connected to the LCL and used can not even be said. And somewhere it costs by default.

If you still think that the placement of the visual engine component on the form is game development, then as I wrote, you have no clue about game development. This thread talks about using LCL content to build a game, not about using engine components for game development. Start reading comprehension.

For such statements, you must first write something worthwhile yourself, and not repeat another Tetris.

At least I did something instead of just talking and pulling the wool over someone's eyes. And I will do a lot more — I am working on my own bigger game, my own IP. So, in summary, have fun putting the components on the form. EoT.

[Seenkao]

furious programming есть какие-то конкретные факты, доказывающие что я не прав? Или просто голословность?  Возможно вы как раз не хотите понять, что вам пишут? Я ни где не утверждал, что использование LCL - это лучший способ для создания игр! Читайте не то что хотите прочитать, а то, что написано на самом деле.
google translate:
furious programming is there any concrete facts proving that I'm wrong? Or just gossip? Perhaps you just do not want to understand what they write to you? I have never claimed that using LCL is the best way to make games! Read not what you want to read, but what is actually written.

[Tomi]

Is there an optimal value to correct speed at all computers?

each "step" of the main process is carried out according to the elapsed time. The deltaTime of the elapsed time of the given cycle is calculated and the hero (and the whole environment) move according to the given deltaTime. And then on different computers it will work approximately the same.

Code: Pascal  [Select][+][-]

1. prcedure proc(dt: double);
2. begin
3.   Heroes.X :=  Heroes.X + Heroes.Speed * dt / 1000;    // 1000 ms
4. end;

Thanks, Seenkao, but what is the value of deltaTime (dt variable) in this case? Is this that value, what i set by interval of the Timer?

[Tomi]

You have several solutions.

Thank you, Furious! I thought, SDL is a tool for C/C++ languages, not for Pascal. But I will look through it, just like your Tetris clone game, what I just downloaded.

[Seenkao]

Thanks, Seenkao, but what is the value of deltaTime (dt variable) in this case? Is this that value, what i set by interval of the Timer?

обычно это разница между текущим временем работы цикла с предыдущим временем цикла.
В Windows есть функция GetTickCount. Для начала можно её использовать.
google translate:
Windows has a GetTickCount function. For starters, you can use it.

Code: Pascal  [Select][+][-]

1. begin
2.   endTime := GetTickCount;
3.   proc(endTime - begintime);
4.   beginTime := endTime;
5. end;

В SDL есть свои функции для работы с таймером. Так же и большинство движков используют свои функции с таймером. Они зачастую внутри похожи, но наверняка называются по разному.
google translte:
SDL has its own functions for working with a timer. Likewise, most engines use their functions with a timer. They are often similar inside, but they are probably called differently.

[BeniBela]

Now, I would like present you my first steps with this topic. If you can recommend me similar Lazarus games, so don't hesitate because I need all kinds of knowledge.

I tried to make an RTS game 20 years ago: https://benibela.de/games_en.html#pbspiel

There are units, buildings and resources. The units can move in a straight line and a worker unit can build buildings which cost resources. The buildings can build units or create resources.

I used TCanvas in Delphi, so it should be mostly LCL compatible. 

Then I abandoned it because TCanvas  was just too slow. I also became bored of games

[Tomi]

Windows has a GetTickCount function. For starters, you can use it.

Code: Pascal  [Select][+][-]

1. begin
2.   endTime := GetTickCount;
3.   proc(endTime - begintime);
4.   beginTime := endTime;
5. end;

A-ha! Thanks, Seenkao, it seems, there is hidden gems in Windows for a programmer - but, I think, if I use these, my program will not be platform independent(?).

[Tomi]

I tried to make an RTS game 20 years ago: https://benibela.de/games_en.html#pbspiel

Wow, you have great games on your website! I will look through these.
I see, you also meet bad things during programming that interrupt your work, e.g. you can't find the source of an error or you get bored of yourself. Unfortunaltely these also happen to me, therefore I wish you all the best for your future works and plans!

[Seenkao]

A-ha! Thanks, Seenkao, it seems, there is hidden gems in Windows for a programmer - but, I think, if I use these, my program will not be platform independent(?).

Да, это подойдёт только для Windows. И это не лучшее решение для Windows.
Если пользоваться кроссплатформенными решениями, то движки содержат в себе данные решения таймеров. Допустим в ZenGL с которым я работаю это timer_GetTicks. Для SDL вам надо найти самому, я с ним не работал. Но чаще этими решениями вообще пользоваться не приходится, а используют внутренние циклы движка, который предоставляем вам самому задать процедуру основного цикла, процедуру прорисовки и многие другие процедуры. Для этого надо изучать движки.
А таймер уже уходит на второй план, движок решает всё сам за вас (но может и не решать, зависит от движка).
google translate:
Yes, this is only for Windows. And it's not the best solution for Windows.
If you use cross-platform solutions, then the engines contain these timer solutions. Let's say the ZenGL I'm working with is timer_GetTicks. For SDL you have to find it yourself, I haven't worked with it. But more often you don’t have to use these solutions at all, but use the internal cycles of the engine, which we leave to you to set the main cycle procedure, the drawing procedure and many other procedures. To do this, you need to study engines.
And the timer is already fading into the background, the engine decides everything for you (but it may not decide, it depends on the engine).

[furious programming]

OnWindows, the GetTickCount and GetTickCount64 functions are completely useless in the terms of calculating delta. These functions are based on the system time which is refreshed only 60 times per second. This causes the delta calculated in this way:

Code: Pascal  [Select][+][-]

1. begin
2.   endTime := GetTickCount;
3.   proc(endTime - begintime);
4.   beginTime := endTime;
5. end;

will always be 0, 16, or 17. I can see that it keeps repeating itself and suggests the same nonsense that these functions are supposed to be useful for game development. No, they are not — in absolute most cases they are useless (at least on Windows). Still don't believe me? Try this:

Code: Pascal  [Select][+][-]

1. uses
2.   SysUtils;
3. var
4.   TicksOld, TicksNew: Int64;
5.   Tries: Integer;
6. begin
7.   TicksNew := GetTickCount64();
8.  
9.   for Tries := 0 to 19 do
10.   begin
11.     TicksOld := TicksNew;
12.     WriteLn(TicksOld);
13.  
14.     repeat
15.       TicksNew := GetTickCount64();
16.     until TicksOld <> TicksNew;
17.   end;
18.  
19.   ReadLn();
20. end.

The result in the console will be the following:

Code: Pascal  [Select][+][-]

1. 149456484
2. 149456500
3. 149456515
4. 149456531
5. 149456546
6. 149456562
7. 149456578
8. 149456593
9. 149456609
10. 149456625
11. 149456640
12. 149456656
13. 149456671
14. 149456687
15. 149456703
16. 149456718
17. 149456734
18. 149456750
19. 149456765
20. 149456781

As you can clearly see, the value of the counter changes every 15-17 milliseconds. Bravo.

If the main game loop is to freeze the thread between frames, no matter what framerate it has to keep (this can be a constant 25fps, 30fps, 60fps, 120fps or dynamic but limited), you need to calculate the freeze time with high precision and carry out the freezing with high accuracy. Some frames can be generated in 1ms and some in 15ms. At 60fps, in the first case you will have to wait a little over 15ms, and in the second only about 2ms. As I wrote, a little over, because at 60fps the time for one frame is 1000/60=16.667ms, so the calculations cannot be rounded to milliseconds.


This type of computation is easily done — on Windows, you can determine counter resolution using QueryPerformanceFrequency function (precision is always nanosecond on Unix). To get the current counter status, use QueryPerformanceCounter on Windows and FPGetTimeOfDay on Unix-based systems. Take the time before and after generating the frame and then calculate their difference. Knowing the precision of the clock and how many ticks it took to generate the frame, it is easy to calculate how many nanoseconds to freeze the thread.

It's easy on Unix-based systems to freeze the thread with high accuracy, because there is the FPNanoSleep function, which has a very high precision (microsecond, although the argument is the number of nanoseconds). It is more difficult on Windows, because Sleep works with millisecond precision. Therefore, in order to maintain a very high precision (more or less microseconds, which is enough for the needs of typical video games), you can divide the freezing into two stages — first, using Sleep, suspend the thread's work for a specified number of milliseconds, and the rest with busy waiting and especially for this purpose, the assembly instruction pause was designed.

Important! If your game does not need super-high precision (you don't create e.g. an emulator), you can safely use only millisecond intervals. It is important not to round the time, but to keep it in a tank so that the remaining, less than a millisecond fraction, accumulates and is used in subsequent freezes. However, it is still necessary to rely on a high-precision counter (i.e. a hardware counter, not a shitty system clock) in order to be able to correctly calculate the waiting time and delta, as discussed below.


Another bad example is delta usage in the form of elapsed milliseconds. This is wrong because such a value is unintuitive and very difficult to use. It is very good for delta to be a floating point number, representing a fraction of a second, in the range 0 to 1. Assuming the game is running at 60fps and there is no lag, the delta should be ~0.01667. At 100fps it should be 0.01 and at 187fps it should be around 0.005348. With a variable frame rate, the delta will contain different values, but still between 0 and 1. If there is a huge lag, for example 5 seconds, the delta will be 5 and still be able to be used in the calculations, so there is no problem.

Given this delta, you determine the speed of each object and other element in the game in terms of units per second (e.g. 100px per second) and multiply it by the delta. No matter what the speed is, and no matter what the framerate (no matter if it's constant or dynamic), it's very easy to configure the behavior of objects.

If your game is going to be able to manipulate the gameplay speed (i.e. support slow-motion or accelerated-motion), you can use the second floating point number, which is the speed of the game, and use it in the delta calculation. At normal speed, this number should be 1, at slow-motion the value should be in the range (0,1), and with accelerated motion in the range (1,n>, where n is any value greater than 1 (x=2 is an acceleration of 2x).

Everything I wrote above will allow you to:

• keep any constant and any variable framerate (with the ability to change the behavior of the game while it is running),
• correctly calculate the waiting time between frames,
• correctly calculate the delta and keep it simple to use in your game engine,
• the mechanics are resistant to lags (the game does not slow down),
• maintain a very high precision of timing (depends of the needs and implementation),
• it is very easy to determine the speed of objects and elements in the game,
• it is very easy to support slow-motion and accelereted-motion regardless of the framerate.

I know all of this can seem complicated, but it's all limited to using a few functions and performing very simple calculations. There is nothing to be afraid of, because such very simple calculations can create an incredibly functional game core mechanics, not only easy to use by the programmer, but also giving players the ability to adapt its behavior to their hardware (limit framerate, safe CPU power and so on).

Everything I described will be implemented in the game I am currently working on, so if I have the timing module finished, I will gladly give you a demo for fun and source for analysis.

[Seenkao]

furious programming, ты явно не далёкий человек! Не понимаешь что ты делаешь вообще! Не читаешь, то что пишут, видишь лишь что-то через строчку. 
Даже читать не стану твои росписи, потому что новичку это вообще не нужно знать. Но ты об этом забыл и при чём совершенно!
Ты просто не хочешь понимать, что люди совершенно разные и большинство из них даже программировать больше не будут, особенно после того, что ты им предлагаешь. Ты делаешь всё, чтобы у человека пропало желание что-то сделать. Заставляешь изучать движки, на которые нужно тратить дополнительное время, кроме самого программирования. И в итоге, человек просто забросит что-то делать.
И можешь потом благодарить самого себя, за то, что он всё бросил.
Либо дай нормальный цикл уроков, чтоб человек мог по этим урокам пройтись и изучать, либо не советуй человеку идти через горы информации!

google translate:
furious programming, you are clearly not a distant person! You don't understand what you are doing at all! You don’t read what they write, you only see something through the line.
I won’t even read your paintings, because a beginner doesn’t need to know this at all. But you completely forgot about it!
You just don't want to understand that people are different and most of them won't even program anymore, especially after what you offer them. You do everything to make a person lose the desire to do something. You make them learn engines that a person needs to spend extra time on, except for the programming itself. And in the end, a person will simply give up doing something.
And then you can thank yourself for throwing everything away.
Either give a normal cycle of lessons so that a person can go through these lessons and study, or do not advise a person to go through mountains of information!

[furious programming]

No, you just write nonsense once again and pass on nonsensical knowledge that cannot be used in practice. You don't know what you are writing about, you don't check anything and instead of admitting your mistakes, you keep denying and blaming me. My above post clearly shows how much you have no idea what you are writing about, so stop confusing people and giving completely wrong solutions.

Windows has a GetTickCount function. For starters, you can use it.

GetTickCount is a total crap and cannot be used, so stop suggesting people to use it.

[Seenkao]

Посмотрим сколько знаний у меня и сколько знаний у вас?
Вы перебрали хоть один движок полностью? Хотя бы под одну систему? Вы знаете как работает движок? Вы смогли заставить работать движок под MacOS Cocoa? Вы знаете как нативно завести программу на андроид, со своими системными вызовами?
Боюсь что нет. Ты просто пользователь движка, не зная как там внутри всё устроено. У тебя нет даже конкретных уроков по данному движку? У тебя нет примеров по данному движку? Всё что тут тобой написано, просто пустой звук без кода. 
Всеми своими эмоциями ты показываешь, что ты явно не прав. (дак и я не прав, что позволяю эмоциям взять верх над собой  но мне просто смешно смотреть, как ты тут брызжешь слюной, вместо того, чтоб предоставить человеку ссылку на уроки).

В чём ты меня обвиняешь? В том, что я предоставляю человеку информацию которою проще на данный момент усвоить? И показываю как это работает?

google translate:
Let's see how much knowledge I have and how much knowledge you have?
Did you go through at least one engine completely? At least for one system? Do you know how the engine works? Were you able to get the engine working under macOS Cocoa? Do you know how to natively launch an Android program with your own system calls?
I am afraid it is not. You are just a user of the engine, not knowing how everything works inside. Do you even have specific tutorials on this engine? Do you have any examples for this engine? Everything that you wrote here is just an empty phrase without code.
With all your emotions you show that you are clearly wrong. (and I'm not right that I let my emotions get the best of me but it's just funny to me to see how you squirt saliva here, instead of providing a link to the lessons to a person).

What are you accusing me of? The fact that I provide a person with information that is easier to assimilate at the moment? And show the person how it works?

[Seenkao]

furious programming, ну и чтоб  не быть голословным, я скидываю код, который будет достаточно точно работать на Unix, ну а вы предоставьте подобный код только для Windows. Я не думаю что это будет сложно. Сложнее это если б я вас попросил нативный код для MacOS Cocoa показать для таймера.
google translate:
furious programming, well, not to be unfounded, I throw off the code that will work accurately enough on Unix, but you provide similar code only for Windows. I don't think it will be difficult. It's more difficult if I asked you to show the native code for MacOS Cocoa for the timer.

Code: Pascal  [Select][+][-]

1. implementation
2. function fpGetTimeOfDay(val: PTimeVal; tzp: Pointer): Integer; cdecl; external 'libc' name 'gettimeofday';
3. ...
4. function timerGetTicks: double;
5. begin
6.   fpGetTimeOfDay(@timerTimeVal, nil);
7.   {$Q-}
8.   Result := timerTimeVal.tv_sec * 1000 + timerTimeVal.tv_usec / 1000 - timerStart;
9.   {$Q+}  
10. end;
11.  

[furious programming]

Let's see how much knowledge I have and how much knowledge you have?
Did you go through at least one engine completely? At least for one system? Do you know how the engine works? Were you able to get the engine working under macOS Cocoa? Do you know how to natively launch an Android program with your own system calls?

Oh, don't be a babycry. It puzzles me even more, since you claim that you have such a large track record and knowledge, and at the same time do not understand how such a basic function as GetTickCount works and how much it is useless for precise timing.

I am afraid it is not.

I didn't make any engine, I made two whole games — the Deep Platformer (almost finished but abandoned) to play with software rendering (LCL rendering sucks) and the Fairtris to learn SDL and to fix anything that broke the sloppy developers of the NES Tetris. For both of these games, I use my own timing implementation (in the first one the cross-platform implementation) and it works great. And now I'm working on a third game, this time big and serious one (commercial), built from scratch in Free Pascal and SDL with my own engine, which will take about 3-4 years to release the first game to the market.

You are just a user of the engine, not knowing how everything works inside.

Don't measure other people by your own yard-stick, especially if you start the discussion by confusing users.

Besides, that's why I chose Free Pascal and SDL to implement everything myself. Thanks to this, I can program every aspect in my own way and have full control over everything, without having to rely on someone else's engine and someone else's API to handle it. If I didn't know how it all works inside, this approach would be suicide. But since I know exactly what the engine should look like inside, I can do whatever I want and however I want, adjusting the implementation to the project requirements.

With all your emotions you show that you are clearly wrong.

It is not the (supposed) emotions that prove the correctness of the argument, but the source code that I have provided, which clearly shows that GetTickCount cannot be used to measure time between frames and cannot be used to calculate delta properly. Deal with it.

Everything I wrote in the previous post is enough to implement powerful timing — someone as experienced as you will surely have no problem writing ~50 lines of code for timing and delta calculation. And you certainly won't have a problem adding a second multiplier as well, which will come in handy for manipulating the speed of the gameplay. Not only to be able to take advantage of the slow-motion effect in several scenes, but also to be able to slow down the gameplay for the needs of players with motor and cognitive limitations (read the Game accessibility guidelines).

It's more difficult if I asked you to show the native code for MacOS Cocoa for the timer.

No, it won't be harder. As I wrote, gettimeofday and nanosleep functions are available on all Unix-based systems, including macOS. You don't even need to import anything, because these functions are already implemented in the form of FPGetTimeOfDay and FPNanoSleep.