Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

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

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

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 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] List pre-defined defines

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

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] List pre-defined defines

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

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] List pre-defined defines

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

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

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

> 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

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

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

Re: [fpc-pascal] FPC Graphics options?

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

Re: [fpc-pascal] FPC Graphics options?

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

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

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

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

Re: [fpc-pascal] FPC Graphics options?

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

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 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] List pre-defined defines

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

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

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

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 64bit for windows

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

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] List pre-defined defines

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

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

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

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

Re: [fpc-pascal] ptcgraph issues

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

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

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