[fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Fri, 19 May 2017 12:32:17 +0100
Graeme Geldenhuys <mailinglists at geldenhuys.co.uk> wrote:

> And no, I don’t agree that this is a “special case”.
Doing lots of calculations in a tight loop is more or less a special case.
On the other hand I have written quite some code that doesn't do much else than computing lots of stuff the fastest way possible.

> It’s a g*d d*mn game engine I tried to implement.
Here I beg to differ. You tried to implement a game engine but that doesn't make it one (no offense intended).
Game engines never, ever, ever use the brute force approach unless it's trivial for your hardware to deal with.
Raycasting was used in Wolfenstein and then dropped. Doom already used BSPs which is completely different and way faster.
Looking at what the 'engine' does it should run on a phone but you need a high end rig to reach interactive frame rates.
But I get where you are coming from and you are IMHO not so wrong with that opinion.

> If the FPC team wants to keep thinking 
> like that, then they should list in big bold letters (on the Free Pascal 
> homepage) what type of applications they deem fit for FPC, and what type 
> of applications you shouldn’t bother writing with FPC.
It's not explicitly stated but by hanging around on this list long enough I got the impression that for raw speed you should just go somewhere else. Maybe FPC can be fast if you know all the knobs and handles and how to push and turn them but I don't have to do that for other languages so it's just less hassle.
C/C++ and Java being the usual suspects. Im sure the FPC developers are not ignoring the performance differences to the aforementioned languages but you know that the team is small and other stuff is deemed more important which considering that not many people need that much performance is the right thing to do.

> As I mentioned, I'll profile the application under both FreeBSD and 
> Windows over the weekend and post my finds.
Just profiling doesn't give you much. Jon profiled on 32-bit with gprof and I did it on 64-bit with callgrind.
Findings: nearly all the time is spent in the render function, floor is slow (but it's in other languages, too).
Fast ASM-floor gives about 25% gain (8->10 fps), replacing floor by cast-to-int gains ~33% (8->12fps) [only compiled with -01 as all other optimizations crash in the map making procedure]. And it gives div-by-zero errors of course (dimLength).

Final: The render function takes about 90%, the cast-to-int about 5%. No other interesting functions shown. So the missing time must be spent doing floating point math and branching (ifs), as that's all the render function does.

> But as far as I'm concerned, 
> there is nothing wrong with the way the program has been implemented.
FWIW I think so, too.

R.