Re: [fpc-pascal] FPC Graphics options?

[Marco van de Voort]

In our previous episode, Graeme Geldenhuys said:
> > qualifies. There are collision detection/response, maybe a physics
> > engine, player input reaction, sound processing and enemy "AI" which
> > will all bring the framerate down.
> 
> I know that perfectly well. I only posted the code for a small demo. My 
> real game had all the above functionality.

The point is that a software raytracing renderer is not a aselect
representative of a small game.

Raytracers like Povray are routinely used as benchmarks, both CPU and
compilers.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-17 14:53, Reimar Grabowski wrote:

Na, having 30 or 45 FPS while doing absolutely no gameplay hardly
qualifies. There are collision detection/response, maybe a physics
engine, player input reaction, sound processing and enemy "AI" which
will all bring the framerate down.


I know that perfectly well. I only posted the code for a small demo. My 
real game had all the above functionality. It generated a 3D world, 
generated textures (yes, I didn't use bitmaps), randomly places the 
character, has First Person view, character movement through the 3D 
world using a mouse or keyboard, the player has the ability to alter the 
3D world, can jump, drop off cliffs (fall) etc.  All this was done using 
the software raycaster, and Java gives me 40 FPS very consistently in 
800x600 resolution (actually 320x200 upscaled to 800x600 - giving the 
nice pixelated effect).


My code in the Lazarus Forum showed an attempt to simply move (fly) 
through a much smaller 3D world, but it couldn't come close to the 40 
FPS mark I saw with Java. As I said, it barely reached 8 FPS.


My system is a i7 3.5Ghz system with 32GB RAM. It it's definitely not my 
system that can't keep up either. Especially if you remember back in the 
day, Wolfenstein 3D, which was also a software raycaster game, ran very 
smoothly on a 486 PC.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-18 09:52, Marco van de Voort wrote:

Raytracers like Povray are routinely used as benchmarks


RayCasting <> RayTracing.

You are referring to "raytracing" programs. I'm talking about  raycasting.

The difference: As explained by somebody after I did a quick google 
search to save time:


"
wolfenstein3d used raycasting. Raycasting is based on sending out a 
"ray" along each line of sight from the viewer, and incrementally moving 
along that line of sight until the ray hits an object.


Ray Tracing involves letting rays reflect off of objects to
produce a realistic-looking scene with reflections and shadows. Ray 
tracing is hard to do fast enough to include in a game. if you want to 
see some examples visit http://www.povray.org/

"




Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-17 14:28, Reimar Grabowski wrote:

But I don't get why you have to *calculate* *all*.


The CPU (your program) calculates all the 3D vertex points, as objects 
(made out of vertex points) move through the scene. Lots of triangles 
really.


The GPU calculates the individual pixel colors based on those vertex 
points (using shaders and textures). eg: CPU calculates 3 points of a 
triangle. The GPU calculates all the points between those 3 points, 
making up the triangle color. The GPU also does clipping calculations 
based on the viewpoint (camera position) in the 3D scene.


So if you work out how many vertex points there are, compared to 
everything that the GPU has to do (a LOT more points and calculations), 
the CPU does relatively little in comparison.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Michael Van Canneyt]

On Thu, 18 May 2017, Reimar Grabowski wrote:


On Thu, 18 May 2017 14:52:25 +0200 (CEST)
Michael Van Canneyt  wrote:

> Why do you have to *calculate* *all*? 


Because you want to create an image ? That's what a ray-tracer does AFAIK.

But raytracing isn't the subject here and never was.
Graemes raycasting isn't the subject here either.


Yes, it was.

The complaint of Graeme was that a FPC ray tracer is much slower slower than an 
equivalent raytracer in Java. All the rest are diversions from the original subject.


Michael.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-18 07:42, Reimar Grabowski wrote:

Camera position?
OpenGL has no concept of a camera.


When I toyed around with Andorra3D it had some concept/code for a 
Camera, but he may have added it with his own code, not sure if he used 
built in directx/opengl code

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 14:26:18 +0100
Graeme Geldenhuys  wrote:

> On 2017-05-18 14:21, Reimar Grabowski wrote:
> > Yes, I get that, but the interesting point is what does the profiler say?
> > Where are the bottlenecks?  
> 
> The full source code was posted in the Lazarus Forum (I supplied links 
> to those) - so knock yourself out.
Thanks but no thanks.
I thought you had at least tried to identify them as that's what I generally do 
when performance is sub par (for whatever language or project).

R.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 21:00:48 +0700
Ryan Joseph  wrote:

> That’s right. I’d really like to know what the hell FPC is doing to make it 
> so slow (besides the call to Floor()). The compiler team should be worried 
> about this also I would think.

No, they should not.
It's no real world problem, just a test program. A real game would be done 
differently and then FPC is fast.
People don't do math on computers so raw calculation speed is not important.
Compiler optimizations would be nice but are hard to do and the project has not 
enough contributors.
Being on many platforms doesn't make the task easier.

Long story short:
Wanne do PacMan in 160x100 resolution, no problem for FPC.
Wanne do something more modern, use something fast like Python or Perl.

R.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-18 16:25, Ryan Joseph wrote:

Please do and keep us informed if you don’t mind.


No problems, will do.

Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Marco van de Voort]

In our previous episode, Ryan Joseph said:
> > No, they should not.
> > It's no real world problem, just a test program. A real game would be done 
> > differently and then FPC is fast.
> 
> Asking honestly, so you don?t think there?s anything troubling about a 8
> fps vs 40 fps from the same code? 

No, since this is not a general trend, but similar extremes are known.

If it is floating point, then the floating point exception regime of FPC
might have to do with it.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 08:40:43 -0700
Jon Foster  wrote:

> I limited run time to 10secs, and used "time" to verify actual run time. 
> Here are the results, time output listed first and the first section of the 
> gprof output without comments:
A little of topic but did gprof just work like it used to?
I remember last time I tried to profile with gprof I could not get it to work 
and even asked about this on this list and was suggested alternatives.
Has there been something fixed or is it by chance that it works?

