I have managed to get ptcgraph and ptccrt to work with my program and I can report that there is an AMAZING increase in graphics performance! It is pretty much a drop in replacement and I did not change any compiler settings. I did have to make a few minor changes to get it to work, not enough to change the speed of anything.
I am getting an error 217 access violation when I try to use outtextXY after a SetTextJustify(2,2); (Top, Right justify) but with the graph unit my text was in the correct place and not off the screen. I also no longer have the 'graphwindow' handle variable so I had to comment out anything that was using it like SetWindowTextA(graphicwindow,graphwindowtext); And ShowWindow(graphwindow, SW_SHOW); So I just commented them out for now. I'm hoping there is a way to get around the graphwindow variable because I was using the above 2 functions and I don't know how else to determine the graphic window handle... but the performance gain and ease of implementation will make working out any other issues worth the effort. Any advice on how I can capture the graph window handle would be appreciated Thank you for the help with this. Jim -----Original Message----- From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of nore...@z505.com Sent: Monday, May 15, 2017 5:50 PM To: FPC-Pascal users discussions <fpc-pascal@lists.freepascal.org> Subject: Re: [fpc-pascal] FPC Graphics options? On 2017-05-15 01:02, Sven Barth via fpc-pascal wrote: >>> Wow, Graeme! That's harsh. One of the last set of benchmarks I did >>> that focused on integer math and procedure call speed came out as >>> follows: >> >> >> I think he specifically meant graphics apps, not general apps > > While a raytracer is indeed a graphics app it's mainly about CPU > computation in this case and not interfacing with the GPU like OpenGL > does (of course one can write a raytracer to take advantage of the > parallel architecture of a GPU, but that's bot the case in this > specific example). > Graeme will need to clarify whether he was trying to be harsh on FPC entirely, or just specifically in some areas.. :-) But Nikolay Nikolov's replacement unit should tell if fpc is as fast as turbopascal, as he claims it is a direct replacement and is super fast.... Then it's not fpc's fault but some problem in the default unit that was not optimized? I don't know, never tried Nikolay's unit. But that also depends on whether Graeme was using that code from that unit too. Any claims that something is slow depends entirely on 1 million parameters... Then there are even those projects out there like FastMM but that's probably another aside unrelated _______________________________________________ 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
