Re: [fpc-pascal] FPC Graphics options?

On Saturday 27 May 2017 03:37:59 Ryan Joseph wrote: > > Is MSElang another Pascal compiler? I’ve never heard of it. I know LLVM is > being used by Apple for Objective-C/Swift (I think) but for Pascal? > https://gitlab.com/mseide-msegui/mselang/wikis/home Martin

Re: [fpc-pascal] FPC Graphics options?

> On May 24, 2017, at 11:47 PM, Martin Schreiber wrote: > > MSElang, LLVM 3.8.0 > No options -> 4.2 FPS > -O3 -> 5.9 FPS > -O3 -mcpu=corei7 -mattr=+sse3,+ssse3 -> 33.5 FPS > > With trunci32() operations >

Re: [fpc-pascal] FPC Graphics options?

seems fpc faster than llvm on -O3/4 only . this is a good news :) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

On Saturday 20 May 2017 21:34:34 Jonas Maebe wrote: > > Also in summary, very little was learned from this. We have known for a > long time that FPC needs SSA for better code generation for loops (and > Florian has been working on it for a long time too). > Here for comparison the results of FPC /

Re: [fpc-pascal] FPC Graphics options?

:40 PM To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org> Subject: Re: [fpc-pascal] FPC Graphics options? Just like you now use -FuSomePath to tell the compiler where to find units, you can use -FiSomePath to tell the compiler where to look for include files. I've been

Re: [fpc-pascal] FPC Graphics options?

. James -Original Message- From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of James Richters Sent: Tuesday, May 23, 2017 5:40 PM To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org> Subject: Re: [fpc-pascal] FPC Graphics options? >

Re: [fpc-pascal] FPC Graphics options?

07 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] FPC Graphics options? On 05/23/2017 08:28 PM, James Richters wrote: I have done the "download snapshot" but I just don't know what to do with it now to properly integrate it into my compiler. Follow the instructions in docs/INST

Re: [fpc-pascal] FPC Graphics options?

>Just like you now use -FuSomePath to tell the compiler where to find units, >you can use -FiSomePath to tell the compiler where to look for include files. I've been trying to compile with Free Pascal Text IDE, I have no experience with compiling programs from the command line, but this gave

Re: [fpc-pascal] FPC Graphics options?

Am 23.05.2017 um 05:15 schrieb Ryan Joseph: > and compiling with -O2 -Cfsse3 (the non-SDL If you do benchmarking, at least -O3 should be used, -O4 is also fine most of the time. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] FPC Graphics options?

t: Tuesday, May 23, 2017 2:07 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] FPC Graphics options? On 05/23/2017 08:28 PM, James Richters wrote: > I have done the "download snapshot" but I just don't know what to do with it > now to properly integrate it into

Re: [fpc-pascal] FPC Graphics options?

On 05/22/2017 07:13 PM, James Richters wrote: The problem is not the ALT-tab from the graphics window, it's ALT being pressed when the window focus changes. CTRL is also affected, but not shift. this is really sounding like a problem i remember from early GUIs several decades ago... when

Re: [fpc-pascal] FPC Graphics options?

Original Message- From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of James Richters Sent: Monday, May 22, 2017 7:13 PM To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org> Subject: Re: [fpc-pascal] FPC Graphics options? Here is a simp

Re: [fpc-pascal] FPC Graphics options?

t: Tuesday, May 23, 2017 1:03 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] FPC Graphics options? On 05/23/2017 06:09 PM, James Richters wrote: > I think I figured out my problem, but I'm not sure how to fix it. I was > looking at the code here: https://sourceforge.n

Re: [fpc-pascal] FPC Graphics options?

From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of James Richters Sent: Monday, May 22, 2017 7:13 PM To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org> Subject: Re: [fpc-pascal] FPC Graphics options? Here is a simple sample program that has the issu

Re: [fpc-pascal] FPC Graphics options?

Sent: Monday, May 22, 2017 7:13 PM To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org> Subject: Re: [fpc-pascal] FPC Graphics options? >Here is a simple sample program that has the issue for me on both my windows >10 desktop and my windows 10 laptop, both are 6

Re: [fpc-pascal] FPC Graphics options?

On 2017-05-22 23:11, nore...@z505.com wrote: What happens if you use the SVN bridge that allows you to run svn commands to a git server? does git suffer the same problems in this mode too? Replied in "fpc-other" mailing list. Regards, Graeme ___

Re: [fpc-pascal] FPC Graphics options?

