[fpc-pascal] Bls: named parameter

[Mr Bee via fpc-pascal]

Hi, Sven… 
This is what I'm thinking… 
// function declarationfunction f(i: integer = 0; s: string = ''; d: 
double);begin // fill code hereend;// method callingf(s := 'text', 0.1); // 
supply the s and d paramf(0.2);  // only supply the required d param// supply 
all the params without proper order is fine,// as long as the parameter name is 
givenf(d := 0.3, i := 3, s := 'text')// supply param with similar variable name 
is fine,// because the compiler knows what each meanss := 'another text';d := 
0.4;m(s := s, d := d);
 
Well, it's all inspired from Swift, but I think it suits Pascal as well. 
As you said the code is already there in FPC compiler, is it possible to 
support such syntax in next release? At least some of them. Can we have this 
named parameter feature in a particular switch mode, say {$MODESWITCH 
NAMEDPARAMETERS} or something, so it doesn't bother anyone who don't want this 
feature.
Thank you.
Regards,
–Mr Bee
 

Pada Sabtu, 27 Mei 2017 21:18, Sven Barth via fpc-pascal 
 menulis:
 

 2017-05-27 16:12 GMT+02:00 Michael Van Canneyt :
>
>
> On Sat, 27 May 2017, Sven Barth via fpc-pascal wrote:
>
>> 2017-05-27 9:54 GMT+02:00 Michael Van Canneyt :
>>>
>>>
>>>
>>> On Sat, 27 May 2017, Mr Bee via fpc-pascal wrote:
>>>
 Hi,

 As Pascal mostly well known as a safe, easy to read, and elegant
 language,
 don't you think Pascal needs named parameter? I mean for ALL kind of
 parameters, not just for Variants. When you have a function with many
 parameters having default values, you know that named parameter is
 desirable. For example:

 function f(p1: string = ''; p2: integer = 0; p3: boolean = false);

 But you only need to supply the third parameter, you still must supply
 the
 first and second ones with appropriate default values, like this:

 f('', 0, true);

 while with named parameter, you can do this:

 f(p3 := true);

 I believe it would raise Pascal's code readability. I know it has been
 discussed before. I know somehow the parser had been able to read such
 syntax. So, why don't we have the option to enable it for people who
 want
 it? Kinda a syntax switch mode.

 What do you think? :)
>>>
>>>
>>>
>>>
>>> Opinions on what constitutes readable code clearly differ :)
>>>
>>> But as far as I know, the parser is not able to read this syntax ?
>>
>>
>> The parser supports it for dispatch calls on variants (both methods
>> and properties). You even wrote that in your own article about Word
>> automation: https://www.freepascal.org/~michael/articles/word/word.pdf
>> ;)
>
>
> Yes, in Delphi. But I didn't know FPC also supports it ?

Yes, it does. I didn't find a testcase for it right away, but the
compiler definitely contains code for this.

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

   ___
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

[Graeme Geldenhuys]

On 2017-05-30 22:37, James Richters wrote:


Putimage() takes
Initial X position
Initial Y position
Pointer to beginning of memory bitmap


In that case the AggPas code should be even faster, because PutImage() 
only want a pointer to the bitmap data - thus no need to go through the 
slow FPImage code to generate a PNG or BMP image. The pixel-by-pixel 
conversions for FPImage is very slow.



   Size := ImageSize(10, 20, 30, 40);
   GetMem(Q, Size);   { Allocate memory on heap }


So you can do pretty much the same with AggPas then. Allocate the memory 
you need, and attach that as the rendering buffer or AggPas. As I 
mentioned before, AggPas just needs to know what memory it can write 
too, and in what format you want that rendered data to be. AggPas 
supports many render buffer formats. BGR, BGRA, RGB, RGBA, Gray8, 
rgb555, rgb565 etc etc. And if an existing render buffer format doesn't 
exist, it is really easy and quick to add a new one - just a few really 
simple procedures to implement.


See the pf_*.inc files for plenty of examples. The "pf_" prefix stands 
for "pixel format definition".




I'm looking at it and I think getimage / putimage are just one byte per 
pixel... maybe?


I'll see if I can get graph or ptcgraph working working here under 
FreeBSD, then I'll take a look at what pixel format they use.



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] Implementing AggPas with PtcGraph

[James Richters]

>  * What parameters does its putimage() function take?
>  * Does in support PNG image format natively?

Putimage() takes
Initial X position
Initial Y position
Pointer to beginning of memory bitmap
Method to use (copy, AND, OR, XOR)  
See https://www.freepascal.org/docs-html/rtl/graph/putimage.html


