Rick

For sure. Every way is going to have it's challenges I think. I suppose one could loop through all entities in the main world and find lights and duplicate those in the "weapon" world via code to make it easier.

Below is option 3. It's a bit to read through but at the end of the day it's a shader that Niosop created which gives you the benefits of instancing while still being able to "apply" different textures to your instances. It does have limitations (like everything else in life huh ) but those limitations might not be reached depending on your texture resolution and required variations. Bottom of 2nd page is the actual shader file. http://www.leadwerks..._hl__instancing

You might be able to place the weapon in another world and play around with how you clear the camera between world drawing. This way it'll can always look like it's always on top of everything and shouldn't look like it goes through anything.

http://www.leadwerks.com/werkspace/page/Documentation/le2/_/command-reference/terrain/terrainheight-r414

Now make an editor that is deigned specifically for touchscreen!

I know for terrain slopes I create a plane that has many segments that I paint the texture on and then I loop through each vertex location and get the height of the terrain directly below that x,z and move the vertex y like .001 above the terrain height. Performance is a balance between how many segments the plane has which comes down to how hilly your terrain is to give a nice look. Could probably do the same for models if you can get the y value of the x,z position on a model.

2010

I restarted it 4 times and same result each time

It looks like the camera is pointing down and spinning like crazy for me.

ty much!

Does anyone know of a free program that can extract the image frames from an AVI file?

I notice you are using C++. However with your timer you only take a normal C function which breaks the C++ idea. If you wish to have a flexible way to assign events you could take a look at the event code I posted in the store. http://www.leadwerks...le/367-c-event/ This allows you to bind class methods as callbacks instead of normal C functions which end up breaking OOP. So for example my timer class looks something like: class Timer { // leaving out variables. this is just to get the idea public: Timer(float interval); void Start(); void Stop(); void Update(); Event0 OnTick; }; // usage class Actor { private: Timer* tmrTest; void tmrTestTick() {} public: Actor() { // create a new timer tmrTest = new Timer(2000); // bind the callback of the timer to a method of this class to keep the OO idea // notice how I can even bind to a private method and it still works! this is great so that the tmrTestTick() isn't exposed to the outside world because why would you want it exposed right? tmrTest->OnTick.Bind(this, &Actor::tmrTestTick); } }; When creating a framework these events can really help decouple your classes so they can easily be exchanged/changed without breaking things. For example in your actor class you can define an Event for OnHurt, which the actor will fire when they take damage. Any class can register to receive this event during the creation of the game. Let's say you want a HUD class to know when the player was hurt. You could tightly couple the HUD class and player class together by passing references of each or 1 or the other. You could poll the player class and pass it or it's data to the HUD class every cycle OR by registering to the players OnHurt event at startup, your HUD class could get member methods fired automatically from the player class when it raises it's OnHurt event. No coupling of the classes, and no polling, so the code becomes more flexible and more efficient. Just an idea.

@tj I believe there were still some people that voted for the zombie style game out of the 5 left working on it at the end.

@LECP Team I've said it before and I'll say it again, having some kind of working game with bugs or needed enhancements is better than having no game at all. Learning what it takes to "finish" a game and the vulnerability you can feel by putting it out into the world is an experience in itself that is only received by doing it. Practice makes perfect (even practice finishing and releasing something) and I'm proud of what everyone was able to contribute to the game. Good job guys and let's learn from it and make another go sometime with LE3. Never give up, never be afraid of failure! Michael Jordan missed the game winning shot 26 times. The point is that he took them! You have no chance at being great unless you take them. So let's keep taking them guys and keep learning.

I switched over to a resource manager and access things via an int ID. I hate having to go through a proxy like that to get the actual object since it's just easier if I can use the pointer directly but the crashes are gone so I'll just have to change Thanks Pixel.

I was playing around with that idea just to avoid having to do loops directly for each list of things I make. I like the idea and will probably change to that, but it would seem in the end it's the same thing just a different way of calling the Update method. You store your stuff in a manager class I put it in my Gameplay state class. At the end of the day some class has a list of objects. You can think of my Gameplay class as sort of the same as your Manager class. It's the only class that creates these objects and the only class that deletes them too. The big question is when one object needs to "target" another how do you define that relationship? Then the bigger question is when 4 objects need to "target" the one single object and one of those 4 objects could cause that single object to be "killed" which triggers a deletion (again the Gameplay class is the only class that deletes things), how do you tell the other 3 that their "target" is now invalid? This continues to be an issue for me. Everything I try still leads to some awkward behavior or crashes. My latest try was to give Actors an OnDeleted event. Just before calling delete on an Actor I fire this event. The Projectiles bind to this event of their target Actor when the projectile is created so that they can NULL out their pointer of this Actor as their target pointer. This all stems from you can have 4 wizards all shooting their projectile at the 1 enemy, and one of those projectiles causes the enemy target to die and be deleted before the other projectiles are finished. In my projectiles I have a pivot and each frame I set the pivot location to the target model location. If the target is no longer valid it'll just stop setting the position but still move towards the pivot. Basically moving towards it's target's last known location. What does happen in certain situations is CRASH/BOOM/BANG Would really love some alternative ideas on how to handle this.

