Deep Platformer — looking for people for cross-platform testing

[flowCRANE]

Finally good news...

I've just downloaded and tested. So far everything seems to work correctly on Ubuntu 18.10 64-bit Lazarus 1.8.4 GTK2.

Thank you @Handoko. I'm wondering why the load is almost 60%, 20% higher than on my rather old hardware. Did you increased the size of the window, and then reduced it? Because this causes the load to increase and after reducing the window to its previous size, the load is greater than before resizing.

It is not dependent on the game code, because this effect occurs in Lazarus 2.0.0, but does not occur if I compile the game in Lazarus 1.8.4. So something had to change in LCL, that the same code works differently in two different versions of the IDE.

If you did not increase the size of the window before taking a screen shot, the higher load on Linux is simply specific to this system when it comes to the current project code. But the most important thing is that the game works properly, which makes me very happy.

For clarity, I develop the game and test it on a Lenovo Thinkpad T60 with the following parameters:

• CPU — Intel Core Duo T2400 @ 1.83GHz
• GPU — 512MB ATI Mobility Radeon X1300
• RAM — 3,00GB Dual-Channel DDR2 @ 265MHz
• OS — WinXP SP3 32-bit

And the in-level load is about 41%.

Here are the "results" on a Pentium 4 3Ghz 512Mb ATI Radeon 7000 with Ubuntu 12.04.

Another older hardware! The better, because the game will definitely run smoothly on a powerful computer, but it is never certain about older ones. I care about all computers, including old and weak ones. Thank you for the test.

But can you reveal how big the load is during plaing on the level (or in the menu)? Just run the game with cheat on parameters pair and look at the counter placed in the lower left corner. It should be smaller than 100% for the game to run smoothly.

I couldn't pass the "deep abbyss"

Don't give up — just try few times more. If you can not jump over, the game will tell you what to do.

First game "meadow" ? not show any floor for can bump or fall ? Then is not easy game 

Can you describe the problem more accurately and show the screenshots?

The first level in the deep meadow world, just after showing up on the screen, should look like in the attached screenshot. As you can see, there are platforms in it.

[flowCRANE]

@lucamar: I have a question for you (to others too).

The game in full-screen mode should hide the cursor, but in windowed mode, the cursor should be visible and have the form suitable for crSizeAll enum. However, on the screenshots you have given, the cursor is a normal arrow, which is incorrect. Is the cursor really an arrow in windowed mode?

Look at the screenshot from the attachment — this is what it looks like in my case (under Windows) and I would prefer it to look like on other platforms.

[Handoko]

I didn't change anything, the window size was the default. I saw the default compilation was in Debug mode. If I try to change it to Release mode, there will be a bit increasing of the performance.

On Debug mode, I mostly got 60% - 95% load when playing. On Release mode, I mostly got 50% - 80%.

My computer is Core2 Quad Q6600 DDR2 4 GB RAM Nvidia GeForce 210 Ubuntu 18.10 64-bit Lazarus 1.8.4.

[Thausand]

Can you describe the problem more accurately and show the screenshots?

The first level in the deep meadow world, just after showing up on the screen, should look like in the attached screenshot. As you can see, there are platforms in it.

For me look like attach

Game instruction help any good work (can show picture attach if want)

[Thausand]

@lucamar: I have a question for you (to others too).

The game in full-screen mode should hide the cursor, but in windowed mode, the cursor should be visible and have the form suitable for crSizeAll enum. However, on the screenshots you have given, the cursor is a normal arrow, which is incorrect. Is the cursor really an arrow in windowed mode?

Look at the screenshot from the attachment — this is what it looks like in my case (under Windows) and I would prefer it to look like on other platforms.

Screen grab program raspbian set option "hide cursor" if grab. If window game active then cursor = "crSizeAll". Click outside for grab then not game active = cursor change "normal"

I not know how work windows 

add:
Because fun game i attach wimp 

you make good game furious programming 

[lucamar]

But can you reveal how big the load is during plaing on the level (or in the menu)? Just run the game with cheat on parameters pair and look at the counter placed in the lower left corner. It should be smaller than 100% for the game to run smoothly.

The game (ok, the tutorial) runs smooth but, 100%? Nah, try rather anywhere from 250% to 500% with fps ranging from around 30 (in the text parts) to 12..18 in the "try yourself" parts (see attached image). But let me repeat: it runs quite smooth, in a really endearing "old-style" kind of way.

@lucamar: I have a question for you (to others too).

[...] on the screenshots you have given, the cursor is a normal arrow, which is incorrect. Is the cursor really an arrow in windowed mode?

It's not an arrow (I guess that's something the screen-grabber does by itself) but it isn't like your pic either: in my system it shows a "hand" cursor.

[Handoko]

On Debug mode, I almost never reached 100% load. But I wonder why on Release mode, I sometimes got 105% and 120%. But on average Release mode has lower loading compare to Debug mode.

Although the load sometimes seems scary, but I didn't experience any slowdown.

[flowCRANE]

