Re: [fpc-pascal] Implementing AggPas with PtcGraph
On 06/22/2017 02:42 AM, Nikolay Nikolov wrote: On 06/22/2017 01:21 AM, James Richters wrote: putimage can be accelerated, although it would still have to do a memory copy. Like this? https://github.com/Zaaphod/ptcpas/compare/Zaaphod_Custom?expand=1#diff-fb31461e009ff29fda5c35c5115978b4 This is amazingly faster. I ran a test of just ptcgraph.putimage() in a loop, putting the same image over and over 1000 times and timing it. The original ptcgraph.putimage() took 18.017 seconds. After I applied this, the same loop took 1.056 seconds. Quite an improvement!It's still nowhere near as fast as just drawing stuff with ptcgraph directly, but for doing a memory copy of the entire screen, it's very fast Yes, that's a good start. That was exactly what I meant :) I have an idea on how I could speed it up even further If I set up a second array with 1 bit per pixel, then (somehow) aggpas could set bits in this array to 1 whenever it changed a corresponding bit. Now by analyzing the 'pixel changed' array one word at a time, (or maybe longword or qword at a time) I could just skip over all the words that =0 and when I come across a word that <> 0 I could do a binary search of that word to only change the pixels that need to be changed. If very little on the screen has changed, this would be quite a bit faster because the pixel changed array would be 1/16 the size of the full buffer. The only way this would be of any benefit though is if aggpas set the bits in the 'pixel changed' array while it was changing the pixels of the buffer, because at that time it already has the array position and the fact that something changed available. If I had to analyze the buffer separately and create the 'pixels changed' array, it would take too long. That sounds like a little bit of a special case - it'll work where you're using putimage for a large area, that has very few pixels set. Perhaps just reimplementing the general algorithm in inline asm, by using SSE (or MMX) vector instructions would be the fastest, but maybe it's not worth the pain and the pascal implementation is fast enough for you. Just experiment and see what works best :) Btw, I looked at your code again and saw a quick and cheap optimization - just move the case statement (case BitBlt of) outside the inner loop (for i:=X to X1 do), so the value of BitBlt is not checked once every pixel, but once per row. Nikolay ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing AggPas with PtcGraph
On 06/22/2017 01:21 AM, James Richters wrote: putimage can be accelerated, although it would still have to do a memory copy. Like this? https://github.com/Zaaphod/ptcpas/compare/Zaaphod_Custom?expand=1#diff-fb31461e009ff29fda5c35c5115978b4 This is amazingly faster. I ran a test of just ptcgraph.putimage() in a loop, putting the same image over and over 1000 times and timing it. The original ptcgraph.putimage() took 18.017 seconds. After I applied this, the same loop took 1.056 seconds. Quite an improvement!It's still nowhere near as fast as just drawing stuff with ptcgraph directly, but for doing a memory copy of the entire screen, it's very fast Yes, that's a good start. That was exactly what I meant :) I have an idea on how I could speed it up even further If I set up a second array with 1 bit per pixel, then (somehow) aggpas could set bits in this array to 1 whenever it changed a corresponding bit. Now by analyzing the 'pixel changed' array one word at a time, (or maybe longword or qword at a time) I could just skip over all the words that =0 and when I come across a word that <> 0 I could do a binary search of that word to only change the pixels that need to be changed. If very little on the screen has changed, this would be quite a bit faster because the pixel changed array would be 1/16 the size of the full buffer. The only way this would be of any benefit though is if aggpas set the bits in the 'pixel changed' array while it was changing the pixels of the buffer, because at that time it already has the array position and the fact that something changed available. If I had to analyze the buffer separately and create the 'pixels changed' array, it would take too long. That sounds like a little bit of a special case - it'll work where you're using putimage for a large area, that has very few pixels set. Perhaps just reimplementing the general algorithm in inline asm, by using SSE (or MMX) vector instructions would be the fastest, but maybe it's not worth the pain and the pascal implementation is fast enough for you. Just experiment and see what works best :) Nikolay ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Serial to TCP gateway in FPC?
On Thu, 22 Jun 2017 00:30:27 +0200, Bo Berglund wrote: >I looked at the socket unit, which has the advantage that it is part >of FPC. But the documentation is very confusing... >For example I was looking at fpconnect: >https://www.freepascal.org/docs-html/rtl/sockets/fpconnect.html >and noted that the example does NOT use fpconnect at all, instead it >uses a depreciated Connect method with strange arguments... >Is there some updated documentation somewhere? OOPS! After I sent my earlier message I realized that the fpconnect example uses code that attaches the socket to textfiles Sin and Sout. But my use is specifically NOT a text based system, all data are binary and no iterpretation whatsoever of the content is allowed. Can I still use the sockets unit with fpconnect? Or must I use the depreciated Connect method so I can specify the files as binary or text files? Connect is overloaded -- Bo Berglund Developer in Sweden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Serial to TCP gateway in FPC?
On Wed, 21 Jun 2017 08:02:00 +, Mark Morgan Lloyd wrote: >> What about Linux (Raspberry Pi)? Is the com port name simply ttyUSB1or do I >> have to use the full /dev/ttyUSB1? > >You *definitely* have to use the name as given. You're opening a file in >the filesystem tree, not an internally-reserved name. OK, thanks! I am now creating a super-simple proxy app which will open a serial port and connect to a TCP server. Then it will send all incoming data on the serial port to the TCP server and all incoming TCP server data back to the serial port. Right now I am doing a Lazarus GUI app on Windows, but eventually I will move the code into a command line app. I have used the serial unit in FPC to handle the serial port connection and am now looking for the TCP Client component to use. I have used Indy's TIdTcpClient in the past, but it required me to create a thread to handle the data transfers, and I don't really like complicating matters like that for this (seemingly) simple project. I looked at the socket unit, which has the advantage that it is part of FPC. But the documentation is very confusing... For example I was looking at fpconnect: https://www.freepascal.org/docs-html/rtl/sockets/fpconnect.html and noted that the example does NOT use fpconnect at all, instead it uses a depreciated Connect method with strange arguments... Is there some updated documentation somewhere? Anyway: The functions of this proxy app are only: - Open the specified serial port and set it to the required baudrate - Open a connection to the TCP server port - Now somehow run a loop as follows: - Serial data available? If so read them and send to the TCP server - TCP data available? If so read and send through the serial port - Stop condition set? If so close down TCP and serial connections and exit the program. (Don't know how this will work) - Repeat loop again Two issues here: 1) How do I enter a loop in a GUI application? In a command line application it is just going to be part of he main program code. 2) How do I stop the program from running at 100% CPU utilization (on Windows)? And of course how to use the sockets unit properly? -- Bo Berglund Developer in Sweden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing AggPas with PtcGraph
>putimage can be accelerated, although it would still have to do a memory copy. Like this? https://github.com/Zaaphod/ptcpas/compare/Zaaphod_Custom?expand=1#diff-fb31461e009ff29fda5c35c5115978b4 This is amazingly faster. I ran a test of just ptcgraph.putimage() in a loop, putting the same image over and over 1000 times and timing it. The original ptcgraph.putimage() took 18.017 seconds. After I applied this, the same loop took 1.056 seconds. Quite an improvement!It's still nowhere near as fast as just drawing stuff with ptcgraph directly, but for doing a memory copy of the entire screen, it's very fast I have an idea on how I could speed it up even further If I set up a second array with 1 bit per pixel, then (somehow) aggpas could set bits in this array to 1 whenever it changed a corresponding bit. Now by analyzing the 'pixel changed' array one word at a time, (or maybe longword or qword at a time) I could just skip over all the words that =0 and when I come across a word that <> 0 I could do a binary search of that word to only change the pixels that need to be changed. If very little on the screen has changed, this would be quite a bit faster because the pixel changed array would be 1/16 the size of the full buffer. The only way this would be of any benefit though is if aggpas set the bits in the 'pixel changed' array while it was changing the pixels of the buffer, because at that time it already has the array position and the fact that something changed available. If I had to analyze the buffer separately and create the 'pixels changed' array, it would take too long. James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing AggPas with PtcGraph
On 06/21/2017 10:27 PM, James Richters wrote: I was trying to find putimage to see how it worked... and I came across some notes about it in graph.inc as follows: { For significant speed improvements , is is recommended } { that these routines be hooked (otherwise the default, } { slower routines will be used) :} .. { PutImage() } .. what does 'these routines be hooked' mean? Is that something I should be doing in my program or something that is already done internally with ptcgraph? Something to be done in the ptcgraph sources, so that putimage becomes faster. Nikolay ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing AggPas with PtcGraph
I was trying to find putimage to see how it worked... and I came across some notes about it in graph.inc as follows: { For significant speed improvements , is is recommended } { that these routines be hooked (otherwise the default, } { slower routines will be used) :} .. { PutImage() } .. what does 'these routines be hooked' mean? Is that something I should be doing in my program or something that is already done internally with ptcgraph? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing AggPas with PtcGraph
On 06/21/2017 08:05 PM, James Richters wrote: Is there a more direct way of getting aggpas to send its output to ptcgraph? Currently I'm doing as in the demo programs and defining an array then using putimage() to transfer the array to ptcgraph... this is fairly slow, especially for fullscreen high resolution applications. I'm trying to follow through some of the demos included with ptcpas and it seems they do something like: { lock surface pixels } pixels := surface.lock; Then using a pointer defined by pixels, the program makes changes to all the pixels, then { unlock surface } surface.unlock; and { copy surface to console } surface.copy(console, area, area); send the changes to the screen. I'm wondering if I can have aggpas work with the ptcgraph buffer directly, and maybe this would be more efficient than putimage() Any ideas? It's more complicated than that, because ptcgraph does all these operations in a separate thread. See the sources for ptcgraph and for the ptcwrapper unit. However, putimage can be accelerated, although it would still have to do a memory copy. This can be done, by implementing and adding a PutImage procedure in the TModeInfo record, which is filled in, during initialization. See the QueryAdapterInfo function in the ptcgraph.pp. It does a series of: InitMode(graphmode); with graphmode do begin ... end; And inside the 'with' statement, various procedure variables are set. There, a PutImage routine can be added as well. Look at e.g. ptc_putpixelproc_16bpp to see how the surface is locked and how the actual drawing to the surface is done, inside ptcgraph. Nikolay ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing AggPas with PtcGraph
Is there a more direct way of getting aggpas to send its output to ptcgraph? Currently I'm doing as in the demo programs and defining an array then using putimage() to transfer the array to ptcgraph... this is fairly slow, especially for fullscreen high resolution applications. I'm trying to follow through some of the demos included with ptcpas and it seems they do something like: { lock surface pixels } pixels := surface.lock; Then using a pointer defined by pixels, the program makes changes to all the pixels, then { unlock surface } surface.unlock; and { copy surface to console } surface.copy(console, area, area); send the changes to the screen. I'm wondering if I can have aggpas work with the ptcgraph buffer directly, and maybe this would be more efficient than putimage() Any ideas? James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ptccrt missing keys
>we've always set that in the BIOS of the machine... it is generally in the >same area where you would toggle the numlock on at boot... Thanks for the suggestion! I did not even think to look there. James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing AggPas with PtcGraph
>The 2 part directory names is because other Canvas renderers will and >can be added to fpGUI. Yes the directory structure makes more sense if there will be other rendering options and render/aggpas/ also makes more sense than render/software for the same reason. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ptccrt missing keys
On 06/21/2017 12:31 PM, James Richters wrote: There is one thing I am wondering about, I'm not sure if it's something that could be (or maybe already is) addressed with pctcrt. That is the typmatic keyboard rate. I wish it to be much faster than it is. I seem to remember that on DOS systems there was a way to set it, but on windows systems the only thing I can find is a control panel setting, which I maxed out but it's still not fast enough. Is there a way to override the typmatic repeat rate? we've always set that in the BIOS of the machine... it is generally in the same area where you would toggle the numlock on at boot... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ptccrt missing keys
>Ok, I've implemented implemented this. ptccrt now has a KeyMode variable Excellent solution! >kmFPWINCRT - behaves like Free Pascal's CRT unit under Windows. Similar to >kmGO32, but emulates several incompatibilities >that the Windows CRT unit has with the GO32V2 CRT unit. Not all of them are >emulated though, since some of them can be considered bugs. I had patched wincrt a while back because it was missing a lot of ctrl keys. I tried to submit changes to freepascal but never did figure out how to do it properly. My attempt is here: https://mantis.freepascal.org/view.php?id=30599 I got confused with 'Please create a proper patch and against development (trunk) version of FPC' and at the time I just didn't have the time to try to figure it out. I wonder if I should try to send it in again. I added a lot of ctrl keys but I never did figure out how to get ANY alt keys working. Even though I will use ptccrt now because I like ptcgraph better, someone else might benefit from having improved functionality of wincrt.Perhaps adding the 'keymode' variable for compatibility reasons should be used here as well? My changes to WinCRT are here: https://github.com/Zaaphod/freepascal/tree/Fix_WinCRT >I've also committed this into FPC trunk and I've proposed it to be merged into >FPC 3.0.4, so please test and report any bugs that you found. :) I'll be happy to do testing with all keymodes and report back any issues I find. I'm curious if there is any estimate on when FPC 3.0.4 will be released? I've downloaded the snapshot at https://sourceforge.net/p/ptcpas/code/785/tree/trunk/ and built it using the instructions in docs\install.txt for i386 and have it working.. so far it's working well in my little keytest program. I still do not know how to build this for x64. I've tried fpcmake -r -Tx86_64-win64 I'm not sure this is correct, it appears to work, and I don't get any errors, but then: make CPU_TARGET=x86_64 OS_TARGET=win64 gives me the following output: J:/Programming/FPC/3.0.2/bin/i386-Win32/gmkdir.exe -p units/x86_64-win64 J:/Programming/FPC/3.0.2/bin/i386-Win32/ppcrossx64.exe -Twin64 -Px86_64 -XPx86_64-win64- -Xr -Fuhermes -Fuptcwrapper -Fuptcgraph -Fux11 -Fuwin32/directx -Fiptcgraph/inc -FE. -FUunits/x86_64-win64 -dx86_64 ptc.pp Warning: Option "-Xr" is ignored for the current target platform. Free Pascal Compiler version 3.0.2 [2017/02/13] for x86_64 Copyright (c) 1993-2017 by Florian Klaempfl and others Target OS: Win64 for x64 Compiling ptc.pp Compiling .\hermes\hermes.pp Compiling .\win32\directx\p_ddraw.pp ptc.pp(125,21) Fatal: Can't find unit glext used by ptc Fatal: Compilation aborted make: *** [ptc.ppu] Error 1 There is one thing I am wondering about, I'm not sure if it's something that could be (or maybe already is) addressed with pctcrt. That is the typmatic keyboard rate. I wish it to be much faster than it is. I seem to remember that on DOS systems there was a way to set it, but on windows systems the only thing I can find is a control panel setting, which I maxed out but it's still not fast enough. Is there a way to override the typmatic repeat rate? James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Serial to TCP gateway in FPC?
On 21/06/17 05:30, Bo Berglund wrote: On Wed, 21 Jun 2017 01:57:36 +0200, José Mejuto wrote: The problem I have is that it seems only to work for COM1 or COM3, as>> soon as I use a higher numbered port like COM33 then it fails.>> What have I missed here?>> Is serial only able to work with the low numbered ports (single>> digit)?>>COM ports in windows can only be 1-9, to open high numbered COM ports >you must use the extended name syntax (without quotes) "\\.\COM99" you >can also use "\\.\COM1" for COM1-9. It turns out that I also must not use the trailing colon in the namewhich is present in the wiki example...But then I get a non-zero handle. I have yet to verify that data canflow. Is there a way to enumerate the available com ports so that they canbe listed in a combobox for selection? This would have the advantagethat it would work on both Windows and Linux and it limits thepossible errors by the user. Of course the enumerator must know aboutthe differences in syntax between Windows and Linux! Not reliably in unix. You have to know the various potential name patterns, i.e. /dev/ttyS*, /dev/ttyAMA* and so on, and then enumerate what's currently visible in the filesystem. It might be possible to get "hints" as to the device type from the /sys filesystem, but I'm not sure it's safe to rely on this. What about Linux (Raspberry Pi)? Is the com port name simply ttyUSB1or do I have to use the full /dev/ttyUSB1? You *definitely* have to use the name as given. You're opening a file in the filesystem tree, not an internally-reserved name. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal