1
General discussions / Re: [SFML] ECS Architecture Efficiency
« on: August 28, 2016, 06:56:53 pm »
Yah.... I think everyone knows that most basic of knowledge.... play again.....
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
General discussions / Re: [SFML] ECS Architecture Efficiency
« on: August 17, 2016, 07:44:00 pm »
Hhmmm, I see your point there. I didn't really give a good basis for my analysis comparison. Thanks for the resource links. I was actually aware of Thor and Selba, but I'm not interested in using any libraries or APIs, I prefer to build everything myself. Good Practice! 
3
General discussions / [SFML] ECS Architecture Efficiency
« on: August 17, 2016, 01:04:34 am »
Hey all, I have been working on a game engine using an ECS Architecture with SFML. I've made several engine versions and I'm hoping to get some idea of where I should be aiming goal wise as well as some ideas on how to make my code more efficient.
Specifically I'm looking at the total number of game objects that can be rendered to the game window simultaneously before rendering drops below 60 FPS. I'm running my engine using a semi-fixed update cycle with a max of 25 UPS and a semi-fixed render cycle with a max of 60 FPS. I'm also calculating the total maximum potential cycles as a guide, that is the total actual number of times the game-loop loops itself.
My first engine version was able to render as many as 75 objects to the screen simultaneously before dropping below 60 FPS.
My second engine version was able to render as many as 2,300 objects to the screen simultaneously before dropping below 60 FPS.
And my third engine version was able to render as many as 12,000 objects to the screen simultaneously before dropping below 60 FPS.
So if anyone is an experience C++ programer making game engines with SFML any advice and stats of your own engines to compare mine to would be awesome!
Specifically I'm looking at the total number of game objects that can be rendered to the game window simultaneously before rendering drops below 60 FPS. I'm running my engine using a semi-fixed update cycle with a max of 25 UPS and a semi-fixed render cycle with a max of 60 FPS. I'm also calculating the total maximum potential cycles as a guide, that is the total actual number of times the game-loop loops itself.
My first engine version was able to render as many as 75 objects to the screen simultaneously before dropping below 60 FPS.
My second engine version was able to render as many as 2,300 objects to the screen simultaneously before dropping below 60 FPS.
And my third engine version was able to render as many as 12,000 objects to the screen simultaneously before dropping below 60 FPS.
So if anyone is an experience C++ programer making game engines with SFML any advice and stats of your own engines to compare mine to would be awesome!
4
General / Re: Multiple objects from same class?
« on: May 28, 2015, 06:22:25 pm »
For once I agree with eXpl0it3r....
You should probably learn c++ before you try using it. And your question is extremely broad, to the extent that it even extends to the programming model your using... OOP, ECS, etc... Your just going to have to figure out a model and run with it, then you can easily find a way to single out specific segments of your program such that it reduces or even erradicates redundancy....
GL
You should probably learn c++ before you try using it. And your question is extremely broad, to the extent that it even extends to the programming model your using... OOP, ECS, etc... Your just going to have to figure out a model and run with it, then you can easily find a way to single out specific segments of your program such that it reduces or even erradicates redundancy....
GL
5
Network / Re: Optimizing Networking
« on: May 28, 2015, 02:02:25 pm »
@eXpl0it3r wow.... no wonder people say that people on this forum aren't friendly.... you don't need to be a mouth-piece about it, it was a perfectly legitimate question.....
@alext94 As the mouth-piece above stated best bet is to try gamedev.net, there are a ton of articles on networking and mmo development. There really isn't a specific source that has a "best way" or anything. Most information on the subject of MMOs is pretty scattered, and anyone that says their way is the "right" way, is simply flaunting their ego... There are ways that are more "efficient" than others, but it's probably best to just read a lot of articles and try to discern which peices of information are more helpful than others.... I had to.....
Oh and ignore the idiots that say it's impossible or you need a massive team.... they clearly don't have any self-confidence... took me all of 2 days to build a client->server model that could host 100+ people in XNA & C#, and I did it going from 0 knowledge of how networking in C# operated.... If I can do it so can you!!!
@alext94 As the mouth-piece above stated best bet is to try gamedev.net, there are a ton of articles on networking and mmo development. There really isn't a specific source that has a "best way" or anything. Most information on the subject of MMOs is pretty scattered, and anyone that says their way is the "right" way, is simply flaunting their ego... There are ways that are more "efficient" than others, but it's probably best to just read a lot of articles and try to discern which peices of information are more helpful than others.... I had to.....
Oh and ignore the idiots that say it's impossible or you need a massive team.... they clearly don't have any self-confidence... took me all of 2 days to build a client->server model that could host 100+ people in XNA & C#, and I did it going from 0 knowledge of how networking in C# operated.... If I can do it so can you!!!
6
General / Re: Linking Error: LNK4099: PDB
« on: May 25, 2015, 01:39:07 am »
Ah, actually I'm using VS2012.... but I see....
7
General / Linking Error: LNK4099: PDB
« on: May 23, 2015, 08:47:01 pm »
Ok so I've recently started using SFML 2.3, it's working fine but I get 47 warnings all are LNK4099: PDB warnings....
I'm using the Static versions of the libraries, and have set things up as follows:
- I created a copy of the SFML 2.3 folder and it's sub-items in my project folder for easier access and to ensure I don't accidentally move or delete it.
In my project: (Note: I am using the 64-bit version)
- I set to All Modes (x64)
- C/C++ > General > Additional Include Directories = "C:\Users\Josh\Documents\Visual Studio 2012\Projects\TestECSModelBeta\SFML-2.3\include"
- C/C++ > Preprocessor > Preprocessor Definitions = SFML_STATIC
- Linker > General > Additional Library Directories = "C:\Users\Josh\Documents\Visual Studio 2012\Projects\TestECSModelBeta\SFML-2.3\lib"
- Switched to Debug Mode (x64)
- Linker > Input > Additional Dependencies =
- Switched to Release Mode (x64)
- Linker > Input > Additional Dependencies =
I get the following warnings:
It's not been an issue, everything seems to work fine, but it would be nice to get rid of these warnings so I can focus on the important ones.... I'm pretty sure I set something up wrong just not certain what....
Anyone had this issue and know how to fix it?
Thanks!
I'm using the Static versions of the libraries, and have set things up as follows:
- I created a copy of the SFML 2.3 folder and it's sub-items in my project folder for easier access and to ensure I don't accidentally move or delete it.
In my project: (Note: I am using the 64-bit version)
- I set to All Modes (x64)
- C/C++ > General > Additional Include Directories = "C:\Users\Josh\Documents\Visual Studio 2012\Projects\TestECSModelBeta\SFML-2.3\include"
- C/C++ > Preprocessor > Preprocessor Definitions = SFML_STATIC
- Linker > General > Additional Library Directories = "C:\Users\Josh\Documents\Visual Studio 2012\Projects\TestECSModelBeta\SFML-2.3\lib"
- Switched to Debug Mode (x64)
- Linker > Input > Additional Dependencies =
- sfml-graphics-s-d.lib
- freetype.lib
- jpeg.lib
- sfml-window-s-d.lib
- opengl32.lib
- gdi32.lib
- sfml-system-s-d.lib
- winmm.lib
- Switched to Release Mode (x64)
- Linker > Input > Additional Dependencies =
- sfml-graphics-s.lib
- freetype.lib
- jpeg.lib
- sfml-window-s.lib
- opengl32.lib
- gdi32.lib
- sfml-system-s.lib
- winmm.lib
I get the following warnings:
(click to show/hide)
It's not been an issue, everything seems to work fine, but it would be nice to get rid of these warnings so I can focus on the important ones.... I'm pretty sure I set something up wrong just not certain what....
Anyone had this issue and know how to fix it?
Thanks!
8
General discussions / Re: How would you go about making something similar to unity for an SFML game
« on: May 22, 2015, 09:41:15 pm »
Just to clarify....
Unity uses an ECS Model (Entity, Component, System); The 'elements' as you called them are actually the components that your attaching to each entity object. Unity uses it's own custom approach to this model and has an editor built on-top of it to create the overall game engine.
And no I have not seen any engine built with SFML that follows Unity.... You could just make one.... it's not that difficult.......
Unity uses an ECS Model (Entity, Component, System); The 'elements' as you called them are actually the components that your attaching to each entity object. Unity uses it's own custom approach to this model and has an editor built on-top of it to create the overall game engine.
And no I have not seen any engine built with SFML that follows Unity.... You could just make one.... it's not that difficult.......
9
General / Re: Component based entity system
« on: September 09, 2014, 06:01:31 pm »
Not to dig up an old topic, and to avoid putting up a new one, but to respond to this topic.
I have been doing a lot of studying on the ECS Design pattern so I'll give you my 2 1/2 Cents....
First off don't mistake it as EC System like most people... it's not a system it's a design pattern that involves 3 components:
1) Entities - Are unique identifiers that relate to a specific piece of "The World"; this could be a player, monster, NPC, sword, rock, the grass you walk on... etc.
2) Components - Are storage units that contain specific pieces of information about an entity, for example, a PositionComponent would possess an X and Y value as well as possibly a Z value to represent the present location of an entity.
3) Systems - Are the "Muscles", they operate everything and tie everything together by creating actions; Systems are generally separated into 3 groups:
The reasoning behind using an ECS over OOP is actually quite simple. OOP was designed to solve a lot of issues when building complex applications such as video games. However, while it did solve quite a few issues it also created more to take their place. This is common for any design pattern, there is no perfect design for coding, it's simply a question of what issues do you prefer to deal with and which ones you can't stand. ECS focuses around fixing the issues known as the "God Blob" and the "Diamond" complexes, where by most features wind up in a lowly base class that collects virtually everything from everywhere (God Blob), or you wind up with 4 classes 1 being the base class with a ton of junk code, 2 and 3 being sub-classes of 1 to represent specific entities and 4 being a sub class of 2 and 3, because 1, 2 or 3 didn't have everything it needed individually. Thus creating 2 base class-like classes (1 & 4) and 2 sub-class-like classes (2 & 3) (Diamond). Both issues which cause a great deal of overhead, not to mention a massive headache, especially later on.
By it's basic definition ECS does not follow any of the OOP standards, in fact most people will tell you to forget everything OOP. At it's core ECS creates a massive degree of dis-connectivity between the objects, data and systems of a game. This might sound pointless when trying to code a video game but it is actually a good thing. The problems faced by OOP design is that everything is based around inheritance, so if you want to change one thing chances are you have to change many things to create a simple outcome, because everything is connected. But with ECS you simply create a unique id and add the components it needs to make it what you want it to be. In essence you literally build objects. This can be very good especially for MMO design as in the MMO world creating updates and patches must happen very quickly, so having to go back and re-code a lot of information can ruin your MMO's career very quickly.
There is of course a great deal of debate on how an ECS should be designed. In realty there is no right or wrong way it's just what you prefer. If you go by what some people say an ECS design should look like, Entities are integers stored in a list, components are classes that inherit from an interface that designates it as type Component, and systems iterate over the list of entities checking the attached components to see if the entity "fits" then operating on them. The only level of communication is between systems by means of Events. So in essence you have a sh** ton of events firing off throughout every operation... (Note issue #1)
I like to look at it this way, as a very smart person once stated: ECS design is like a Lock and Key, the lock is a System and only a certain key can open it. The key itself is an Entity, and the little groves/prongs coming out of the key are components. When you insert the key into the lock if it doesn't turn then it doesn't belong to that lock. This is a perfect analogy for ECS design, but that doesn't mean it is the perfect design concept.
So what are some drawbacks? Well first off, you have a ton of events firing off everywhere, that alone kinda negates the reduced overhead by not using massive class hierarchies. What else? Well if nothing but systems communicate then how do your components and entities communicate? If systems are listed and ran in order based on the most common ECS design, then what about time-lag? If I move and Move sends a message to Render, how long till render runs in order to update my screen? For that matter what if Render is before my Move system? So I have to wait till the next interval for it to update? What if something updates my components before Render can get to it? Does it glitch? These kinds of questions quickly arise and the entire design breaks down.
But ultimately this is how it works. Personally I prefer a more hybrid design, bringing in certain features of OOP into the ECS design to solve several flaws creating a middle ground for the overhead issue. I'm actually working on a design pattern right now that mostly follows the ECS standards, while hybridizing certain OOP aspects to create a fast and efficient model.
If you have any further questions let me know...
I have been doing a lot of studying on the ECS Design pattern so I'll give you my 2 1/2 Cents....
First off don't mistake it as EC System like most people... it's not a system it's a design pattern that involves 3 components:
1) Entities - Are unique identifiers that relate to a specific piece of "The World"; this could be a player, monster, NPC, sword, rock, the grass you walk on... etc.
2) Components - Are storage units that contain specific pieces of information about an entity, for example, a PositionComponent would possess an X and Y value as well as possibly a Z value to represent the present location of an entity.
3) Systems - Are the "Muscles", they operate everything and tie everything together by creating actions; Systems are generally separated into 3 groups:
- Global System: Basically the game itself
- Managers: Entity, Component, & System Manager which regulates everything
- Sub-Systems: Which operate your basic features, from rendering to crafting to movement.
The reasoning behind using an ECS over OOP is actually quite simple. OOP was designed to solve a lot of issues when building complex applications such as video games. However, while it did solve quite a few issues it also created more to take their place. This is common for any design pattern, there is no perfect design for coding, it's simply a question of what issues do you prefer to deal with and which ones you can't stand. ECS focuses around fixing the issues known as the "God Blob" and the "Diamond" complexes, where by most features wind up in a lowly base class that collects virtually everything from everywhere (God Blob), or you wind up with 4 classes 1 being the base class with a ton of junk code, 2 and 3 being sub-classes of 1 to represent specific entities and 4 being a sub class of 2 and 3, because 1, 2 or 3 didn't have everything it needed individually. Thus creating 2 base class-like classes (1 & 4) and 2 sub-class-like classes (2 & 3) (Diamond). Both issues which cause a great deal of overhead, not to mention a massive headache, especially later on.
By it's basic definition ECS does not follow any of the OOP standards, in fact most people will tell you to forget everything OOP. At it's core ECS creates a massive degree of dis-connectivity between the objects, data and systems of a game. This might sound pointless when trying to code a video game but it is actually a good thing. The problems faced by OOP design is that everything is based around inheritance, so if you want to change one thing chances are you have to change many things to create a simple outcome, because everything is connected. But with ECS you simply create a unique id and add the components it needs to make it what you want it to be. In essence you literally build objects. This can be very good especially for MMO design as in the MMO world creating updates and patches must happen very quickly, so having to go back and re-code a lot of information can ruin your MMO's career very quickly.
There is of course a great deal of debate on how an ECS should be designed. In realty there is no right or wrong way it's just what you prefer. If you go by what some people say an ECS design should look like, Entities are integers stored in a list, components are classes that inherit from an interface that designates it as type Component, and systems iterate over the list of entities checking the attached components to see if the entity "fits" then operating on them. The only level of communication is between systems by means of Events. So in essence you have a sh** ton of events firing off throughout every operation... (Note issue #1)
I like to look at it this way, as a very smart person once stated: ECS design is like a Lock and Key, the lock is a System and only a certain key can open it. The key itself is an Entity, and the little groves/prongs coming out of the key are components. When you insert the key into the lock if it doesn't turn then it doesn't belong to that lock. This is a perfect analogy for ECS design, but that doesn't mean it is the perfect design concept.
So what are some drawbacks? Well first off, you have a ton of events firing off everywhere, that alone kinda negates the reduced overhead by not using massive class hierarchies. What else? Well if nothing but systems communicate then how do your components and entities communicate? If systems are listed and ran in order based on the most common ECS design, then what about time-lag? If I move and Move sends a message to Render, how long till render runs in order to update my screen? For that matter what if Render is before my Move system? So I have to wait till the next interval for it to update? What if something updates my components before Render can get to it? Does it glitch? These kinds of questions quickly arise and the entire design breaks down.
But ultimately this is how it works. Personally I prefer a more hybrid design, bringing in certain features of OOP into the ECS design to solve several flaws creating a middle ground for the overhead issue. I'm actually working on a design pattern right now that mostly follows the ECS standards, while hybridizing certain OOP aspects to create a fast and efficient model.
If you have any further questions let me know...
Pages: [1]