Thank you for taking your time in order to read the sourcecode! I really appreciate your effort.

I think you are right in EVERYTHING you said. Hopefully it would help in order to improve the tutorial.

Currently I’m working in the next tutorial, and I think I should keep working on it and not to go back to this one. Maybe I’m asking too much, but do you have enough time in order to make the improvements you commented in the sourcecode and to send it to my mail (javierlopezpro [ at ] gmail [ dot ] com).

I will of course credit you and put a link to your blog.

Thank you again!

I also would like to make some comments about the code presented here. Please, take all my comments as positive criticism since is what I intend to do, but is not always easy. So, if something seems to harsh, please excuse me.

I’ll start with a non-code issue: the past of draw is “drew” not “drawed”. I know it because I’ve done this mistake so many times

I see that you put “using namespace” directives in you headers. For me, this is a bad practice since it defeats the purpose of namespaces. Imagine that I have a class called ‘vector’ to descrive math vectors. If now I include your header I’m importing in my local namespace all the std namespace that I have included before your header and probably I will get duplicate name errors. In this case I would use directly std::vector directly.

The std::vector in Resources is used to look up surfaces by id and to traverse, regardless of order, the list of tiles in Listener::CreateBackDropBrushes(). I wonder, why didn’t you use an std::map instead? From my point of view we would get the same (and id linked to a surface) but without the need of a separate structure (SURFACE), faster look up, and easier clean up. Oh, and in C++ there’s no need to use the ‘typedef struct structBackDropSurfaces SURFACE’ trick. Just declare the struct as SURFACE and use it as it.

Probably I am nitpicking here, but I normally use ++mIter instead of mIter++ when using iterators (when using iterators “by hand” instead of using standard algorithms like std::for_each and such.) The reason is because in user defined types (like iterators) it is somewhat better to use pre-increment instead of post-increment for performance reasons (i.e., the post-increment operator needs to create a copy before incrementing in order to return the original value.) My rule of thumb is: if I don’t need to original value use pre-increment. Of course, your mileage may vary.

I would be a little more const-correct in some methods. For example, Node::GetLayer() and Node::GetSurfaceId() don’t modify the Node object, so I would declare them const.

More nitpicking here: please, use initialization list in constructors. An initialization list doesn’t get worse performance but sometimes it gets better performance, since a constructor doesn’t have to create objects just to assign new values later in the constructor’s body.

In Map::CloneNode() I don’t see why you are making all these calls, since they all use information from the original node that we are trying to copy. Wouldn’t be better to declare a copy constuctor in Node that already does this? After all this is a Node’s responsability, isn’t it? Cloning a node, from my point of view, should be: Node *mNewNode = new Node (*pNode);

Is there a reason because OpenFileDialog returns a char * instead of an std::string? Using an std::string is easier (mPath.empty() instead of !strcmp(mPath, “”)) and harder to make mistakes, as you do in Map::SaveMap() and Map::LoadMap(): the last delete of mPath should be delete[] ;-). With std::string I don’t care and the responsability of who to delete the data is clearer (i.e., the string object.)

Maybe this is a design issue, but when loading and saving Nodes I would let the node object to use a TiXmlElement to save itself. That way, If we have different Node types, by using inheritance, we can have a virtual method that does the correct thing for each subtype. I am not sure right now, but I thing this is called the “visitor pattern”. Again, your mileage may vary here too

I prefer the new C++-style castings (static_cast, const_cast, reinterpret_cast, and dynamic_cast) instead of the C-style casts ( (type)var .) They are easier and safer to use (but no to type, I know.)

And I am stopping here

I really appreciate your work, I just wanted to throw in a little disscusion and possible improvements in an already wonderful work.

Thanks for all!

Un tutorial que explica como hace un editor de pantallas en C++ e IndieLib al estilo del que usan juegos como Braid o Aquaria. A diferencia de los usuales motores / editores de tiles, estos juegos usan un sistema en el que el fondo se va creando a part…

Un tutorial que explica como hace un editor de pantallas en C++ y usando IndieLib al estilo del que usan juegos como Braid o Aquaria. A diferencia de los usuales motores / editores de tiles, estos juegos usan un sistema en el que el fondo se va creando…