Recent

Author Topic: Actual gaming performance of FPC?  (Read 19306 times)

shihonage

  • Newbie
  • Posts: 6
Actual gaming performance of FPC?
« on: May 31, 2016, 10:38:43 pm »
I've searched high and low on the Internet, and can't find a single coherent source of information on how would FPC behave, say, in having to render 1000 sprites via a loop using SDL, against C++ doing the same. Very simple, direct measure of FPC+SDL performance.

Does anyone have experience with something like this?

I have 2 project prototypes, one of which is far better suited for Pascal (because it processes a lot of text), and the other is very heavy on sprite drawing, which was written in C/C++ and DirectDraw a long time ago.

I wish there was a way to find out how the latter would behave in FPC+SDL, without actually porting it first.

AlexK

  • Jr. Member
  • **
  • Posts: 55
Re: Actual gaming performance of FPC?
« Reply #1 on: June 01, 2016, 01:27:36 am »
Theoretically, FreePascal is a better fit for games because it compiles quickly(separate compilation).

But everyone uses C++ because it has libraries that resolved problems in memory management deficiency, in some cases a long time ago.
Many experts working at corporations were contributing their work to C++ code-base during past decade.

If something is slow in a compiled language, first guess is that memory is managed not efficiently behind the scenes.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Actual gaming performance of FPC?
« Reply #2 on: June 01, 2016, 10:36:47 am »
Well, first C++ is a language. I think here you will need to pitch various C++ implementations vs FPC.

In general I expect FPC to be a bit less, but not much (say 10-20% on average).  In applications where most of the heavily lifting is done by an external library (like SDL) it might even be not noticable.

I don't recognize AlexK remarks at all. To my best knowledge, there is nothing fundamentally different about C(++) and fpc memory management from a performance viewpoint.

serbod

  • Full Member
  • ***
  • Posts: 142
Re: Actual gaming performance of FPC?
« Reply #3 on: June 01, 2016, 11:16:11 am »
Modern games use highly optimized engine/framework for most scene manipulations and drawing operations, but other game mechanics can be done even on scripting languages - Lua, Python, JavaScript..

User137

  • Hero Member
  • *****
  • Posts: 1791
    • Nxpascal home
Re: Actual gaming performance of FPC?
« Reply #4 on: June 01, 2016, 05:58:10 pm »
SDL is not really going to give as much performance as OpenGL or DirectX (not crossplatform). It's a purely 2D graphics engine for pixel-perfect graphics. Both of above can be programmed with Lazarus/fpc, arguably even easier than in C++.

AlexK

  • Jr. Member
  • **
  • Posts: 55
Re: Actual gaming performance of FPC?
« Reply #5 on: June 01, 2016, 10:23:08 pm »
I don't recognize AlexK remarks at all. To my best knowledge, there is nothing fundamentally different about C(++) and fpc memory management from a performance viewpoint.

Memory management strategies in libraries, optimized for years. RAII, more allocations on stack.
Topics in C++ discussions are often "What’s the Best Buffer Growth Strategy?", or something like that.

That difference in low level assembler performance is not significant(but I don't know yet how compilers differ on RISC CPUs like ARM).

ykot

  • Full Member
  • ***
  • Posts: 141
Re: Actual gaming performance of FPC?
« Reply #6 on: June 02, 2016, 12:40:09 am »
I've searched high and low on the Internet, and can't find a single coherent source of information on how would FPC behave, say, in having to render 1000 sprites via a loop using SDL, against C++ doing the same. Very simple, direct measure of FPC+SDL performance.
SDL has nothing to do with performance and IMHO, unless you are absolutely clueless in programming, you should avoid it.

Speaking of performance, I have recompiled several projects of ours in FPC (before used Delphi), including Aztlan Dreams and Wicked Defense 2 games (unfortunately, our Ixchel Studios site is down now, but I'll see into republishing them later this year). The second one, being a 3D game, in some scenes, have been rendering around 2 million triangles per frame and that ran at pretty stable 60 FPS (vsync on) on 2005 - 2006 old 3D hardware using Direct3D 9 and shader version 3 (using heavy hardware instancing). We are talking about > 120 million triangles per second here. On the other hand, I have seen *many* games compiled with C++ that can't handle more than 200,000 triangles per frame while doing excruciating 5 FPS or less.

My point is, performance-wise, there is nothing inherently wrong in FPC regarding code generation - as long as you keep your algorithms optimal, you should obtain whatever results you are aiming for. If for some reason you have to think about performance in code generation between FPC and other compilers, you are either thinking of premature optimization, or just have some personal issues of insecurity or whatever - in this case, changing career might be a good option. :)

There are other reasons why C++ can be chosen as a language of preference, but mostly these are not performance-related. For instance, in my case, I use it because my colleagues and other people in the project use it, and because it has many compiler options (specifically, MSVC, GCC and Clang/LLVM) supported by large companies and big budget, whereas in case of FPC, you are pretty much stuck at good will and good health of remaining FPC development guys, with all the associated risks involved.
« Last Edit: June 02, 2016, 12:42:05 am by ykot »

AlexK

  • Jr. Member
  • **
  • Posts: 55
Re: Actual gaming performance of FPC?
« Reply #7 on: June 02, 2016, 01:51:52 am »
SDL is not really going to give as much performance as OpenGL or DirectX (not crossplatform). It's a purely 2D graphics engine for pixel-perfect graphics.

They are not mutually exclusive though. SDL provides sounds, events.
OpenGL works on data you pass to it, in graphical memory. Shaders are text snippets that are passed to OpenGL and compiled on the fly by OpenGL's builtin shader compiler.
I worked with OpenGL in Python, Kivy.

shihonage

  • Newbie
  • Posts: 6
Re: Actual gaming performance of FPC?
« Reply #8 on: June 02, 2016, 10:02:10 am »
Thank you all for your feedback, it was very informative.

@ykot: What do you mean? SDL has poor performance in 2D compared to other things? What would be a faster alternative for a 2D game that wants to run on Windows and Linux?


Eugene Loza

  • Hero Member
  • *****
  • Posts: 663
    • My games in Pascal
Re: Actual gaming performance of FPC?
« Reply #9 on: June 02, 2016, 11:13:09 am »
I wish there was a way to find out how the latter would behave in FPC+SDL, without actually porting it first.
Well... there is no way even after porting it... :) You can't compare Linux vs Windows performance... They're too different. One does better one task, and another task is solved better by its adversary.