> On May 22, 2017, at 9:24 PM, Marco van de Voort wrote: > > I saw Florian worked hard last weekend, and the new value is 23.0 - 23.6 > (was 19.1 - 19.5) for x86_64. Sometimes floating point division by zero. > > and for x86 10.8 but half of the time I get an exception (ctrl-C

Re: [fpc-pascal] FPC Graphics options?

I realized I should have posted this in fpc-other. So, please reply in [fpc-other] and not here. On 05/23/2017 03:03 AM, Nikolay Nikolov wrote: On 05/23/2017 01:20 AM, nore...@z505.com wrote: On 2017-05-18 19:54, Ryan Joseph wrote: On May 18, 2017, at 10:40 PM, Jon Foster

Re: [fpc-pascal] FPC Graphics options?

>Here is a simple sample program that has the issue for me on both my windows >10 desktop and my windows 10 laptop, both are 64bit. >https://hastebin.com/nubonozaho.pas I started thinking about this, and did some more tests, and I think I have narrowed down what is really happening, but not

Re: [fpc-pascal] FPC Graphics options?

On 2017-05-18 19:54, Ryan Joseph wrote: 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

Re: [fpc-pascal] FPC Graphics options?

On 2017-05-19 05:25, Graeme Geldenhuys wrote: On 2017-05-19 06:58, Florian Klämpfl wrote: 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. Good to know, thanks. It has its purposes,

Re: [fpc-pascal] FPC Graphics options?

On 2017-05-19 06:16, Graeme Geldenhuys wrote: On 2017-05-18 16:33, Reimar Grabowski wrote: and JS is clearly not faster than FPC. The JavaScript version runs very smooth on my system. There is no framerate counter though, so I don't know how much faster. http://jsdo.it/notch/dB1E Again,

Re: [fpc-pascal] FPC Graphics options?

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.

Re: [fpc-pascal] FPC Graphics options?

Hi, On Mon, 22 May 2017, Nikolay Nikolov wrote: > Today, I checked whether we can take advantage of this optimization for > floats, but I didn't see any load-modify-store instructions in the x86 > instruction set (neither x87, nor SSE/AVX). Are there any floating point > instructions on any

Re: [fpc-pascal] FPC Graphics options?

Am 22.05.2017 um 19:34 schrieb Nikolay Nikolov: > > > On 05/20/2017 12:07 AM, Nikolay Nikolov wrote: >> >> >> On 05/19/2017 11:24 PM, Sven Barth via fpc-pascal wrote: >>> On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote: Hi, On Fri, 19 May 2017, Sven Barth via fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

On 05/20/2017 12:07 AM, Nikolay Nikolov wrote: On 05/19/2017 11:24 PM, Sven Barth via fpc-pascal wrote: On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote: Hi, On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote: I think Jeppe wanted to add vector support. Though the question here

Re: [fpc-pascal] FPC Graphics options?

In our previous episode, Marco van de Voort said: > > i386: > just compile : 7.9 (both 3.0.2 and 3.1.1) > -O4 3.0.2: 8.2 3.1.1: 8.1 > -O4 -Opcoreavx2 -Cfavx2 -Cpcoreavx2 3.0.2 8.35 3.1.1 : 12.1 > > > x64: only 3.1.1, sometimes divide by zero (have to set exception mask?) >

Re: [fpc-pascal] FPC Graphics options?

On 05/16/2017 02:45 PM, Nikolay Nikolov wrote: Tonight I'll also add the option for changing the title bar text, when in windowed mode. Implemented in r715. Note that you still cannot change the window title, after the window has been created, but at least now you can set it (in a

Re: [fpc-pascal] FPC Graphics options?

On 21/05/17 14:58, Felipe Monteiro de Carvalho wrote: Well, Java also has its issues. Please move that kind of posts to the fpc-other mailing list. Thanks. Jonas FPC mailing lists admin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] FPC Graphics options?

On Thu, May 18, 2017 at 5:05 PM, Graeme Geldenhuys wrote: > Use Java instead. ;-) Check. Oh wait, that's what I did for that project. Well, Java also has its issues. I am studying Java and I am completely shocked that you need to use "volatile" to avoid serious

Re: [fpc-pascal] FPC Graphics options?

On 21/05/17 10:35, Florian Klämpfl wrote: Am 20.05.2017 um 23:15 schrieb Sven Barth via fpc-pascal: At least if the compiler also recognizes that oy and oz are constant... If the typed constants are declared as read only, we could treat them as real constants. Maybe at least in -O4 mode?

Re: [fpc-pascal] FPC Graphics options?

On 05/21/2017 06:34 AM, Ryan Joseph wrote: I just compiled with ppcx64 3.1.1 (from 3.0.2) and went from 8fps to 22fps without optimizations and 28fpc with (I got some divide by zero errors but that’s just translations). What is that about? What changed? Just curious, why isn’t -Cfsse3

Re: [fpc-pascal] FPC Graphics options?