Here's an example:
Var Q: Pointer;
   Bar(0, 0, (GetMaxX div 3), GetMaxY);
   Size := ImageSize(10, 20, 30, 40);
   GetMem(Q, Size);   { Allocate memory on heap }
   GetImage(10, 20, 30, 40, Q^);
   Readln;
   ClearDevice;
   PutImage(100, 100, Q^, NormalPut);
   readln;
   putimage(0,0,Q^,normalput);
   readln;

I can get this to work with getimage and putimage, but I have no idea how to 
build the image in memory and just use putimage.

I don't think it really supports any 'image formats'  it's just the TP 
compatible graphics thing for DOS style graphics.

I'm looking at it and I think getimage / putimage are just one byte per 
pixel... maybe?  so probably not what I want. 
I'm getting the feeling this is apples and oranges here, TP compatible memory 
map vs tcolor or tfpcolor or some other scheme with 4 bytes per pixel.
Maybe there just isn't anything canned that can do what I want?  Maybe I need 
to put the pixels on the screen myself using a nested loop and getpixel / 
putpixel and do whatever logic on my own.

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Tuesday, May 30, 2017 4:55 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

On 2017-05-30 20:20, James Richters wrote:
> I've re-attached Graeme's sample slightly modified to open the 
> ptcgraph window, and attempt to use putimage on line 103 but when I 
> run it I get 217- access violation

I haven't downloaded or looked at ptcgraph at all. A few questions:

  * What parameters does its putimage() function take?
  * Does in support PNG image format natively?

I would imagine that it probably supports BMP only - comping from DOS and 
Windows background. If so, change the example program to use a BMP image 
instead of a PNG image. In your code you attached you are actually pushing the 
c variable, which is a TFPColor record of the last color retrieve from the 
AggPas buffer - so no surprise you are getting a AV error.

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

___
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

[Graeme Geldenhuys]

On 2017-05-30 20:20, James Richters wrote:

I've re-attached Graeme's sample slightly modified to open the
ptcgraph window, and attempt to use putimage on line 103 but when I
run it I get 217- access violation


I haven't downloaded or looked at ptcgraph at all. A few questions:

 * What parameters does its putimage() function take?
 * Does in support PNG image format natively?

I would imagine that it probably supports BMP only - comping from DOS 
and Windows background. If so, change the example program to use a BMP 
image instead of a PNG image. In your code you attached you are actually 
pushing the c variable, which is a TFPColor record of the last color 
retrieve from the AggPas buffer - so no surprise you are getting a AV error.


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

[fpc-pascal] Implementing AggPas with PtcGraph

[James Richters]

>As I mentioned, AggPas can use allocated memory, array, a memory image etc as 
>its rendering buffer. If you want a graphical console program
>(eg: using Linux Console Framebuffer) using AggPas, then render your 
>application output via AggPas to a memory image, then bitblit that image
>to the console graphics output in whatever paint event you have available.

>Using AggPas with desktop GUI applications works pretty much identical as 
>above, except it bitblit's the memory image to the Window Canvas.

What is the best method for getting the memory image to a ptcgraph window?  I 
have been trying to figure how to use something like putimage to do this but 
I'm not sure how to do it or if it's even the best way.I think I probably 
need to convert the format of the memory buffer or something, but I can't 
figure out what to do.

I've re-attached Graeme's sample slightly modified to open the ptcgraph window, 
and attempt to use putimage on line 103 but when I run it I get 217- access 
violation

Any advice on how to get the image into the window is greatly appreciated.

James


Agg2DConsole.dpr
Description: Binary data
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GLM library alternative?

[Marco van de Voort]

In our previous episode, Ingemar Ragnemalm said:
> BTW, when I ported my OpenGL demos to FPC, I found that the FPC glext.pp 
> had some fatal bugs. (Easy to fix, but I never figured out who would 
> want the corrections, so I hope someone else noted that it crashed for 
> modern OpenGL.)

Well, actually I don't use FPC opengl but dglopengl :-)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GLM library alternative?

[Anthony Walter]

I've done a bit of assembly programming for IA-32, none recently and zero
compiler development other than simple parsers, but from what I know
optimizing with newer instructions like SSEx is only part of there story.
There's also optimizing for out of order instruction execution (OoOIE), or
instruction reordering. Even on a single core, when optimized done properly
it can yield 4x or more increase in processing speed, avoiding CPU stalls,
which is likely happening a lot given the descriptions people have provided
in this thread.

Obviously properly using SSEx instructions and optimizing for OoOIE is a
non trivial undertaking. I think probably the best way to test FPC out is
to stop writing speed tests against other languages, and to view the CPU
instructions generated for a few different loop types, including
trunc()/floor() functions. Next rewrite those parts in assembler, include
SSE whatever instructions and pepper in OoOIE, and finally test the speed
difference.

My instincts tell me if the compiler could then generate both SSEx and
OoOIE properly it could automatically applied in many places, resulting in
a huge speed up for FPC programs. But for me, the main advantage of Free
Pascal is that it generates native language, leading to easier reuse of C
style APIs such as Cairo/GTK/SDL, and also allowing for the PME
(properties, methods, events) plus all the other nice features Free Pascal
offers. Most of the time my programs are either idle waiting for user
input, or idle waiting for other APIs or in the case of OpenGL the graphics
hardware to complete. As such the execution speed of the pascal portion of
my programs isn't as important.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GLM library alternative?

[code dz]

tested with the fpc trunk , got only 3 fps increased .
but even with this result fpc does great job , compared with gcc7  ,
gcc is faster only about 45% . so when compared with a compiler like
gcc which get tens of patches par day from from around the world
including big companies like sumsung . and you get only 45% deference
in speed , no doubt fpc is great compiler .
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Error building FPC 3.0.2 from svn sources on RPi3

[Giuliano Colla]

Il 29/05/2017 23:28, Bo Berglund ha scritto:


I have bought and initialized a new RPi3 today. It runs Raspbian
Jessie PIXEL latest version.
I don't know what you're going to use your RPi3 for, but just in case, 
are you aware that now you can install an RT_PREEMPT kernel, and enjoy 
the real-time patch low latencies?


Giuliano

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

Re: [fpc-pascal] GLM library alternative?

[Graeme Geldenhuys]

On 2017-05-29 12:24, Mattias Gaertner wrote:

Jonas told that the benchmark program contains a number of bugs/wrong
translation from the C code:


And all of those recommendations were applied by Jon Foster and yielded 
only a 0.6% increase in speed.


"I ended up with an hour of extra time so I went over Jonas' suggestions 
again. I made tweaks fixing integer types, using trunc() instead of 
round, ... The over all  improvement is only +0.6%, as I predicted 
nowhere near the 10x+ needed to compete with the other languages."


  -- Jon Foster (in the MSEide+MSEgui mailing list dated 2017-05-24)


So the major speed problem still seems to be the FPC optimisation with 
looping and not using SSEx when it is available.


I personally haven't tested with the latest FPC 3.1.1 yet.


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] GLM library alternative?

[Graeme Geldenhuys]

On 2017-05-30 14:52, Ingemar Ragnemalm wrote:

so I hope someone else noted that it crashed for
modern OpenGL.)


Huh? I've been using it for 4 months with "modern OpenGL 4.x" (non-fixed 
rendering pipeline) and it hasn't crashed on me.


Next time it crashes, please supply a small code example if you can, or 
at least a backtrace so we can see where the error originated.



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] GLM library alternative?

[Ingemar Ragnemalm]

Den 2017-05-30 kl. 12:00, skrev Marco van de Voort:

For the 2Ders, in old GL I used glortho2d a lot. In newer ones I missed that, 
but I found
an equivalent on stackoverflow:


My FPC vector unit has overloading and many other functions 
(determinant, rotation around arbitrary axis...). Some functions like 
lookAt, frustum, ortho, matrix inverse etc are only in my C version so 
far. Not hard to port.


mat4 ortho(GLfloat left, GLfloat right, GLfloat bottom, GLfloat top, 
GLfloat near, GLfloat far)

{
float a = 2.0f / (right - left);
float b = 2.0f / (top - bottom);
float c = -2.0f / (far - near);

float tx = - (right + left)/(right - left);
float ty = - (top + bottom)/(top - bottom);
float tz = - (far + near)/(far - near);

mat4 o = SetMat4(
a, 0, 0, tx,
0, b, 0, ty,
0, 0, c, tz,
0, 0, 0, 1);
return o;
}

So I have a pile of code on the topic, much of it for FPC. But shouldn't 
there really be a good OpenGL support package for FPC that was some kind 
of "standard"?


BTW, when I ported my OpenGL demos to FPC, I found that the FPC glext.pp 
had some fatal bugs. (Easy to fix, but I never figured out who would 
want the corrections, so I hope someone else noted that it crashed for 
modern OpenGL.)


/Ingemar

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

Re: [fpc-pascal] GLM library alternative?

[Reimar Grabowski]

On Mon, 29 May 2017 14:07:40 -0400
Anthony Walter  wrote:

> By the way, what's stopping you guys from using OpenGL ES 2.0?
It's ten years old, the current ES version is 3.2.
It has less functionality than "standard GL" as it's meant for embedded systems 
(hence ES).

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

