Am 19.05.2017 02:22 schrieb "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 uni
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 usin
> 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 in
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(Graphicwin
> 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 neit
> 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
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
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..
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-
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
Subj
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 dow
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 testi
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
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
__
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
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
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
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
>>>
>>> ?
>>>
>
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.
___
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 d
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 t
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() u
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 tha
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://w
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
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 l
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
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?
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 te
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
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-pa
> 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 crashe
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
Th
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 som
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, th
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. ;-) Chec
> 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
> 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 differenc
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, jus
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
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 Poi
> 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
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
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
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 lo
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
>
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
> 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
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
> 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
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 incremental
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.
Graeme
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.
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
_
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
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 (actua
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
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. Lo
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:
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
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 p
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
62 matches
Mail list logo
