Re: [fpc-pascal] FPC Graphics options?

[Brian]

Forgot to mention.

SDL2.0 is multi platform and uses accelerated graphics.

https://www.libsdl.org/

The best speed is achieved with NVidia graphics cards and proprietary NVidia
drivers rather than the default Linux X.org drivers.

http://www.freepascal-meets-sdl.net/chapter-1-introduction/

Brian



--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/FPC-Graphics-options-tp5728513p5728519.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?

[Brian]

I have an older project (Virtual Pascal) using DPMI32 and writing to the
graphics card  , and had the same issue as you when deciding which graphics
library to use for Linux. In my case , part of the application is GUI and
part is very fast 2D pixel graphics (points lines , polygons etc.)

The first approach in porting to Linux was to write directly to the Linux
graphics frame buffer and bypassing X11 entirely. This is very fast but that
leaves you without many of the benefits of Linux.

The second approach was to write directly to X11 , but writing a lot of
pixel data to the X11 server will cause the X11 server to bog down and even
crash. X11 is a server so that approach was ruled out.

The chosen approach is to use SDL2.0+. If you are coming from pixel based
BGI graphics where everything is pixel based , SDL takes a bit of getting
used to , as everything (SDL 2.0) is based on textures. You write to a
texture and render it to the graphics card as and when or periodically.

In your case if you have a lot of pixel writing , SDL 2.0 has a very clever
mechanism where you can render to a software (CPU memory) frame buffer at
whatever rate you want and render (copy) that frame buffer to the graphics
card at say 60Hz frame rate which make things appear faster than the eye can
perceive.

Here is basically how to do it.

http://gigi.nullneuron.net/gigilabs/sdl2-pixel-drawing/

There is a nice Image  and TTF library with SDL 2.0

Brian




--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/FPC-Graphics-options-tp5728513p5728518.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?

[Graeme Geldenhuys]

On 2017-05-11 19:43, James Richters wrote:

Any Suggestions?


Speed:
  In recent graphics work I've done, I've noticed that FPC is fantastic
  at created cross-platform applications. But the generated binaries
  are NOT fast at all - no matter how many compiler parameters and
  artificial speed optimisations we tried to implement. Sloppy Java
  code ended up 3x faster than the best I could get out of FPC
  generated binaries.

  I'm not saying this is your performance problem (especially comparing
  a 3Ghs PC vs a 233Mhz PC) - there certainly seems to be another
  problem contributing to your speed issue.

Graphics:
  I highly recommend you take a look as AggPas. It is a 100% high
  quality sub-pixel rendering engine - hand ported from the original
  C++ code. The latest and most up to date AggPas (there are a few
  forks from the original) can be found in the fpGUI code repository.
  The AggPas code is totally independent of the rest of fpGUI, so
  you can write per console applications that uses AggPas and render
  to any image format, byte array etc.

  For examples of what AggPas can do, take a look at this following
  websites:

Agg (Anti-Grain Geomerty):
  http://www.antigrain.com/about/

AggPas (Pascal port):
  http://crossgl.com/aggpas/aggpas-demo.htm

Latest AggPas code:

https://github.com/graemeg/fpGUI/tree/develop/src/corelib/render/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?

[Bart]

On 5/11/17, James Richters  wrote:
> I have a few console graphics applications that I originally wrote in Turbo
> Pascal that I have been able to convert over to Free Pascal and now have
> windows versions of these programs.

Porting them to Lazarus (GUI) is not an option?

Bart
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Sven Barth via fpc-pascal]