> The code that is slow appears to be all standard floating point and integer 
> math
AFAIK floating point math is done using the extended type (as the gprof output 
shows) and there are no optimizations for single or double.
Correct me if I am wrong.

R.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Marco van de Voort]

In our previous episode, Graeme Geldenhuys said:
> > I was extremely curious to see if those calls to Floor() were causing it.
> 
>  From memory, I remember trying replacing Floor() with Frac() and even 
> Trunc(), and neither made any difference in the speed.
> 
> So I don't believe it is simply down to the Floor() usage.

FPC/Delphi do high precision rounding. A lot of Delphi gaming uses simple
assembler instructions for rounding.

Note that the profiling from Jon also shows that all targets should be
forced to the same architecture (since 64-bit division seems to be a RDS)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Jon Foster]

On 05/18/2017 07:19 AM, Reimar Grabowski wrote:

On Thu, 18 May 2017 20:32:57 +0700
Ryan Joseph  wrote:


On May 18, 2017, at 8:23 PM, Graeme Geldenhuys  
wrote:

The compiler must be doing something really stupid for it mess up like that but 
how can we know?

By getting the source of Graemes test, using a profiler on it and having a look 
at the results?

I compiled Graeme's code which was surprisingly easy. I guess I already had 
SDL installed with the dev files. FPC on my old 2GHz Intel gets 2fps. With 
Java (OpenJDK 1.6.x) I get a pretty steady 14fps. On my 3yr notebook with a 
1.9GHz Intel I get 4fps for FPC and 18fps for Java. I find it amusing the 
slower chip is faster. But there has been significant hardware improvements 
over the years.


I would have provided the fps for C++ but I haven't figured out how to get 
it to render the same content. It was doing half the resolution. I upped 
the window size which was obvious but it appears to be magnifying the same 
low pixel count. I've got to get back to work so I'll have to stop fiddling 
with this.


Both devices are multi-core Intel processors, obviously two different 
families, running 32bit Linux with Xorg for the display. FPC is version 
3.0.0. For the benchmark runs I used "-XXs -O3" for compiler switches.


I limited run time to 10secs, and used "time" to verify actual run time. 
Here are the results, time output listed first and the first section of the 
gprof output without comments:


10.05user 0.01system 0:10.11elapsed 99%CPU (0avgtext+0avgdata 9188maxresident)k
0inputs+272outputs (0major+1010minor)pagefaults 0swaps

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self  self total
 time   seconds   secondscalls  Ts/call  Ts/call  name
 62.44  1.33 1.33 fpc_frac_real
 26.76  1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
 10.33  2.12 0.22 FPC_DIV_INT64
  0.47  2.13 0.01 SYSTEM_$$_GENRAND_MT19937$$LONGINT
  0.00  2.13 0.00   43 0.00 0.00 P$TEST_$$_RENDER
  0.00  2.13 0.008 0.00 0.00 
P$TEST_$$_INTTOSTR$LONGINT$$ANSISTRING

  0.00  2.13 0.001 0.00 0.00  P$TEST_$$_INIT
  0.00  2.13 0.001 0.00 0.00  main


The code that is slow appears to be all standard floating point and integer 
math (* / mod + - >> <<). All of the time is spent in the render() 
function's main loops (lines 191-282 inclusive). I might have missed 
something but I didn't see any function calls of any concern. I rem'd those 
lines out and my frame rate jumped to ~1200. Obviously all I saw was a 
black screen. But I wanted to eliminate the SDL calls from the suspect list 
and make sure I had targeted the right lines.


I'm convinced that its not the integer math from the benchmarks I published 
earlier. And I thought everyone used the FPU so  I never imagined there 
could be a significant speed difference with floating point. But this feels 
like the compiler is using software math instead of the FPU. I tried 
various -Cf... switches and either got the same results or "Access 
Violation". Even tried "-Ce" and the compiler said it was an invalid switch.


I suppose there could be something else I'm missing. Much more work to do 
to find the culprit.


Seems like the compiler team should be very interested in this. Fortunately 
I don't do much with floating point math or I'd probably be heading back to 
C/C++. Ugg. I can still churn through millions of web log lines in pretty 
quick order. :-D

--

--
Sent from my Debian Linux workstation -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
j...@jfpossibilities.com
541-410-2760
Making computers work for you!

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] List pre-defined defines

[Jon Foster]

On 05/18/2017 08:46 AM, Jon Foster wrote:


On 05/17/2017 05:40 AM, Ewald wrote:

On 16/05/17 23:53, Mattias Gaertner wrote:

touch mytest
fpc -vc mytest

Perhaps a one-liner:
fpc -vc /dev/null

?

Saves one the need to create a dummy file and remove it afterward ;-)

I like it!


Although that won't work on windoze! ;-)

--
Sent from my Debian Linux workstation -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
j...@jfpossibilities.com

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-18 15:28, Ryan Joseph wrote:

I was extremely curious to see if those calls to Floor() were causing it.


From memory, I remember trying replacing Floor() with Frac() and even 
Trunc(), and neither made any difference in the speed.


So I don't believe it is simply down to the Floor() usage.

Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Brian]

Ryan Joseph wrote
>> On May 18, 2017, at 9:19 PM, Reimar Grabowski 

> reimgrab@

>  wrote:
>> 
>> By getting the source of Graemes test, using a profiler on it and having
>> a look at the results?
> 
> I tried (had to change the code to support SDL 2 even) but gave up after
> it crashed on one line. Graeme suggested a staggering difference in
> performance and I was extremely curious to see if those calls to Floor()
> were causing it. Hopefully this was a red herring and FPC isn’t as bad as
> the test suggests.
> 
> Regards,
>   Ryan Joseph
> 
> ___
> fpc-pascal maillist  -  

> fpc-pascal@.freepascal

> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

You must treat SDL2.0 as a single threaded library. You can open a window in
any thread , but whichever thread in which you create the window , all
subsequent function calls to SDL2.0 must be made from within that thread ,
including events otherwise strange behavior or crashes will ensue.