This is unbelievable... Why is this game working so slowly on Linux...?

On my 12-year-old laptop it works twice as fast as on a modern computer with Linux and a quad-core processor. I checked how the game works on newer hardware — Samsung RV720 with 3GB RAM, Windows 7. And the load is much smaller, reaching 24% at the default window size and 55% at full screen (see attachments). Project compiled in Lazarus 2.0.0 64-bit as a native 64-bit executable works with the same speed. On Windows (on my old laptop with XP), the release version works 5% faster than the debug version (because handling exceptions are disabled and better optimizations are used).

Rather, it's not a hardware problem, but a native code generetaed for Linux. And it should not be much slower, because bitmap processing looks exactly the same on this system as on Windows (alpha channel is not used, it is completely skipped).

I have no idea why there are such large differences in performance between these platforms... Perhaps the problem is not the bitmap processing, but the calculation in the timer class? Maybe the timer does not work properly?

I have an idea how to measure the real FPS count.

[flowCRANE]

Ok, we need to check if the timer is working properly. Please, download the project sources from the attachment. The code is the same as before, but I commented out the code responsible for waiting for the calculated amount of time between frames:

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

1. procedure TClock.WaitForNMI();
2. //var
3. //  NextFrameCounts, CurrentCounts: Int64;
4. begin
5.   //NextFrameCounts := FFrameCountsBegin + FCountsPerFrame;
6.   //
7.   //repeat
8.   //  CurrentCounts := GetHardwareCounterValue();
9.   //until CurrentCounts >= NextFrameCounts;
10. end;

Now the game will perform as many frames as possible, and because the game works on the same principle as NES, will work much too fast (this is intended).

On my old laptop, the CPU can perform about 145 frames per second during in-level gameplay. On the better laptop, Core2Quad CPU can perform about 244 frames per second. Please, make the same test and provide a screenshot with first blue level (as in my screenshots).

[lucamar]

Here you have it. The same ancient box

[nouzi]

win 7 64 bit
cpu i7-3770 3.40 GHz
ram 8g

[flowCRANE]

@lucamar: damn it… So the timer works properly and it looks like for some reason bitmap processing on Linux takes much longer than on Windows. Ie. the reasons can be two (or more) — either the bitmap processing takes too long, or it takes a long time to render the final frame bitmap on the window canvas (this is done using TCanvas.StretchDraw, so it would not be my fault).

If you want, download the soruces from the attachment, compile and run. The window will be always black, because rendering frame buffer on the window canvas is disabled. The code responsible for doing the delay between frames is also disabled, so the game should perform as much frames as CPU can do. The console window will be shown on the screen (except the game window itself), in which the current framerate will be printed in every second. Just check the values printed in the console and let me know what is the framerate.

One important thing — do not deactivate game window, because if you do this, the game will disable the logic resposible for drawing the frame, so the framerate will jump 10 times. Just run the game, spread the windows so that the console will be visible and click on the game window to activate it. Wait a few seconds for the framerate to stabilize. Then you can check the values in the console.

On my old computer, the framerate is about 167-170 (look at the screenshot in the attachment).

@nouzi: thank you for test. But what about frame load? Just run the game with the following parameters pair:

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

1. > platformer.exe cheat on

and check the load counter value in the lower left corner during menu or in-level gameplay.

[lucamar]

I don't think the "problem"  is that it is Linux but that this machine is (relatively) slow. I'll try to test with one of the other (more modern) machines to see what's what

Meanwhile, here is the result of the frame tester:

ETA: So... I made another test: Booted this same machine in Windows XP, compiled and run; results on the second image. It looks like it might be a Linux vs. Windows affair.

[flowCRANE]

I don't think the "problem"  is that it is Linux […]

No, I did not write that the problem is Linux, and the native code, generated by the compiler for this system. Something is terribly slow and I have no idea what… The very logic of the game (without the bitmap processing code) does not constitute any overhead, almost 100% of the used CPU power is used to generate frames (processing bitmaps).

[…] but that this machine is (relatively) slow.

It's fast enough for the game to work without any problems with a fixed 60fps (no matter which scene), all the more in the form of a small window (with the default size). This problem is not harware related for sure.

Meanwhile, here is the result of the frame tester:

Yep, this is the proof that the bitmap processing code works terribly slow. But I don't know why.

And since that is how it looks, I will probably stop the porting the code. Honestly, I'm just wasting the time instead of focusing on content creation. In the end, the game can be easily run on Linux with Wine (and will work correctly, it was tested some time ago).

[lucamar]

And since that is how it looks, I will probably stop the porting the code. Honestly, I'm just wasting the time instead of focusing on content creation.

No, please.Keep porting even if it'll be slow in Linux. After all it's not slow enough as to be unplayable and, frankly, if you hadn't told us I wouldn't have noticed at all. I would love to have this game/tech-demo available for Linux. Pretty please ...

As for the problem, I would really love to see the results of the framerate-tester on other computers. Come on, linux-people, test a little! It's just 5 minutes tops.