So whatever happened to the whole PGDCE thing?

[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

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

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

[Akira13]

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.

No offense taken, but you've definitely completely missed my point. (Also, when did I take anything "emotionally" or personally? Do you have me confused with someone else?) I use BGRABitmap to load images for use as OpenGL textures/to perform blending/e.t.c. and that's it. I've certainly never used TForms in any game or game engine related project I've ever written. Finally, once again, my point about the VKs was just that you should simply use the existing VK codes instead of defining your own. (Because, as I'm sure you know, they're just numerical constants, and nothing more!) Not sure where you got the idea that I'm suggesting people should write BGRABitmap-enhanced VCL/LCL-based game engines....

[AthenaOfDelphi]

Let's get this thread back on track.

First up, to those suggesting we might like to use other languages and tools.... this is a site about developing games with Pascal. I don't want to use Unity, C#, Game Maker etc. etc. etc. I want to use Pascal, just like many of the other visitors here. Suggesting we're wrong for this (and with some of the comments, intimating we're somehow mentally deficient because of this) is wrong. There are no technical reasons why you can't use Pascal to make games. Performance wise it's right up there, learning it is pretty straight forward and there is a good range of tools.

The project failed because people couldn't agree, it was overly ambitious and ultimately only one person contributed any sizeable amount of code.

There are posts that suggest we should make games not engines, and having read the post by Ian Mallett I generally agree... but what are you going to use to make a game? What's out there that is well documented, under active development and isn't reliant on a single developer?

This is the hole I was hoping we might, as a community, be able to fill.

[laggyluk]

What I was trying to say was that technology is secondary choice in making a game once you decide to do it. You should judge features and pick whichever engine fits your game idea best. Trying to do it in non mainstream tech basing on sentiment is wasting resources.

On other hand If you want to make game engines then pascal is perfectly fine choice.