PDA

View Full Version : Community Engine Announcement Discussions



code_glitch
24-04-2014, 03:49 PM
I think one of the first things to look it is the architecture of how we build this. As in, what units will supply what functionality, what will it be based on (D3D vs OGL and such debates need to happen), how it will be structured (object wise and structure/class wise) and how it will be used (calling conventions and the like). Also, how much freedom do we award the pogrammers using this engine? Should they make a game that uses this engine (like a lot of current oferrings) or compile their code into our engine or run their game inside the engine on a higher level (basically like a script).

That said -


I believe the requirement for delphi compatibility explicity is possibly redundant as FPC and delphi now share the core compiler code (correct me if mistaken) but delphi has its own FCL/LCL-esque equivalents/extensions? As I understand fpc code -> delphi is ok but latest delphi -> FPC = not always ok. Again, please correct me if I'm mistaken.



I know that the Pascal community prefers OpenGL a LOT but from what I see a lot on a day to day basis is that compliance for the masses is 2.1 + Extensions. Meanewhile, DirectX 9 is ubiquitous - even under gallim


Also, if anyone has components/code/engines/libraries they work on in private and wouldnt mind submitting to this engine please drop a note as I think it might be worthwhile to 'cobble' an engine together from code already written once we have a rough idea to the above questions to test it out in some sort of useful environment (A PGD challenge this could be? 'make a game/demo with the engine' perhaps?) and using those results to refine it further.

Just a few thoughts as to what the next step I would take if this were my project based on my experiences. To be completely frank, if we're after a very basic, quick and dirty system I'd be tempted to go with ZenGL on graphics (as its faster than native OpenGL code to write but rather quite fast) and some utilities on the side. Personally I find myself re-using a lot of my config handler, TMX loader and various utility functions a whole lot, so for me that'd already be pretty close to what I work with currently :D

Super Vegeta
25-04-2014, 06:50 AM
DirectX is unfortunately bound to Windows, and I guess that would put some members of the community unable to use the engine. Regarding OpenGL, I think we should use >= 3.1 - the API went a massive change in 3.1 (no more fixed pipeline), and regarding compliance - even my 2005 integrated GPU laptop supports OGL 3.1, so I don't really suppose there's much sense in going back as far as 2.X.

I could probably provide some data structure code - I have some various purpose trees, tries, lists et cetera. Eventually I could also try (well, I'm already working on that) to create some CFI for awful, allowing to use it as in-engine script language, but I think we'd be off better using Lua or something. :P

We will also have to agree on what license to use. I personally suggest zlib or MIT, but I'll be happy to listen to other options (as long as it's not GNU GPL cancer).

User137
28-04-2014, 12:48 AM
I don't see anything wrong with MIT at least, and it is compatible with GNU GPL too.
edit: Might actually prefer zlib.

You can freely use nxPascal source code https://code.google.com/p/nxpascal/source/browse/#svn%2Ftrunk%2Fsrc

code_glitch
28-04-2014, 05:25 PM
Well, if we're offering code up, there the prometheus code over at http://sourceforge.net/projects/prometheuslib/?source=directory though I would HIGHLY recommend waiting for the next update that fixes pretty much everything as the update currently posted has (if I recall) a broken something in every file >.>

The problem being that the version I work on is for the ongoing UAV project, and as a bad coder I end up messing with the whole thing to get it to behave just so... So if anyones going to be interested in it, give me a heads up and I'll pull the latest source from that project, fix it and post :)

MarcoCestari
29-04-2014, 03:23 AM
That's just my two cents. :)


Code Style:

