I do cross-platform game using Qt (from Linux). Qt has chosen it, because in the future we will need a graphical interface for all editors, as well as it is pre-installed on almost all Linux systems.

I tried to use the standard QApplication :: exec () loop and make a timer with a zero interval. But all this was very twitching, although it was still normal in full screen mode. Here is the code:

QApplication app; QTimer t; t.setSingleShot(false); t.start(0); app.exec();

Then I tried to make my infinite loop, calling processEvents, and after it updating the game. It became better, but still it still jerks in windowed mode. It produces FPS from 50 to 70, although in the Windows version WinAPI was more than 200. Code:

 while(running) { QApplication::processEvents(); engine->Step(); }

The code that I tried on WinAPI, when I have not yet switched to Linux:

 while(GetMessage(...)) { TranslateMessage(&msg); DispatchMessage(&msg); engine->Step(); }

It seems the same as on Qt, but on Qt it slows down, but not on WinAPI. Although the experiment was not entirely clean, I measured FPS on WinAPI on Windows, and I measured FPS on Qt on Linux.

    2 answers 2

    Usually they write for each platform a stack of platform-specific files that process input, collect information about the system, initialize individual streams for the sound, and bring it all to the form adopted in the engine. Then somewhere in one of the files for each system is inserted:

     int main(int argc, char *argv[]) { core.init(); while(1) //Специальная олимпиада открыта вдруг for(;;) быстрее { core.drawFrame(); } return 0; //should never get here }

    At the same time, the cross-platform rendering code itself is encapsulated in the core. This method itself can be quite complicated. There may be FPS counters, work with input, processing AI, collisions, logic, and only at the end of rendering / clearing the memory. In this case, the rendering is carried out by different techniques for different objects / materials in several passes with different shaders in different buffers.

    Regarding the editors for the game, it is very doubtful that he really needs cross-platform and it is not clear what he will do. In the best case, combine meshes unloaded from a normal 3D editor to a level. But if the game is small, it can be done in any other 3D editor. A file with a description of the level / assets is simply automatically generated by the script.

    As for core.init (), this also depends on the implementation. If the game is small, it simply loads everything that can be downloaded. If a large one is loaded, the main GUI, shaders, a metafile with a description of other assets, a user cache, a boot screen / splash screen, etc. The geometry and level textures are loaded separately by a signal from the GUI from the input handler inside the drawFrame if the user decides to load the next level.

    As for the FPS jumps, it is not clear how you consider it. Weighted moving average for the last 20 ticks seems to be a good method. http://en.wikipedia.org/wiki/Moving_average

    PS The code for Doom 3, which I am guided by, is made in this way, if you look at how it manages to cover several platforms.

    • The answer is completely off topic. I did not ask how to implement cross-platform. The cross-platform game is already there, but it slows down because the standard Qt message loop is not designed for games. The question is how to make your cycle? - gammaker
    • Why do you need Qt? - igumnov
    • I mean, it's easier to manually debug a couple of thousand lines of code that create a game window for MacOS, Linux, Windows than to try to use the "Qt non-game standard message loop" - igumnov
    • Cross-platform window creation, keyboard (although there is a separate problem with it in another of my questions on Heshkod), mouse, MessageBox for displaying errors. Reluctance to do it all manually through XLib. SDL or glut also do not want to drag along with the game. And Qt is convenient, there is almost all Linux "ah when installing. And why this editor does not depend on the engine? The level editor will render the level. He should be able to manage objects and so on. In short, you need to combine the interface and the engine into one. - gammaker
    • one
      It is still not clear why your message processing is inside the loop separately? while (GetMessage (...)) // Lousy idea while (running) // running. Is there somewhere the global variable running = true? Isn't it easier to create a UserInput class that processes all messages from all systems into an internal input model made specifically for the game (one keyboard buffer and mouse cursor). After that, conditionally compile it through macros and insert it immediately into engine-> step (). Then the main loop will become much easier. - igumnov

    It turned out that the point is not the main Qt loop. I tried to recompile under Windows, where I had already implemented the WinAPI version, the same low FPS there. I did it via XLib on Linux - a bit smoother, but the FPS did not seem to increase. The only thing that changed when porting and was not tested is the MSVC compiler changed to g ++. I also tried llvm-g ++ and clang ++, but it doesn't affect performance in any way. Yes, and debugging from the release of performance is almost no different, but in the studio it was very different. In general, I can not understand what happened during porting. There were suspicions of some changes, but I tried to repeat them in the old version of the engine in the studio and they did not affect the high FPS.

    So I will learn to use a Linux profiler. I’ll also try to create an OpenGL debug context and use GL_AMD_debug_output . Maybe he will say something. If not, then try to compile the project in the studio.

    • Try first to reduce the work that is being done in the main loop. Say, remove the rendering of objects, but consider FPS'y. And then the change of libraries and compilers are like dancing with a tambourine, so you do not localize the problem - Michael M
    • Tried to delete objects already. As a result, in an empty scene, the FPS barely reached the level that was in the full scene before porting. So generally some incomprehensible results. - gammaker