PDA

View Full Version : Lazarus - Game Developers Edition



WILL
22-01-2007, 09:49 PM
It's been talked about over and over, but it seems that now we're going to see it finally come to light. The idea... Lazarus, the Game Developers Edition.

I was talking with Vincent Snijders on IRC not too long ago and I brought up the PGD Annual.

<__WILL__> PGD Annual is about to start, you as excited as I am? :P
<fpcfan> no :-)

...to be fair, I don't think it was even possible anyhow. ;)

Well after a bit of blabbing, we both came up with an idea for a new distro made specifically with the PGD Annual in mind. Most people that use Laz or even just FPC for game development don't really have a 'full suite' of tools and/or libs specifically for game development.

We hope to end this by making a special edition that will suit not only say GLScene users, but JEDI-SDL, DelphiX, Omega, Asphyre, DirectX, Lua, OpenGL, DirectX9/10, Newton and OpenAL users and so on. You can sort of think of it as the first all-inclusive out of the box edition of Lazarus that we all have been waiting for. :thumbup:

I've created a page on the Lazarus Wiki for the planned list of included features. We'll be pulling participation from as many people as we can to make it happen.


What I'd really like to know though is what do you think would be the best set of standard headers/libraries to use considering max supported platforms (minus the DirectX-based libs) stability, completeness and compatibility...