Am 20.05.2017 um 23:15 schrieb Sven Barth via fpc-pascal: > On 20.05.2017 21:34, Jonas Maebe wrote: >> There's at least one minor twist of the classic "C compiler evaluates >> constant stuff at compile time": >> 1) oy and oz are constant. The "floor" function is a standard C library >> function,

Re: [fpc-pascal] FPC Graphics options?

> On May 21, 2017, at 2:34 AM, Jonas Maebe wrote: > The Pascal test program that was benchmarked here contains a number of > bugs/wrong translations from the C code (some stem from the original version, > another one was added): Thanks for looking this over. I’m

Re: [fpc-pascal] FPC Graphics options?

On 20.05.2017 21:34, Jonas Maebe wrote: > There's at least one minor twist of the classic "C compiler evaluates > constant stuff at compile time": > 1) oy and oz are constant. The "floor" function is a standard C library > function, and hence C compilers know what it does and can evaluate it at >

Re: [fpc-pascal] FPC Graphics options?

Am 20.05.2017 um 21:34 schrieb Jonas Maebe: > Also in summary, very little was learned from this. We have known for a long > time that FPC needs SSA > for better code generation for loops (and Florian has been working on it for > a long time too). Actually, this is not completely true :) What

Re: [fpc-pascal] FPC Graphics options?

On 19/05/17 02:54, Ryan Joseph wrote: 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

Re: [fpc-pascal] FPC Graphics options?

On 05/19/2017 06:13 PM, Jon Foster wrote: On 05/19/2017 04:11 AM, Nikolay Nikolov wrote: On 05/19/2017 03:54 AM, Ryan Joseph wrote: 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

Re: [fpc-pascal] FPC Graphics options?

On 05/19/2017 04:11 AM, Nikolay Nikolov wrote: On 05/19/2017 03:54 AM, Ryan Joseph wrote: 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

Re: [fpc-pascal] FPC Graphics options?

Am 19.05.2017 22:24 schrieb "Sven Barth" : > > On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote: > > Hi, > > > > On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote: > > > >> I think Jeppe wanted to add vector support. Though the question here is > >> whether

Re: [fpc-pascal] FPC Graphics options?

On 05/19/2017 11:24 PM, Sven Barth via fpc-pascal wrote: On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote: Hi, On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote: I think Jeppe wanted to add vector support. Though the question here is whether one wants to optimize/detect this at

Re: [fpc-pascal] FPC Graphics options?

On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote: > Hi, > > On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote: > >> I think Jeppe wanted to add vector support. Though the question here is >> whether one wants to optimize/detect this at the AST level and convert >> that to implicit

Re: [fpc-pascal] FPC Graphics options?

Hi, On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote: > I think Jeppe wanted to add vector support. Though the question here is > whether one wants to optimize/detect this at the AST level and convert > that to implicit vectors or at the CSE level. I think the higher level you can do an

Re: [fpc-pascal] FPC Graphics options?

In our previous episode, Sven Barth via fpc-pascal said: > > > > I also tried -Oofastmath, but to no avail. (floor is still external, and > > still double) > > Floor is not declared as inline and even the Trunc()/Frac() intrinsics it > uses wouldn't be inlined as they're assembler routines and

Re: [fpc-pascal] FPC Graphics options?

Am 19.05.2017 16:39 schrieb "Karoly Balogh (Charlie/SGR)" < char...@scenergy.dfmk.hu>: > > Hi, > > On Fri, 19 May 2017, Reimar Grabowski wrote: > > > 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 >

Re: [fpc-pascal] FPC Graphics options?

Am 19.05.2017 15:29 schrieb "Marco van de Voort" : > > In our previous episode, Sven Barth via fpc-pascal said: > > > > You only compiled the program with SSE, but not the RTL. And to completely > > avoid the x87 FPU you additionally need to fiddle around with some > >

Re: [fpc-pascal] FPC Graphics options?

On 05/18/2017 07:21 PM, Ryan Joseph wrote: 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

Re: [fpc-pascal] FPC Graphics options?

Hi, On Fri, 19 May 2017, Reimar Grabowski wrote: > 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. Well, if

Re: [fpc-pascal] FPC Graphics options?

In our previous episode, Sven Barth via fpc-pascal said: > > You only compiled the program with SSE, but not the RTL. And to completely > avoid the x87 FPU you additionally need to fiddle around with some > defines/code inside the compiler as well. Hmm. in addition to my earlier benchmarks, the

Re: [fpc-pascal] FPC Graphics options?

On Fri, 19 May 2017 14:34:40 +0200 (CEST) mar...@stack.nl (Marco van de Voort) wrote: >[...] > Not the point, the point is, does javascript generate exceptions on division > by zero by default? No. It creates Infinity. Mattias ___ fpc-pascal maillist

