Am 17.05.2017 07:12 schrieb <nore...@z505.com>: > > On 2017-05-15 17:27, Graeme Geldenhuys wrote: >> >> On 2017-05-15 22:50, nore...@z505.com wrote: >>> >>> Graeme will need to clarify whether he was trying to be harsh on FPC >>> entirely, or just specifically in some areas.. :-) >> >> >> I'll try and clarify... I believe FPC generates slow (or slower than >> Delphi, GCC and Java) code no matter what. The saving grace is that >> you don't really notice it on normal event-based desktop applications. >> Writing a game is a whole different story. Games are way more >> sensitive to performance. >> >> Now the game I wrote, was a desktop GUI application. It was slow under >> Linux, FreeBSD and Windows. So the results were consistent, no matter >> what GUI API was used.... Be that fpGUI (via GDI), fpGUI (via X11) or >> LCL-GTK2. In all cases, game rendering was to a memory image, then >> once done, that memory image was bitblit to the Window Canvas. >> >> The Java and GCC versions did the same, but were faster. >> >> That's all I can say about. Make your own assumptions - read into it >> any conspiracy theories or what-not. ;-) At this point I don't really >> care, as I already moved on with that project, using OpenGL instead >> (both for Java and Object Pascal). >> > > But any game ends up using opengl anyway, doesnt' it? Sorry I'm not a big game programmer. Want to be, some day.
No, OpenGL is not a given. E.g. on Windows you can use DirectX and depending on the demands of your game a TCanvas might be completely sufficient. Also Graeme was talking about a raytracer which is a completely different beast compared to OpenGL/DirectX/Vulkan. While a raytracer *might* use one of those APIs for output of the final image the main task is the calculation of said image and *that* is where Graeme said that FPC had problems. Regards, Sven
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