See the Lazarus Wiki page on the new edition for more information: Lazarus - Game Developers Edition (http://wiki.lazarus.freepascal.org/Lazarus-_Game_Developers_Edition)

Zenophran
23-01-2007, 02:41 AM
That all sounds fantastic. One other suggestion would be to include the Open Dynamics Engine (http://www.ode.org/). There are some Delphi headers here (http://www.hypeskeptic.com/Mattias/DelphiODE/). This would provide an alternative physics engine as an option.

I also think the indy components should be in there initially instead as an addition as, having used them with Delphi in the past, I've found them quite useful.

Cross-compilation from any platform to any platform would be a major benefit I would think.

Just my AUD$0.02, I know it's not worth much :roll:

WILL
23-01-2007, 03:42 AM
That all sounds fantastic. One other suggestion would be to include the Open Dynamics Engine (http://www.ode.org/). There are some Delphi headers here (http://www.hypeskeptic.com/Mattias/DelphiODE/). This would provide an alternative physics engine as an option.

Alright, sounds ok to me. I had though of this one, but was unsure as it seems that support for it has gotten somewhat lax in recent years. If nothing else perhaps it can be included as legacy?

http://www.hypeskeptic.com/Mattias/DelphiODE/


I also think the indy components should be in there initially instead as an addition as, having used them with Delphi in the past, I've found them quite useful.

Yeah, I have to agree, however the problem surrounding Indy is that the Indy guys are still trying to port it to Lazarus themselves. At least this is how I understand it.

(http://www.indyproject.org/Sockets/fpc/index.aspx)

Perhaps with a little bit more help both teams needs can be fulfilled. ;)


Cross-compilation from any platform to any platform would be a major benefit I would think.

I agree. However complications with acquiring needed libraries (legally in some cases) make it unable to provide this part out of the box. At least on Windows. On Linux or even Mac OS X (I think it would be a bit easier) it isn't as so hard to provide a pre-packaged ability to cross-compile for Win32/64, as hard to get libraries are not needed in this case.

This is still a big issue to overcome yet.


Just my AUD$0.02, I know it's not worth much :roll:

I'm Canadian. I know what you mean. :p


Here a question primed for debate, whats the best OpenGL headers to use? (outside of JEDI-SDL's included copy which will be kept and used for JEDI-SDL created projects specifically)

I also am unsure of what OpenAL headers to use. OpenAL.org themselves point to noeska's headers, but I don't know how cross-platform compatible they are and I want to hear what others feel about this before I make it official.

cairnswm
23-01-2007, 04:56 AM
You are welcome to include Fantasy Land as a cross platform compatable project.

Just my RSA R1.00 - to make it about equal to the mighty AU$ and CAN$ few cents!

dmantione
23-01-2007, 07:20 AM
Cross-compilation from any platform to any platform would be a major benefit I would think.

I agree. However complications with acquiring needed libraries (legally in some cases) make it unable to provide this part out of the box. At least on Windows. On Linux or even Mac OS X (I think it would be a bit easier) it isn't as so hard to provide a pre-packaged ability to cross-compile for Win32/64, as hard to get libraries are not needed in this case.

This is still a big issue to overcome yet.


Free Pascal 2.2 will be big step into the direction of transparant cross-compilation because of the internal linker. This means the compiler can create executables for a certain platform independend on what host platform it is running. It is just implemented for COFF platforms at this time, i.e. you can create Win32 executables under Linux, but the rest will surely be coming. As nobody uses 10 platforms, easy cross compilation will be a big step into the direction of multi-platform software.

Vincent
23-01-2007, 12:05 PM
IMHO, the biggest stumbling block for cross compilation is the fact that on *nix the linked to libraries are needed, not the fact that it has to be done with an external linker.

Cross compiling to windows was easy (no need for kernel32.dll during linking) and has become easier because of the internal linker (no need to distribute an external linker).

dmantione
23-01-2007, 01:12 PM
The solution is to make the internal linker not to require the libraries present on the system. I don't think there is any information in the libraries the linker needs to create the executable.

Also, the FPC spirit has always been "remove the libraries". Now that is a quite hard with Lazarus using GTK and most games using SDL, but if the wish is there it can be done: both Pascal widget sets (lptk, MSE) and Pascal game libraries (PTCPas) already exist.

Vincent
23-01-2007, 01:21 PM
[quote="dmantione"]The solution is to make the internal ]

I would love to see that happen, but I thought that was impossible, because the linker needed the binary offsets in *nix and the loader doesn't link by name as it does on windows.

Vincent
23-01-2007, 01:22 PM
Also, the FPC spirit has always been "remove the libraries". Now that is a quite hard with Lazarus using GTK and most games using SDL, but if the wish is there it can be done: both Pascal widget sets (lptk, MSE) and Pascal game libraries (PTCPas) already exist.

I only know MSE well enough to comment, but even that uses external libraries, viz. X.

dmantione
23-01-2007, 01:44 PM
Sure, they do, but I wanted to say about 75% of the obstacle has been taken away.

Vincent
23-01-2007, 01:52 PM
Sure, they do, but I wanted to say about 75% of the obstacle has been taken away.

75% of the obstacle removed is the same as 0 % removed => compilation failed due to linking errors.

IOW, if a solution can be found for the remaining 25%, I see no problem applying the same techniques to the other 75%.

noeska
23-01-2007, 06:05 PM
I also am unsure of what OpenAL headers to use. OpenAL.org themselves point to noeska's headers, but I don't know how cross-platform compatible they are and I want to hear what others feel about this before I make it official.
I did test it in the beginning. After moving an .so file it worked for an basic test. I have not tested it since so i don not know if they still work under linux. Do test them and do update them if you feel like it. If needed i give write access to http://webpm.noeska.net/.

The idea of game developers lazures will compareable with xna studio of microsoft?

Also it would be nice if the gba/nds will be suportable from it.

WILL
27-02-2007, 09:26 PM
Hey Maarten, sorry for the late response.

Lazarus Game Developers Edition will be the first all-in-one, out-of-the-box version of the IDE/compiler suite to support all the major libraries, tools and binaries to do game development under Lazarus.

If you go to the wiki page it lists all the intended features we wish to include. It's quite extensive. We do however need to select the best of all the SDL, DirectX, OpenGL, OpenAL, etc... API libraries to be used and some of that includes testing and making updates/tweeks.

So if people want to help the best thing is to help verify what works with what and what is better than what to help us determine the best possible libraries to include in the new edition.

Unfortunately, XNA is off the list as it would require .NET and FPC is not .NET capable without a major rewrite. For that you'll have to rely on Chrome.


Anyone else interested in this new/exciting edition of Lazarus? :)

jdarling
28-02-2007, 01:13 PM
As we talked about over IM, I'm interested, but I'll believe it when I see it. Very few people have actually made Lazarus cross compile from Windows to Linux, Linux to Windows, or worse yet either of those to Mac. As I said, I'd love to see it, and it would become my IDE of choice (I think), but I'm a devils advocate at heart :twisted:

What I see missing from your package idea are scripting languages. Here are my suggestions: DWS II, Pascal for Delphi (Lazarus Edition), Lua, and if you could get the people at paxScript to give up a free edition for your build that would be great as well.

As for demos, I'd be happy to give up what I have available. Pretty much everything is around SDL, Lua, or generic graphics but its all up for grabs.

Vincent
28-02-2007, 02:58 PM
As we talked about over IM, I'm interested, but I'll believe it when I see it. Very few people have actually made Lazarus cross compile from Windows to Linux, Linux to Windows, or worse yet either of those to Mac. As I said, I'd love to see it, and it would become my IDE of choice (I think), but I'm a devils advocate at heart :twisted:

From linux to windows is easy. Lazarus release for linux consists of several rpms, one of them a crosswin32 rpm.

From windows to linux is more difficult as soon as you link to shared libaries. AFAIK you have to match the exact version of the shared library of the target, because on linux linking is not done on name of the exported function, but on the binary offset. (Please correct me if wrong). So the pain is in the linking, not the compilation per se.

The solution would be to somehow figure out all needed .so's of the target machine and copy them to the host.

Fran
28-02-2007, 06:29 PM
Not sure what part of this doesn't work, this isn't my field of expertise, but it seems like what's needed is an internal loader/linker...

1: Add link_library() as first instruction of fpc for unix
2: Link_Library:
- list of external libraries and function names, with their associated offset in program code
- replace code bytes with found library offsets

I've barely worked with unix yet, but i seem to remember that loaded code is in writable memory pages, so that should (could?) work. Or at worst... i once did a scripting engine that would use fpc to compile the script to a dll, would then load the dll in user memory (not using dll functions) and manually patch the offsets. I'm quite sure something like this could be done...

I don't have much time right now, but in a couple of months i'll likely join the fpc cross compile effort since i'll need it for a major project next year and delphi... just doesn't deliver outside of windows...

ps: not related at all but i wanted to make a new account since this is an old nick i don't really use but when i create an account i get kicked out with no error messages and a non working "new" account... an ideas??

WILL
28-02-2007, 08:29 PM
Cross-compiling obviously is a hot topic with regards to this release. :)

Well keep in mind guys that we're going to be making a Windows port first THEN we'll eventually do a Linux and Mac set of packages afterwards.

Windows because it's the system that'll be easiest and is most popular for game dev in Object Pascal.

The only cross-compiling for the first release will be GBA, NDS and possibly GP2X along with PalmOS and WinCE(PocketPC).


Vincent, what tool is being used to package Lazarus? I think I should get familiar with it. :)

