Installation of Graphics32 compile fails

[jkorten]

I have downloaded the graphics32 an want to use it, given how slow the default Tbitmap operations are, but the install fails with the message: unkown identifier. It points to a portion of assembler code highlighting the variable "SrcPoint.X" as unknown.

{$IFNDEF TARGET_x86}
begin
  DstPoint.X := (SrcPoint.X + $7F) div 256;
  DstPoint.Y := (SrcPoint.Y + $7FFF) div 65536;
{$ELSE}
asm
    MOV ECX, [SrcPoint.X]
    ADD ECX, $0000007F
    SAR ECX, 8 // sub-sampled
    MOV [DstPoint.X], ECX
    MOV EDX, [SrcPoint.Y]
    ADD EDX, $00007FFF
    SAR EDX, 16
    MOV [DstPoint.Y], EDX
{$ENDIF}     


And when I comment out the ifdefs to compile the pascal code instead it knows about SrcPoint.X

Is there a compiler switch I need to make in order to allow Lazarus to know about variable names in assembler code?

Thanks for your help.

Jerry

[jkorten]

OK if nobody else replies to my post I will. So I undefined TARGET_x86 to avoid the error. Now I only have an error on install that it does not know where GR32_blend is.

I will keep you posted (I know this is exciting).

Thanks

[BigChimp]

Hi jkorten,

Thanks for posting your solution - that might help other people that find this post...

Don't know if graphics32 is in the Lazarus CCR repository; if it is, please file a bug report with the information in your posts (including Lazarus, FPC version, operating system, version/date of graphics32).
This will make it MUCH more likely that the developers will see this and fix it.

If graphics32 is not in Lazarus or Lazarus CCR, I'd suggest you file a bug with the author...

Thanks,
BigChimp

[felipemdc]

Some years ago I ported Graphics32 to Lazarus so if you get their very latest source code it should work. Last time I looked their last release was ages ago, so a snapshot or something like that would be a better choice. But I haven't used it in years, so I can't say much for sure.

[jkorten]

 

OK the complete install works on a windows installation when you do the following:

