Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 May 2012
Offline Last Active Apr 17 2014 06:47 PM

#5142146 Statistics Books for Games?

Posted by Irlan on 25 March 2014 - 05:28 PM

Just google "best statistics book" and you'll find one smile.png .

#5142144 Entity Component System questions/tips

Posted by Irlan on 25 March 2014 - 05:25 PM

You have to remember the other systems that will be involved in your game like the AI System etc.
The simple case of Actor/Game Object/Component/ class is just a way to generalize the way you organize a Scene/GameWorld.
The book Game Engine Architeture goes in detail about that and if you've not read I recommend you do cool.png . 

#5132075 OpenGL Lighting Issue

Posted by Irlan on 17 February 2014 - 11:51 AM

If you keep editing your original post without noting the changes (which is bad form), it's a bit difficult to help you. Better to post revised code snippets.

Ok. Edit no more.

#5130620 Win32 API and Petzold - still relevant?

Posted by Irlan on 11 February 2014 - 03:08 PM

It is important but not a priority. It takes time to note that a Win32 loop is very very similar to an Engine. The variables sometimes confuses. Like INT_PTR CALLBACK, MSG, etc. The first time I've looked to this I said: what the hell? But it's like a game. It has a space inside the code to handle and dispatch messages/actions/input a update function to refresh data variables and a paint command to render stuff (just a eg.). 

#5129991 glDrawElements Patches Crashing

Posted by Irlan on 08 February 2014 - 08:21 PM

A little bit off-topic but If you are starting to OpenGL, you can follow the right path and try to not put OpenGL code inside the shape class itself. Create some wrapper class that encapsulates the OpenGL Objects and some Renderer that owns them (manages its life/creates/destroy/consult).

Other advice: load the model from a file. Hardcode nothing that can be loaded from stream.



Irlan Robson

#5129680 Advice on Component Based System

Posted by Irlan on 07 February 2014 - 02:14 PM

What are Actor and RigidBody? Are those components?


This means that there is some outside code that knows specifically about a PhysicsSystem, and more importantly that entities with Actor and RigidBody should be added via PhysicsSystem.PushSync.


Instead, I would think this logic would exist in the PhysicsSystem. e.g. systems in general implement a common interface that has methods for adding/removing entities. When it's called, the PhysicsSystem itself knows that it's interested in entities with Actor and Rigid body, and can then add them to some internal list. That way you don't need outside logic that knows about the PhysicsSystem (other than a single line of code that says, "create a PhysicsSystem and add it to the list of systems") and that it depends on Actor & RigidBody.


1. Yes

2. Was just a simple way of saying...

3. I completely agree with you in that case. Now, following your method, becomes:

class Entity {
template <class T> 
T* GetComponent(const std::string& _id)
std::map<std::string, Component*>::iterator it = component.find(_id);
if (it != component.end()) {
return static_cast<T>(it->second);
} else {
return 0;
class PhysicsSystem {
PushComponent(Entity* _entity)
Actor* actor = _entity->GetComponent<Actor*>("Actor");
RigidBody* rbody = _entity->GetComponent<RigidBody*>("RigidBody");

if (rbody && actor)  {
PhysicsSync sync(actor, body);

#5124230 Tips when learning a Graphics API like OGL and DX11?

Posted by Irlan on 16 January 2014 - 03:54 PM

Start with DX not with OpenGL. Read Frank De Luna's book (DX11).

#5119299 How can I gain a deeper understanding of C/C++?

Posted by Irlan on 26 December 2013 - 09:08 AM

I said the More Effective/Effective C++ books because those are the books that every C++ programmer should read. Like the front cover says: the objective of the book is improve your code design and efficiency as well.

#5119297 Best way for a complete beginner to learn Open GL.

Posted by Irlan on 26 December 2013 - 08:57 AM

IMHO: don't lose your time with fixed-function pipeline (I've lost 6 months studying that) because your lines of codes will grow exponentially, and with shaders, you will learn  interesting stuffs at the same time knowing that you are in the right way of learning OpenGL. Also, never hardcode geometry (use OBJ models or something for the job). cool.png  

#5119243 How can I gain a deeper understanding of C/C++?

Posted by Irlan on 25 December 2013 - 08:16 PM

More effective/Effective C++.

#5119200 Best way for a complete beginner to learn Open GL.

Posted by Irlan on 25 December 2013 - 10:05 AM

Use shaders.

#5119199 C++, Graphics, Game Programming, Where do I start?

Posted by Irlan on 25 December 2013 - 10:02 AM

Mathematics + Implementation
Object Oriented Programming
Effective/More Effective C++
A little about Graphics (to not get lost)
Build a small game using your creativity not your skills and keeping the code simple as possible.
Also choose a library of your taste (SFML, SDL, etc.)

#5118361 How to write fast code without optimizing

Posted by Irlan on 20 December 2013 - 08:41 AM

If you know what you're doing I'll probably say "with your hands".

#5104571 ECS - Renderable, Animation, Physics

Posted by Irlan on 26 October 2013 - 08:29 AM

Well, the purpose of an ECS is to get away from OOP and its intertwined calltrees to have a nice clean structure, where you get a fixed list of systems that do straight iterations through full arrays of components in a fixed order. For example, you first call the physics system which updates all positions and then call the render system which reads all positions.

I dont see how the observer pattern, which is basically spaghetti-code repackaged into OOP, can help you on that, when it generates back-and-forth jumping between single components of different types. For example that would mean every single time the physics system updates one of the position components there would be a render component observing it and the code would just jump there, then back, then on the next component again and so on with the contraption.


I would suggest you read the article series at http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/.



#5103977 Will it be C++ the preferred game dev language in 3 years from now?

Posted by Irlan on 23 October 2013 - 07:51 PM


I'm a fan of C++ but I think that for production Java and OpenGL will lead for compatibility/readability advantages of both.


... Says the absolute dearth of Java / OpenGL games rolleyes.gif besides that, I have to question the sanity of anyone who believes that Java or OpenGL is more compatible or readable than alternatives in practical terms, despite promises of the contrary. The readability of both is perhaps a matter of taste, though.


For the kinds of things that C++ is really good at there really is no viable replacement--maybe D someday, or Rust, but certainly not any kind of Java or C#-like productivity language. The trouble with C++, really, even moreso than C, are the number of potholes you'll encounter on a daily basis. I think this stems mostly from the fact that so many subtleties are afoot that almost no piece of code does precisely what it appears to do, and any piece of code that does perform its purported function precisely probably bears only a passing resemblance--at least, with the way most people write C++. For example, probably any 10-20 line function of C++ that does anything at all non-trivial and which compiles with exceptions enabled probably has 20 or more ways of exiting, often not safely when an exception is thrown.


More idiomatic, best-practices C++ code which relies on proven patterns and facilities like smart pointers, standard containers and standard algorithms is both safer and more productive, but for some reason -- sometimes technical reasons, other times cultural ones -- C++ users are in practice somewhat resistant it seems. Its an additional learning curve that many people percieve as being "outside" the necessities of the language itself -- perhaps because the learning curve of the lange is itself so large. Languages like C# or Java, I think, will always be ahead on the productivity and safety curve, owing first to a shorter legacy, a smaller and more-homogenous language, and the conveniences and safety buffers that their runtime environments supply -- which is a bit like bowling in the bumper lane.



People don't use C++ because it's HARD and takes TIME to learn. By learn I mean, everything. When you are ready to C++ you read a Game Programming Gems book WITHOUT A SINGLE DUBT.