Vincent
28-02-2007, 09:03 PM
Vincent, what tool is being used to package Lazarus? I think I should get familiar with it. :)

Inno setup.

The current installer scripts are in lazarus\tools\install\win (or win32 for 0.9.20).

Vincent

WILL
28-02-2007, 11:30 PM
Excellent. Should make putting together an installer package easy then. :)

I guess I'll see what libraries are Lazarus ready as a start. From there I can tell what work needs to be done to make the rest Lazarus capable.

WILL
21-03-2007, 01:51 PM
So how blasphemous would it be to do a standard install of 0.9.20, install everything (libraries, templates, etc) that I want into an edition release and use InnoSetup to make my installation from that?

Or is that pretty much what happens within the Laz Team anyhow?

Vincent
21-03-2007, 03:45 PM
So how blasphemous would it be to do a standard install of 0.9.20, install everything (libraries, templates, etc) that I want into an edition release and use InnoSetup to make my installation from that?

Or is that pretty much what happens within the Laz Team anyhow?

It more or less what the lazarus team does, but we have 'make bigide' to install everything.

As long as take care of license of the plug-ins :-). See the FAQ about licensing in the lazarus wiki.

WILL
21-03-2007, 04:02 PM
Yes, the IDEIntf part of the IDE is licensed under the LGPL with the same exception, so that shared data structures in this part will not force you to license your plug-in or design-time package under the GPL. We want everyone to be free to choose what plug-in to use, and not limit this choice. Therefore non-GPL compatible plug-ins are allowed. Note that it's not allowed to distribute a precompiled Lazarus with these non-GPL-compatible plugins included statically; however, we do not see this as a severe limitation, since recompiling Lazarus is easy.

Doesn't this sort of defeat the whole concept of an 'all-in-one, out-of-the-box' edition of Lazarus for game programmers?

So if I say, added SDL, OpenAL, FMOD and OpenGL as a few examples, I cannot include the DLL files in the same installation?

Though I think that FMOD *may* be an exception, I think the rest are freely available to distribute...

Vincent
21-03-2007, 04:31 PM
Yes, the IDEIntf part of the IDE is licensed under the LGPL with the same exception, so that shared data structures in this part will not force you to license your plug-in or design-time package under the GPL. We want everyone to be free to choose what plug-in to use, and not limit this choice. Therefore non-GPL compatible plug-ins are allowed. Note that it's not allowed to distribute a precompiled Lazarus with these non-GPL-compatible plugins included statically; however, we do not see this as a severe limitation, since recompiling Lazarus is easy.

Doesn't this sort of defeat the whole concept of an 'all-in-one, out-of-the-box' edition of Lazarus for game programmers?

So if I say, added SDL, OpenAL, FMOD and OpenGL as a few examples, I cannot include the DLL files in the same installation?

Though I think that FMOD *may* be an exception, I think the rest are freely available to distribute...

That depends on their license. If they did not make their License GPL compatible, for example by using LGPL, that may be aproblem, but IANAL.

I don't think this is a problem for SDL for example.

WILL
21-03-2007, 04:33 PM
Giving this more thought....

I believe I know of a way around this apparent limitation in Lazarus' Licensing policy. Simply by supplying a separately downloadable module or package(s) for the Game Developer's Edition we could in fact do it in a friendly way without stepping on licensing toes.

It's perfectly legit to bundle Laz with wrappers and open libraries, right? The problem as I see it, is the closed source (dynamic) library files that have non-GPL licencing attached to them.

jdarling
21-03-2007, 06:11 PM
If you want to get around this in a legal way, you can also have your installer provide an option to call a service (or another application) that downloads the DLL's and places them into proper folders. Of course, it could also download them as a single ZIP and extract them.

This way, the Laz IDE is not being "Shipped" with invalid assets, and instead its an option to download :). I've had to use the loophole for a few applications that required packages that had to be "Downloaded from XYZ". They never say how it has to be downloaded, just that it can't be sent with your application. Thus you provide the option to download them for the user.

Of course, my example isn't directly in effect, but its the same idea.

Vincent
21-03-2007, 06:16 PM
If you want to get around this in a legal way, you can also have your installer provide an option to call a service (or another application) that downloads the DLL's and places them into proper folders. Of course, it could also download them as a single ZIP and extract them.

I think the criterium is not what is in the installation package, but what is linked into the lazarus executable.

jdarling
21-03-2007, 06:46 PM
[quote="Vincent"]I think the criterium is not what is in the installation package, but what is ]

An EXE can link or link to anything. Its only what you distribute with your EXE. Otherwise, you couldn't link the DX8 libraries and require a download as separate and still have your application be GPL/LGPL. And there are plenty of games out there that do this.

