Furbolg

That's not fully true, you could use more then 5 textures by having multiple "splat"-maps or split the terrain in chunks where every chunk (16x16 or 32x32 usually) can have his own 5 textures.

I think you are on the wrong way. 1) I can tell you, a modern c++ compiler will beat your well tailored c code. 2) You will definitly have tasks that require the same programm knowledge/skill (or even more) and now you are asking for a ready to use solution ("make network"). Sorry if im a bit harsh but to me its sounds like the old "im gonna make a mmo"

Besides the MMO(RPG) for Android/iOS thing (mmo in tablet/smartphone ?... really ?), where is the problem to write your own encapsulation of an UDP socket class in c++ ?

Nope, for that case you have namespaces

You should name your #define macros like XXX_INPUT, where XXX stands for your project or your favorite name. That's also a good scenario why c++ programmer use namespace and why "using namespace" shouldn't be in header files (if your #define would be a const int input = 0x01 for example and windows.h (or some other header) using the same variable name, you would have similiar problems). Good to see, you could resolve your problem *cheers*

You got 3 possibilities in my opinion to achieve that : - use pure lua ( just google for "c++ lua call function" e.g.: http://gamedevgeek.com/tutorials/calling-c-functions-from-lua/ ) - use luabind (c++ interface which allows classes (c'tor, d'tor, inheritance etc.) but you still have to do the hard coding) - tolua++ (which creates the code for you, if i understand it right, never used it)

Strange, the winuser.h is an windows header, i don't think it's contained in leadwerks. Did you tried to restart your computer ?

Hi Aggror, it's a standard windows header file. Try to Clean Solution + Rebuild Solution and restart Visual Studio before doing this.

Auto completion is just suggesting what you probably want to write. I dont understand these kind of guys like you, "i just use notepad" ... sure just do it if you want. But when you don't want to see to improvement in workflow with auto completion, high lighting and refactoring ... then sorry but you are living in the 80s (hungarian notation *wave*). Why not use these helpers ? There is enaugh hard stuff to care about in programming, why not use this comfort and concentrate on the important stuff ?

Wow ... really good tutorial aggror You are right about XML its a good format because you can change your level format in a minor way without messing up your loading routine. The problem with XML is its size, i would prefer a binary level format in the final result/game (with stream::writeint etc) because its faster to load. // edit: If you want to see a real bloated XML file, have a look at an animated complex Model in COLLADA Format... its the worst i've ever seen...

How about something basic like saving/loading own game format (level) ?

Hi Aggror, good c++ classes tutorial, thanks for mentioning me Am i famous now ? I just get some suggestions: - when you speak from a class: it's definitely method not function - you can use "using namespace leadwerks;" within cpp files (it's bad style to use it in a header because everyone that includes your header also get this "using namespace xxx;" to work with... within cpp files it doesnt matter) - std::string::c_str() is from the Standard Template Library (STL) not c++ (im a bit of smart *** ) and stands for const string Im a also doing something like this: class foo() { // C'Tor / D'Tor public: foo(); ~foo(); // Methods public: void method(); };

Really ? i was about to preorder for my iphone 3Gs

So we can see your game next week ?

@Rick: Yes, you are right. Overoptimizing is a real bad thing and im normally for readability / usability / maintainability over pure speed (premature optimization is the root of all evil, you know ? ). But in my example the changes are small compared to a full data-oriented design and you can gain some extra speed. Aggror's approach is not wrong as long it works for him and his game. It's always nice to see how other programmers solve a problem. So we can share experience and help eachother, as i said to aggror already, this is the best feature of the leadwerks engine.

Sorry for double post @Rick @Aggror: Look this article: http://gamedev.stackexchange.com/questions/16116/component-entity-system-updates-and-call-orders The first big answer from Joe Wreschnig describes my idea in more detail.

@Rick: Sure but 20-40% more speed (tested with two dimensional loop where i switched the x/y loops) for very low cost (invested time) is worth it, in my opinion (to be fair, it was a large 2d array... 1024 by 1024 i think) @Aggror: No, i mean you could store your components not directly within themselves (your pictures: list<component>components;). And store them in "a large array" so the cpu can walk straight through all components of type move / gui instead of breaking and process the next component and afterwards going to the next component and start with the next move component. Its just an idea/opinion, go for your approach. It will definitly work and looks like clean code. Just wanted to give you the extra speed

Good work aggror, nice to see your approach. Just be aware, your current design will produce a lot of cpu cache misses. To avoid this you could store all your components in a componentcontroller (however you like to call) list/vector for each componenttype (vector<movecomp>, vector<guicomp>...).

Are we talking about a "simple" console ? Then use lua its the best choice for this kind of stuff, dont make your life harder then it needs to be

No problem. Be careful, that your components dont lead you into "The diamond problem" http://en.wikipedia.org/wiki/Multiple_inheritance

Try this one: CComponent #ifndef CCOMPONENT #define CCOMPONENT class GameObject; class CComponent { public: CComponent(); CComponent(GameObject* parent); ~CComponent(); int ID; GameObject* parent; virtual void Init() = 0; virtual void Update() = 0; virtual void Draw() = 0 ; bool enabled; }; #endif GameObject #ifndef GAMEOBJECT #define GAMEOBJECT #include "Leadwerks.h" #include <list> #include "CComponent.h" class GameObject : public CComponent { public: GameObject(); GameObject(GameObject* parent); ~GameObject(); void Init(); void Update(); void Draw(); void RemoveComponent(CComponent* component); void AddComponent(CComponent* component); //holds all the components of that game object list<CComponent*> components; }; #endif You have to add the GameObject Header include in the CComponent C++ File ( #include "gameobject.h" in ccomponent.cpp). Sorry for double post

You done it the wrong way, as rick mentioned you cant use forward declaration (btw. you are using forward declaration and the CComponent header file... this can't work) as a normal class (inherit from it) just as a pointer. Your CGameObject has to include CComponent the normal way but your CComponent has to use forward declaration. Forward declaration works like this: //test.h: class cgameobject; class ccomponent { public: ccomponent(cgameobject* obj); private: cgameobject* gameobject; }; // test.c++ #include "test.h" #include "cgameobject.h" ccomponent::ccomponent(cgameobject* obj) { this->gameobject = obj; }

Forward declaration is the solution but as rick mentioned you can only use pointers. You should avoid circular dependencies whereever possible. // Edit: You should also avoid "using namespace xxx;" in your header files, it can happen that you use another library and as soon as you include your header it will have multiple classes / types with the same name. Use "using namespace xxx;" only in c++ files. (of course your code will work but its bad style and you CAN run into problems later)

I didnt realized it is a class Only in debug mode, try this in release mode and you will wonder what an uninitialized variable can do.

Can you post more / attach a sample project ? Right now, im am wondering: why you declaring "window" two times (in *.h and *.cpp) ? // Edit: (your "public:" irritated me ) Sorry my mistake, Rick is right you have to initialize the static variable and not just declare it because the static variable exists (or can exists) before your class does.