1) Open the file GR32_Polygons.pas and insert a line {UNDEF TARGET_x86} after the  {$I GR32.inc} directive.
2) choose package->open package file and choose the GR32_DSGN_L.lpk file and compile.
3) before installing - open the GR32_L.PAS file and change the "unit gr32_l" to "unit gr32_l.pas" hit file save.
4) open the GR32_DSGN_L.PAS and chang ethe "unit GR32_DSGN_L" line to "unit GR32_DSGN_L.PAS" and hit file save
5) now click the "use" (which will install the package in lazarus by recompiling the GUI.

The gr32_dsgn_l file will be changed back by the compiler again and so will the gr32_l file but this is how you get the fpc compiler to know about the various unit dependencies I guess.

This seems like a Lazarus package install bug more than a graphics32 issue - can anybody comment?

Thanks

Jerry

[mica]

I think in Code Typhon is a working Version included.

[jkorten]

Thank you Mica,

In fact with the package installed - all kinds of range check errors and stack faults occur. It appears the package is not useable on windows at least.

 

[dballesg]

Hi,

I have problems with the package for this library and the library itself as well.
I managed to compile and compile a few of the examples with the latest FPC SVN and Lazarus versions (under Windows Vista 64).

For that I redid the package from scratch, making all the units filenames lowercase. After that I tried to use the GR32 library inside a control using the same technique that customdraw controls use. And I can only get a black square with a simple button.

So I decided to split the library on smaller units getting rid of the HUGE GR32.pas. And I started getting circular unit errors between GRBitmap32 (one of my smaller units, split from GR32.pas) and GR32_Layers.pas. I managed to solve it reviewing all the uses clauses by trial and error.

And a snippet of the code:

Code: [Select]

//--------------------------------------------------------------------------------------------
unit GR32CustomBitmap32;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, Graphics,

  GR32CustomMap,
  GR32BitmapTypes,
  GR32BitmapFunct,
  GR32_Lowlevel,
  GR32Color,
  GR32Rectangles,
  GR32FixedTypes,
  GR32CustomSampler,
  GR32ThreadPersistent,
  GR32_Blend;             

interface 

type
  // TCustomMap is  on it's own unit
  TCustomBitmap32 = class(TCustomMap)
  private
    // Field declarations....

    procedure BackendChangedHandler (Sender: TObject); virtual;
    procedure BackendChangingHandler(Sender: TObject); virtual; 
    // more code...
end;

implementation

procedure TCustomBitmap32.BackendChangingHandler(Sender: TObject);
begin
  // descendants can override this method.
end;

procedure TCustomBitmap32.BackendChangedHandler(Sender: TObject);
begin
  FBits := FBackend.Bits;
  ResetClipRect;
end;   

end.

--------------------------------------------------------------------------------------------
unit GR32Bitmap32;

{$mode objfpc}{$H+}

interface

uses
  LCLType, Types, Classes, SysUtils, Graphics,

  GR32CustomBitmap32,
  GR32Color;         

type
  TBitmap32 = class(TCustomBitmap32)
  private
    FOnHandleChanged: TNotifyEvent;

    procedure BackendChangedHandler (Sender: TObject); override;
    procedure BackendChangingHandler(Sender: TObject); override;
  end;

implementation

uses
  GR32_Backends;   

procedure TBitmap32.BackendChangedHandler(Sender: TObject);
begin
  inherited;
  HandleChanged;
end;

procedure TBitmap32.FontChanged(Sender: TObject);
begin
  // TODO: still required?
end;       

end.


Now I'm getting this strange error:

C:\lazarus\components\graphics32Laz\source\gr32bitmap32.pas(66,15) Error: There is no method in an ancestor class to be overridden: "TBitmap32.BackendChangedHandler(TObject);"

Note that I'm using the objfpc mode and I tried to erase as much of the Delphi compatibility (defines even) for Delphi.

A friend of mine has even implemented a reviewed version of some of the SSE2 routines, but he submitted one to the original project and has been completely ignored.

We are thinking on fork this monster and make it 100% Lazarus compatible, completely avoiding the Delphi mode of the FPC compiler. I even have a second package mixing up GR32 and VPR in one package (Aliased support on GR32 + VPR for tex is the state of the art),  but this mix-up is on hold due to the problems that I found on GR32 alone.

Is a pity, because this library made 100% Lazarus compatible and cross platform could be the base to substitute the non aliased and slow drawing methods of the LCL.

So any help will be appreciated fixing that error with the two virtual methods?

Thanks in advance
David

[marcov]

In fact with the package installed - all kinds of range check errors and stack faults occur. It appears the package is not useable on windows at least.

Most Delphi originated code doesn't work with checks on. 

[Sternas Stefanos]

Hi,
........

So any help will be appreciated fixing that error with the two virtual methods?

Thanks in advance
David

CodeTyphon has the latest SVN (revision 1459)
Graphic32 Library, with our modifications
for win32, win64 and WinCE
and with some working samples
have fun...

[dballesg]

Thanks Sternas. Last time I tried Code Typhoon had problems trying making it to work. But hta twas months ago. I will have a look to it again.

Loesje on the IRC helped me. I simply need to move those to methods from the private to the protected section.

I have my own modifications, like use the objfpc mode, and I splitted the GR32.pas on several smaller units.  And other ASM modifications specific to x64 made by a friend.

David

[fripperama]

To sucessfully install the Graphics32 1.9 (in Delphi or in Lazarus), I modified the procedures RoundShifts in a way it can be compiled and to keep functioning correctly.

Apparently, there is a problem in using vectors and registers in ASM code, so this modification uses a temporary variable to pick up the values from the registers and then assigning it back.

This is the example for RoundShift1. You can use the same for the others RoundShifts. If anyone finds this helpful, I can put the others procedures for making things easier for everyone.

All the Best,
Gabriel.

procedure RoundShift1(var   DstPoint: TFixedPoint;
                      const SrcPoint: TFixedPoint;
                      const T: TTransformation);

Var
SourcePointX: TFixed;
SourcePointY: TFixed;
DestPointX:   TFixed;
DestPointY:   TFixed;
{$IFNDEF TARGET_x86}
{$IFDEF INLININGSUPPORTED}
inline;
{$ENDIF}
{$ENDIF}
begin
{$IFNDEF TARGET_x86}
  DstPoint.X := (SrcPoint.X + $7F) div 256;
  DstPoint.Y := (SrcPoint.Y + $7FFF) div 65536;


{$ELSE}
  SourcePointX := SrcPoint.X;
  SourcePointY := SrcPoint.Y;
  DestPointX   := DstPoint.X;
  DestPointY   := DstPoint.Y;

  asm
  // MOV ECX, [SrcPoint.X]
  MOV ECX, [SourcePointX]

  ADD ECX, $0000007F
  SAR ECX, 8   // sub-sampled

  // MOV [DstPoint.X], ECX
  MOV [DestPointX], ECX

  // MOV EDX, [SrcPoint.Y]
  MOV EDX, [SourcePointY]

  ADD EDX, $00007FFF
  SAR EDX, 16

  // MOV [DstPoint.Y], EDX
  MOV [DestPointY], EDX
  end;
  DstPoint.X := DestPointX;
  DstPoint.Y := DestPointY;
{$ENDIF}
end;