The BEST solution if this was a concern would be to dynamically link the libraries instead of statically linking them. That way there are no ties that bind, and you can still provide the down-loader I talked about. Of course, that would require some changes to Lazarus itself to make it fail or recover gracefully instead of just barfing on your desktop :).

Vincent
21-03-2007, 07:00 PM
[quote="Vincent"]I think the criterium is not what is in the installation package, but what is ]

An EXE can link or link to anything. Its only what you distribute with your EXE. Otherwise, you couldn't link the DX8 libraries and require a download as separate and still have your application be GPL/LGPL. And there are plenty of games out there that do this.

IANAL nor a license expert, I think you may only distribute a Lazarus executable linked against the DX8 libraries, if those libraries are part of the operating system.

Suppose there is a typo somewhere in a lazarus menu caption, the GPL ensures me that I can fix this typo in the Lazarus sources and recompile my application with it.

WILL
21-03-2007, 08:52 PM
Well I'll see as to how I package the dynamic libraries that cannot be included with the core installation. I'll make it as hassle free as I can though.

Odd, question... Vista. Will Lazarus work alright on the new version of Windows? (Awaiting a snowball effect. :))

Also... would I be able to modify the Help sub menus without too much flack? I want to eventually link to:

1) a Language Help wiki (finally a full online Object Pascal dialect manual!)

and

2) Lazarus GDE Manual with instructions for several ways to setup Laz/FPC to compile for different gaming platforms, etc...

Vincent
21-03-2007, 09:00 PM
Odd, question... Vista. Will Lazarus work alright on the new version of Windows? (Awaiting a snowball effect. :))
Try yourself, I don't have it. I know there are some bitmap problems with win64.

Also... would I be able to modify the Help sub menus without too much flack?

I guess creating a package is the least obtrusivem I don't know exactly how to do it, but you can add custom menu items, the IDE is extensible.

Of course you can patch the lazarus source too. But this is not so nice solution. :-)

jdarling
22-03-2007, 12:32 AM
My experiences with Win64 and Vista have been interesting, but successful. Vista "WARNS" you about Lazarus quite a bit, but it seems to run/compile. Also, depending on your "security" settings, it asks you if you can run something EVERY SINGLE FRIGGING TIME YOU COMPILE IT! But, it will let you run it :).

Win64 seems to work just fine, though I have to admit that I am running the 32 bit version, I've yet to play with the 64 bit version.

I'm not a lawyer either, but I sure have to deal with enough legal matters that I feel like one :). The thing is, as long as WILL provides the source files that allow you to link the DLL's along with the distro, then the only thing you have to get around is the DLL or library specific license issues. This may require a separate download, and can be performed by an application.

PS: You can't statically link DX application and ship the DLL's with it. You MUST provide the user a separate install, instructions on how to install and where to get it from, or have a separate "process" that retrieves the install/files and places them in the "approved" place. Only Vista ships with DX installed automatically, on all other versions of windows it either didn't ship or is optional.

WILL
22-03-2007, 01:52 AM
Well my concern with Vista is, besides the obvious, mostly to do with DirectX 10.

I don't know if Alexey (Clootie) is planning on doing a translation of a DX10 SDK or not, but on of the deciding factors of choosing to do as such would be a compiler or compilers that supports Vista.

Microsoft has made it very clear that no Vista means no DirectX 10. This sort of has a huge impact on how accessible next gen will be to the open source world. And in our case... Lazarus.


On the issue of libraries though, I'm not too concerned with the DirectX DLLs though. MS takes care of MS so the files will be on just about any Windows box. My thoughts do lie on what I can put out of the box and what will be needed to be made into separate packages. (if I can do so considering the creator/owner's license on it)

All headers and source however will be included as I see no real clause stating that I cannot bundle the source in with the GDE.

Reiter
04-01-2008, 12:07 AM
Anyone else interested in this new/exciting edition of Lazarus?

I am completly interested but wonder if the project still is active?

