Community Engine Announcement Discussions

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

[code_glitch]

As for other language support, my initial proposition stands. Once could make a generic engine and then just put a smal layer of fixes on top that would make everything procedural which could be exported to a library... Renderer wise, I think a modular system is best indeed and that having opengl and directx support with be a must at some point in the future.

On silver's idea of having modules, I can say that the best thing I ever did was break up Prometheus into modules so I think thats definitely worth considering. Modular also means we can swap them out for other modules (to, say, change the renderer from opengl to directx) without rewriting/changing anything. Though this would require pretty rigorous standards.

[User137]

I would imagine it's easier for everyone if we make things very object oriented. Using standard pascal dynamic arrays, TLists and TObjectLists where needed. Completely procedural would be a nightmare to use, as you would have to memorize every command. I very much rely on autocompletion feature of Lazarus (or Delphi when used it) when coding, less guessing.

Should also get things started soon, and i could recommend 1 website for the designing: http://prezi.com/
We could at realtime and online plan the structure of engine, almost like powerpoint but much more flexible. Should be free to use for all our purposes.

[AthenaOfDelphi]

Just a quick note to say... I'm liking how you guys are thinking about structure... this is what I've been thinking too. I would suggest we support minimum of OpenGL 2.

I also agree that we don't need to worry about supporting other languages too much.

Here in the UK, we have a long weekend coming up (it's a bank holiday on Monday), so I was planning on getting a lot of the basics into the repos and... we do need to think about the design, so maybe we should start off with a chat on IRC and branch out to other websites as needed for diagrams etc.

[Mirage]

In my opinion the most reasonable way to switch renderer is to change a conditional define. As only one renderer implementation can be in use at a time. Others will just waste memory being included in binary.
For a typical API-specific or OS-specific module - there is always API (OS) agnostic part. So this part can be in a base class and specific part in a descendant one.

Concerning other languages - what languages are in question?
Even if we'll use procedural approach this will allow only C/C++. Not Java or C#. As these languages can't use native data structures (not sure about C#).

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

[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