Go32v2 DOS: Compilation of HW Acceleraded GraphiX Lib

[tol]

Is anybody able to compile the (hardware accelerated) GraphiX Lib vor Go32v2? ( http://downloads.freepascal.org/fpc/contrib/gxfp405.zip ).

It seems to be made for an older FPC version but not available any more.
I finally got parts of it to compile (graphix.pp), by simply commenting out (hopefully not needed parts) parts that won't compile anymore.
But I get stuck now when trying to compile gxdemo.pas

Current Errors:

gximg.pp(1368,31) Error: You cannot reach COSTAB from that code
gximg.pp(1424,31) Error: You cannot reach COSTAB from that code
gximg.pp(5660,18) Error: function header doesn't match the previous declaration "Read(var <Formal type>;LongInt);"
gximg.pp(5771,18) Error: function header doesn't match the previous declaration "Read(var <Formal type>;LongInt);"

If someone somehow manages to create/obtain the compiled units, or tell me how to fix this error, that would be a great help to me.

[cdbc]

Hi
At least I can tell you that these

gximg.pp(5660,18) Error: function header doesn't match the previous declaration "Read(var <Formal type>;LongInt);"
gximg.pp(5771,18) Error: function header doesn't match the previous declaration "Read(var <Formal type>;LongInt);"

errors are to do with the function declaration in interface section doesn't match the function implementation in the implementation section of the unit. Have you changed one or the other?!? Should be easy to fix 
The rest... I dunno.
Regards Benny

[tol]

I've not changed anything.

This is the implementation within gximg.pp:

Code: Pascal  [Select][+][-]

1. TYPE PMyStream=^TMyStream;
2.      TMyStream=OBJECT(TStream)
3.        f:file;
4.        buffer,curbufferpos:pointer;
5.        buffersize:longint;
6.        bufferstartpos,bufferendpos,bytesinbuffer:longint;
7.        io:longint;
8.        fmode:word;
9.        CONSTRUCTOR Init(name:string;mode,size:word);
10.        DESTRUCTOR Done;virtual;
11.        PROCEDURE read(var buf;count:sw_word);virtual;
12.        PROCEDURE seek(pos:longint);virtual;
13.        FUNCTION getpos:longint;virtual;
14.        FUNCTION getsize:longint;virtual;
15.      END;

According to this the proc read(..) is a new overloaded proc ( besides

Code: Pascal  [Select][+][-]

1. function Read(var Buffer; Count: LongInt) : LongInt; Virtual; Overload

of the TStream base class. Or do I misunderstand this? Maybe I should just change the parameter LongInt to override the base implementation?

[cdbc]

Hi
1)

Maybe I should just change the parameter LongInt to override the base implementation?

Yes you should, the overriding method MUST match exactly the virtual overridden method!!!
2)
This function:

Code: Pascal  [Select][+][-]

1. function Read(var Buffer; Count: LongInt) : LongInt; Virtual; Overload

has got nothing to do with the same-named method of "TMyStream" if anything it would look like this:

Code: Pascal  [Select][+][-]

1. PROCEDURE TMyStream.read(var buf;count:sw_word);
2. begin
3.   ...
4. end;

in the implementation section that is...
It seems to me, that you need to read up on your /old-school/ Object-framework(s) to fet more acquanted with the workings of it/them...
I can recommend the programming guides and manuals from Borland on TP 5.5, they're available allover the place to download for free. I even think 'Embarcadero' has one for download at their site 
If you feel adventurous, you can have a 'looksee' at our own 'Free Vision' framework, you'll find it in the fpc source-tree, under 'fv' ...and there's even a version for unicode.
Regards Benny

[tol]

If I understand correctly, declaring a method with different parameter(s) does not create a new (overloaded) method in FP?
(Because then the error message would be wrong).

( Keine Ahnung ob im Code der Lib die Methode read überschrieben werden soll oder eine neue Methode read eingeführt werden sollte, von daher die Verwirrung )

[marcov]

I think TP was simply more forgiving because it didn't have any form of procedural overloading.

Anyway, the best solution seems to simply correct and move on.

[cdbc]

Hallo
Eine Lösung wäre:

Code: Pascal  [Select][+][-]

1. TYPE PMyStream=^TMyStream;
2.      TMyStream=OBJECT(TStream)
3.        f:file;
4.        buffer,curbufferpos:pointer;
5.        buffersize:longint;
6.        bufferstartpos,bufferendpos,bytesinbuffer:longint;
7.        io:longint;
8.        fmode:word;
9.        CONSTRUCTOR Init(name:string;mode,size:word);
10.        DESTRUCTOR Done;virtual;
11.        PROCEDURE read(var buf;count:sw_word);virtual;
12.        ///// ein neuer Funktionsname /////
13.        function ReadBuffer(var Buffer; Count: LongInt) : LongInt; Virtual;
14.        PROCEDURE seek(pos:longint);virtual;
15.        FUNCTION getpos:longint;virtual;
16.        FUNCTION getsize:longint;virtual;
17.      END;
18.  

Und dann die neue Funktion zu implementieren:

Code: Pascal  [Select][+][-]

1. function TMyStream.ReadBuffer(var Buffer; Count: LongInt) : LongInt;
2. begin
3.   ...
4. end;

HTH
Regards Benny

[tol]

I finally got everything to compile, including the FreeType lib.
(I simply quickly removed the JPEG support).
Unfortunately, everything was for nothing: the program crashes deep in the assembler code when initializing the graphics mode. (Dosbox-X, for all emulated graphics cards).
Unfortunately I'm out here.
Does anyone know of another graphics lib that offers hardware acceleration for the first 2D accelerator cards?
(This offered hardware support for graphics cards in the mid-90s, which would be exactly my historical goal PC). If necessary also in C via DJGPP, adding a Pascal interface is not the world.

[dbannon]

You can still download the source code for FPC 2.6.4 from github, thats the one mentioned on the wiki page. I wonder of someone can tell us when you can download either a compiled version or a boot compiler to build 2.6.4 ?

The link to old compilers on the main FPC website is broken.

Davo

[tol]

I'm afraid I need a 1.X version of Free Pascal.
And even then it doesn't seem clear whether the runtime errors that I get after compiling with 3.2.0 when running in Dosbox-X don't have something to do with dosbox-x's hardware emulation.