[fpc-pascal] ptcgraph issues

[James Richters]

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 ?

[Michael Van Canneyt]

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

[Bogdan]

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 ?

[fredvs]

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 ?

[Michael Van Canneyt]

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 ?

[fredvs]

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?

[Reimar Grabowski]

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?

[Reimar Grabowski]

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

[Tony Whyman]

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

[Ewald]

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 ?

[Michael Van Canneyt]

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

[Graeme Geldenhuys]

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

[Graeme Geldenhuys]

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 ?

[Maciej Izak]

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 ?

[fredvs]

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?

[Graeme Geldenhuys]

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?

[Graeme Geldenhuys]

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?

[Michael Van Canneyt]

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?

[noreply]

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?

[Marco van de Voort]

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

[Michael Schnell]

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?

[noreply]

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

[Mattias Gaertner]

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

Re: [fpc-pascal] Best way to check SimpleIPC for messages

[noreply]

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

[noreply]

On 2017-05-16 09:20, fredvs wrote:

Michael Van Canneyt wrote

On Tue, 16 May 2017, fredvs wrote:


Michael Van Canneyt wrote

What can be misunderstood about adding --gc-sections to the linker
options if -XX is used on the command-line ?


Ha, the way you present it seems to show that you did understand it 
;-)


OK, maybe is it time to add a feature request...


Before filing a request, you can already check yourself what happens 
with

form data if you compile a lazarus form into the library.

Michael.


Huh, with all the respect that I have for LCL, I was never able to 
compile a

Lazarus form into library


Hrm... I think way back I was able to compile a lcl form into a library, 
as a plugin for lazarusrb, but, had issues with showmessage requiring 
two mouse clicks instead of one click to close it, or some strange 
behaviors..


But it was such a long time ago that I forgot. Some strange message loop 
issues AFAIR

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

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



Upon further inspection it seems fpc already uses internal functions
such as
fpc_in_sqrt_real

which are defined as integers that fpc references magically somehow 
internally..


So probably already fast, but I'd have to check further.

I don't know how internal functions work. Internal to the compiler 
source code, internal as in direct cpu calls that the cpu so gladly 
gives you?


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

Am 17.05.2017 07:18 schrieb :
>
> On 2017-05-15 17:37, James Richters wrote:
>>
>> I have managed to get ptcgraph and ptccrt to work with my program and
>> I can report that there is an AMAZING increase in graphics
>> performance!   It is pretty much a drop in replacement and I did not
>> change any compiler settings.  I did have to make a few minor changes
>> to get it to work, not enough to change the speed of anything.
>>
>
> So it can't be an fpc problem, but a unit module problem that someone
didn't spend time optimizing which has little to do with fpc but more to do
with the way the units were written?
>
> Or is the ptcgraph/ptccrt in assembly code to avoid FPC mode objcfpc
compilation and use assembly instead? Sorry I have not looked at it.. don't
know.

You don't need to look at the code you merely need to look at the mails
that Nikolay has written in this thread. There he writes that the stock
graph unit and the PTC graph unit both use different approaches to interact
with the Windows API this allowing the latter not to have the same
bottleneck as the former.

Regards,
Sven
___
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]

Am 17.05.2017 07:15 schrieb :
>
> 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...
>
> At one time the fpc system units or sysutils was written in a lot of
assembly, then they changed it to more pascal so it was more readable for
people like me who stay away from assembly :-)  Not because assembly is bad
or anything, I just like living in high level procedural land, instead of
low level assembly machine land.

It has nothing to do with readability. It's about portability instead as
FPC supports many different CPUs all with their own assembly language and
quirks.
Though that stops no one from implementing platform specific routines which
was done for some platforms (e.g. the x86 ones).

Regards,
Sven
___
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]

Am 17.05.2017 07:12 schrieb :
>
> On 2017-05-15 17:27, Graeme Geldenhuys wrote:
>>
>> On 2017-05-15 22:50, nore...@z505.com wrote:
>>>
>>> Graeme will need to clarify whether he was trying to be harsh on FPC
>>> entirely, or just specifically in some areas.. :-)
>>
>>
>> I'll try and clarify... I believe FPC generates slow (or slower than
>> Delphi, GCC and Java) code no matter what. The saving grace is that
>> you don't really notice it on normal event-based desktop applications.
>> Writing a game is a whole different story. Games are way more
>> sensitive to performance.
>>
>> Now the game I wrote, was a desktop GUI application. It was slow under
>> Linux, FreeBSD and Windows. So the results were consistent, no matter
>> what GUI API was used Be that fpGUI (via GDI), fpGUI (via X11) or
>> LCL-GTK2. In all cases, game rendering was to a memory image, then
>> once done, that memory image was bitblit to the Window Canvas.
>>
>> The Java and GCC versions did the same, but were faster.
>>
>> That's all I can say about. Make your own assumptions - read into it
>> any conspiracy theories or what-not. ;-) At this point I don't really
>> care, as I already moved on with that project, using OpenGL instead
>> (both for Java and Object Pascal).
>>
>
> But any game ends up using opengl anyway, doesnt' it? Sorry I'm not a big
game programmer. Want to be, some day.

No, OpenGL is not a given. E.g. on Windows you can use DirectX and
depending on the demands of your game a TCanvas might be completely
sufficient.
Also Graeme was talking about a raytracer which is a completely different
beast compared to OpenGL/DirectX/Vulkan. 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.

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