Brian



--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/FPC-Graphics-options-tp5728513p5728697.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 17:06:39 +0200 (CEST)
Michael Van Canneyt  wrote:

> And here I was thinking that math is what computers are for... :/
Back in the day, yes.
But nowadays computers do strings.

R.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] List pre-defined defines

[Jon Foster]

On 05/17/2017 05:40 AM, Ewald wrote:

On 16/05/17 23:53, Mattias Gaertner wrote:

touch mytest
fpc -vc mytest

Perhaps a one-liner:
fpc -vc /dev/null

?

Saves one the need to create a dummy file and remove it afterward ;-)

I like it!

--
Sent from my Debian Linux workstation -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
j...@jfpossibilities.com

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 17:07:47 +0200 (CEST)
Michael Van Canneyt  wrote:

> Giving people advice that they should use perl instead of FPC for math is 
> simply insulting.
But Python is ok?

Btw. everyone knows that you do your math in C if you do Python or Perl.

R.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] List pre-defined defines

[Jon Foster]

On 05/17/2017 04:52 AM, Graeme Geldenhuys wrote:

On 2017-05-16 23:25, Jon Foster wrote:

Works good, even without source.


With a source file it gives a few more options.


Thanks Graeme!

--
Sent from my Debian Linux workstation -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
j...@jfpossibilities.com

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] List pre-defined defines

[Sven Barth via fpc-pascal]

Am 18.05.2017 17:47 schrieb "Jon Foster" :
>
> On 05/18/2017 08:46 AM, Jon Foster wrote:
>>
>>
>> On 05/17/2017 05:40 AM, Ewald wrote:
>>>
>>> On 16/05/17 23:53, Mattias Gaertner wrote:

 touch mytest
 fpc -vc mytest
>>>
>>> Perhaps a one-liner:
>>> fpc -vc /dev/null
>>>
>>> ?
>>>
>>> Saves one the need to create a dummy file and remove it afterward ;-)
>>
>> I like it!
>>
> Although that won't work on windoze! ;-)
>

fpc -vc NUL

;)

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

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.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 18, 2017, at 8:23 PM, Graeme Geldenhuys 
>  wrote:
> 
> 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.

I’m making a game now with FPC and that example is pretty disturbing. I haven’t 
had any problems yet (it’s a 2D isometric engine on SDL/OpenGL) but that’s 
going to haunt my dreams anytime something comes up. :) Fortunately there’s no 
reason to write code like that so hopefully FPC is still a good choice for 
making games.

Has there been any good explanation by the compiler team as to why that code 
performed so terribly? I saw there were many optimizations that could be made 
(Floor() is stupid slow for some reason in FPC) but still that’s no excuse. The 
compiler must be doing something really stupid for it mess up like that but how 
can we know?

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 18, 2017, at 8:53 PM, Michael Van Canneyt  
> wrote:
> 
> The complaint of Graeme was that a FPC ray tracer is much slower slower than 
> an equivalent raytracer in Java. All the rest are diversions from the 
> original subject.

That’s right. I’d really like to know what the hell FPC is doing to make it so 
slow (besides the call to Floor()). The compiler team should be worried about 
this also I would think.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-18 15:58, Reimar Grabowski wrote:

A real game would be done differently and then FPC is fast.


Oh, so work around the FPC problem. I get it now. ;-)



Wanne do PacMan in 160x100 resolution, no problem for FPC.


Check.



Wanne do something more modern...


Use Java instead. ;-) Check. Oh wait, that's what I did for that project.

ps:
  I might have a few days free soon (between jobs), then I might dig 
more into this problem. Seeing that everybody is so keen to know.



Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 18, 2017, at 10:05 PM, Graeme Geldenhuys 
>  wrote:
> 
> ps:
>  I might have a few days free soon (between jobs), then I might dig more into 
> this problem. Seeing that everybody is so keen to know.

Please do and keep us informed if you don’t mind. On Mac with ppcx64 the 
program crashed on the line:

plot( x, y, rgbmul( col, fxmul( br, round(ddist) ) ) );

or I would have done this myself this morning.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 09:59:03 +0100
Graeme Geldenhuys  wrote:

> The difference: As explained by somebody after I did a quick google 
> search to save time:
> 
> "
> wolfenstein3d used raycasting. Raycasting is based on sending out a 
> "ray" along each line of sight from the viewer, and incrementally moving 
> along that line of sight until the ray hits an object."

That's a raycasting renderer.
Raycasting in itself is even less.
It's just the act of casting one or multiple rays and checking for 
collisions/intersections for whatever purpose.
Can be used for example for user selection of objects in 3D scenes, collision 
detection of bodies in physics engines or advanced lighting effects.

R.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[noreply]

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

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 15:53:46 +0200 (CEST)
Michael Van Canneyt  wrote:

> Yes, it was.
Don't tell me which mail I replied to, that's just rude.

> The complaint of Graeme was that a FPC ray tracer is much slower slower than 
> an 
> equivalent raytracer in Java. All the rest are diversions from the original 
> subject.
Are you a moderator now?
Graeme never complaint about anything raytracing related. 
Could you at least try to understand the differences between raytracing and 
raycasting, please?
The original subject is about the CRT units. All the rest are diversions from 
the original subject.

I just wanted a little explanation from Marco about one of his sentences and I 
get you with lacking reading comprehension and impolite attitude.
Awesome.

R.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Michael Van Canneyt]

On Thu, 18 May 2017, Reimar Grabowski wrote:


On Thu, 18 May 2017 21:00:48 +0700
Ryan Joseph  wrote:


That’s right. I’d really like to know what the hell FPC is doing to make it so 
slow (besides the call to Floor()). The compiler team should be worried about 
this also I would think.


No, they should not.
It's no real world problem, just a test program. A real game would be done 
differently and then FPC is fast.
People don't do math on computers so raw calculation speed is not important.


And here I was thinking that math is what computers are for... :/

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-18 16:04, Ryan Joseph wrote:

