So whatever happened to the whole PGDCE thing?

[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...

[AthenaOfDelphi]

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...

Performance wise, it's not going to be great using TCanvas and TBitmap etc. And as for learning OpenGL, if you're just starting out, it can be a bit daunting.

When I first joined this site there were quite a few nice little frameworks that worked out of the box and allowed people to make games easily. Many of these are not developed anymore and as a consequence there is a lack of some basic functionality that allows people to create games with decent graphical performance.

So whilst I fundamentally agree, writing games is the ultimate goal, for those that have a great idea in terms of gameplay but lack some of the finer technical skills to make it work when it comes to the graphics etc. what can they do? Some people may simply never be able to develop the skills required to build even the basics because it's beyond them, but give them a tool chain that facilitates their ideas and hey presto, they may be able to make a game. There are enough skilled people on this site to be able to do this, I'd like to see a well documented engine focusing on say 2D for now, created and maintained by the community for the community so that those people who simply want to make games without having to focus on the technical aspects of OpenGL etc. can do so.

[laggyluk]

When I first joined this site there were quite a few nice little frameworks that worked out of the box and allowed people to make games easily. Many of these are not developed anymore and as a consequence there is a lack of some basic functionality that allows people to create games with decent graphical performance.

So whilst I fundamentally agree, writing games is the ultimate goal, for those that have a great idea in terms of gameplay but lack some of the finer technical skills to make it work when it comes to the graphics etc. what can they do?

Pick up any other existing engine? There's no reason to stick with pascal if someone wants to make a game, on the contrary. And if someone wants to make a pascal engine he should first make couple of games in other engines to see how it's done anyways.

For example people arguing over using VK key codes in previous posts might discover that in proper engine it's necessary to define input actions and map them to keys instead of using key codes directly.

[Carver413]

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 Also, your redefinition of all the keyboard codes is both utterly pointless and incredibly inconvenient. Just use the "VKs"!
written by those people into our own projects!

I like Being able to use a single case statement for keyboard or mouse input but I don't believe that is possible with VKs

case vMessage.Input.CombineButton of
  CK_CONTROL or CK_MOUSE1          :begin
                                    end;
  CK_CONTROL or CK_Alt or CK_MOUSE1:begin
                                    end;
  CK_MOUSE2                        :begin
                                     end;
end;

case vMessage.Input.CombineKey of
  CK_Alt or CK_S   :begin
                    end;
  CK_Shift or CK_S :begin
                    end;
end;

also BGRABitmap is one of those reinvented wheels that you so greatly discourage. and kind of a bulky solution just to get a texture into video memory

[Akira13]

I like Being able to use a single case statement for keyboard or mouse input but I don't believe that is possible with VKs

case vMessage.Input.CombineButton of
  CK_CONTROL or CK_MOUSE1          :begin
                                    end;
  CK_CONTROL or CK_Alt or CK_MOUSE1:begin
                                    end;
  CK_MOUSE2                        :begin
                                     end;
end;

case vMessage.Input.CombineKey of
  CK_Alt or CK_S   :begin
                    end;
  CK_Shift or CK_S :begin
                    end;
end;

also BGRABitmap is one of those reinvented wheels that you so greatly discourage. and kind of a bulky solution just to get a texture into video memory

You can definitely use VKs with case statements. Not sure why you would think otherwise.

procedure TForm1.FormKeyUp(Sender: TObject; var Key: Word; Shift: TShiftState);
begin
  case Key of
    VK_UP:
      ShowMessage('Up!');
    VK_DOWN:
      ShowMessage('Down!');
    VK_LEFT:
      ShowMessage('Left!');
    VK_RIGHT:
      ShowMessage('Right!');
  end;
end;

Also BGRABitmap is not what I would call a "reinvented wheel", nor is it a game engine. It's also written by someone who actually knows what they're doing! I'd much rather use it and be able to handle all major image formats in a single short method than have to write my own thousand-plus line unit with a separate BMP loading routine, PNG loading routine, TGA loading routine, e.t.c.

[Carver413]

You can definitely use VKs with case statements. Not sure why you would think otherwise.

procedure TForm1.FormKeyUp(Sender: TObject; var Key: Word; Shift: TShiftState);begin   case Key of     VK_UP:       ShowMessage('Up!');     VK_DOWN:       ShowMessage('Down!');     VK_LEFT:       ShowMessage('Left!');     VK_RIGHT:       ShowMessage('Right!');   end; end;

Also BGRABitmap is not what I would call a "reinvented wheel", nor is it a game engine. It's also written by someone who actually knows what they're doing! I'd much rather use it and be able to handle all major image formats in a single short method than have to write my own thousand-plus line unit with a separate Bitmap loading routine, PNG loading routine, TGA loading routine, e.t.c.

those are only single key not combo's

[Akira13]

Well, my example is obviously restricted to the capabilities of the VCL/LCL event handling system. I think you may have missed my point though: I wasn't saying you should only use built-in key handling methods, I was just saying you should use the actual keycodes that already exist instead of defining your own. For example, VK_A is defined as $41. If you go and define MYENGINEK_A as $58, you're just making the engine less compatible with everything for no reason.

[JC_]

Please do not take it personally or emotionally as in previous case, but it's little bit out of reality. Form/VK/BGRABitmap.. Minesweeper 2?
BGRA is great stuff when you're making editors for game or such things.

There is no good choice in pure Pascal game library/framework right now, if someone wanted to make a commercial product.
I remember only one ZenGL game which was in Steam Greenlight and thats all.