On 2017-05-18 08:23, Graeme Geldenhuys wrote:
On 2017-05-18 13:42, Reimar Grabowski wrote:
The GPU also does clipping calculations
based on the viewpoint (camera position) in the 3D scene.
Camera position?
OpenGL has no concept of a camera.
Yes, yes, but you know what I mean. Camera, View Point, Player View
whatever. And yes I know there is no "real camera", its the scene that
moves in the opposite direction to the user input.
Why do you have to *calculate* *all*?
My original project was to implement a _software_ raycaster, so no
GPU, no OpenGL etc. Old old early 90's style programming.
This thread is getting a bit ridiculous - just like the Lazarus Forum
thread did. Bottom line is, the exact same code (identical, just the
language syntax that differed) produced acceptable results with GCC
and Java. It didn't with FPC. We all now know FPC doesn't do such a
great job at optimisation (I know the reasons why), and that the
graphics API's is also not to blame. So lets leave it at that.
No no you don't "leave" when you are trying to figure out a slow
procedure that could be causing the problem, you stay here and find what
is the bottlneck, then insert 3-234 lines of code to fix it so it's
equal to the speed of x that you are comparing it to :-)
I just want to pinpoint why fpc is slow:
1.the math unit
2.nothing to do with the math unit
3.a wrapper around a graphics lib is slow, not the graphics lib itself
just the wrapper in fpc
4. system.pp is slow
5. sysutils is slow
6.none of the above
7.magic (not an option. Leave thread..) ;-)
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