On 11.05.2017 20:43, James Richters wrote:
> I have a few console graphics applications that I originally wrote in
> Turbo Pascal that I have been able to convert over to Free Pascal and
> now have windows versions of these programs.  I notice that unless I run
> my program on a 3.5GHz machine or faster, the graphics are fairly
> slow.By slow, I mean noticeably slower than they were on a Pentium
> 233 DOS machine with Turbo Pascal.  The intended computers for these
> programs are simple inexpensive PCs with motherboard video, no dedicated
> video cards, I think it should be possible for any modern computer to
> severely out perform a Pentium 233 with a VGA card in it, so I’m not
> sure what the issue is.   I am just using the graph unit for windows,
> and I wonder if there is a more efficient method of creating a full
> screen graphics only application than to use the graph unit?I am
> only looking for it to work under windows and the main issue I would
> like to solve is the speed of drawing things on the screen like lines
> and arcs.  It would be nice if I am also able to get away from BGI fonts
> and use True Type fonts instead.  I don’t need 3D rendering or anything
> so complicated, just to draw lines and arcs and maybe ellipses as well
> as various text, and flood fill closed shapes with some solid color.
> 
>  
> 
> Any Suggestions?

You could try the units ptcgraph or sdlgraph as alternatives (both are
part of FPC). Other than that you could try to investigate why the
graphic unit is so slow on Windows...

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Vehicle management

[Sven Barth via fpc-pascal]

On 11.05.2017 19:58, Jon Foster wrote:
> 
> On 05/11/2017 09:37 AM, Sven Barth via fpc-pascal wrote:
>>
>> Am 11.05.2017 18:14 schrieb "Jon Foster"
>> >:
>> > Anyhow tips on the FPC->C++ front would be appreciated. I will
>> probably search the list archives as I know this topic comes up
>> repeatedly. I don't understand how ginormous an undertaking this might
>> be but maybe I can contribute something on this front.
>>
>> I can't speak for other approaches to interface with C++ code, but
>> patches to the compiler's cppclass support are definitely welcome :D
>> It will never support everything there is in C++, but if we'd manage
>> to interface with most library code that would be something...
>>
> @@ <- me being bug eyed
> 
> cppclass?!?! Where? When? How? What?
> 
> I still can't find any mention of C++ support in the FPC 3.0 doc PDFs.
> I've just grepped the source and I see something... Still trying to
> figure out what it means. But to put it more specifically:
> 
> What support is there?
> How is it used?
> Where are the docs, if any?
> When did it sneak in? (not really important, just curious)
> 

It's rather old in fact though still in its infancy. Improving it a
little bit was one of the first patches I had done for FPC (back in 2009
or so), though not much has happened since then.

The only code of note is the tests that exist in
$fpcdir/tests/test/cg/tcppcl*.pp

Essentially only static methods of GCC C++ code are currently supported.
The next step would be instantiation and the vtables.

(Should you want to continue this topic I'd suggest a new thread in
fpc-devel)

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] FPC Graphics options?

[James Richters]

I have a few console graphics applications that I originally wrote in Turbo
Pascal that I have been able to convert over to Free Pascal and now have
windows versions of these programs.  I notice that unless I run my program
on a 3.5GHz machine or faster, the graphics are fairly slow.By slow, I
mean noticeably slower than they were on a Pentium 233 DOS machine with
Turbo Pascal.  The intended computers for these programs are simple
inexpensive PCs with motherboard video, no dedicated video cards, I think it
should be possible for any modern computer to severely out perform a Pentium
233 with a VGA card in it, so I'm not sure what the issue is.   I am just
using the graph unit for windows, and I wonder if there is a more efficient
method of creating a full screen graphics only application than to use the
graph unit?I am only looking for it to work under windows and the main
issue I would like to solve is the speed of drawing things on the screen
like lines and arcs.  It would be nice if I am also able to get away from
BGI fonts and use True Type fonts instead.  I don't need 3D rendering or
anything so complicated, just to draw lines and arcs and maybe ellipses as
well as various text, and flood fill closed shapes with some solid color.

 

Any Suggestions? 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Vehicle management

[Jon Foster]

On 05/11/2017 09:37 AM, Sven Barth via fpc-pascal wrote:


Am 11.05.2017 18:14 schrieb "Jon Foster" >:
> Anyhow tips on the FPC->C++ front would be appreciated. I will probably 
search the list archives as I know this topic comes up repeatedly. I 
don't understand how ginormous an undertaking this might be but maybe I 
can contribute something on this front.


I can't speak for other approaches to interface with C++ code, but 
patches to the compiler's cppclass support are definitely welcome :D It 
will never support everything there is in C++, but if we'd manage to 
interface with most library code that would be something...