You have. You helped me walk through the problem. You need to give yourself more credit Mubmles! About my other problem I think I need another list that has the scope of my Gameplay class and create the pointers to those objects in there so they stay alive.

Because to me the projectile doesn't own the actor, it's just using it for information (it's location so it can move towards it). When it reaches the actor it calls a TakeDamage() but that doesn't always kill the Actor it just gives it dmg. Inside TakeDamage() the actor determines if it's dead or not and sets an alive flag. Then outside in the gameplay class where the actor was originally created is where it checks the alive flag of these actors from a list of actors.

The thing is I have a list of these actors in my Gameplay class (where they get created from originally) and in there it's looping through them each frame calling Update() and Draw() functions on them. If I delete the Projectiles pointer of the actor it'll work for the Projectile class but the Gameplay classes list of these will then have the same issue. Gameplay won't know that projectile delete it. So same issue just on the other side.

Dangit, now I have another issue with this It's a rabbit hole I tell you. Now in my list I store a pointer to a pointer. If I have a function that creates the Actor*, then I add the memory of that point to the list, as soon as the function is done (scope) that Actor* isn't valid anymore. That seems odd to me because without any delete I would think Actor* would still be valid, but I guess that variable is out of scope once the function leaves (but the object is still created and in scope). list<Actor**> lst; void CreateEnemy() { Actor* a = new Actor(); lst.push_back(&a); } int _tmain(int argc, _TCHAR* argv[]) { CreateEnemy(); // doesn't work because the pointer to a pointer now points to nothing Projectile p((lst.front())); } This makes sense since 'a' itself (not it's object) is local to the function. However I need a way to get around this.

Aha, the list needs to store a pointer to a pointer as well for this to work! That may work but you're casting instead of passing the address of the pointer. Not sure what the difference would be between that and doing Projectile p (&a);

Interestingly enough the other element I have in my game is that these actors are stored in a list, and removed from the list when they are deleted via remove_if(). This seems to give different behavior as well. Now it passes the if check with the following below. Guessing the pointer has gone out of scope once it was removed from the list so now the pointer to the pointer is pointing at garbage. class Actor { private: int i; public: Actor() { i = 50; } void Increase() { i++; } }; class Projectile { private: Actor** _actor; public: Projectile(Actor** actor) { _actor = actor; } void Update() { if((*_actor)) (*_actor)->Increase(); } }; bool DeleteActor(Actor* a) { delete a; a = NULL; return true; } int _tmain(int argc, _TCHAR* argv[]) { list<Actor*> lst; Actor* a = new Actor(); lst.push_back(a); Projectile p(&a); lst.remove_if(DeleteActor); //delete a; //a = NULL; p.Update(); return 0; }

Can't get that to work because then Projectile ctor has to be Actor** and if you do that Projectile p(a); fails because it's expecting a pointer to a pointer not just a pointer. If I don't change Projectile ctor then the assignment in the ctor fails because of the same reason: Projectile(Actor* actor) { _actor = actor; } If anything is defined as a pointer to a pointer then it needs to point to the memory location of a pointer right. It can't just point to a pointer. If you're able to get my example to run in how you are saying please post it because it doesn't seem to work the way you are saying it does.

Below is a modified version of what I posted and seems to be what you are suggesting above. I pass 'a' instead of the address of 'a'. However this is not correct. If you run it and step through it you'll see that the if check passes, and it calls the Increase() method and the _actor is pointing to garbage. class Actor { private: int i; public: Actor() { i = 50; } void Increase() { i++; } }; class Projectile { private: Actor* _actor; public: Projectile(Actor* actor) { _actor = actor; } void Update() { if(_actor) _actor->Increase(); } }; int _tmain(int argc, _TCHAR* argv[]) { Actor* a = new Actor(); Projectile p(a); delete a; a = NULL; p.Update(); return 0; }