Community Engine Announcement Discussions

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

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