After I looked at the code I didn't see anything strange about it


Thank you, that's what I thought too.


it just got me thinking, if that code can be that slow how slow is
all the stuff I’m writing on a daily basis? It’s just worrying that’s
all.


+1
Thank goodness normal desktop applications are not that sensitive to 
inefficient generated binaries.


Regards,
  Graeme
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 09:02:45 +0100
Graeme Geldenhuys  wrote:

> On 2017-05-17 14:28, Reimar Grabowski wrote:
> > But I don't get why you have to *calculate* *all*.  
> 
> The CPU (your program) calculates all the 3D vertex points, as objects 
> (made out of vertex points) move through the scene. Lots of triangles 
> really.
Nonsense.
Most of the time you just load the vertex positions from file. No calculations 
at all.
And even if you calculate your objects most are static (meaning their vertex 
positions in object space do not change). So they are calculated once and then 
sent to the GPU once.
Animations are mostly done sending scalars/matrices/quaternions as uniforms to 
the corresponding shader.
Skeletal animation may be done on the CPU (if you need the fully transformed 
mesh for anything CPU side, but you seldom do).

> The GPU calculates the individual pixel colors based on those vertex 
> points (using shaders and textures).
You mean fragment colors not pixel colors.

> eg: CPU calculates 3 points of a 
> triangle. 
> The GPU calculates all the points between those 3 points, 
> making up the triangle color.
> 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.
Clipping is done based on the clip-space positions of the vertices after the 
last vertex processing stage.

> So if you work out how many vertex points there are,
Some million for a typical game scene, which makes it sound scary to calculate 
them all every frame when you only have 16ms to do user input 
processing/sound/physics/enemy AI/etc. if you target 60fps. Heck even 32ms is 
not much and that's as low as you can go.

> compared to 
> everything that the GPU has to do (a LOT more points and calculations), 
> the CPU does relatively little in comparison.
And still too much.

So the question remains:

Why do you have to *calculate* *all*?

R.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Michael Van Canneyt]

On Thu, 18 May 2017, Reimar Grabowski wrote:

compared to 
everything that the GPU has to do (a LOT more points and calculations), 
the CPU does relatively little in comparison.

And still too much.

So the question remains:

Why do you have to *calculate* *all*?


Because you want to create an image ? That's what a ray-tracer does AFAIK.

I'm not an expert, but I remember writing POVRay scenes that took forever to
calculate e.g. a chess board with pieces on it. Admittedly, a long time ago.

You assume that you have a GPU to do a lot of work for you because it
renders on screen, but what if you don't want to render the scene on 
screen, but in a bitmap, without GPU...


Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 14:52:25 +0200 (CEST)
Michael Van Canneyt  wrote:

> > Why do you have to *calculate* *all*?  
> 
> Because you want to create an image ? That's what a ray-tracer does AFAIK.
But raytracing isn't the subject here and never was.
Graemes raycasting isn't the subject here either.
 
> I'm not an expert, but I remember writing POVRay scenes that took forever to
> calculate e.g. a chess board with pieces on it. Admittedly, a long time ago.
POVRay is a benchmarking tool ^^

> You assume that you have a GPU to do a lot of work for you...
Yes, because that's what we are talking about.
I replied to this:

"On Wed, 17 May 2017 09:57:11 +0200 (CEST)
mar...@stack.nl (Marco van de Voort) 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."

You see OpenGL is a given, as is the rendering on the GPU.

The question is why do I have to *calculate* *all* vertices that I sent to the 
graphics card.
I am really interested in where this train of thought comes from or if I am 
missing anything because I am quite sure that you don't have to and mostly 
don't do.
But only Marco can tell what he meant with his comment.

> because it renders on screen, but what if you don't want to render the scene 
> on 
> screen, but in a bitmap, without GPU...
Well, if it's without GPU then there surely is no need to "calculate vertices" 
before sending them to the graphics card, or is there?
And personally I would just render the scene in a bitmap with GPU. No reason to 
not use the hardware you are provided on any system down to raspberry pis. But 
rendering to bitmaps is the basis for really boring games. ;)

R.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 08:45:59 -0500
nore...@z505.com wrote:

> On 2017-05-18 07:42, Reimar Grabowski wrote:
> > Camera position?
> > OpenGL has no concept of a camera.  
> 
> When I toyed around with Andorra3D it had some concept/code for a 
> Camera, but he may have added it with his own code, not sure if he used 
> built in directx/opengl code
15+ years of OpenGL here and I can tell you it has no camera and never had one.

R.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Michael Van Canneyt]

On Thu, 18 May 2017, Graeme Geldenhuys wrote:


On 2017-05-18 15:58, Reimar Grabowski wrote:

A real game would be done differently and then FPC is fast.


Oh, so work around the FPC problem. I get it now. ;-)



Wanne do PacMan in 160x100 resolution, no problem for FPC.


Check.



Wanne do something more modern...


Use Java instead. ;-) Check. Oh wait, that's what I did for that project.

ps:
  I might have a few days free soon (between jobs), then I might dig 
more into this problem. Seeing that everybody is so keen to know.


I am, because I do care about speed.

Giving people advice that they should use perl instead of FPC for math is 
simply insulting.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-18 14:21, Reimar Grabowski wrote:

Yes, I get that, but the interesting point is what does the profiler say?
Where are the bottlenecks?


The full source code was posted in the Lazarus Forum (I supplied links 
to those) - so knock yourself out.


Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 14:23:41 +0100
Graeme Geldenhuys  wrote:

> 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.
This we know for years.
The bottlenecks would have been interesting to show if there could be something 
done to improve the situation. Just stating that it's slower doesn't help.

> So lets leave it at that.
Seems to be better.

R.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 20:32:57 +0700
Ryan Joseph  wrote:

> > On May 18, 2017, at 8:23 PM, Graeme Geldenhuys 
> >  wrote:
> The compiler must be doing something really stupid for it mess up like that 
> but how can we know?
By getting the source of Graemes test, using a profiler on it and having a look 
at the results?

R.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 18, 2017, at 7:42 PM, Reimar Grabowski  wrote:
> 
> Nonsense.
> Most of the time you just load the vertex positions from file. No 
> calculations at all.
> And even if you calculate your objects most are static (meaning their vertex 
> positions in object space do not change). So they are calculated once and 
> then sent to the GPU once.
> Animations are mostly done sending scalars/matrices/quaternions as uniforms 
> to the corresponding shader.
> Skeletal animation may be done on the CPU (if you need the fully transformed 
> mesh for anything CPU side, but you seldom do).

I only have some game experience but it’s common to need to perform some sort 
of viewport culling/sorting before you can send the data to OpenGL. As you may 
know you need to format the vertex, texture and color data into an array and 
generating that array can require signification calculations. In my isometric 
engine the sorting process got terribly complicated and CPU intensive, so much 
so in fact it won’t be able to run on mobile like I planned.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 09:23:02 +0100
Graeme Geldenhuys  wrote:

> All this was done using 
> the software raycaster, and Java gives me 40 FPS very consistently in 
> 800x600 resolution (actually 320x200 upscaled to 800x600 - giving the 
> nice pixelated effect).
I don't doubt that Java is fast (actually it's currently my most used language) 
but 320x200 (original Doom resolution) and 40 FPS on your rig is amazingly slow 
as well.

> My code in the Lazarus Forum showed an attempt to simply move (fly) 
> through a much smaller 3D world, but it couldn't come close to the 40 
> FPS mark I saw with Java. As I said, it barely reached 8 FPS.
Yes, I get that, but the interesting point is what does the profiler say?
Where are the bottlenecks?

R.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 22:04:19 +0700
Ryan Joseph  wrote:

> > On May 18, 2017, at 9:58 PM, Reimar Grabowski  wrote:
> > 
> > No, they should not.
> > It's no real world problem, just a test program. A real game would be done 
> > differently and then FPC is fast.  
> 
> Asking honestly, so you don’t think there’s anything troubling about a 8 fps 
> vs 40 fps from the same code? After I looked at the code I didn't see 
> anything strange about it so it just got me thinking, if that code can be 
> that slow how slow is all the stuff I’m writing on a daily basis? It’s just 
> worrying that’s all. 

Honestly, if I would use FPC on a daily basis I would have profiled Graemes 
code the moment it came to my attention but I don't so ...
As my FPC use is currently only hobby I don't care as much.
But to be fair when I coded my little learning 3D OpenGL engine 15+ years ago 
with FPC, I was able to reach nearly the peak performance triangle throughput 
of my card so it was fast enough and nowadays even more calculations be can 
moved to the GPU.
And without joking you can do games in Python just fine if you use your GPU. 
You can do great stuff in the browser as well with WebGL and JS is clearly not 
faster than FPC.

R.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-18 14:45, nore...@z505.com wrote:

When I toyed around with Andorra3D it had some concept/code for a
Camera, but he may have added it with his own code


He must have done it himself. Reimar is correct, OpenGL doesn't have a 
Camera object/view. But in tutorials and texts they often use the 
"concept of a camera" to describe how to set up a scene - that seems to 
give many the false sense that OpenGL has a "camera". It doesn't. :)


Regards,
  Graeme


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] List pre-defined defines

[Marco van de Voort]

In our previous episode, Sven Barth via fpc-pascal said:
> 
> fpc -vc NUL
> 

But I assume that requires executing a shell?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC 64bit for windows

[James Richters]

Thank you for the explanation.  I didn't really understand how to use the cross 
compiler.

I have installed the cross compiler and tried to compile my program with 

ppcrossx64 program.pas

but I get
PaStep.pas(3,98) Fatal: Can't find unit smtpsend used by PAStep

Smtpsend is part of synapse...   I was going to try to copy the library to the 
x86_64-win64 folder but then I thought, wait a minute, I will need the 64bit 
library to get this to work...  but it looks to me like Synapse has only 
support for Win32.  So maybe I'm out of luck with a 64bit version if I'm going 
to use Synapse, unless the cross compiler will take care of this for me?  
Anyone know about this?   

I'm not sure I really need to compile a 64bit version for any reason, it's just 
I don't plan to ever run the program on a 32bit machine, so I'm thinking if I 
have a 64bit machine I might as well have a 64bit program as well and thought 
it might offer a performance advantage.

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Thursday, May 18, 2017 7:39 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC 64bit for windows



On 05/15/2017 02:41 PM, Graeme Geldenhuys wrote:
> On 2017-05-15 11:59, James Richters wrote:
>> When I try to install 64 bit windows
>> version, I don't have this anymore
>
> The Free Pascal project, for some weird reason, only ships a 64-bit 
> Windows cross-compiler. So you need both the 32-bit and 64-bit 
> installs. I don't know why they do this.
Is there an _actual_ problem with that, or is it only imaginary? The
32-to-64 crosscompiler works perfectly fine and has no known disadvantages. On 
the other hand, the 64-bit compiler cannot crosscompile 32-bit fpc, because it 
doesn't support the 80-bit extended float type, which is only supported by the 
x87 FPU, but not by SSE. So, basically, if you're a FPC compiler developer and 
you're using windows as your main platform, the 64-bit native fpc is inferior. 
And I don't think anyone has a problem running a 32-bit hosted compiler on a 
64-bit windows OS - there are simply no known issues with that under any 64-bit 
windows version that I know of.
>
> Simply compile your own _full_ 64-bit FPC, by installing a previous or 
> current stable 32-bit release. Download the latest stable release 
> source code. And then build a new 64-bit target compiler and tools.
Or, alternatively, you can simply install the 32-bit to 64-bit crosscompiler on 
top of your already working install and then crosscompile from the commandline 
with:

  ppcrossx64 program.pas

without any need to compile fpc from sources. It won't work from the IDE, 
though, but compiling your program from the command line, when you want to 
build a 64-bit .exe shouldn't be hard.