@@ <- me being bug eyed

cppclass?!?! Where? When? How? What?

I still can't find any mention of C++ support in the FPC 3.0 doc PDFs. I've 
just grepped the source and I see something... Still trying to figure out 
what it means. But to put it more specifically:


What support is there?
How is it used?
Where are the docs, if any?
When did it sneak in? (not really important, just curious)

--
Sent from my Debian Linux workstation -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
j...@jfpossibilities.com

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Vehicle management

[Sven Barth via fpc-pascal]

Am 11.05.2017 18:14 schrieb "Jon Foster" :
> I should also throw out here that it would be *REALLY* nice, and even
somewhat needful on the Android front, if FPC could interface directly with
C++ libs and use their classes and objects. Besides Java, Google prefers to
use C++ (for obvious reasons) and their supplied native code libraries are
C++. If you look at Google's software architecture diagram they say they
use FreeType2. But, even rooted, if you search the Android file system you
won't find a FT2 lib anywhere. Digging through the AOSP source base it
turns out that FT2 is statically linked into Skia. Skia is a C++ library
used by Dalvik (and other places) to do the usual 2D text/graphics
rendering. This acts much like AggPas, used by Graeme's AggCanvas. I did
find it exports a limited set FT2 functions in standard C style. But it
looks like, for full functionality, I'm going to have to bridge the C++
divide.
>
> Anyhow tips on the FPC->C++ front would be appreciated. I will probably
search the list archives as I know this topic comes up repeatedly. I don't
understand how ginormous an undertaking this might be but maybe I can
contribute something on this front.

I can't speak for other approaches to interface with C++ code, but patches
to the compiler's cppclass support are definitely welcome :D It will never
support everything there is in C++, but if we'd manage to interface with
most library code that would be something...

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Vehicle management

[Jon Foster]

On 05/11/2017 01:29 AM, Felipe Monteiro de Carvalho wrote:

On Thu, May 11, 2017 at 1:19 AM, Jon Foster
 wrote:

Yeah. The wiki is cluttered with inaccurate and abandoned information for
Android development. It needs a serious scrubbing. And access to needed
sources is somewhat hidden. I've combed it for a few years, now, to try and
deduce what's real and what's not. I'm not even sure where I got the bits of
source I'm using now. I've just been clinging to it like a shipwreck
survivor clinging to flotsam.

I don't think the wiki page I posted is inaccurate, all the stuff
there is valid AFAIK, but it is simply very incomplete. A lot more
should be written, and also note that there are 2 different ways:

1> Via NDK combining native Pascal + Java
2> Via JVM compiler

The wiki I posted is only for approach 1, even a link to a full
compilable example is posted there (thought it is for OpenGL). I never
used approach 2 and dont plan on using it.
Thanks for the info Felipe. I'll bookmark that page somewhere. I was also 
referring to the many other Android pages on the wiki that are misleading. 
Its hard for us outsiders to know what's authoritative and current.


I would like to hazard there is, yet, another way:

3> #1 w/o Java - pure native.

However that would never be entirely accurate as all "native activities" 
have to be chaperoned by a Java "Activity". And JNI will have to be used to 
interface to any Android supplied services as everything else is stuck in 
Dalvik land. All part of what makes Android so inefficient. But my intent 
is not to have to do Java once an FPC based activity is launched.  Might 
have to build a better "NativeActivity" class with ppcjvm too... I think 
that's something Lazarus did/does.


I should also throw out here that it would be *REALLY* nice, and even 
somewhat needful on the Android front, if FPC could interface directly with 
C++ libs and use their classes and objects. Besides Java, Google prefers to 
use C++ (for obvious reasons) and their supplied native code libraries are 
C++. If you look at Google's software architecture diagram they say they 
use FreeType2. But, even rooted, if you search the Android file system you 
won't find a FT2 lib anywhere. Digging through the AOSP source base it 
turns out that FT2 is statically linked into Skia. Skia is a C++ library 
used by Dalvik (and other places) to do the usual 2D text/graphics 
rendering. This acts much like AggPas, used by Graeme's AggCanvas. I did 
find it exports a limited set FT2 functions in standard C style. But it 
looks like, for full functionality, I'm going to have to bridge the C++ divide.