Re: [fpc-pascal] FPC Graphics options?

On Fri, 19 May 2017 12:32:17 +0100 Graeme Geldenhuys 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

Re: [fpc-pascal] FPC Graphics options?

Am 19.05.2017 12:51 schrieb "Mattias Gaertner" : > > On Fri, 19 May 2017 10:54:25 +0200 > Sven Barth via fpc-pascal wrote: > > >[...] > > Even though FPC might use SSE for maths it will still use the x87 to > > transfer floating values

Re: [fpc-pascal] FPC Graphics options?

Am 19.05.2017 13:32 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2017-05-19 12:11, Nikolay Nikolov wrote: >> >> In FPC, if you want to use SSE and >> avoid the x87 FPU, you have to compile with a specific compiler options >> and forfeit the option for your executable to run

Re: [fpc-pascal] FPC Graphics options?

In our previous episode, Graeme Geldenhuys said: > > Then maybe the original code was DESIGNED for gcc and/or java ? > > Now you are taking the piss! > > The code I worked from was JavaScript actually. I posted the link a > couple minutes ago. Translating the JavaScript code to Object Pascal

Re: [fpc-pascal] FPC Graphics options?

On 2017-05-19 13:14, Karoly Balogh (Charlie/SGR) wrote: Ps: can someone direct me to the right code you are discussing? Forwarded Message Subject: Re: [fpc-pascal] FPC Graphics options? Date: Fri, 12 May 2017 18:29:05 +0100 From: Graeme Geldenhuys <mk> To: fpc-

Re: [fpc-pascal] FPC Graphics options?

On 2017-05-19 12:43, Marco van de Voort wrote: Then maybe the original code was DESIGNED for gcc and/or java ? Now you are taking the piss! The code I worked from was JavaScript actually. I posted the link a couple minutes ago. Translating the JavaScript code to Object Pascal was a manual

Re: [fpc-pascal] FPC Graphics options?

Hi, On Fri, 19 May 2017, 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

Re: [fpc-pascal] FPC Graphics options?

In our previous episode, Graeme Geldenhuys said: > Bottom line is, with the exact same code, NO work-arounds is required > for GCC or Java! Then maybe the original code was DESIGNED for gcc and/or java ? > So why must we have work-arounds for FPC? The language is different. E.g. I get

Re: [fpc-pascal] FPC Graphics options?

In our previous episode, Jon Foster said: > > 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

Re: [fpc-pascal] FPC Graphics options?

On 2017-05-19 12:11, Nikolay Nikolov wrote: In FPC, if you want to use SSE and avoid the x87 FPU, you have to compile with a specific compiler options and forfeit the option for your executable to run on non-SSE capable CPUs, because FPC generates native code. If you want to keep All good and

Re: [fpc-pascal] FPC Graphics options?

On 2017-05-19 12:16, Graeme Geldenhuys wrote: The JavaScript version runs very smooth on my system. ps: And it doesn't use WebGL either. Simply blitting of a memory image to the canvas. Regards, Graeme ___ fpc-pascal maillist -

Re: [fpc-pascal] FPC Graphics options?

On 05/19/2017 02:11 PM, Nikolay Nikolov wrote: On 05/19/2017 03:54 AM, Ryan Joseph wrote: 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

Re: [fpc-pascal] FPC Graphics options?

On 2017-05-18 16:33, Reimar Grabowski wrote: and JS is clearly not faster than FPC. The JavaScript version runs very smooth on my system. There is no framerate counter though, so I don't know how much faster. http://jsdo.it/notch/dB1E Again, what does that say about FPC generated binary

Re: [fpc-pascal] FPC Graphics options?

On 05/19/2017 03:54 AM, Ryan Joseph wrote: 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

Re: [fpc-pascal] FPC Graphics options?

On Fri, 19 May 2017 10:54:25 +0200 Sven Barth via fpc-pascal wrote: >[...] > Even though FPC might use SSE for maths it will still use the x87 to > transfer floating values to/from function, especially if they take Extended > as parameter/result. Can you

Re: [fpc-pascal] FPC Graphics options?

On 2017-05-19 06:58, Florian Klämpfl wrote: 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. Good to know, thanks. It has its purposes, but it is not suitable for the main repository

Re: [fpc-pascal] FPC Graphics options?

Am 19.05.2017 03:30 schrieb "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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

> 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.

Re: [fpc-pascal] FPC Graphics options?

> 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

Re: [fpc-pascal] FPC Graphics options?

> 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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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.

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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()

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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 -

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

> 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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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. ;-)

Re: [fpc-pascal] FPC Graphics options?

> 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

Re: [fpc-pascal] FPC Graphics options?

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.

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

> 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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

  1   2   >