Of course, there's no problem in following Graeme's route and compiling the 
compiler yourself (and it might be helpful in the long run to learn how to 
compile the compiler), but installing the already packaged
32-to-64 crosscompiler package might be easier to start with.
>
> It might sound complicate, but the process is pretty easy. Here is a 
> batch file I normally use to do this for me.
>
>
> ...
>
> But again, I don't know why the FPC team doesn't make an official full 
> 64-bit Windows release??
Because it is inferior, since it cannot build a 32-bit FPC. Imagine your advice 
for compiling the 64-bit native compiler, using the 32-bit starting compiler. 
What would happen if you had to go the other way around? Your advice only 
works, because the 32-bit compiler can compile both the 32-bit and 64-bit 
version of FPC. If you were to start with the 64-bit version, it won't be able 
to compile the 32-bit version (under windows, that is; under linux, it works, 
because 64-bit linux has abi support for the 80-bit extended x87 fpu type and 
there we usually ship a native 64-bit compiler). It may not matter for you, but 
is a huge showstopper for any FPC compiler developer that uses Windows.

Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Jon Foster]

On 05/18/2017 08:56 AM, Reimar Grabowski wrote:

On Thu, 18 May 2017 08:40:43 -0700
Jon Foster  wrote:


I limited run time to 10secs, and used "time" to verify actual run time.
Here are the results, time output listed first and the first section of the
gprof output without comments:

A little of topic but did gprof just work like it used to?
I remember last time I tried to profile with gprof I could not get it to work 
and even asked about this on this list and was suggested alternatives.
Has there been something fixed or is it by chance that it works?
It just worked for me. I'm using FPC 3.0.0 with gprof 2.22. Probably an 
older version as I'm still running Debian 7 32bit. If it hadn't just worked 
I wouldn't have been able to post anything more useful in a timely fashion.

The code that is slow appears to be all standard floating point and integer
math

AFAIK floating point math is done using the extended type (as the gprof output 
shows) and there are no optimizations for single or double.
Correct me if I am wrong.



I read that some were having trouble compiling Graeme's code because of SDL 
version differences so I stripped out the SDL code and replaced the timing 
function with traditional time/now calls. I then realized I still had Kylix 
buried in some recess of all these excess terabytes and thought I'd see 
what happens if I compiled the code with that. So I went through another 
set of changes taking out all of the neat FPC C style operators and 
returning them to the traditional ones. And put "inline" declarations and 
other useful FPC defines in ifdefs. I then back ported all of those changes 
into the SDL enabled code just to make sure it still rendered accurately.


You can find both versions in my GitHub account: 
https://github.com/jafcobend/fpcflop


Graeme, I assume you don't mind me reposting that code on GuitHub? If so I 
can take it down.


The headless code when compiled with "fpc -XXs -O3" on my 32bit Linux box 
produces the preset 100 frames in about 32secs, a tad over 3fps. When 
compiled with "dcc" (Kylix v3) using whatever its default optimizations are 
and losing the FPC inlining, runs just slightly faster averaging 29sec for 
the 100 frame runs. Not much better, but not worse either. Kind of thought 
that loss of inlining would have hurt more. Or maybe it does and that's why 
it didn't do much better.--


--
Sent from my Debian Linux workstation -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
j...@jfpossibilities.com

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 18, 2017, at 10:40 PM, Jon Foster  
> wrote:
> 
> 62.44  1.33 1.33 fpc_frac_real
> 26.76  1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
> 10.33  2.12 0.22 FPC_DIV_INT64

Thanks for profiling this.

Floor is there as I expected and 26% is pretty extreme but the others are 
floating point division? How does Java handle this so much better than FPC and 
what are the work arounds? Just curious. As it stands I can only reason that I 
need to avoid dividing floats in FPC like the plague.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC 64bit for windows

[Nikolay Nikolov]

On 05/15/2017 02:41 PM, Graeme Geldenhuys wrote:

On 2017-05-15 11:59, James Richters wrote:

When I try to install 64 bit windows
version, I don't have this anymore


The Free Pascal project, for some weird reason, only ships a 64-bit 
Windows cross-compiler. So you need both the 32-bit and 64-bit 
installs. I don't know why they do this.
Is there an _actual_ problem with that, or is it only imaginary? The 
32-to-64 crosscompiler works perfectly fine and has no known 
disadvantages. On the other hand, the 64-bit compiler cannot 
crosscompile 32-bit fpc, because it doesn't support the 80-bit extended 
float type, which is only supported by the x87 FPU, but not by SSE. So, 
basically, if you're a FPC compiler developer and you're using windows 
as your main platform, the 64-bit native fpc is inferior. And I don't 
think anyone has a problem running a 32-bit hosted compiler on a 64-bit 
windows OS - there are simply no known issues with that under any 64-bit 
windows version that I know of.


Simply compile your own _full_ 64-bit FPC, by installing a previous or 
current stable 32-bit release. Download the latest stable release 
source code. And then build a new 64-bit target compiler and tools.
Or, alternatively, you can simply install the 32-bit to 64-bit 
crosscompiler on top of your already working install and then 
crosscompile from the commandline with:


 ppcrossx64 program.pas

without any need to compile fpc from sources. It won't work from the 
IDE, though, but compiling your program from the command line, when you 
want to build a 64-bit .exe shouldn't be hard.


Of course, there's no problem in following Graeme's route and compiling 
the compiler yourself (and it might be helpful in the long run to learn 
how to compile the compiler), but installing the already packaged 
32-to-64 crosscompiler package might be easier to start with.


It might sound complicate, but the process is pretty easy. Here is a 
batch file I normally use to do this for me.



...

