So whatever happened to the whole PGDCE thing?

[turrican]

Hi,

Most of the time Object Pascal compiled code is near fast as C++ code. I develop applications and games with Delphi/FPC (production enviorment) and never have perfomance problems. Every language developer can do good programs and bad programs. The important thing is the developer and the spirit.

I use ZenGL to make games for Android, Windows and Linux, and all the games I developed runs at 60fps at most systems with FULLHD graphics, more FPS than crap Android Java SDK based games. Also I'm trying to port Ñuño's AllegroPAS to Android.

I think the developer is the whole think and programming language is a secondary stuff.

[turrican]

If there was anything usable so it was ZenGL, but today it's useless also, unfortunately.

You are wrong... Today is still usable and stable. But need developers to mantain it! I think we need to focus on this framework because is simple and very strong.

[Akira13]

we decided to drop generics because we planned to bring the engine to developers on older delphi with no generics.

I see. Personally I wouldn't have bothered with trying to support versions that old, but that's just me. I mean, if you can't afford a newer Delphi version, why wouldn't you just use FPC/Lazarus instead? I'd rather quit programming forever than have to use Delphi 7 in this day and age...

You are wrong... Today is still usable and stable. But need developers to mantain it! I think we need to focus on this framework because is simple and very strong.

It's an abandoned project (the developer seems to have just vanished) built ENTIRELY around outdated OpenGL functionality. I don't doubt you get 60 FPS in what are probably relatively simple 2D sprite games, but that's just your CPU brute-forcing the immediate-mode rendering. If you tried to scale ZenGL up to anything relatively complex you would hit a brick wall, trust me.

[turrican]

It's an abandoned project (the developer seems to have just vanished) built ENTIRELY around outdated OpenGL functionality. I don't doubt you get 60 FPS in what are probably relatively simple 2D sprite games, but that's just your CPU brute-forcing the immediate-mode rendering. If you tried to scale ZenGL up to anything relatively complex you would hit a brick wall, trust me.

Yes, simple 2D games are my focus now. No CPU usage at all (2%) with more than 800 sprites at screen. What modern framework do you recommend me to have the same functionity?

[JC_]

Why do you say using something else is nonsense?

If you're making a real 3D game so you need complex and standardized tools with some continuity and with good visual/graphics possibilities (in case that you are not John Carmack).
It's not only about people but also about time and money. There are some good non-commercial 3D engines? Or exists more commercial engines which can compete Unity, UE, CryEngine?
I like games like Legend of Grimrock with own 3D engine which have benefits from optimalization etc., but this is another case. They have team of people making engine directly for the game
not not kind of universal thing. Secondly, I have not seen such game with own 3D engine done in Pascal or in Java etc. => if somebody want 100% performance logically he uses the language that will allow it.

I strongly disagree with you on this. Even when rendering 2D graphics you could greatly benefit from features available in newer API's.

Can you specify which benefits and features? OpenGL have shader support since 2004, which was maybe most important thing for 2D graphics rendering?

Why do you think all Pascal engines/frameworks are dead? Because there weren't enough interest in using them. And why weren't enough interest from people in using them? One of the reasons is people always saying of how much they suck instead of trying to help improving them. Pretty much like you now.

If you need more real reason: 90% of them were not usable just some start-up projects. Working systematically is challenging. In second case, capable author(s) lost interest ( own life, no time, growing complexity, limitations of Pascal language..).
You can use same concept again and it will probably fail again. I do not know how you, but I preferred the solution which survived such natural selection and are universal like SDL or SFML..
This increases the chances to finish game in 1 person lifetime.

Why should the posted code be optimized? So that you can only copy and paste it into your project? This way you won't learn much especially because heavily optimized code is often much harder to understand.
I would recommend that instead of worrying about the posted code being optimized we provide as many possible approaches in solving specific problems. This way we allow people to chose the approach which suites them the most. And that largely depends on their coding style and the rest of the project code.

I do not understand much here, eg. ZenGL code is well optimized and very easy understandable and modifiable. On other hand there is ZenGL Particle editor from different author who did great job but it's pure chaos.
Chaos is not optimized in that sense

[JC_]

It's an abandoned project (the developer seems to have just vanished) built ENTIRELY around outdated OpenGL functionality. I don't doubt you get 60 FPS in what are probably relatively simple 2D sprite games, but that's just your CPU brute-forcing the immediate-mode rendering. If you tried to scale ZenGL up to anything relatively complex you would hit a brick wall, trust me.

With ZenGL you can render >10 000 animated sprites with transformations on 10y old hardware without any problems, it uses sprite batching etc. If there is any bottleneck so it's management or structure of game objects and their dynamics adding and removing - so rather Pascal language performance problems. Also internal ZenGL gameloop have some gaps in performance and it does a lot.

[AthenaOfDelphi]

Edited:-

