Re: [fpc-pascal] Implementing AggPas with PtcGraph

[Nikolay Nikolov]

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

[Nikolay Nikolov]

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?

[Bo Berglund]

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?

[Bo Berglund]

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

[James Richters]

>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

[Nikolay Nikolov]

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

[James Richters]

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

[Nikolay Nikolov]

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

[James Richters]

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

[James Richters]

>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

[James Richters]

>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

[wkitty42]

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

[James Richters]

>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?

[Mark Morgan Lloyd]

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