Which linux compiler?

[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 [size=9px](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)[/size] 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[size=9px](moving to any major library is about the same situation)[/size]. 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.