But again, I don't know why the FPC team doesn't make an official full 
64-bit Windows release??
Because it is inferior, since it cannot build a 32-bit FPC. Imagine your 
advice for compiling the 64-bit native compiler, using the 32-bit 
starting compiler. What would happen if you had to go the other way 
around? Your advice only works, because the 32-bit compiler can compile 
both the 32-bit and 64-bit version of FPC. If you were to start with the 
64-bit version, it won't be able to compile the 32-bit version (under 
windows, that is; under linux, it works, because 64-bit linux has abi 
support for the 80-bit extended x87 fpu type and there we usually ship a 
native 64-bit compiler). It may not matter for you, but is a huge 
showstopper for any FPC compiler developer that uses Windows.


Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-18 21:48, Florian Klämpfl wrote:


Well, the reason are the linux calling conventions:


Not sure if it makes any difference, but I was testing under 64-bit 
FreeBSD. I believe on the Lazarus Forum, some folk were using Linux and 
some on Windows.


Over the weekend I’ll verify by testing on both FreeBSD and Windows, and 
then see if “calling conventions” make any difference.





I have some prototype fixes in my local
git mirror, but they are neither finished nor tested.


What I took away from that is You are using Git! ;-)



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC 64bit for windows

[James Richters]

That would be very much appreciated, I don't know why I have such difficulty 
with this.

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Thursday, May 18, 2017 6:02 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC 64bit for windows

On 2017-05-18 22:53, James Richters wrote:
> Is there an easier way to generate a 64bit executable for windows than to 
> compile this myself?

I can zip up my 64-bit FPC 3.0.2 directory and make it available for 
_unofficial_ download if that will help. Let me know, and I'll post a link to 
the download.

Regards,
   Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Florian Klämpfl]

Am 18.05.2017 um 16:00 schrieb Ryan Joseph:
> 
>> On May 18, 2017, at 8:53 PM, Michael Van Canneyt  
>> wrote:
>> 
>> The complaint of Graeme was that a FPC ray tracer is much slower slower than 
>> an equivalent
>> raytracer in Java. All the rest are diversions from the original subject.
> 
> That’s right. I’d really like to know what the hell FPC is doing to make it 
> so slow (besides the
> call to Floor()).

Well, the reason are the linux calling conventions: there are no callee saved 
xmm registers. This
means FPC does not use any single/double register variables. I have some 
prototype fixes in my local
git mirror, but they are neither finished nor tested.

> The compiler team should be worried about this also I would think.

I am not worried, the code on windows is reasonable good as windows has well 
designed calling
conventions making life for a compiler much easier :)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] List pre-defined defines

[Sven Barth via fpc-pascal]

Am 18.05.2017 22:01 schrieb "Marco van de Voort" :
>
> In our previous episode, Sven Barth via fpc-pascal said:
> >
> > fpc -vc NUL
> >
>
> But I assume that requires executing a shell?

If I remember correctly it should not (though I could be wrong of course).

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC 64bit for windows

[James Richters]

I still haven't figured out how to do this.  Is there an easier way to generate 
a 64bit executable for windows than to compile this myself?

I've downloaded fpc-3.0.2.source.zip but I think I'm still not getting the 
directories right or something.   Are there instructions somewhere on how to do 
this?

When I try to do the "Make Clean"  I get
Makefile:29: *** You need the GNU utils package to use this Makefile.  Stop.

I think I am missing something somehow.

James



-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Monday, May 15, 2017 1:57 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC 64bit for windows

On 2017-05-15 18:19, James Richters wrote:
> Could you please give me a link to download 3.0.2 source archive?
> I'm on the FPC sourceforge page but I'm very confused as to what is 
> what.


All downloads can be found from here:

   https://sourceforge.net/projects/freepascal/files/

 From there you click "Source" and then "3.0.2".  ;)

   https://sourceforge.net/projects/freepascal/files/Source/3.0.2/

For Windows you probably want the .zip file so look for:

fpc-3.0.2.source.zip

