Community Engine Announcement Discussions

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

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