The future of Pascal as language for games

[de_jean_7777]

I'm also guilty of writing my own engine. Though, from what I've noticed, most people write their own engines in other languages. Mostly because, licensing a major one for commercial work is not possible for most developers. and it can be a great learning experience. I hope you won't be discouraged, because in my opinion Pascal is quite suitable for writing games (or any other form of software), just needs a better foundation (an uber-engine or a very nice library like pstudio mentioned). I'm afraid most people not familiar with modern Pascal don't realize that there is nothing that C++ can do, that Pascal can not. What Pascal needs, if we want to make it more popular, is amazing games made with it.

[AirPas]

i think because the general idea that alot of ppl have is dalphi designed for database app and c++ for scientific app , and as you maybe noticed that embarcadero and borland previously Focused on database all times , so the name 'delphi' has been associated with databse domain rather than games

[Cybermonkey]

Here are some humorous thoughts about why Pascal beats C: http://www.pascal-central.com/top10.html (but I think most of you already knew this)
Btw, did you know that for Pascal programmers a C listing consists only of comments?

{
}

[SilverWarior]

and as you maybe noticed that embarcadero and borland previously Focused on database all times , so the name 'delphi' has been associated with databse domain rather than games

Yes I did noticed that and infact I can't understand this policy.
I can understand back in day Borland focused a lot on databases mostly becouse of their BDE (Borland Database Engine). The main advantage of BDE was ability to work with various types of databases raging from old DOS databases like paradox to all the newest and all this with exactly the same framework. If my memory serves me corect BDE was the only tool back in day to provide that and SQL was stil in development.
But today when we talk about databases we always talk about SQL. Why? SQL is similar to what BDE was back in days with the main difference that it is cros-language and cros-platform compatible. Lets face it nowadays rarely anybody works directly with databases all other use SQL for that.
Yes through out the years Borland and now Embarcadero did developed a lot of standalone programs for working and managing the databases but I still doesn't understand why they focus so much about databases.

I do have to admit that some of the focus has ben turned to FireMonkey lately wich should alow developing application for multiple platforms but still the main focus is on databases. You can even see this by the fact that whole FireMonkey platform focuses on data binding.

And as I'm mentioning FireMonkey here I might share some of my expiriences with it.
The core idea for FireMonkey is good but I'm afraid that its implementation isn't. If you intend to use it for game development I recomed you to stay away, atleast for now. Why? FireMonkey's performace is quite bad.
Having quite simple form with several controls on it and you are already down to les than 30 FPS especialy if you use any special effects that FireMonkey provides.
The special effects that FireMonkey provides also aren't much.
The worst part is how controls works. For instace if you have a form with three trackbars wich are used to determine rotation of some 3D object wich is being drawn by FireMonkey you could expect horible performance (verry laggy). Why? Becouse for some reason FireMonkey seems to be queing events fired by your interaction with FireMonkey-s controls. So for instance when you move trackbar left for three units three events would get qued. And FireMonkey will first rotate your object based of first qued event, than on second qued event, and then on third qued event. And if this 3D object of yours is atleast a bit compex could take even a second for FireMonkey to finish all three events.
If you ask me FireMonkey-s controls should check their imputs only after redrawing phase and not que any events just as games graphical engines does.

[AirPas]

I still doesn't understand why they focus so much about databases

because it is the most requested in the market

[FelipeFS]

It is comforting to see that there are people who realize the potential of the Pascal language.
This post renewed my courage to go ahead, not only with my game engine, but with the IDE I'm doing for Free Pascal.

Thank you very much, guys!

[phibermon]

I believe that for commercial game development, pascal will one day be a viable choice in the financial sence but that won't happen until there are sufficiently advanced cross platform capable libraries to choose from. And for pascal to be an attractive option for increasingly larger game budgets, it's often preferable within the industry to license engines and libraries that don't require them to reveal their code assets due to various open source licenses.

Now indie development is a totally different matter, we already see FPC compiled games released for IOS and people are making great headway with Android framework designs that can make efficient use of OpenGL. Win/OSX/Lin are all sorted and to top it all off there's a myriad of other supported operating systems as an added bonus.

The best thing that could happen at this stage is for one engine to rule them all, and in the darkness bind them. An engine that does so much for you, that it's just a pain in the ass to consider anything else. I think projects like GLScene are pretty close to that idea and I've seen some impressive engines here in the forums but it's like they've spent their experience points in different stats, and nobody has reached level 60 yet.
*edit* me included. *shame*

[LP]

I believe that for commercial game development, pascal will one day be a viable choice in the financial sence but that won't happen until there are sufficiently advanced cross platform capable libraries to choose from. [....] The best thing that could happen at this stage is for one engine to rule them all, and in the darkness bind them. An engine that does so much for you, that it's just a pain in the ass to consider anything else. I think projects like GLScene are pretty close to that idea and I've seen some impressive engines here in the forums but it's like they've spent their experience points in different stats, and nobody has reached level 60 yet.

These two statements assume that everyone in the game development industry uses third-party engines for creating games. By this logic, I guess we all should forget programming and software development beyond anything trivial and start using Unity3D from now on... On the other hand, I think you don't need any third-party engines to make even the largest game project, which in this sense is no different than any other software project out there. Therefore, the existence of third-party engines and libraries do benefit the game development community, but they are not essential to consider Delphi and FPC/Lazarus as viable platforms for commercial development.

[LP]

If you ask me FireMonkey-s controls should check their imputs only after redrawing phase and not que any events just as games graphical engines does.

I disagree. Event-based refresh mechanism does not inherently imply low performance or slow performance time. The problem is, as you correctly pointed out, an actual implementation, which in the case of FireMonkey is not good.

[SilverWarior]

I disagree. Event-based refresh mechanism does not inherently imply low performance or slow performance time.

Yes it can if you que events for a single controll, where only last event matters as in my previously stated example especialy if theese events gets fired before you can finish the drawing sequence.