Object Pascal Style Guide (http://edn.embarcadero.com/article/10280)


License:

MIT (It's simple!)


Compilers:

Delphi XE2 Up
FreePascal Trunk 2.7.x (Dotted unit)


I think we shouldn't support old delphi compilers. That way we can focus on the engine and make it simple, without a lot of ifdefs.

Graphics API:

DX 7 Up
OpenGL 1.1 Up
OpenGL ES 1.x Up


It's not hard to support these versions with a good engine structure. Initially we can add only OpenGL and later others.

Sound API:

OpenAL
DirectSound


Engine Structure:

Abstracts

Bitmaps
Canvas
Device
Provider (Graphic API)
SwapChains/Context
Texture


Factory
Types
Utils (Color, Math, etc)


It's something like Asphyre structure, imo, it's the way to go.

dj_sharp
29-04-2014, 07:21 AM
It should support both 2D and 3D graphics, right?

About license: I suggest using Free Pascal license http://wiki.lazarus.freepascal.org/licensing

Also check out this library: "United Open-libraries of Sound. United procedures for open-source audio libraries. For FPC & Delphi.": https://github.com/fredvs/uos/

code_glitch
29-04-2014, 11:51 AM
I mostly agree with Cestari on this but I would do something more like:

fpc 2.6.4 support primarily, 2.7 for extended funtionality (extra bits and pieces)
DX9 and up, OGL 2.1 with extensions and up (we at least want FBOs right?)
As for the enigne structure, I think I'd like to see more suggestions on this as I know there will be most likely be a different proposition from every individual and each will have their own reasons. I'll spare everyone the time to read my own thoughts as I wouldn't consider myself an expert in this domain.

dj_sharp
29-04-2014, 02:58 PM
Take a look at this library: http://code.google.com/p/la-pe/
It is a scripting engine for FPC & Delphi
Supports Pascal-like syntax, but no classes, it seems

code_glitch
29-04-2014, 04:25 PM
Now thats quite pretty... It is lesser GPL code but surely theres some way we could fork that and improve it a bit to better suit our purposes if we wanted to...

pitfiend
29-04-2014, 06:03 PM
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
29-04-2014, 07:41 PM
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
29-04-2014, 07:45 PM
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
29-04-2014, 07:47 PM
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
29-04-2014, 09:04 PM
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
29-04-2014, 09:10 PM
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
29-04-2014, 09:25 PM
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
29-04-2014, 11:07 PM
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
30-04-2014, 12:54 AM
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
30-04-2014, 05:32 AM
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
30-04-2014, 07:44 AM
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
30-04-2014, 09:39 AM
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
30-04-2014, 11:00 AM
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
30-04-2014, 06:01 PM
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
02-05-2014, 11:50 AM
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
02-05-2014, 06:55 PM
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
02-05-2014, 07:55 PM
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
02-05-2014, 11:41 PM
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
03-05-2014, 06:22 AM
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
03-05-2014, 06:23 AM
...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
03-05-2014, 08:05 AM
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.

AthenaOfDelphi
03-05-2014, 08:10 AM
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.

To avoid such issues, the guideline (open for comment by devs) is unit names will be prefixed with PGDCE and type and class names will be prefixed with TCE (obviously the T is standard anyway). They are short, clear and should avoid any such naming confusion. Ordinarily I'm not keen on prefixes, but with a project such as this, to avoid potential issues with user code bases I think they are a necessary evil :-)

User137
03-05-2014, 03:55 PM
I can't see any potential issues, and like they said before, certain types can be referred to as unitname.type. I would say it would hurt the programmer even more and consistently if he had to type TCE everywhere, even something like TCEVector3f?

de_jean_7777
03-05-2014, 04:11 PM
Some often used types, such as vectors, should be without a prefix. In my engine, I used "oxu" as a prefix for units. So something like "ceu" or "uce" can be used instead of pgdce, if anyone finds it too long.

pitfiend
04-05-2014, 03:52 AM
Well, after a quick look on the naming used by JEDI JCL, they use Jcl as identifier, followed by unit name, then class/component name. For JEDI JVCL, they use Jv as identifier, in some cases only initial unit character is used. For class fields the naming is direct, no prefix.
So I agree with our CE prefix and the JEDI guideline for the rest.

pstudio
08-05-2014, 04:24 PM
Well, it seems like an interesting project you guys (and gal(s)) are undertaking here.

I'm sorry if the answer is written somewhere, but exactly how do you envision the final engine?
What sort of features do you dream this engine will have in a stable state?
It's a dead given that it will offer 2D/3D rendering, (basic) input system and other basics for game development, but what about the higher level stuff?
What's the overall arcihtecture of of the engine and a game developed with it? What kind of game object/entity handling will be offered?
Will the engine be more data driven and designer friendly versus focussed on just exposing functionality through an API?
Will there be an editor at some point?
What kind of engines would you like to compare this with? How ambitious of an engine do you want to create?

You probably haven't settled on many of these things yet, but at this point all I know is that you want to make a game engine. What that means to you I don't know.

SilverWarior
08-05-2014, 08:38 PM
As you have guested we still didn't firmly decided on what exactly we will put in the final engine.
So far the general concensus is that we make it object oriented and of modular design.
We don't plan of focusing the game engine to specific game genre in the first place. But modular design should alow you to quickly focus the engine to desired game genre by including or excluding certain features.
Modular design will also alow you to extend the engine with your own code if needed.
We are leaving an option for making specific editor but at first we want to focus on the engine itself.
What is our wish for final product? We want this game engine is to be able to compare with other comercial game engines out there like Unity.
But my personal wish is that we make this engine even better than Unity ;)

Anywhay we are currently in making of a basic design document for the engine.
Naturally as soon as more firm decisions are made we will notify the comunity about this since this is a comunity based project after all.