If you are experiencing performance issues with Pascal, I would suggest that the problem is perhaps yours and not the language. Achieving maximum performance takes skill in the form of a thorough understanding of what's slow, what's fast and what's going on when your code is actually executed. It also requires patience. I spent 12 months optimising the server for my first publicly released game and it showed because performance wise it blew away a lot of the competition and included the capability to scale to handle lots of users. I learned a lot doing it and have since applied that learning to more commercial products for some past employers and I have frequently been able to beat 'the best tools for the job' using Delphi.

Engines are ultimately written for a purpose. I'm in the process of starting a new game development project. Am I going to use an engine that already exists? No, because the ones that are out there won't do what I want in the way I want them to so I'm planning on rolling my own. There is one engine out there that would do what I want, but the chances of me getting my hands on it are nil! If it takes me a couple of years, so be it, if it takes me longer, again so be it. Along the way, I'll learn some neat stuff, have fun and be a better developer at the end of it.

Now my original post was driven by some of the posts before it are simply rubbishing our attempts to try and create something for the community. Part of the problem with a lot of the frameworks that exist currently is that they are written by one person! Life gets in the way and the project dies a death and then people complain. Well here's a radical idea... you want to know why good shit exists for other languages Because lots of people come together to work on them! It's that simple! One of the key problems this site has experienced through out it's life is this unwillingness of the community to get in there and help out and give back. Now if you've volunteered your services in response to some of my rantings on this subject, thank you it is much appreciated... I know I have one article to review that I've just been a bit busy to get around to (and if you think this is a cop out, screw you, I'm busy trying to build a business from the ground up in an area where I have no commercial contacts or pre-existing customers and it's hard going).

Maybe, just maybe, if the community had volunteered to help some of these earlier projects they wouldn't have died a death. Maybe, just maybe.

I keep banging on about this, and I'm going to continue until either everyone that does this leaves or people stop complaining about what exists for this language. The reason it doesn't exist is because people don't give up their time for the benefit of others and those that do are normally called out because 'this is wrong with the engine', 'the documentation sucks', 'there's no examples'. If you're that kind of person, keep your negative comments to yourself about the endeavours of people who have genuinely tried to help this community by trying to bring tools to it that enable the vast majority to do what this site is about... make games.

My original post was a far more personal attack and I'm sorry about that but the last few posts pushed me over the edge.

Pascal is an amazing language and simply lacks the community support that exists for other languages. You want more for the language you (we) need to do more, to create more, to share more.

[Akira13]

I honestly have no idea how we got onto this particular tangent about APIs/ZenGL/C++/e.t.c to begin with, but I certainly agree with what AthenaOfDelphi said above. Also, on a more general note, there are two specific things I've noticed in the sources of various dead Pascal game engines I've browsed through that seem to crop up consistently and are likely part of what contributed to the death of the engines in question, that I thought I'd outline here as "things to be avoided" for any future Pascal game engine devs:

1) They all try to "reinvent the wheel" when there's absolutely no reason for them to do so.

By this, I mean: they have their own "System" or "Core" or some similar name units where they redefine all of their own keyboard codes/mousebutton codes/e.t.c, and re-implement already-existing basic things like string handling functions, file system handling functions, and so on and so forth. 99% of the time these functions are objectively worse/slower/buggier than the Delphi RTL or FPC RTL equivalent. The overall point being: Design your engine around the existing, established "Object Pascal" RTL core shared by Delphi/FPC. I promise you that your handwritten string routines aren't as good as you think they are. Also, your redefinition of all the keyboard codes is both utterly pointless and incredibly inconvenient. Just use the "VKs"!

2) They attempt to implement their own image loading/handling code instead of using established image libraries that actually work.

I cannot count the number of times I've encountered some utterly broken low-level behemoth of an OpenGL texture loading routine, full of pointers getting typecasted to integers and other stupidity that won't even come close to working in anything other than 32-bit applications compiled in ancient products like Delphi 6 or 7. Every time I encounter methods like this I just replace them with the same less-than-twenty-line BGRABitmap-based loading routine I use in every project, and immediately everything works perfectly! The overall point, for this one, being: if you were the sort of developer who wrote useful, high-quality image-related code, you would already know it. The rest of us should just pull the libraries written by those people into our own projects!

[AthenaOfDelphi]

And I absolutely agree with those two points.

[LP]

The problem is that you should Write Games, Not Engines (bold intended). Even if a hobby developer(s) have the appropriate software engineering background with an actual work experience (many of developers of hobby engines don't) to be able to come up with a "not so horrible" architectural design eventually, without any well-thought objectives and reasons behind the developed engine in question, it still won't be very useful even for original developer itself.

So my suggestion would be, just stop making any new engines - not for your own projects, not even as a learning experience. If you want to learn, just make an actual game, maybe a very simple one, you don't need an engine for that: just a TCanvas, TBitmap and its magical Scanline property are the only ones you would need. If you want to learn an API like OpenGL, then just learn it, but without any helpers such as SDL, GLFW or similar, which distract you from learning what's actually happening behind the scenes. Just my two cents...