C to Pascal conversion hq2x

[jdarling]

System: Windows, Linux, other
Compiler/IDE: FPC, Lazarus
Libraries/API: None

After seeing the threads and playing with hq2x myself I started looking for a pascal equivalent. There is none . So, I converted it myself.

I converted the entire contents of hp2x from C++ to FPC/Lazarus (should work in Delphi too). Problem is the output image is always black (read blank). I know that this is due to pointer problems, but it may also be due to the fact that I had to use LazarusRGB to load the images (this is so I can get the pointer to the pixels).

If anyone feels frisky download http://www.eonclash.com/PGD/hq2x.zip and see if you can fix it.

I think that there is quite a few of us that could benefit from just such a unit.

In case your lazy, my conversion of the pointers looks as follows:
C Source:

*((int*)pc) = (c1*3+c2) >> 2;

Pascal:[pascal]Longword(pc{$IFDEF DeReferenceOutPointers}^{$ENDIF}) := (c1*3+c2) shr 2;[/pascal]

If you have DeReferenceInPointers defined then the app will blow up with an invalid index (I think this is due to the alpha channel in Lazarus RGB pixel pointer), if you don't have it defined then you get a black output image. Undefining DeReferenceOutPointers won't allow the application to compile, as the compiler can't match the types. I also had to make one minor change to the init method due to FPC complaining about signed assignment when there wasn't a problem in the first place .

Lets get this working for all of our sakes

[savage]

I can't compile your code in Delphi and I hate pointer arithmetic with a passion, but I wanted to ask why you changed all the integer declarations to Longword?

[dmantione]

Why use the classes unit in procedural code?

[jdarling]

Looking at longwords they are 4 bytes wide and unsigned. The way that the original source used the int's was as a unsigned value so I thought long was appropriate. I'll give normal ints a try .

The classes thing is just me being lazy and not cleaning up lazarus' default template

[Setharian]

try this, I've updated the unit and refactored it....unable to test it because I do not have Lazarus installed and Delphi does not have that TRGB32Bitmap class....http://filebeam.com/aac2781e878589afdd56a03a380d92b7
it *should* work now, the pointer arithmetic was translated incorrectly....

[JSoftware]

I also tried to convert it. I didn't inline it however and use nested procedures for all the pixel things and a bit other naughty things like operator overloading for pointer types...

It compiles in both fpc and delphi though. I didn't bother testing it but here it is if you want it
http://www.graesdal.dk/opengl/laks/hq2x.pas

[dmantione]

Why not:

[pascal]
{$ifdef FPC}
type Pbyte=^byte;
{$else}
ppbyte = ^byte;

pbyte = record
value: ppbyte;
class operator Implicit(x: pbyte): ppbyte;
class operator Add(a: pbyte; x: int): pbyte;
class operator Subtract(a: pbyte; x: int): pbyte;
end;
{$endif}
[/pascal]
... so you don't need the ugly pointer arithmetic emulation on FPC's side?

[JSoftware]

Well I didn't think that long. I primarily ported it for Delphi and then added fpc emulation afterwards

[Sly]

In case your lazy, my conversion of the pointers looks as follows:
C Source:

*((int*)pc) = (c1*3+c2) >> 2;

Pascal:[pascal]Longword(pc{$IFDEF DeReferenceOutPointers}^{$ENDIF}) := (c1*3+c2) shr 2;[/pascal]

The literal conversion of that C code would be
[pascal](PInteger(pc))^ := (c1 * 3 + c2) shr 2;[/pascal]
Note the dereference operator outside the parentheses, so it is dereferencing the typecasted pointer.

[Setharian]

Why not:

[pascal]
{$ifdef FPC}
type Pbyte=^byte;
{$else}
ppbyte = ^byte;

pbyte = record
value: ppbyte;
class operator Implicit(x: pbyte): ppbyte;
class operator Add(a: pbyte; x: int): pbyte;
class operator Subtract(a: pbyte; x: int): pbyte;
end;
{$endif}
[/pascal]
... so you don't need the ugly pointer arithmetic emulation on FPC's side?

why redeclaring PByte type anyways....Delphi allows direct pointer arithmetic only with PChars (not sure why though), so I changed it to a PChar which should work also under FPC because it allows pointer arithmetic on all pointer types (?)...

EDIT:
the function is not thread-safe because it has YUV1 and YUV2 variables declared as global even if they are local to the function....modified that (now it is threadsafe) and included $G- directive to speed up global memory access under Delphi....the link in my previous post has been updated....no pass this time....