[fpc-pascal] FPC Graphics options?

[noreply at z505.com]

On 2017-05-19 06:32, Graeme Geldenhuys wrote:
> Bottom line is, with the exact same code, NO work-arounds is required
> for GCC or Java! So why must we have work-arounds for FPC? It's a
> compiler or RTL issue - not being able to understand the code good
> enough to generate more efficient binaries.

Agree, but hopefully if it is an RTL issue you can just swap in a 
fastMath.pp unit or fast system.pp unit, or fast sysutils, or crt, or 
fastmm.... The whole advantage of a modular unit system is you can swap 
in replacements easily, then you verify that it really was an RTL issue 
and not a compiler issue. As an example, the graph unit is swapped in 
with ptc graph unit and look what happens? So then you decide to fix the 
graph unit and match it to ptc graph, or take another route and leave it 
as a more reliable unit but not as fast

> 
> And no, I don’t agree that this is a “special case”. It’s a g*d d*mn
> game engine I tried to implement. 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.
> 

I think it was good for you to do the demo/test to find an issue in fpc 
that needs to be optimized. If you hadn't done this no one would have 
found this bug/slow code until a later time.

Same with the doom/quake ports. In mode delphi, the equivalent code did 
not run the same as Delphi 5/7, meaning that mode delphi had a bug that 
needed to be fixed... Without the quake/doom ports available to compile 
and try, those bugs/issues would have never been found. So not all 
wasted, IMO.

There were workarounds required to get the doom/quake code to work 
properly, which meant mode delphi must have had a bug, or fpc must have 
had an issue that made the graphics not render correctly and the menus 
to not function properly. The fixes were fairly small afair.

> As I mentioned, I'll profile the application under both FreeBSD and
> Windows over the weekend and post my finds. But as far as I'm
> concerned, there is nothing wrong with the way the program has been
> implemented. Time permitting, I might even try compiling it with
> Delphi 7 to see what happens.

That's a good comparison