On Wed, 17 May 2017, nore...@z505.com wrote:
On 2017-05-17 02:57, mar...@stack.nl wrote:
In our previous episode, nore...@z505.com said:
i.e. if you end up using opengl, or its successor, why does it even
matter if FPC pure games without any libs are slow?
You still need to calculate all the vertices that you send to the
graphics
card, even if the GPU renders then.
True so a test to confirm that the calculating functions/procedure are
really the bottleneck, would need to be written, and compare it to the
equivalent c++ program with the same calculations
It would just be silly to start optimizing the calculation functions
without any evidence that those are the issue..
If it's fpc's internal functions such as sqrt() I wonder what those
internal functions actually are. Right now they are just magic, pointing
to a magic number, in my mind
They are mostly functions for which the compiler generates code directly
instead of calling actual pascal functions (although that still happens e.g.
for writeln).
You really need to check the generated code for the problem case.
If I understood the thread, Graeme published his ray-tracing code on a
forum, so it can probably be used as a base for examining the problem.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
