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
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 ptcg
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 tha
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-r
>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 imag
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 rou
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) :}
.
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 fullsc
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
>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@lis
>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.
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 t
>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 ar
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 l
14 matches
Mail list logo
