Community Engine Announcement Discussions

[pitfiend]

Nice, but I have an objection. For scripting we must adhere to what's standard, sure we can write scripts in pascal alike, but Lua is predominant. Also was thinking about DX and OpenGL, my propose is to have an independent engine with external renders for graphics, same for audio.

The other thing that's floating in my mind is: are we going to make an embeded engine or a dynamic library? the first is good for pascal developers, the second is good for everyone. Remember, the spirit of this work is to compete pear-to-pear with other engines, so it is mandatory that we don't preset limits to it.

[code_glitch]

I agree with you on the renderer front. As for the second issue, why not make it a pascal project that benefits us primarily? Nothing is stopping us from making a dll or two that exposes the functionality in the engine...

[Andru]

are we going to make an embeded engine or a dynamic library?

If you want to use classes and support something else than Windows(where you can use COM) - forget about this.

[de_jean_7777]

Think we should primarily focus on making it an engine for Pascal developers. Making it embeddable is easiest since it's open source. I think other languages are covered by other solutions quite well.

[User137]

Would it be possible to make rendering code so high level, that we could switch between OpenGL and DirectX with something simple like engine.API:=apiOpenGL; , without any other changes in program code? I'm thinking it would limit us to some rendering arrays or queues which is not a bad thing at all, on the opposite it can greatly speed it up. What we propably don't want to see at all is uses of glBegin..glEnd structures.

[de_jean_7777]

What we propably don't want to see at all is uses of glBegin..glEnd structures.

Some deal of abstraction helps to keep things simple. Like the UI. Also glBegin and glEnd should be avoided, as its possible to use arrays even in OpenGL 1.1 and there is no need for glBegin/glEnd. Personally don't think we should use anything below opengl 2.1. But if separate renderers are made then it'd be possible to make a fixed pipeline (gl1) renderer if anyone needed it.

[SilverWarior]

I would also like to see engine seperated into multiple modules like having seperate rendering providers for different DirectX or OpenGL implementations. Similar I would like to see other parts of the engine to have their own modules (sound module, network module, etc.).
This would in the end make engine maintenace much easier as you would only need to update seperate module and not whole engine.
Also it would alow pepole to go and develop their own modules to replace the default ones that we would provide if needed.

And another thing. While most pepole would probably be quite happy with our higher level implementation I think we should still alow pepole to go and use low level calls if they do desire so to either get more perfomance out of it or acces to some not othervise available functionality.

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