Lazarus
Announcements => Third party => Topic started by: Core on November 11, 2009, 10:06:28 pm
-
It's been awhile to get really going, but it's going now!
http://c-evo.org/forum/index.html
C-evo is a very well designed & developed game from Steffen Gerlach that has been programmed in Delphi4.
Once this port is complete, we'll be looking to port to Linux & MacOS. If anyone would like to lend a hand or somehow be involved let me know. =)
-
is it open source project?
while porting, try to get rid of as much WinAPI as possible! This would help making Linux/OSX versions
-
Yes, all Open Source... it is Delphi4 at the moment. I want anyone to help on this, especially those who love both FP & Delphi. Once that's ported, will have a different project to port to MacOS & Linux.
-
is there a link for the sources?
-
Close to the above link: http://c-evo.org/files/download.php?cevosrc.cevosrc.zip
-
sorry! i've just found it.
-
Okay, please note that this is the quite the game, old skool and of commercial quality, it's 1st class and i've been playing it for many years.
I could not do justice to just say Steffen has put a tremendous amount of thought and time in to its development and still continues to.
I have only a wish to create a FreePascal port/fork so that it may also become a game on MacOS and many Unixes. This is a good thing to try and do, even the FreePascal/Lazarus community will see good things from this. =)
-
here's the first step. Lazarus compiles the project.
http://havefunsoft.com/fpc/CevoLaz.zip
But if you launch the .exe, it will fail with an exception!
So there're a lot of work to do (and i'm not going to do it)
Some notes about the C-evo project and porting it to Lazarus:
1st) there's guicomponents dir, there additional packages stored for Lazarus. Install the package first, or you'll have problems opening the project
2nd) the project has been adapted by Lazarus "Delphi to Laz" converter, this make the project uncompilable by delphi due to lazarus units used.
3d) the project itself uses TBitmap.Scanline property a lot!!! all these places has been "closed" by {$ifndef fpc}...{$endif}.
The code must be changed to use Lazarus images.
Search for: "todo:" in the sources.
4th) in some places WinAPI functions were used, like:
ScrollDC, OpenClipboard... they must be replaced, but the proper code.
Search for: "todo:" in the sources.
5th) some ShellExecute(.., 'open','http://...') calls were replaced by OpenURL () calls.
Summary: if points 3 and 4 are fixed, then you'll have c-evo for all 3 platforms: Win, OSX and Linux ;)
-
3d) the project itself uses TBitmap.Scanline property a lot!!! all these places has been "closed" by {$ifndef fpc}...{$endif}.
The code must be changed to use Lazarus images.
Search for: "todo:" in the sources.
Maybe a hint about what this means would be helpful. In TRasterImage I see this:
// property ScanLine[Row: Integer]: Pointer; -> Use TLazIntfImage for such things
TLazIntfImage has this:
function GetDataLineStart(y: integer): Pointer;// similar to Delphi TBitmap.ScanLine. Only works with byte aligned lines.
So how to get from one to the other? Use CreateIntfImage? The source comments leave much to the imagination.
Thanks.
-Phil
-
I wonder what was the reason to remove ScanLines from TBitmap?!
Maybe it would be easier, to restore them?
There're lot of delphi projects using ScanLines.
-
Scanline did never exist for lazarus, so it never got removed.
I can try to explain, but I guess its explained several times in this forum and on google.
Just try imagine what a scanline means on windows and how to implement the same thing on a remote Xserver.
-
Hello Marc.
I would be grateful if you could explain in detail the reason why ScanLine doesn't exists in Lazarus.
I've used a lot of ScanLine in Delphi. I am thinking about porting my graphical application and I am a bit confused by this.
Googling didn't help to much. I've found some info here:
http://forum.lazarus.freepascal.org/index.php?topic=3178.0
but I think it confused me even more ;-)
So, what is the fastest(in terms of performance) and best way to properly implement "scanline" functionality.?
-
I would be grateful if you could explain in detail the reason why ScanLine doesn't exists in Lazarus.
ScanLines for TBitmap is a bit more, than just raws of pixels in Windows.
http://wiki.freepascal.org/Developing_with_Graphics
Working with TBitmap
The first thing to remember is that Lazarus is meant to be platform independent, so any methods using Windows API functionality are out of the question. So a method like ScanLine is not supported by Lazarus because it is intended for Device Independant Bitmap and uses functions from the GDI32.dll.
Bear in mind that if you do not specify the height and width of your TBitmap it will have the standard one, which is quite small.
-
That quote does not answer his question.
I also note this:
"Since ScanLines property has been temporary removed from TBitmap class" (my emphasis)
However, while waiting for ScanLine to be restored, the example given on the wiki page should have enough information for modifying Delphi source that uses ScanLine.
Thanks.
-Phil
-
"Since ScanLines property has been temporary removed from TBitmap class" (my emphasis)
Scratch the temporary, it is permanent.
If you know the inner working of a scanline, then you would understand it never will work for a (display) client-server solution like X or for carbon. Both have no notion that a piece of "graphics" memory is changed.
-
"Since ScanLines property has been temporary removed from TBitmap class" (my emphasis)
Scratch the temporary, it is permanent.
If you know the inner working of a scanline, then you would understand it never will work for a (display) client-server solution like X or for carbon. Both have no notion that a piece of "graphics" memory is changed.
I have no idea what is X or carbon... Why this is connected to the TBitmap? TBitmap should be represented in RAM memory and I should easly obtain a pointer to a given row of this memory and be able to mydify it.
That is how it works under Windows, right?
-
I have no idea what is X or carbon...
Each OS has its own mechanism to handle graphics (i.e. GUI subsystem). Windows has WinAPI, Linux uses X, Mac uses Carbon (or Cocoa in OS X). The architecture of these systems are different. WinAPI uses message passing, X uses client-server, don't really know about Carbon (I don't have Mac).
Why this is connected to the TBitmap?
Because TBitmap is part of LCL and LCL is made for cross-platform use, therefore it MUST works on all supported platforms.
That is how it works under Windows, right?
Yes. But as Marc states, X and Carbon have no notion that a piece of "graphics" memory is changed. Perhaps due to the client-server architecture. I believe Marc can explain it better.
-
I'm wondering if the missing ScanLines property from TBitmap class issue has changed in any way since we last discussed this?
Update: I found this info, still looking for solutions to get this great game fully converted.
http://forum.lazarus.freepascal.org/index.php/topic,19807.msg113286/topicseen.html#msg113286
I have attached the latest game sources if someone is willing to see how far they could get this to fully compile using Lazarus/FPC. =)
-
I have no idea what was available back then but today the situation is surmised nicely in the page http://wiki.freepascal.org/Fast_direct_pixel_access (http://wiki.freepascal.org/Fast_direct_pixel_access) although there is no scanline property you can see that there is a scanline like access.
-
There is a Scanline property on TBitmap.
Simple test:
procedure TForm1.FormPaint(Sender: TObject);
type
TPixelInfo = packed record
r, g, b: byte;
end;
var
b: TBitmap;
i, j: integer;
p: ^TPixelInfo;
begin
b:=TBitmap.Create;
b.PixelFormat:=pf24bit;
b.SetSize(ClientWidth, ClientHeight);
for j:=0 to ClientHeight-1 do begin
p:=b.ScanLine[j];
for i:=0 to ClientWidth-1 do begin
p[i].r:=i;
p[i].g:=j;
p[i].b:=255;
end;
end;
canvas.Draw(0, 0, b);
b.Free;
end;
It should make repeated 4 color gradient of red, magenta, yellow and white.
And no, it's not good practise to initialize TBitmap inside onPaint. I just tried how it works, and it's incredibly fast for me at least.
Also i know that i made the record wrong, it should've been b, g, r: byte, because bmp is awkward format...
-
And (as written) your form can't be bigger than 256x256 pixels, or you'll try to access illegal array indices.
But it's nice - thanks for pointing this out.
-
Hmmm... so should this section be updated
http://wiki.lazarus.freepascal.org/Developing_with_Graphics#Direct_pixel_access
then?
(Warning: graphics noob despite dabbling with tiffs)
-
We now have the first successful ports of C-evo in FP/Lazarus!! Author: Chronos http://forum.lazarus.freepascal.org/index.php?action=profile;u=39106 (http://forum.lazarus.freepascal.org/index.php?action=profile;u=39106)
http://c-evo.org/bb/viewtopic.php?f=4&t=174