[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 do with my multiple monitors why top left is not 0,0 So I have no way of knowing what to set this to on any given system, so it's not really a solution at all. it just proves what the problem is. So I thought I would force it to be full screen, to see if I could prevent the scaling.. but that also has issues. I figured if it looks right shifting the title bar off the top of the screen, then simply shutting off the title bar should fix it, but I could not get that to work either. There are 2 ways I can get full screen without the title bar that I can think of. I can just shut off all windows styles withSetWindowLongPTR(graphwindow, GWL_STYLE, 0); but this has the opposite problem, If I draw a rectangle from 0,0 to GetMaxX,GetMaxY, I should get a rectangle that barely fits on the screen, but I don't see anything because it's way too big. I have to draw a rectangle from 8,8 to GetMaxX-8,GetMaxY-8 to get it to fit on the screen.However with this method of getting rid of the titlebar, I can taskswitch out and back in with no issues, my keyboard still works and if I taskswitch out, it just puts other windows on top of this, so I can always click on it to make it active again. The scaling causes things to not look right. If I get the full screen by setting fullscreengraph := True; then it does seem to report stop scaling and now everything fits correctly on the screen, however. this has it's own issues. For some reason when I use this to obtain full screen, it does not task switch anywhere near as gracefully as using SetWindowLongPTR(graphwindow, GWL_STYLE, 0);If I task switch to anything else, the graph window disappears completely, so now I have nothing to click on to get it back, and using ShowWindow() to get it back takes a very long time. Then when I eventually get the window back, it no longer responds to the keyboard. James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Size of program vs library ?
On Wed, 17 May 2017, fredvs wrote: Michael Van Canneyt wrote You didn't even file an official request in the bugtracker ? Because I tried already and because I know the (rejected) answer. Where is this bugreport ? I was talking about earlier other requests. Each case is always judged separately. But now, if you think that the request has a little chance to be considered, I will sent a bugreport with great pleasure, To the best of my knowledge, we only refuse requests if there is (for us) a good reason. Until now, I see no reason why we would refuse your request ? I do still think that we need to investigate it somewhat more thoroughly. So if you submit a request, you actually improve the probability it gets looked at and subsequently added... If you could add a sample library project with some resources (they need not necessarily be forms), then this would help us investigate the case. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Crosscompiler for Arm Cortex A7
Hi, On Windows 7 I have build FPC crosscompiler for Moxa UC-8410A with Arm Cortex A7 microprocessor with following: set PPBINDIR=c:\FPC\3.0.2\bin\i386-win32 set SRCDIR=c:\FPC\3.0.2 set INSTDIR=c:\FPC\pp84a set MYCFG=uc84a.cfg set HH=i386-win32 make clean all install CROSSINSTALL=1 NOGDB=1 OS_TARGET=linux CPU_TARGET=arm OPT="-dFPC_ARMHF" CROSSOPT="-dFPC_ARMHF -CpARMV7A -CaEABIHF -CfVFPV3" INSTALL_PREFIX=%INSTDIR% PP=%PPBINDIR%\fpc.exe CROSSBINDIR=%INSTDIR%\bin\%HH% BINUTILSPREFIX=arm-linux-gnueabihf- Cross binutils are from http://gnutoolchains.com/raspberry/ (raspberry-gcc4.9.2-r4.exe) When I crosscompile one of my project, I get errors from assembler: [0.417] Assembling v8par [0.417] Executing "c:\FPC\pp84a\bin\i386-win32\arm-linux-gnueabihf-as.exe" with command line "-mfloat-abi=hard -meabi=5 -march=armv7-a -mfpu=vfpv3 -o lib\uc8410a\v8par.o lib\uc8410a\v8par.s" lib\uc8410a\v8par.s: Assembler messages: lib\uc8410a\v8par.s:3386: Error: garbage following instruction -- `blx V8$_$TV8LIST_$__$$_GET$LONGINT$$TV8DATA' lib\uc8410a\v8par.s:3500: Error: garbage following instruction -- `blx V8$_$TV8LIST_$__$$_GETCOUNT$$LONGINT' lib\uc8410a\v8par.s:3733: Error: garbage following instruction -- `blx V8$_$TV8SETSTRINGPARAM_$__$$_CREATE$LONGINT$LONGINT$LONGINT$ANSISTRING$$TV8SETSTRINGPARAM' lib\uc8410a\v8par.s:3736: Error: garbage following instruction -- `blx V8$_$TV8LIST_$__$$_ADD$TV8DATA' lib\uc8410a\v8par.s:3758: Error: garbage following instruction -- `blx V8$_$TV8SETFLOATPARAM_$__$$_CREATE$LONGINT$LONGINT$LONGINT$DOUBLE$$TV8SETFLOATPARAM' lib\uc8410a\v8par.s:3761: Error: garbage following instruction -- `blx V8$_$TV8LIST_$__$$_ADD$TV8DATA' [0.432] v8par.pas(745) Error: Error while assembling exitcode 1 [0.433] v8par.pas(745) Fatal: There were 2 errors compiling module, stopping Is crosscompiler build with wrong options or is something else ? Thanks. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Size of program vs library ?
Michael Van Canneyt wrote >>> You didn't even file an official request in the bugtracker ? >> >> Because I tried already and because I know the (rejected) answer. > > Where is this bugreport ? I was talking about earlier other requests. But now, if you think that the request has a little chance to be considered, I will sent a bugreport with great pleasure, Fre;D - Many thanks ;-) -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library-tp5718200p5728658.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] Size of program vs library ?
On Wed, 17 May 2017, fredvs wrote: But, IMHO, if fpc uses a external linker, it is also part of the compilation process. And each feature of the linker should be analyzed. We are agreed on that. Michael Van Canneyt wrote You didn't even file an official request in the bugtracker ? Because I tried already and because I know the (rejected) answer. Where is this bugreport ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Size of program vs library ?
Michael Van Canneyt wrote > On Wed, 17 May 2017, fredvs wrote: > >> Hello. >> >> OK, I see that fpc team is afraid to change something that mom-Delphi did >> not do. > > This is simply not correct and a *very* unfair statement on your part. > Mails like this will really not get you anywhere. Yes, I now. I know also that if you do not speak hot, people does not listen. By the way, I sent advices about size of fpc libraries more than 10 years ago. A lot of "work in progress" as answers but nothing change. A other thing that I discover: it is extremely sensible to talk about linkers. In FreeBSD forum, I was insulted because I reveal that their linker (GNU ld) was not compatible with FreeBSD multi-arch design. But, IMHO, if fpc uses a external linker, it is also part of the compilation process. And each feature of the linker should be analyzed. Michael Van Canneyt wrote > You didn't even file an official request in the bugtracker ? Because I tried already and because I know the (rejected) answer. Michael Van Canneyt wrote > You didn't even test the resources thing. It means we will need to test > this. >This takes time, and the issue is not considered very important, so > this time >is indeed not spent right away. Of course I tested it, why do you write this ? Michael Van Canneyt wrote > With this mail, you're simply behaving like a small girl that didn't get > her > ice cream right away... Ha, so you do not know me. If I do not get my ice cream, I am much more unbearable. Fre;D - Many thanks ;-) -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library-tp5718200p5728656.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 Wed, 17 May 2017 10:57:58 +0100 Graeme Geldenhuys wrote: > On 2017-05-17 06:12, nore...@z505.com wrote: > > But any game ends up using opengl anyway, doesnt' it? > > They shouldn't have too. I love the retro style low-fidelity games. They > are perfectly possible to implement without OpenGL using GCC or Java. 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. And most successful (meaning released on consoles and not only on steam) retro low-fi looking games nowadays are done using Unity or Unreal Engine. Even if their style looks old the graphics are often much more complex to render than what you would think. > But I couldn't achieve the same with FPC - what this whole discussion > was about in the Lazarus Forum (and now here it seems). If you identify the bottlenecks there may be a solution. 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 Wed, 17 May 2017 09:57:11 +0200 (CEST) mar...@stack.nl (Marco van de Voort) wrote: > You still need to calculate all the vertices that you send to the graphics > card, even if the GPU renders then. Can you elaborate? I know you have to *transfer* *most* vertices to the GPU (not the ones that are created on the GPU side obviously, think tesselation or geometry shaders). But I don't get why you have to *calculate* *all*. R. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC FIXES__3_0 fails to compile
When compiling the latest fixes branch under Linux 64-bit fpc 3.0.2, with the following make command: make all OS_TARGET=linux CPU_TARGET=x86_64 NOGDB=1 OPT=-O3 NEWOPT=-O4 The compilation failed with: /bin/mkdir -p x86_64/units/x86_64-linux make ./msg2inc make[6]: Entering directory `/home/tony/fpcsrc/fpcfixes/compiler' /usr/bin/ppcx64 -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu/home/tony/fpcsrc/fpcfixes/rtl/units/x86_64-linux -Fix86_64 -FE. -FUx86_64/units/x86_64-linux -Cg -dRELEASE -O3 -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew -FE. utils/msg2inc.pp msg2inc.pp(800,8) Warning: Variable "Mode" does not seem to be initialized msg2inc.pp(824) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted make[6]: *** [msg2inc] Error 1 make[6]: Leaving directory `/home/tony/fpcsrc/fpcfixes/compiler' make[5]: *** [msgtxt.inc] Error 2 make[5]: Leaving directory `/home/tony/fpcsrc/fpcfixes/compiler' make[4]: *** [next] Error 2 make[4]: Leaving directory `/home/tony/fpcsrc/fpcfixes/compiler' make[3]: *** [ppc1] Error 2 make[3]: Leaving directory `/home/tony/fpcsrc/fpcfixes/compiler' make[2]: *** [cycle] Error 2 make[2]: Leaving directory `/home/tony/fpcsrc/fpcfixes/compiler' make[1]: *** [compiler_cycle] Error 2 make[1]: Leaving directory `/home/tony/fpcsrc/fpcfixes' make: *** [build-stamp.x86_64-linux] Error 2 The output of svn info is Working Copy Root Path: /home/tony/fpcsrc/fpcfixes URL: https://svn.freepascal.org/svn/fpc/branches/fixes_3_0 Relative URL: ^/branches/fixes_3_0 Repository Root: https://svn.freepascal.org/svn/fpc Repository UUID: 3ad0048d-3df7-0310-abae-a5850022a9f2 Revision: 36236 Node Kind: directory Schedule: normal Last Changed Author: pierre Last Changed Rev: 36152 Last Changed Date: 2017-05-07 23:13:21 +0100 (Sun, 07 May 2017) As a sanity check, I tried the same make command with fpc trunk (r36236) and that compiles with no errors. ___ 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 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 ;-) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Size of program vs library ?
On Wed, 17 May 2017, fredvs wrote: Hello. OK, I see that fpc team is afraid to change something that mom-Delphi did not do. This is simply not correct and a *very* unfair statement on your part. Mails like this will really not get you anywhere. 1. You didn't even file an official request in the bugtracker ? 2. Where did we say we would not do this ? We're just careful, since the effect is not known. 3. You didn't even test the resources thing. It means we will need to test this. This takes time, and the issue is not considered very important, so this time is indeed not spent right away. 4. Delphi doesn't use GNU ld, so this comparison is totally without basis. With this mail, you're simply behaving like a small girl that didn't get her ice cream right away... Michael. ___ 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 2017-05-16 23:25, Jon Foster wrote: Works good, even without source. With a source file it gives a few more options. eg: These are missing without a source file. There might be others too. Macro FPC_VERSION set to 2 Macro FPC_RELEASE set to 6 Macro FPC_PATCH set to 4 Macro FPC_FULLVERSION set to 20604 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 2017-05-16 22:53, Mattias Gaertner wrote: touch mytest fpc -vc mytest :-D That's just genius! Regards, Graeme ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Size of program vs library ?
2017-05-17 13:32 GMT+02:00 fredvs : > > OK, I see that fpc team is afraid to change something that mom-Delphi did > not do. You don't know that. Lack of bug report / feature request on mantis, means that the feature request doesn't exist in any formal way. Sometimes is good to have reported thing like this on bugtracker for documentation purposes (even if finally will be rejected). -- Best regards, Maciej Izak ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Size of program vs library ?
Hello. OK, I see that fpc team is afraid to change something that mom-Delphi did not do. So, to resume, for people who wants to smartlink their libraries, you may use this command: *fpc -k--gc-sections my_smartlinked_library.pas* Fre;D - Many thanks ;-) -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library-tp5718200p5728647.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 2017-05-17 06:59, Sven Barth via fpc-pascal wrote: While a raytracer *might* use one of those APIs for output of the final image the main task is the calculation of said image and *that* is where Graeme said that FPC had problems. 100% correct. I tried the blitting of the image using SDL with OpenGL, but as expected, that made no performance difference, because 95% of the application's time was spend generating the memory image (raycaster engine) - all done in pure software. 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 06:12, nore...@z505.com wrote: But any game ends up using opengl anyway, doesnt' it? They shouldn't have too. I love the retro style low-fidelity games. They are perfectly possible to implement without OpenGL using GCC or Java. But I couldn't achieve the same with FPC - what this whole discussion was about in the Lazarus Forum (and now here it seems). AFAIR the doom and quake ports ran pretty fast, Are you talking about the Object Pascal implementations? If so, where they compiled with FPC or Delphi? As far as I know they where compiled with Delphi, and thus should have much better performance. 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 Wed, 17 May 2017, nore...@z505.com wrote: On 2017-05-17 02:57, mar...@stack.nl 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. True so a test to confirm that the calculating functions/procedure are really the bottleneck, would need to be written, and compare it to the equivalent c++ program with the same calculations It would just be silly to start optimizing the calculation functions without any evidence that those are the issue.. If it's fpc's internal functions such as sqrt() I wonder what those internal functions actually are. Right now they are just magic, pointing to a magic number, in my mind They are mostly functions for which the compiler generates code directly instead of calling actual pascal functions (although that still happens e.g. for writeln). You really need to check the generated code for the problem case. If I understood the thread, Graeme published his ray-tracing code on a forum, so it can probably be used as a base for examining the problem. 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-17 02:57, mar...@stack.nl 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. True so a test to confirm that the calculating functions/procedure are really the bottleneck, would need to be written, and compare it to the equivalent c++ program with the same calculations It would just be silly to start optimizing the calculation functions without any evidence that those are the issue.. If it's fpc's internal functions such as sqrt() I wonder what those internal functions actually are. Right now they are just magic, pointing to a magic number, in my mind ___ 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, 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Best way to check SimpleIPC for messages
On 16.05.2017 07:30, Michael Van Canneyt wrote: select is basically what peekmessage does. AFAIK "select()" (and - more versatile - "poll()" ) in Linux uses an appropriate system call to wait on one of multiple events (i.e. devices, including e.g. pipes, which might be used by IPC). (Despite the name) it does not do any "busy wait" ("polling"). So it's can be used (instead of waiting in a blocking read) in a worker-thread of an "application". It's perfectly useful in an program without a message queue provided by LCL or the mse-library. -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-17 00:14, nore...@z505.com wrote: On 2017-05-16 09:10, Jon Foster wrote: I think the key word in Graeme's complaint is "game". And I'm willing to bet that most of his envisioned gaming scenarios deal with a lot of floating point math and the more advanced math functions. A quick glance over his example code and I'm willing to bet that the "math" unit providing the sqrt(), cos(), sin() and others is the bottle neck. But that's just a knee-jerk reaction. Seems to me I read a while back that a ton of effort had not gone into them. Could those math routines just be written in assembly with a FastXXX unit? i.e. FastMM is a fast memory manager, so you could have a FastCRT, fastWhatever, FastMath... Doh! Someone already thought of this Quote: "FastMath is a Delphi math library that is optimized for fast performance (sometimes at the cost of not performing error checking or losing a little accuracy). It uses hand-optimized assembly code to achieve much better performance then the equivalent functions provided by the Delphi RTL." Github: https://github.com/neslib/FastMath Whether it ports over to fpc, I don't know ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Best way to check SimpleIPC for messages
On Wed, 17 May 2017 01:50:32 -0500 nore...@z505.com wrote: > On 2017-05-17 00:54, Sven Barth via fpc-pascal wrote: > > OnIdle() is called when there is no more event waiting in the > > widgetset's event queue, basically meaning that the application has > > nothing better to do anyway. It has nothing to do with CPU usage. > > > > That makes sense. > And recursively what happens if you call an event, inside the onidle, > ... > > Recursive nightmare, or not a problem? Not a problem for the LCL, but it may be a problem for your application. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal