Lazarus and Freepascal PND

[ZXDunny]

I'll have a look at it over the next few days

D.

 

[Farox]

@ZXDunny

have you found some time to take a look at doublefractal?

I have done searching on code and found that this function:


function Test64kColors:boolean;
{testa se video tem 60k cores }
var TB:TBitMap;
TM:TMemoryStream;
SizeWord;
begin
TM:=TMemoryStream.Create;
TB:=TbitMap.Create;
TB.Height:=100;
TB.Width:=100;
Tb.SaveToStream(TM);
Size:=TM.Size;
Test64kColors:=(Size>30000);
TM.Free;
TB.Free;
end;

is responsible for not enabling the RGB controls.

I have reworked the main interface to fit the pandora screen and made the buffer to work with 800*480, but i have this problem with RGB controls.

Sorry for the little derailing of the thread

 

[ZXDunny]

function Test64kColors:boolean;
{testa se video tem 60k cores }
begin
Test64kColors:=True;
end;

We know that the Pandora can handle >64k colours, so just shortcut that procedure and return true in Test64kColors. Should do the trick.

D.

 

[Farox]

Ok i already done (bypassing the check) some days ago i now can move sliders but without any effect on image.

 

[ZXDunny]

Then it may be that there's an issue with TBitmap that doesn't exist on other architectures. Basically, that snippet creates a bitmap, then saves its contents to a memory stream. If there's enough bytes saved for it to be absolutely a high-colour image then TBitmap must have been created correctly.

Shortcutting that test tells the system that TBitmap must be able to handle high-colour images, but in reality it doesn't - at least on the Pandora. You could try testing TBitmap in small test projects to see what happens, or look for some sort of override to force the right bit-depth. TBitmap may inherit the default bitdepth of the desktop which may only be 16bit, in which case an override should sort it out.

Other than that you're going to have to rewrite all the TBitmap operations with SDL_Surface objects, which isn't going to be fun at all.

D.

 

[ZXDunny]

Been messing with this for various projects I have on the go, and it's getting a tad annoying - every time I build a project, it rebuilds the LCL, every single bit of it. On my CC pandora, this can take a few minutes at least!

Any idea why it does that, and if there's anything I can do about it?

D.

 

[Farox]

every time I build a project, it rebuilds the LCL, every single bit of it. On my CC pandora, this can take a few minutes at least!

yeah i experimented it...it's very annoying

 

[ptitSeb]

I will try to track down that.

 

[ptitSeb]

Been messing with this for various projects I have on the go, and it's getting a tad annoying - every time I build a project, it rebuilds the LCL, every single bit of it. On my CC pandora, this can take a few minutes at least!


Any idea why it does that, and if there's anything I can do about it?


D.

I have compiled latest Lazarus version (1.4.0).

