Community Engine Announcement Discussions

[Super Vegeta]

For almost any language, C is the first thing you want to be able to interface with, so if we manage to create a proper interface accessible from C, bindings to other languages can build on that.

As for graphics, I stand by my words regarding OGL >= 3.0. Regarding DX, although I won't mind anyone devoting their time to writing DX rendering, I'm slightly concerned whether such "doubling" of features won't be an unnecessary spending of manhours.

Regarding OS integration - are we planning on using native APIs, or go with some library like SDL or Allegro? The latter may be a bit limiting, but then again, I think writing the OS interaction code from scratch (or copy-pasting and stitching it together) is reinventing the wheel much.

[de_jean_7777]

For almost any language, C is the first thing you want to be able to interface with, so if we manage to create a proper interface accessible from C, bindings to other languages can build on that.

This can be done separately from the pgdce. I personally have no interest in providing C integration.

Regarding OS integration - are we planning on using native APIs, or go with some library like SDL or Allegro? The latter may be a bit limiting, but then again, I think writing the OS interaction code from scratch (or copy-pasting and stitching it together) is reinventing the wheel much.

As with other things, this should be separated as much as possible so that it can be replaced (input, window creation, ...). And yeah, one should not reinvent a wheel, even though I'd prefer as much of the functionality to be done in pascal. SDL2 is preferable since it seems much more active.

[Rodrigo Robles]

Thinking about the real implementation, we should plan something using incremental iteraction, having a big plan but starting with the minimum features to have something usable briefly.

To the great plan we can be megalomaniac and support many kinds of platforms, 3D file formats and so on. Since we advance step by step on implementation.

[dj_sharp]

A suggestion regarding naming:
I know that some developers like to use prefixes for type names, like TOGLVector
But what if I told you that a better approach is to use prefixes only for unit names, but not for type names and other identifiers?

Consider a situation:
Programmer has a unit named Geomerty. Then the game engine also includes a unit named Geometry.
Guess what: there is no way to resolve identifier conflict in this case other than rename unit. So the programmer will be forced to rename his unit from Geomerty to, let's say, MyGeometry.

Now consider another situation:
Programmer has a unit named Geometry. The game engine includes a unit named PGD_Geomerty. There most likely will be no unit name conflict ever.
Even if both units contain equally named type, like TVector, then the programmer will be able to refer both of them like:
Geomerty.TVector and PGD_Geometry.TVector. Such type name conflict is even more unlikely to occur if you consider that some units use Geometry, other units depend on PGD_Geometry, but it is likely that there are no units which depend both on Geomerty and PGD_Geometry unit.

That is why I suggest using prefix for unit names, but not for type names

[AthenaOfDelphi]

The naming conventions will be covered in the developer guidelines, I'm going to be putting in the repos this weekend.

Not everyone will like them, but they have served me very well over the years. Type and class naming conventions will also be defined.

[SilverWarior]

Now consider another situation:
Programmer has a unit named Geometry. The game engine includes a unit named PGD_Geomerty. There most likely will be no unit name conflict ever.
Even if both units contain equally named type, like TVector, then the programmer will be able to refer both of them like:
Geomerty.TVector and PGD_Geometry.TVector. Such type name conflict is even more unlikely to occur if you consider that some units use Geometry, other units depend on PGD_Geometry, but it is likely that there are no units which depend both on Geomerty and PGD_Geometry unit.

That is why I suggest using prefix for unit names, but not for type names

Now you consider this situation:
As you suggest you have two units. One is named Geometry and another is named PGD_Geometry. Both of them contain equaly named type TVector.
In unit geometry TVector is defined like so:

type
  TVector = record
    X1: Integer;
    X2: Integer;
    Y1: Integer;
    Y2: Integer;
  end;

In unit PGD_Geometry TVector is defined like so:

type
  T2DPoint = recod
    X: Integer;
    Y: Integer;
  end;

  TVector = record
    P1: T2DPoint;
    P2: T2DPoint;
  end;

