Which linux compiler?

[M109uk]

Hi all,
I have now got mandriva on my other system, and i want to make some of my games on linux as well as windows, now im using SDL.

Im not sure which compiler to use, i have some forms and standard controls and im using file streams (although im thinking about using 'File' instead), OpenAL, OpenGL (SDLs version), Does any one have any suggestions on which compiler i should use?
I thought about Kylix and Free Pascal with Lazarus, but im not sure what units i can use in Delphi and Free Pascal :?

[{MSX}]

Hi all,
I have now got mandriva on my other system, and i want to make some of my games on linux as well as windows, now im using SDL.

Im not sure which compiler to use, i have some forms and standard controls and im using file streams (although im thinking about using 'File' instead), OpenAL, OpenGL (SDLs version), Does any one have any suggestions on which compiler i should use?
I thought about Kylix and Free Pascal with Lazarus, but im not sure what units i can use in Delphi and Free Pascal :?

Hi! actually i suggest you to forget about kylix and go with freepascal.
Streams are ported and works correctly (as well as the whole Classes unit), instead forms and buttons are way more problematic. You could try to use Lazarus but don't expect too much.
Bye!

[M109uk]

Hi {MSX}



Hi! actually i suggest you to forget about kylix and go with freepascal.

I had i try with Kylix earlier, i had a few problems running any of the compiled examples, well urm they wouldnt run :?
So its now gone :)

Whats the differences between the VCL classes between Delphi and Lazarus? What kind of problems would i have with the two?

Thanks

[savage]

Maybe a better question would be, What are you using the VCL for?

The VCL and LCL ( FreePascal' version ) are not very compatible.

If you are using VCL for GUI, there is a set of GUI classes and a Delphi like form editor for JEDI-SDL that you could possibly use.

[M109uk]

Hi savage,

At tht moment i am using VCL for the development tools, i could probably use the Jedi-SDL controls for this, i didnt really think of that :oops:

Il give it a go :)

Are there any plans to make the VCL and lazarus any more compatible?

Thanks

[savage]

Are there any plans to make the VCL and lazarus any more compatible?

Not that I am aware of, but then I am not part of the FPC dev team.

[WILL]

Well the way I see it...

You can use JEDI-SDL with either Delphi, Kylix, GNU Pascal, Lazarus or FPC.

Lazarus needs FPC. GNU Pascal Compiler needs the GNU C Compiler.

Now there are working examples for JEDI-SDL for FPC and Delphi(I think maybe Kylix too). But none that I know of for any of the others.

Personally I think that your best bet is to learn FPC first and foremost. Mainly because Lazarus is built on top of FPC and if you understand FPC you automatically understand Lazarus in the way of the code you write.

There may be benifits to start using Lazarus before FPC stand-alone, and vice versa, but you should at least take a wee bit of time to evaluate that for yourself before jumpping in there.

GNU Pascal is great I'm sure. as fully compatable as GCC, but you're not really compiling Pascal code you're compiling C code written up like Pascal code. And any optimizations you make will not nessisarily reflect good Pascal code practices.

Chrome may be an option if you wanted to make .NET or Mono(I think this is the Linux version of .NET?) games. It comes in 2 flavours. Command line compiler that works with Mono and as a plug-in compiler for Microsoft Visual Studios(obviously not Linux).

As for the rest, unless you want to target PIC Microprocessors or the Palm, they won't be of much use to you.

[Almindor]

It also depends on what you want to write with it.
OOP is for example available only in Delphi/Kylix/FPC.
Gnu pascal has some OOP IIRC but it's limited at best.
I don't know Chrome so I can't say anything about it.

I'd get Lazarus/FPC combo and work with that. You can use Lazarus as
Just Another Text Editor with nice features and code pure FPC with no LCL.
I use it that way for my game and the editor features of laz are GREAT
(For example, ctrl+shift+up/down = jump to declaration/implementation)

Then if you need VCL capability you can start using LCL or design form.
Ofcourse lazarus is still beta so some things don't work yet as they should
but it's not that bad as it sounds. Most common controls are almost 100% ok.

[savage]

As for the rest, unless you want to target PIC Microprocessors or the Palm, they won't be of much use to you.

Just for everyone's infor, FPC also has some PalmOS bindings, but by the look of it, they were 1.x compatible and have not been updated for yonks.

[M109uk]

Thanks for all the advice :D

At the moment im just targeting Windows and Linux, im not sure about any others at the moment.
Im not really intrested in .Net, i doubt il ever want to use it, i personally dont see the point of it :)

Iv finally got FPC and lazarus installed (after a few problems :() i had a quick look at it, but at the moment im writting my games using Delphi.
Im no longer going to use any VCL and just use either the JEDI-SDL Controls or update my own GUI.

There are a few things im unsure about:
Im using several functions and types from SysUtils and Classes, can FPC/lazarus use these units or do i need to copy the functions to a seperate unit?

How would i get lazarus to compile my Delphi project? Do i need to create a new lazarus project and import the units in to it?

[savage]

FPC contains both SysUtils and Classes, so you shouldn't have any problems there.

To compile your project you just need to type...
fpc -Sd -B <project name>.dpr

on the command line and if should build.

-Sd puts FPC into Delphi compatible mode and -B is to do a Build All.


I hope this helps.

[Bart]

I suggest to use FreePascal. I'm using FPC in combination with SDL, OpenGL and OpenAL myself and I'm very happy with it.

[cairnswm]

Im not really intrested in .Net, i doubt il ever want to use it, i personally dont see the point of it

My feeling is .NET is the natural progression from pascal units. Instead of just encapsulating the functionality you need in a unit which gets compiled into your program it now resides outside the program.

@Bart -what wrappers are you using for OpenAL?

[WILL]

If you want to know a quick way to see if you actaully NEED a unit (becasue Delphi starts you off with a standard set, and adds them automatically if you use and VCL drag and drop components, even if you remove them after the unit will stay in your source) try this.

Just comment out each unit starting with the more obvious ones. Don't nuke it just yet incase you actaully do need it (maybe at least for now?). As you go through each one you'll get errors after removing them ONE BY ONE! Just go through all the errors each at a time and decide if you can substitute the code so it will compile on the other compiler.

I have done this tons of times with my own game projects while changing graphics libraries from DelphiX to UnDelphiX to XCESS to JEDI-SDL. I also tried to make the code Kylix compatable with some, but limited success. Next I plan on moving the cade-bade from Delphi/Kylix to FreePascal. And I'll be damned if I move anymore from that. :lol:

So that is one way. The idea is to prep it for moving THEN once you open it, be able to go a peice at a time to get it working under the new compiler(moving to any major library is about the same situation). JUST GET IT COMPILED FIRST. Then you can start to make each part work in order of your preferance. Moving code form one base to another really sucks becasue so many changes are involved, but it's possible and can be done with less confustion or mistakes by organizing your whole process into steps. The rest is just keyboard work. ;)

[M109uk]

To compile your project you just need to type...
fpc -Sd -B <project name>.dpr

Is there a way to include directories when fpc compiles, e.g.
F:\Xngine - Contains my projects source
F:\Xngine\Formats - Contains file format headers
F:\Xngine\Headers - Contains any extra headers that i will need (e.g. OpenAL, Newton, etc)

Im using the unit Graphics too for the TBitmap class, fpc cant find this unit so should i just create a new unit with the class in it? or is there a different unit that has it?

With my game im currently using the indy components, i saw that Kylix has these components too, is there a FPC set of classes?



If you want to know a quick way to see if you actaully NEED a unit (becasue Delphi starts you off with a standard set, and adds them automatically if you use and VCL drag and drop components, even if you remove them after the unit will stay in your source) try this.

Thanks WILL, found out i had 4 units i didnt need :roll:



My feeling is .NET is the natural progression from pascal units. Instead of just encapsulating the functionality you need in a unit which gets compiled into your program it now resides outside the program.

But wont you be restricting yourself to what windows wants to do with the controls?
I mean with some controls you can override the drawing events and make it look and do what you want it to do?!

Wont it take longer for all the properties, methods and events to be refreshed with all the calls to .Net?


I have another dumb question, does any one know the defined Delphi 7 version? (e.g. VER150)?

[WILL]

My feeling is .NET is the natural progression from pascal units. Instead of just encapsulating the functionality you need in a unit which gets compiled into your program it now resides outside the program.

But wont you be restricting yourself to what windows wants to do with the controls?
I mean with some controls you can override the drawing events and make it look and do what you want it to do?!

Wont it take longer for all the properties, methods and events to be refreshed with all the calls to .Net?

Hmm... can someone let me know if this is true here. I think that Mono is supposed to be a Linux-based solution for .NET apps. There is a way I think that the Mono 'engine' or whatever it's called will execute like a .NET server on Windows would, provided that you follow a set of conventions for both .NET apps and Mono compatability.

[cairnswm]

Why would it take longer - its still in computer memory. It's like using a DLL - does it slow down your program accessing all the properties etc in the DLL. Of course is the .NET object is over the network it will be slower (But then so are webservices - about 0.6sec overhead per call on my Delphi to Delphi services).

As far as I know you can still change the display look and feel of the windows controls - you are also able to make your own controls and wrap them in an Assembly (I think its the right term) for rollout. Think components here - .NET is just removing the compoennts from inside your EXE to outside.

I am not a .NET programmer - I have only used it in Delphi 8 for small client apps. Rolling them out was such a hassle I went back to Delphi 7.

One of the other benefits of .NET is the size of the EXEs. Delphi EXEs using many visual controls was around 58kb - the same program in Delphi 7 was over 700kb. This would be really nice if everone had .NET but otherwise it doesn;t help as the EXE and .NET framework are 20MB or something.

[BenBE]

You can move them out, but like in Visual Basic once you get very nice errors, if there's something missing ...

IMHO .NET was the best waste of time mankind could create ...

There are several reason:
1. .NET uses JIT-compiling that is slow in nature
2. .NET takes control and responsibility away from the developer
3. .NET uses GC memory cleanup that does whatever it wants, but not, what the developer needs
4. .NET encapsulates the DX API that is anything else than perfect for system interoperaability and compatibility
5. .NET tries to optimize what men could do much better
6. .NET uses too strict Object Orientation
7. .NET is done by M$
8. .NET is cooked with water only!

Hope that does for now.

Oh, well, to proof this:
1. Have a look at Java
2. You can't use assembly language for optimizations of time-critical operations without loosing compatibility to the framework and markiing your assembly.
3. Have a look at the documentation provided by M$
4. Have a look at the documentation provided by M$
5. General problem with every software optimizer
6. Everything in .NET is an object, even native data storage types like integers
7. There hasn't been any stable system by M$ since DOS (we assume it was stable); why should just .NET break this line?
8. Well, logical result out of Common Sense

Greets,
BenBE.

P.S.: Compare with my signature ...

[cairnswm]

While I agree with some of your points I think there is one thing you forgot.

90% of developers do not work at your level of complexity, garbage collection and optimisation are tow prime examples of where the avergae programmer can benefit from something like .NET. In any industry you get specialists and you get average members. .NET support the Average programmer better than the specialist.

[BenBE]

Well, but what benefits do I have as specialist from a language designed for "average" developers? In the main point only limitations. The few programs that might be running better with .NET are in no way a compensation for the limitations I get.

Also I think you forget about the point that, at least M$ wants to make .NET standard in their next OS versions - i.e. embedding in LH, general must-have on its succeeder. That's just about 5 year ahead!

But I agree with you in one point: Most users and so-called "developers" know their machine as much as the next lotto numbers.

[Lightning]

From what i know a .NET app is half the speed of a win32 native executable, i don't know about MONO but this is reason enough to stay away from it, also many goodies like powerful(real) pointers for all kinds of things and ASM are not available in .NET, "putting all your eggs in one basket is dangerous" that is depending on such a restricted technology as .NET is not wise.
Please correct me if i'm wrong ...

[Paulius]

.NET is JIT(Just in time) compiled so there shouldn?¢_Tt be much of a speed difference, because when it?¢_Ts running it is native code

[cairnswm]

From what i know a .NET app is half the speed of a win32 native executable

From what I know a VCL app is "half" the speed of a native win32 API program - is that a good reason for staying away from the VCL?

I know I do for games but Delphi and .Net is so more than just speed.

[savage]

.NET is indeed JITed, but it is late JITing. By this I mean that it compiles a function/method the first time it is called. Thereafter it will use the JITed version of the function. So the speed hit is always the first time a method/function call is made.

IIRC you can set a flag somewhere which can force all methods/functions to be JITed at startup, thus avoiding the speed hit later on. IHTH.

Btw, it JITs every time the application is started. There is a tool you can use that will create a permanent native exe if that is what you like, but then you might as well be using Delphi/C++ etc.