For Linux/FreeBSD/*nix you probably want the .tar.gz file so look for:

fpc-3.0.2.source.tar.gz

But in actual fact, the FPC compiler will compile either of them without 
problems. I ofter share a source archive between my Linux and Windows VMs.


Regards,
   Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC 64bit for windows

[Graeme Geldenhuys]

On 2017-05-18 22:53, James Richters wrote:

Is there an easier way to generate a 64bit executable for windows than to 
compile this myself?


I can zip up my 64-bit FPC 3.0.2 directory and make it available for 
_unofficial_ download if that will help. Let me know, and I'll post a 
link to the download.


Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] ptcgraph issues

[James Richters]

I've been able to figure out a few workarounds for issues with ptcgraph,

 

To prevent scaling and dropped pixels, I have come up with 3 workarounds,
not ideal but they could work:

 

1.  Positon the window so the title is off the top of the screen with

   SetWindowPos(Graphicwindow,HWND_TOP,-8,-31,0,0,SWP_NoSize);

   I cannot use maximize with this and the coordinates for the
top left corner might be different on different machines.  

   I think my development computer is strange because of having
3 monitors

 

2.  Leave the title bar on with the window sized correctly, but set my
own variables to not use the bottom of the window which

is off the screen so it looks right with

SetWindowPos(Graphicwindow,HWND_TOP,-8,0,0,0,SWP_NoSize);

WinMax_Y:=GetMaxY-31;  

   Then I use WinMax_Y instead of GetMaxY

   This has the same problem as option #1 in that the
coordinates for the top left of the screen might not be the same on other
machines

   I haven't been able to find a really good solution to keeping
the titlebar and having the window the right size and being able to use
maximize. 

   I think the only way will be for ptcgraph to create the
window sized so maximized it fits completely on the screen with the titlebar
and then report a smaller GetMaxY

 

3.  Turn off the title bar, then reset the size of the window to be
correct with:

 SetWindowLongPTR(graphicwindow, GWL_STYLE, 0);

 SetWindowPos(Graphicwindow,HWND_TOP,0,0,GetMaxX+1,GetMaxY+1,0);

 ShowWindow(graphicwindow, SW_Maximize);

If you don't want the titlebar then this is the best solution because the
Maximize will make it fit properly on the screen regardless of 

How it is configured.

 

 

The only other issue I am having is the problem where task switching with
ALT-Tab causes the keyboard not to respond to ptccrt anymore.  I have
narrowed this down a bit,  it's NOT task switching in general that causes
this, it's specifically ALT-TAB that causes it.   I was also mistaken about
it only happening with full screen, this happens all the time, no matter how
the window is configured.  If I hit the windows logo key and task switch
that way , there is no problem when I go back to the ptcgraph window, also
if I get back to my console window with 

 ShowWindow(ConsoleWindow,SW_show);

 SetActiveWindow(ConsoleWindow);

 SetForegroundWindow(ConsoleWindow);

And alt tab from the console window, then no matter what method I use to get
back to the ptcgraph window, even alt-tab,  it's no problem and ptccrt
responds to the keyboard.

 

So that's where I'm at with this.  It would be great if better solutions can
be found for these issues.  The main thing for me is the ALT-Tab issue,
especially if I go with option 3 above where I won't have a minimize button.
Alt-tab is a really big habit because as I mentioned before, most of the
computer I run this on don't have a mouse attached.   If I could disable
alt-tab from this window somehow, then at least I wouldn't accidentally
break keyboard response to the ptcgraph window, but I don't know how I could
do that either.

 

James

 

 

From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf
Of James Richters
Sent: Wednesday, May 17, 2017 4:19 PM
To: 'FPC-Pascal users discussions' 
Subject: [fpc-pascal] ptcgraph issues

 

I'm having a few issues with ptcgraph.  

 

The main issue is that it's not correctly reporting the actual size of the
available area to use inside the ptcgraph window.  It's reporting my full
screen resolution, but that amount of space is not really available due to
the title bar.   The window that is generated is a 1919x1176 window, but it
won't fit on the screen due to the title bar, so I hit maximize, now it fits
on the screen but it's too small.   I generate my screen based off the
GetMaxX and GetMaxY functions and my screen based on GetMaxX being 1919 and
GetMaxY being 1199 should not fit inside a window that fills the screen but
with a border around it and a title bar at the top, but it is being scaled
down to fit.  This scaling is causing pixels to be dropped.   If I force
GetMaxX and GetMaxY to be the correct numbers of 1919x1176 which is what the
graph unit reports, It just leaves a gap at the bottom of the screen the
same width as the title bar, and still scales the screen from 1919x1199 down
to fit in the available space of 1919x1176 making some pixels drop.I
have tried maximizing the screen with ShowWindow(graphwindow, SW_Maximize);
before I use GetMaxX and GetMaxY, but they still report the full screen
size.   

 I can get the screen to look right with no scaling and no dropped pixels if
I use SetWindowPos(Graphicwindow,HWND_TOP,-8,-32,0,0,swp_nosize); to
position the window so the title bar is off the top of the screen,  but as
you can see my X and Y 

Re: [fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 19, 2017, at 8:01 AM, Jon Foster  wrote:
> 
> You can find both versions in my GitHub account: 
> https://github.com/jafcobend/fpcflop

Thanks again, I was finally able to get this complied. No idea why the 
inclusion of SDL 2 was crashing at that line.

The profiler on Mac seems to be incomplete and is telling me 23% in Floor and 
3.8% in FPC_DIV_INT64 which is not what you’re getting. If I remove floor I 
don’t get any more interesting information from it besides FPC_DIV_INT64.

with floor:

Seconds: 11.66   fps: 8.6

without floor (replaced to trunc):

Seconds: 9.34   fps: 10.7

replacing sin+cos with sincos added 2 fps but that’s not really the issue here. 
Your profiling says FPC barfed with the math and I’d like to know why.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 19, 2017, at 3:48 AM, Florian Klämpfl  wrote:
> 
> Well, the reason are the linux calling conventions: there are no callee saved 
> xmm registers. This
> means FPC does not use any single/double register variables. I have some 
> prototype fixes in my local
> git mirror, but they are neither finished nor tested.

Can you please explain how do calling conventions affect this? I failed to run 
this at all on my Mac but I’m not sure why and even more confused how this 
would decimate speeds like this.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Reimar Grabowski]

On Thu, 18 May 2017 20:38:44 +0700
Ryan Joseph  wrote:

> I only have some game experience but it’s common to need to perform some sort 
> of viewport culling/sorting before you can send the data to OpenGL.
In general there is no sorting needed and culling is better done on mesh level 
than vertex level.
Culling can be really fast if you do it correctly and don't overdo it.
Sending everything you want to draw every frame is definitely wrong for most 
applications.

R.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 18, 2017, at 9:19 PM, Reimar Grabowski  wrote:
> 
> By getting the source of Graemes test, using a profiler on it and having a 
> look at the results?

I tried (had to change the code to support SDL 2 even) but gave up after it 
crashed on one line. Graeme suggested a staggering difference in performance 
and I was extremely curious to see if those calls to Floor() were causing it. 
Hopefully this was a red herring and FPC isn’t as bad as the test suggests.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Florian Klämpfl]

Am 18. Mai 2017 11:59:30 nachm. schrieb Graeme Geldenhuys
:

> On 2017-05-18 21:48, Florian Klämpfl wrote:
>>
>> Well, the reason are the linux calling conventions:
>
> Not sure if it makes any difference, but I was testing under 64-bit
> FreeBSD. I believe on the Lazarus Forum, some folk were using Linux and
> some on Windows.
>
> Over the weekend I’ll verify by testing on both FreeBSD and Windows, and
> then see if “calling conventions” make any difference.

*BSD is the same as Linux.

>
>
>
>> I have some prototype fixes in my local
>> git mirror, but they are neither finished nor tested.
>
> What I took away from that is You are using Git! ;-)

It has its purposes, but it is not suitable for the main repository of FPC.
And actually, if I had not used git, the patches would be already in trunk
because I would be forced to clean up my working copy. With git I just
commit unfinished stuff to a branch and forget about it. It is not a
technical thing but just a matter of mind :-)

>
>
>
> Regards,
>Graeme
>
> --
> fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
> http://fpgui.sourceforge.net/
>
> My public PGP key:  http://tinyurl.com/graeme-pgp
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal