16
SFML game jam / Re: Next Jam
« on: March 19, 2015, 01:16:44 am »
I'd say any weekend that's not the next, the easter one and the Ludum dare one :p
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.
17
SFML game jam / Re: 4th SFML Game Jam
« on: February 18, 2015, 10:54:51 am »
Yay, will definitely try to participate on this one, what's the theme?
18
Feature requests / Re: new sf::Sprite Method "void centerOrigin()"
« on: February 12, 2015, 02:19:52 pm »
I see a clean design for that function:
void centerOrigin(object) as a global function, in the user's own code, its what I recommend
--
At most I would consider adding to Transform an anchor system or something similar, where you'd call instead Anchor(TopLeft | BottomRight | Center | Whatever). This way it would cover most common needs and still have a nearly clean API.
void centerOrigin(object) as a global function, in the user's own code, its what I recommend
--
At most I would consider adding to Transform an anchor system or something similar, where you'd call instead Anchor(TopLeft | BottomRight | Center | Whatever). This way it would cover most common needs and still have a nearly clean API.
19
SFML projects / Re: Untitled (Zombienation) - 2D survival zombie shooter
« on: February 10, 2015, 11:36:29 am »
Finally GTA 1: Zombies is being made Cmon, we want to play
Cmon, we want to play 20
SFML projects / Re: Moonman (my sfml game is on kickstarter!)
« on: February 07, 2015, 03:30:44 am »
Hi again Ben (from facebook),
Really hope you succeed your funding, you're really close man! I'm sure you will. Your work deserves only praise, its looking pretty sweet, time to conquer the world! Pity I don't enjoy myself playing this style of game (not Terraria or Starbound or alikes), but if I liked the genre I'd really buy this right away!
Good luck!
Really hope you succeed your funding, you're really close man! I'm sure you will. Your work deserves only praise, its looking pretty sweet, time to conquer the world! Pity I don't enjoy myself playing this style of game (not Terraria or Starbound or alikes), but if I liked the genre I'd really buy this right away!
Good luck!
21
SFML projects / Re: F.I.R.E.D. v0.99.pre-alpha
« on: December 13, 2014, 04:39:59 pm »
I tried your game and it was so great, got me hooked for a while! Great job ! I don't find that much stuff that needs improvement, unless you want to further polish the game.
The experience was really good, complete, intuitive and with a bit more work I'm sure you can make a commercial success out of it.
The experience was really good, complete, intuitive and with a bit more work I'm sure you can make a commercial success out of it.
22
SFML projects / Re: Let There Be Light 2
« on: December 06, 2014, 04:29:26 pm »
I might integrate this into my game tools if it can be done seamlessly (aka able to integrate with my low level abstract renderer, which by itself can be DX/GL/Other).
You're really good at rendering man, you never fail to impress!
You're really good at rendering man, you never fail to impress!
23
SFML projects / Re: Let There Be Light 2
« on: December 05, 2014, 12:59:55 pm »
Again a fantastic job mate !
How hard would it be to convert the rendering code into a new platform, say raw OpenGL or some other wrapper around low level rendering API's?
How hard would it be to convert the rendering code into a new platform, say raw OpenGL or some other wrapper around low level rendering API's?
24
Feature requests / Re: Separating event generation and the window.
« on: November 21, 2014, 02:01:05 pm »
sf::Event and sf::Window are already two separate classes, and they're done right. This is a clear case of wanting to take a good architecture and dismantle into something awful.
Windows generate events, that's just how the graphical environments work in modern OS's. If there was a global event pusher, then how would your application even know the input is meant for it, and not other application doing the same thing? Its even unsafe to use realtime input without proper check for window focus.
Plus, the whole concept of an event based architecture is about passing down the event object down in a hierarchy, in this case, event polling -> game -> states -> objects (or whatever else architecture you have.).
Seems like horrible design to me to let each class re-fetch the event queue manually...
Windows generate events, that's just how the graphical environments work in modern OS's. If there was a global event pusher, then how would your application even know the input is meant for it, and not other application doing the same thing? Its even unsafe to use realtime input without proper check for window focus.
Plus, the whole concept of an event based architecture is about passing down the event object down in a hierarchy, in this case, event polling -> game -> states -> objects (or whatever else architecture you have.).
Seems like horrible design to me to let each class re-fetch the event queue manually...
25
Feature requests / Re: Separating event generation and the window.
« on: November 16, 2014, 03:35:20 pm »
Yeah, use a multimedia library to make a console game makes sense. If you want to make a console game with SFML, then make a custom console with a proper RenderWindow so you can leverage all SFML features.
26
General discussions / Re: Insomniac Game Engine Developer Shares Some Thoughts On Engine Design
« on: October 22, 2014, 01:25:43 am »
I second what MorleyDev says. I proudly mix all kinds of patterns and "architectures" in my code. Whatever fits my current sense of elegance and performance is what finds its way into the source, even if it has to be refactored later.
I really advocate iterating a lot while writing code, especially if its going to be a library API or something similar. I despise implementing everything and cluttering the API from the start as it's almost always wasted time (partially at least) and since API's take time to develop and become mature, its really good to keep iterating and using it during that time. Trial by fire to your own code, allowing it to fail early and achieve a nice tradeoff of all worlds, as exploiter's post mentions.
Other than that, my opinion is: don't try to optimize every single thing for cache efficiency right away. Do what works and use these techniques where its absolutely obvious you should do it. This is because many times you make a nice contigous container and yet the nature of the task doesn't allow you to iterate it sequentially at all. In this case you're not really squeezing lots of extra performance and the design got complicated anyway, uselessly.
I really advocate iterating a lot while writing code, especially if its going to be a library API or something similar. I despise implementing everything and cluttering the API from the start as it's almost always wasted time (partially at least) and since API's take time to develop and become mature, its really good to keep iterating and using it during that time. Trial by fire to your own code, allowing it to fail early and achieve a nice tradeoff of all worlds, as exploiter's post mentions.
Other than that, my opinion is: don't try to optimize every single thing for cache efficiency right away. Do what works and use these techniques where its absolutely obvious you should do it. This is because many times you make a nice contigous container and yet the nature of the task doesn't allow you to iterate it sequentially at all. In this case you're not really squeezing lots of extra performance and the design got complicated anyway, uselessly.
27
SFML projects / Re: The 8-Bit Encounter - My Open-World 2D Game Demo
« on: October 21, 2014, 11:05:37 am »
Annoying song, amazing tech, seems really promising! 
28
General discussions / Re: Insomniac Game Engine Developer Shares Some Thoughts On Engine Design
« on: October 17, 2014, 04:45:13 pm »
The talk is quite interesting, and he does hit a few points right. However, I agree with Nexus. He is too involved with his own environment that he simply can't explain objectively what he means to.
He swallows his own words most of the time and complicates the idea he wants to pass on, but in the end, its all about shifting our code towards efficient cache use, as well as writing code that is favorable to memory access patterns on modern machines.
From what I can see, there are two main things he advocates:
1) Whenever possible, put your data in sequential chunks for faster processing, as pulling/pushing data from memory is one of the most expensive things you can do in realtime applications; Even when this implies sacrificing something else, its worth it because cache efficiency is the most powerful optimization you can do.
2) Be careful with how you access your data, to avoid for example, load-hit-store hangs; So, be careful how we read and write to our variables etc.
I just think he is too extreme about it and became a fanboy of himself, as this kind of design is not antagonistic to other design patterns or OOP.
--
In the end, if you are developing a game, you should just think what entities you have and how they relate to each other. Then apply these principles where it makes sense to.
Let me try to give a nice example. Imagine you are making a nice shmup with potentially hundreds or thousands of bullets in the screen at once; let's take the bullets as a prime example for data oriented design. They will all be moving every frame, usually very fast, so we know we will have a lot of bullets, and they all have movement in common. We know allocation is an expensive operation, especially if its happening every frame hundreds of times, so we automatically know we need a pool for optimal usage; we preallocate a ton of bullets using a std::vector<Bullet> (for example) and can almost assume we will never need another allocation for bullets.
Now, we know that every frame we can just iterate a cache efficient structure to update the bullet transforms with an efficient calculation. This is pretty much the most efficient way to go about bullet processing. But, the key here is that laying our data in such arrays of structures is NOT antagonistic to having our GameObjects and typical OOP hierarchies.
One of the most beautiful ways to go about using both approaches together (in my opinion) is to use "deferred data" in our classes. This means essentially that our classes still can access the data exactly like the old days, completely internally, but the data is not allocated there anymore, but rather in an external block of memory. Instead, a pointer or handle is used to access it every time it is needed.
Using the above example, we already solved efficient iteration and behavior updating of our bullets in a good way. Now, let's say each of our bullet-shooting GameObjects wants to render bullets in different ways, there is no need to pollute the Bullet class with all this rendering data with various types etc. We simply keep track of the handles to the right bullets in our classes, and use their data to render the bullets however we want to.
To make sure our simple integer handles stay valid, depending on the nature of our pool container etc, we can use "roster" systems, an additional array of indices that remaps our handles to the actual indices of the real pool. Since many pools like to have "alive" instances together for even quicker iteration, this means handles would break often, but not with our roster system, which would ensure valid handles. There are many ways to go about this, but I do believe this is the core of what data oriented design is. Sorry for the wall of text.
He swallows his own words most of the time and complicates the idea he wants to pass on, but in the end, its all about shifting our code towards efficient cache use, as well as writing code that is favorable to memory access patterns on modern machines.
From what I can see, there are two main things he advocates:
1) Whenever possible, put your data in sequential chunks for faster processing, as pulling/pushing data from memory is one of the most expensive things you can do in realtime applications; Even when this implies sacrificing something else, its worth it because cache efficiency is the most powerful optimization you can do.
2) Be careful with how you access your data, to avoid for example, load-hit-store hangs; So, be careful how we read and write to our variables etc.
I just think he is too extreme about it and became a fanboy of himself, as this kind of design is not antagonistic to other design patterns or OOP.
--
In the end, if you are developing a game, you should just think what entities you have and how they relate to each other. Then apply these principles where it makes sense to.
Let me try to give a nice example. Imagine you are making a nice shmup with potentially hundreds or thousands of bullets in the screen at once; let's take the bullets as a prime example for data oriented design. They will all be moving every frame, usually very fast, so we know we will have a lot of bullets, and they all have movement in common. We know allocation is an expensive operation, especially if its happening every frame hundreds of times, so we automatically know we need a pool for optimal usage; we preallocate a ton of bullets using a std::vector<Bullet> (for example) and can almost assume we will never need another allocation for bullets.
Now, we know that every frame we can just iterate a cache efficient structure to update the bullet transforms with an efficient calculation. This is pretty much the most efficient way to go about bullet processing. But, the key here is that laying our data in such arrays of structures is NOT antagonistic to having our GameObjects and typical OOP hierarchies.
One of the most beautiful ways to go about using both approaches together (in my opinion) is to use "deferred data" in our classes. This means essentially that our classes still can access the data exactly like the old days, completely internally, but the data is not allocated there anymore, but rather in an external block of memory. Instead, a pointer or handle is used to access it every time it is needed.
Using the above example, we already solved efficient iteration and behavior updating of our bullets in a good way. Now, let's say each of our bullet-shooting GameObjects wants to render bullets in different ways, there is no need to pollute the Bullet class with all this rendering data with various types etc. We simply keep track of the handles to the right bullets in our classes, and use their data to render the bullets however we want to.
To make sure our simple integer handles stay valid, depending on the nature of our pool container etc, we can use "roster" systems, an additional array of indices that remaps our handles to the actual indices of the real pool. Since many pools like to have "alive" instances together for even quicker iteration, this means handles would break often, but not with our roster system, which would ensure valid handles. There are many ways to go about this, but I do believe this is the core of what data oriented design is. Sorry for the wall of text.
29
General discussions / Re: A Visualization of the development of SFML, 2009-2014
« on: July 12, 2014, 02:18:50 pm »
This was fantastic, I am so amazed since I was on it, I ran gource on my engine and on my first game and damn, it was pretty cool to see what I was doing all the time and how things progressed.
Thanks!
since I was on it, I ran gource on my engine and on my first game and damn, it was pretty cool to see what I was doing all the time and how things progressed.Thanks!
30
Graphics / Re: SFML Game Development [Parameter <name> was not found in shader]
« on: June 23, 2014, 01:59:47 pm »
Looking at diagonally, the code seems correct, are you sure the shader is successfully being compiled?