Re: [fpc-pascal] GLM library alternative?

[Marco van de Voort]

In our previous episode, Anthony Walter said:
> 
> This type of 2D setup in OpenGL allows for allows you to freely mix in both
> 2D and 3D effects. Here's are two examples of how 2D in a 3D world can work:

If you check the myorthohelp function that called it, you'll already see it
is normalized to [0..1] coordinates.

But there are some special cases (e.g. sometimes zoomx<>zoomy to get square
pixels), vertical inversion etc where not everything is 0..1,0..1

I don't need 3D effects, this is a business app. For an (older) demo based
on the code see

http://forum.lazarus.freepascal.org/index.php/topic,30556.msg194484.html#msg194484


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

Re: [fpc-pascal] GLM library alternative?

[Anthony Walter]

Marco,

Regarding 2D animation, what I've far far more effective than an
orthographic projection is to draw 2D billboard sprite at a distance and
size to align exactly with your screen's resolution. That is each width and
height of "1" gl world equals "1" screen pixel, and coordinate (0, 0)
equals the top left corner of your screen.

This type of 2D setup in OpenGL allows for allows you to freely mix in both
2D and 3D effects. Here's are two examples of how 2D in a 3D world can work:

Card Games: https://www.youtube.com/watch?v=lOUB4pqRLjY
Animation of vector graphics: https://www.youtube.com/watch?v=P1cd-kWBz0E
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GLM library alternative?

[Marco van de Voort]

In our previous episode, Anthony Walter said:
> By the way, what's stopping you guys from using OpenGL ES 2.0? It works on
> most all Windows, Mac, and Linux systems, and it's the only 3D graphics API
> on Raspberry Pi and most smart phones/tablets.

IIRC I went for opengl 3.3-4 because one could find more about it and
because opengl ES afaik has no geometry shader support.

The GL stuff is only for Windows PC (and very maybe Linux PC) anyway.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GLM library alternative?

[Marco van de Voort]

In our previous episode, Ryan Joseph said:
> > On May 28, 2017, at 10:33 PM, Ryan Joseph  
> > wrote:
> > 
> > projTransform := TMatrix4x4.CreatePerspective(60.0, 500 / 500, 0.1, 
> > 10.0);
> > modelTransform := TMatrix4x4.CreateTranslation(0, 0, -3.0) * 
> > TMat4.CreateRotateX(54);
> 
> I found out the problem. I was expecting the multiply to work like with GLM 
> where you could do: 
> 
> translation * rotation
> 
> but with the operator overloads I need to do protation * translation.
> Anthony?s multiply matrix 4 operators did this in the order I expected and
> how I figured it out.  Not sure why and it?s probably not safe to swap the
> parameters because it would likely break other parts of the unit.

For the 2Ders, in old GL I used glortho2d a lot. In newer ones I missed that, 
but I found
an equivalent on stackoverflow:

// http://stackoverflow.com/questions/21323743/modern-equivalent-of-gluortho2d
procedure MyOrtho2D(var mat : TGLMatrixf4;left,right,bottom,top:single);
var inv_y,inv_x : single;
begin
  inv_y := 1.0 / (top - bottom);
  inv_x := 1.0 / (right - left);

// this is basically from
// http://en.wikipedia.org/wiki/Orthographic_projection_(geometry)

//first column
mat[0][0] := (2.0*inv_x);
mat[0][1] := (0.0);
mat[0][2] := (0.0);
mat[0][3] := (0.0);

//second
mat[1][0] := (0.0);
mat[1][1] := (2.0*inv_y);
mat[1][2] := (0.0);
mat[1][3] := (0.0);

//third
mat[2][0] :=  (0.0);
mat[2][1] :=  (0.0);
mat[2][2] :=  (-2.0*inv_z);
mat[2][3] :=  (0.0);

//fourth
mat[3][0] :=  (-(right + left)*inv_x);
mat[3][1] :=  (-(top + bottom)*inv_y);
mat[3][2] :=  (-(zFar + zNear)*inv_z);
mat[3][3] :=  (1.0);
end;

I have a TGLvector for zoom (X/Y) and one for pan (offset, also in X and Y
direction).

// calcs a matrix for the shader. pass the matrix as an uniform and multiply  
in vertex or geometry shader

procedure myorthohelp(var mat : TGLMatrixf4;const
aoffs,azoom:TGLVectorf2;topdown:boolean=false);
begin
  myOrtho2D(mat,aoffs[0], 1.0 / (aZoom[0]) + (aoffs[0]), 1.0 / (aZoom[1]) + 
(aoffs[1]), aoffs[1])
end;

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