Can you please test the PND before I put it on the repo: lazarus.pnd.(*edit* it's on the repo now).

 

[ZXDunny]

Much better! Only builds my source now, rather than all of the LCL when I compile

Many thanks!

D.

 

[ptitSeb]

It's on the repo now.

Build 06

-----------

• Updated Lazarus to 1.4.0

 

[Farox]

Hi

i was playing around with the examples of Lazarus and i don't seem to be able to build the project with opengl in LCL (called openglcontrol_demo) compilation goes ok but when the linker is called it's saying:

Compile Project, Target: openglcontrol_demo: Exit code 1, Errors:1

ld --dynamic-linker=/lib/ld-linux.so.3 -L -o openglcontrol_demo link.res

ld.bfd: warning: link.res contains output sections; did you forget -T?

ld.bfd: cannot find -lGL

openglcontrol_demo.pas(34,0) Error: Error while linking

i tried adding the libs (GL.so.1 GLU.so.1 etc) in the fpc/dir where are also the other libs but nothing,

i tried adding the libs in the source folder adding in the options the dir or the libs (passing -k option) but no effect.

i don't know if someone have already compiled this example or other with opengl with lazarus, if you have had success let me know how.

thanks

 

[Farox]

I found a solution

Codeblocks CLI must be running  to enable Lazarus found some missing libs (like GL one's ) when linking.

The only (strange) problem was that when i link with the CLI active it didn't find libxcb.so.1 (but the lib is there under /mnt/utmp/codeblocks/usr/lib ), i have copied this lib under

/media/sdcard/pandora/appdata/lazarus/fpc/lib/fpc/2.6.4  and linking was done correctly. B)

 

[ZXDunny]

Just a small query for you guys - probably this should be under general development rather than Lazarus, but anyhoo...

I've ported PandaBAS to OSX recently and performance of SDL is ... well, it's bloody awful. Maximum of 30fps on my very (very) high spec Macbook Pro which is also causing the entire interpreter to bog down as SDL waits for VSync that only happens every other frame, blocking the CPU at 100% while it does so.

So obviously SDL is a no-go for PandaBAS on OSX.

I got around it by implementing a very simple OpenGL renderer rather than SDL. This flies, and is very, very fast. So I used the same source to build it for Linux (Mint 32/64 17.3) and I'm getting frame times going down from 10-15ms per frame to less than 1ms per frame. Huge speed up as it reduces the load on the interpreter, on single core systems.

Here's the code for the GL upgrade, it's very simple (Width/Height are the size of the display, there's no scaling or anything, just a straight dump of the PixArray[] array to the display) :

  DISPLAYSTRIDE := Width * 4;
  SetLength(PixArray, Width * Height * 4);
  DISPLAYPOINTER := @PixArray[0];

  SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);
  glClearColor(0, 0, 0, 0);
  glClearDepth(1);

  glViewPort(0, 0, Width, Height);

  glMatrixMode(GL_PROJECTION);
  glLoadIdentity;

  glOrtho(0, Width, Height, 0, 1, -1);

  glMatrixMode(GL_MODELVIEW);
  glEnable(GL_TEXTURE_2D);
  glLoadIdentity;

  glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, Width, Height, 0, GL_RGBA, GL_UNSIGNED_BYTE, DISPLAYPOINTER);
  glTexParameterI(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
  glTexParameterI(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
  glEnable(GL_TEXTURE_2D);

And here's the code for the frame update:

      glClear(GL_COLOR_BUFFER_BIT);
      glLoadIdentity;
      glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, DISPLAYWIDTH, DISPLAYHEIGHT, GL_BGRA, GL_UNSIGNED_BYTE, @PixArray[0]);
      glBegin(GL_QUADS);
      glTexCoord2D(0, 0); glVertex2D(0, 0);
      glTexCoord2D(1, 0); glVertex2D(DISPLAYWIDTH, 0);
      glTexCoord2D(1, 1); glVertex2D(DISPLAYWIDTH, DISPLAYHEIGHT);
      glTexCoord2D(0, 1); glVertex2D(0, DISPLAYHEIGHT);
      glEnd;
      SDL_GL_SwapBuffers;

Yes, it's using SDL-GL, but I might as well - I'm using SDL for image loading and such anyway.

So here are the questions:

1. Will this benefit the Pandora at all? The interpreter runs in its own thread separate from the display, which updates at 50Hz. I figure that the performance upgrade on OSX/Linux/Win x86 will benefit single cores most of all because the interpreter gets more CPU time to itself. But SDL on the Pandora uses (I assume!) Notaz's fast blitting code which may well be faster than uploading textures to the SGX every frame. Would that be right?

2. Can this be done, in Lazarus, on the Pandora? The only way to test it is to build it myself, I suppose.

3. Can the frame update be made faster (the second portion of code)? I'm not sure that declaring a quad every frame is necessary - can it be cached somehow and just uploaded to the SGX without creating it with glTexCoord2D every frame?

Cheers Guys

D.

 

[ptitSeb]

This code is mostly GLES 1.1 compatible, so you either use glshim or use some GLES code on Lazarus (I know it exist somewhere).
The only issue will be the BGRA that you use in the glTexSubImage2D, that will not work on GLES, and will be slow on glshim.

About the speed, it's a single blit, so it will not be any faster with GL than using plain SDL, or using omapdss driver (plus there is no scalling, so GL will probably be useless, unless you add some scanlines or things like that), or convert the whole engine to use GL instead of blitting in a surface).

The 2nd part can be made faster on Pandora using Streaming Texture (but you need RGB 565 data), but still, for just plain blitting, use SDL (I can send you diff from cannonball to have an exemple of SDL vs OGLES 1.1+Streaming Texture)

 

[ZXDunny]

Sounds like it's not gonna be much of a gain then - though there's no scaling done anyway, a single blit will be just as fast. PandaBAS works internally with BGRA format, that's not been a problem for the Pandora at all in the SDL version (I chose that format as it was the one that SDL uses by default in 32bpp on he Pandora, so all the builds - OSX/Linux/Windows use that format).

I'll drop this one and continue to use SDL then.

Also going to give armhf a try in Lazarus, see what kind of difference that makes

D.