Anyhow tips on the FPC->C++ front would be appreciated. I will probably 
search the list archives as I know this topic comes up repeatedly. I don't 
understand how ginormous an undertaking this might be but maybe I can 
contribute something on this front.


--
Sent from my Debian Linux workstation -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
j...@jfpossibilities.com

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Vehicle management

[Michael Van Canneyt]

On Thu, 11 May 2017, Mark Morgan Lloyd wrote:


On 11/05/17 08:30, Felipe Monteiro de Carvalho wrote:
On Thu, May 11, 2017 at 1:19 AM, Jon Foster 
wrote:> Yeah. The wiki is cluttered with inaccurate and abandoned information 
for> Android development. It needs a serious scrubbing. And access to needed> 
sources is somewhat hidden. I've combed it for a few years, now, to try and> 
deduce what's real and what's not. I'm not even sure where I got the bits of> 
source I'm using now. I've just been clinging to it like a shipwreck> 
survivor clinging to flotsam.
I don't think the wiki page I posted is inaccurate, all the stuffthere is 
valid AFAIK, but it is simply very incomplete. A lot moreshould be written, 
and also note that there are 2 different ways:

1> Via NDK combining native Pascal + Java2> Via JVM compiler
The wiki I posted is only for approach 1, even a link to a fullcompilable 
example is posted there (thought it is for OpenGL). I neverused approach 2 
and dont plan on using it.


Thanks for that, I admit that I found what was on the wiki confusing: 
it's never clear what's obsolete and what's merely incomplete.


So I think that what you're saying is that both approaches are still 
viable, but you favour the first.


I favour the second. I've been using it actively.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Vehicle management

[Mark Morgan Lloyd]

On 11/05/17 08:30, Felipe Monteiro de Carvalho wrote:

On Thu, May 11, 2017 at 1:19 AM, Jon Foster wrote:> Yeah. The 
wiki is cluttered with inaccurate and abandoned information for> Android development. It needs a 
serious scrubbing. And access to needed> sources is somewhat hidden. I've combed it for a few years, 
now, to try and> deduce what's real and what's not. I'm not even sure where I got the bits of> 
source I'm using now. I've just been clinging to it like a shipwreck> survivor clinging to flotsam.
I don't think the wiki page I posted is inaccurate, all the stuffthere is valid 
AFAIK, but it is simply very incomplete. A lot moreshould be written, and also 
note that there are 2 different ways:
1> Via NDK combining native Pascal + Java2> Via JVM compiler
The wiki I posted is only for approach 1, even a link to a fullcompilable 
example is posted there (thought it is for OpenGL). I neverused approach 2 and 
dont plan on using it.


Thanks for that, I admit that I found what was on the wiki confusing: 
it's never clear what's obsolete and what's merely incomplete.


So I think that what you're saying is that both approaches are still 
viable, but you favour the first.


For anybody else following this saga, I've now talked to the vehicle and 
the utility I'm using appears to run at 600 bps, not 800 so I'm probably 
not going to have to modify serial.pp. But some of the results are a bit 
odd and the author's had to use a lot of carefully tweaked timings which 
suggests that something's not quite right... 750 Baud, anybody? :-)


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

Re: [fpc-pascal] Vehicle management

[Felipe Monteiro de Carvalho]

On Thu, May 11, 2017 at 1:19 AM, Jon Foster
 wrote:
> Yeah. The wiki is cluttered with inaccurate and abandoned information for
> Android development. It needs a serious scrubbing. And access to needed
> sources is somewhat hidden. I've combed it for a few years, now, to try and
> deduce what's real and what's not. I'm not even sure where I got the bits of
> source I'm using now. I've just been clinging to it like a shipwreck
> survivor clinging to flotsam.

I don't think the wiki page I posted is inaccurate, all the stuff
there is valid AFAIK, but it is simply very incomplete. A lot more
should be written, and also note that there are 2 different ways:

1> Via NDK combining native Pascal + Java
2> Via JVM compiler