Now you don't have any unit which would use both Geometry and PGD_Geometry at the same time so you don't have any problems with naming conflicts.
But you are using these TVector-s in two different units. One uses Geometry and other uses PGD_Geometry.
Now tell me this when you are writing codein any of these units how do you know which TVector type definition are you using. Yes you are using only one and compiler will always know which one. But how will you know which one are you using in that particular unit.
Sure you could add unit name before type so you use Graphics.TVector or PGD_Graphics.TVector so it would become perfectly clear which definition are you actually using. But that is almost the same as if you are using type prefixes in the first place.

So you see general advice is to use prefixes for both unit names and type/class names.
Prefixes for unit names can be longer like PGD_Comunity_Engine_Graphics.
But prefixes for type/class names sould be short ones. Preferable prefix size for types/classes is 3 characters or less where 5 chareacters long prefixes are considered the largest allowed.

[Carver413]

The naming conventions will be covered in the developer guidelines, I'm going to be putting in the repos this weekend.

Not everyone will like them, but they have served me very well over the years. Type and class naming conventions will also be defined.

so much for everyone having a say in your engine

[dj_sharp]

But how will you know which one are you using in that particular unit.

Ctrl+Click to go to type definition, then click "Back"

Another possibility: hover mouse cursor over type. I'm not sure if there's such feature in Delphi, but in Lazarus if u have variable declaration like

var
  x: TVector;

then when user points mouse cursor over TVector, it displays hint which says in which file this type is declared like:

TVector = record
C:\Dev\MyLibrary\Geometry.pas

I believe that Delphi since 2007 does this too

If u use Notepad, than it it would be indeed more difficult to say which type u use in current unit. Perhaps I would then have to scroll file to top to observe used unit list. But when using IDE there should be no problem

[User137]

...One uses Geometry and other uses PGD_Geometry.
Now tell me this when you are writing codein any of these units how do you know which TVector type definition are you using. Yes you are using only one and compiler will always know which one. But how will you know which one are you using in that particular unit.

In Lazarus you can see it by hovering mouse over the type name, and it will tell what unit it comes from. Or you can ctrl-click the type and it will take to definition. I think same thing applies for Delphi.
Edit: Nice dj, covering same things at the same time

I prefer not to use prefixes for class names, but unit names yes. Not any long ones because we're going to be adding them to uses list, and for convenience sake short is better.

[AthenaOfDelphi]

so much for everyone having a say in your engine

When someone initiates a project such as this there will be times when decisions are made by them or other people involved that not everyone will like. That unfortunately is a fact. An important part of being involved in community projects is the ability to compromise.

The truth of the matter is that as I started writing the guidelines last night I came to the conclusion that the naming conventions I was going to use added complexity that was unnecessary, so they've gone and been replaced by something much simpler and easier to follow. I've compromised what I would like for the benefit of the project. There is one thing I haven't compromised on and that is indentation. There was much discussion about this subject and a poll did not reach a clear majority, and so I elected to use the widely accepted (and most importantly, used) standard of 2 spaces. Not everyone will like that decision, but since it's not just us who may use the project's end results, I think following accepted standards is more important.

That said, the developer guidelines are pretty much a straight copy of the JEDI Delphi Style Guide (which is itself a widely accepted standard), in fact our guidelines don't specify everything, they are meant to be read alongside the JEDI guide, providing only project specific information such as headers and naming conventions. They have been submitted to the project repository and as we're not actually writing code yet, the guys have got an opportunity to comment.

Ultimately I guess what I'm trying to say is that if I truly believe that something needs to happen that will benefit the project and/or the community then I may, as the initiator of the project and the current community manager, make a decision that goes against the views of others involved in the project. Thus far, I've made one of those decisions (indentation) and I've explained my reasons here and to the team.

I should perhaps also point out that there is a private developers forum where a lot of discussion has been taking place, I think overall the standards encapsulate quite nicely the collective view of what we should do.