WILL
04-01-2008, 03:15 AM
Umm... permanent back burner...?

I was pushing the idea, but then I got real busy and to be honest just don't have the kind of time I used to for these community projects. However, I'm all for endorsing those who have the time and motivation to take and continue/complete projects like these.

Check out the wiki page for the Game Developers Edition at FreePascal.org to learn more about what the project's end goal is. :)

Vincent
04-01-2008, 03:59 AM
I am still willing to support, but I won't pull the cart (as we say in Dutch).

arthurprs
04-01-2008, 04:36 AM
The project is alive?

Reiter
04-01-2008, 01:47 PM
Since I am too unexperienced and additionally also don't have enough time I shouldn't even think about "pulling the cart" ;). It's a pity though.

farcodev_
10-10-2008, 02:56 PM
a Lazarus post 0.9.24 (0.9.26 or even a .27) + the new vampyre lib which will comme in some weeks+ Glscene/ODE + agg2pas if you need svg support + Orpheus

that should be ok :)

add Andorra for some fun and you have the package

I actually use 0.9.24 + vampyre, and waiting the 0.26.2 of vampyre to switch to the 0.9.27 build (because post .24 are full unicode now among other things)

Vincent
13-01-2009, 07:59 PM
Any news?

pjpdev
02-04-2009, 08:16 PM
I think this is as dead as Elvis. Last updates on the wiki was in 2007, a bit way back....

gintasdx
24-03-2010, 05:09 PM
There is a alternative to this called CodeTyphon from PilotLogic.com (http://www.pilotlogic.com).
It includes:

GLScene components
TOpenGLControl
17 cross-compilers including FPC for NDS,GBA,Android ARM Linux...
Anti-Grain Geometry (AGG) with examples
DirectX 9.2 with lots of examples
APE (Actionscript Physics Engine) for Pascal with 2D/3D examples
Windows MIDI components package



In GLScene components folder I found Fmod 3.7.4 header,BASS 2.3 header,old OpenAL 1.0 header translation and ODE 0.9 Pascal header. :)

Darkhog
17-08-2014, 08:07 PM
I think that available headers for Lazarus Game Dev edition aren't as important as things like level designers, etc. - Let's face it, libraries/headers can be easily learned, but what is not as easy is getting levels to work. Sure, you can write your own tools, but that takes time & is reinventing the wheel for the most part. What I'd like to see if it'd be made is level designer for 2D games (and in distant future 3D as well) that'd be based on form designer code. You'd have components like Sprite that would take ImageList, etc.

SilverWarior
17-08-2014, 09:20 PM
What I'd like to see if it'd be made is level designer for 2D games (and in distant future 3D as well) that'd be based on form designer code. You'd have components like Sprite that would take ImageList, etc.

If that is what you seek then make sure to check the GL Scene library
http://glscene.sourceforge.net/wikka/HomePage

azrael11
20-08-2014, 08:37 AM
If that is what you seek then make sure to check the GL Scene library
http://glscene.sourceforge.net/wikka/HomePage

There is big problem adding the latest components of glscene in the latest lazarus release...

If someone success to do that please let us know...
I left a project in the middle and i want to catch it again...

Thank you...

Tomi
18-12-2015, 06:27 AM
So would it be suitable for me to create a new thread titled "Dynamic in-game object creation and manipulation" in "Start with basics" section http://www.pascalgamedevelopment.com/forumdisplay.php?20-Start-with-The-Basics and then move your posts there?

Okay! Let's go there with it!:)

SilverWarior
18-12-2015, 03:49 PM
Okay! Let's go there with it!:)

I have moved relevant posts to a new thread http://www.pascalgamedevelopment.com/showthread.php?32489-Dynamic-in-game-object-creation-and-manipulation
I also deleted posts regarding our discussion of where to move the off-topic posts.

So feel free to continue your discussion in the new thread.
I will remove this and your last post here after a while as they are also off-topic in this thread.