The wiki I posted is only for approach 1, even a link to a full
compilable example is posted there (thought it is for OpenGL). I never
used approach 2 and dont plan on using it.

-- 
Felipe Monteiro de Carvalho
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Vehicle management

[Jon Foster]

On 05/08/2017 11:34 AM, Mark Morgan Lloyd wrote:

On 08/05/17 18:30, Felipe Monteiro de Carvalho wrote:
On Sun, May 7, 2017 at 8:33 PM, Mark Morgan 
Lloyd wrote:> Can anybody give me a 
quick summary of the position of FPC on Android etc.?
Works fine like via JNI, you can do most stuff in Pascal using JNI 
butpart still needs to be in Java.

some info here: http://wiki.lazarus.freepascal.org/Android_Programming


Thanks Felipe, noted. I rather lost track when therewere (at least) two 
competing approaches.


Yeah. The wiki is cluttered with inaccurate and abandoned information for 
Android development. It needs a serious scrubbing. And access to needed 
sources is somewhat hidden. I've combed it for a few years, now, to try and 
deduce what's real and what's not. I'm not even sure where I got the bits 
of source I'm using now. I've just been clinging to it like a shipwreck 
survivor clinging to flotsam.


So, does anyone know, is this the "official" Android dev page?

I can testify that it is possible to write Android apps with FPC 3+. So far 
its been the most frustrating effort of my programming life. FPC does 
amazingly well but Android is chalk full of hidden gotchas and things that 
simply don't work as described.


I finally settled on the approach of using the JVM target to compile my 
app. I used GNU "make" to coordinate compiling and packaging. I used a few 
of the CLI tools from the Android SDK and "jarsigner" from the JDK to do 
the packaging and generating the resource identifiers. I used a stupid 
simple FPC program to perform a bunch of StringReplace() calls to convert 
the "aapt" created "R.java" (resource ID constants) file into Pascal. I 
also threw some headers and cruft-stripping in for good measure.


The biggest problem with doing it this way, besides the Google widgets 
doing things that I just can't fathom, is the lack of the FPC libraries we 
all love and have come to expect. You do have to bend your mind to fit the 
Java paradigm and sift through the Android/Java docs to find the things you 
normally use. Something as simple as converting a number to a string needed 
to be found. Actually I think I finally just wrote an IntToStr() because it 
was quicker than digging through docs.


I was thoroughly frustrated with the experience. Having previously tried to 
go all native code, which would be my preference anyways, I decided to 
revisit that idea before I do more with Android. As Graeme mentioned, I 
decided to try and leverage fpGUI into the Android environment. But with 
the extreme differences in execution model between Android and everything 
else, its kind of like fitting a square peg into a round hole. It will be a 
while. :-/


Speaking of frustrations. I don't envy you with your vehicle issue. I did 
some experimenting with a USB OBD-II dongle some time back. I was looking 
at building an FPC/Lazarus based diagnostic system. This was mostly spurred 
by the fact that my '99 Dodge Dakota ran well... but sometimes it ran 
REALLY AWESOM! I wanted it the latter way all the time.


In short I found that a huge amount of diagnostic data and interfaces are 
proprietary. The auto manufacturers don't want us lowly individuals to have 
it unless we're willing to shell out tons of money. One source I read said 
Ford was licensing their full PID data for $100K per year! Since I 
discovered the fpGUI gauges and the PocketCHIP I'm thinking I'd like to 
tinker with the OBD-II stuff again. But that probably won't help you.


I've never used the serial unit. It seems odd that you would have to patch 
"serial.pp" if the hardware is capable. Are there some non-OS imposed 
restrictions in there? I wrote some code back in the Kylix days to 
manipulate the Linux serial devices and that is my go-to lib for anything 
serial. Really all it does is provide an interface to ioctl() to set line 
disciplines. Other than that the serial device is just another file. My 
only concern with 800 baud is if the clock divider in the serial chip can 
go that low. Its also an odd step (300, 600, 1200, ... being the standards).


THX - Jon

--
Sent from my Debian Linux workstation -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
j...@jfpossibilities.com

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal