Re: [fpc-pascal] FPC 64bit for windows
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 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? You'll need to compile synapse from source then using the cross compiler (I doubt that they don't support Win64). Btw: instead of calling "ppcross64.exe ..." you can also use "fpc -Px86_64 ..." 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?
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
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. 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] 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 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 coordinates are screwy. it's something to
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 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?
> 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 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 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 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 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 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
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 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 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
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 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
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] 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
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 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
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 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 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
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?
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] 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 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?
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?
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] 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 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] 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 -- 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
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] 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 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?
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] 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 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?
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] 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 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?
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?
> 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?
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?
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?
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?
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?
> 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. 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?
> 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?
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?
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?
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?
> 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?
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?
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?
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?
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?
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?
> 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?
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?
> 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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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