In Castle Game Engine i get ~60 FPS with ~400-800 sprites (rendered in non-optimized way) at 5-10 years old computer and ~30 FPS at Android tablet and 15 years-old computer.
I think its not efficiency but convenience is the main problem. C(++) was used to make games for a very long time and many games are actually written in C. That means you can find lot's of ready libraries, patterns, examples, answers, tutorials and support. Many C tools have been proven by time and excessive use.
Many game engines use C++,C#,Java,Python, etc. as scripting language, but you can hardly find any quality and actively developed FPC game engines but GLScene and Castle Game Engine, afaik, none of those can provide you with drag-n-drop interface to create games like Unity (C# based), you'll have to do everything by code.

So... I like pascal. I write my games in pascal. But I understand, that usually people don't write games in pascal and there are good reasons for it :)
I do it for fun, so, I don't care about obtaining the highest quality and productivity - I want fun :) But if I'd had to do a commercial-level game I might would have changed my approach.
« Last Edit: June 02, 2016, 11:15:44 am by Eugene Loza »
My FOSS games in FreePascal&CastleGameEngine: https://decoherence.itch.io/ (Sources: https://gitlab.com/EugeneLoza)

shihonage

  • Newbie
  • Posts: 6
Re: Actual gaming performance of FPC?
« Reply #10 on: June 02, 2016, 12:00:38 pm »
Well, I never really use other people's engines, so that's not the issue. It's just about performance for me... because in other areas, Pascal wins over C++ by being better at diagnostics, more intuitive, easier to read, tons of convenience functions for pretty much everything...


Eugene Loza

  • Hero Member
  • *****
  • Posts: 663
    • My games in Pascal
Re: Actual gaming performance of FPC?
« Reply #11 on: June 02, 2016, 12:10:06 pm »
Well, I never really use other people's engines, so that's not the issue.
I was also thinking this way... until I've found out that my life it too short and if I want to finish anything, I'll need to speed up the process significantly :) Engines usually more portable (e.g. in Castle Game Engine you don't have to rewrite the code to port it to Android - my today's result :D), more optimal (people spend a lot of time on developing the structure and optimizations), less buggy (as they were tested and bug-reported on different platforms). So... practically not using other engine is using your own engine. It can be better and convenient, but it would definitely take much more time for coding and reading docs.
So... yes. If you need just a 1000 sprites you can do it by OpenGL and that'll do. If you want to extend in 3D with animations, shadows, etc... It'll take too much time to do it from a scratch.
My FOSS games in FreePascal&CastleGameEngine: https://decoherence.itch.io/ (Sources: https://gitlab.com/EugeneLoza)

shihonage

  • Newbie
  • Posts: 6
Re: Actual gaming performance of FPC?
« Reply #12 on: June 02, 2016, 12:29:50 pm »
I don't do 3D. For that I would indeed need someone else's engine. But for my unique purposes, I need extensive amounts of 2D blitting, and this is where another engine, which is an unneeded abstraction, would start clogging up the much-needed performance.

Handoko

  • Hero Member
  • *****
  • Posts: 5131
  • My goal: build my own game engine using Lazarus
Re: Actual gaming performance of FPC?
« Reply #13 on: June 02, 2016, 12:52:43 pm »
If you're not doing a commercial project, you may try to write your on graphics engine using OpenGL API, which is fast that can handle thousands of polygons even on old pcs. OpenGL isn't too hard to learn, its information is easy to find on the web. And it's fun to write your own engine which you can optimize for your need.

I'm writing my own OpenGL visual control. It's cross platform, can be used on Linux and Windows. Now, I'm making it to be able to use on Android OpenGL ES. If I were doing for commercial project, I will pick any ready-made game/graphics engine. But because it's just for hobby, I enjoy the fun and learning process.
« Last Edit: June 02, 2016, 12:58:20 pm by Handoko »

Paul_

  • Full Member
  • ***
  • Posts: 143
Re: Actual gaming performance of FPC?
« Reply #14 on: May 23, 2017, 02:36:05 pm »
In general I expect FPC to be a bit less, but not much (say 10-20% on average).  In applications where most of the heavily lifting is done by an external library (like SDL) it might even be not noticable.

But game is not just rendering. Game elements must have structure - arrays, classes, lists. In every frame is calculated lot of things (physics, states, AI), game loop must go through the lists etc. etc.
If you lose 20% in every aspect..

FPC classes are performance killer. What I test earlier.

E.g. there are 2 demos in ZenGL library:
- first is based on classes, nice clear code and really low performance.
- second is using records + array of pointers and it's really fast (but if it could compete with C ++ I dont know).


Modern games use highly optimized engine/framework for most scene manipulations and drawing operations, but other game mechanics can be done even on scripting languages - Lua, Python, JavaScript..

Not all, Unity is really slow. If you need speed or lot of objects, you must go outside Unity  framework and create own object structure, game loop etc. Maybe rendering is OK but the rest is the same problem as is described above.
In addition, those scripts are not the best solution, it's always simplicity vs performance.

 

TinyPortal © 2005-2018