<?xml version="1.0"?>
<rss version="2.0">
	<channel>
		<title>My First Game</title>
		<link>http://www.allegro.cc/forums/view/596197</link>
		<description>Allegro.cc Forum Thread</description>
		<webMaster>matthew@allegro.cc (Matthew Leverton)</webMaster>
		<lastBuildDate>Thu, 01 May 2008 02:26:08 +0000</lastBuildDate>
	</channel>
	<item>
		<description><![CDATA[<div class="mockup v2"><p>I was wondering if anyone could please help me with my little project here.  This is a Tank War game that I have been writing.  This is my first real full game project.  That is to say that this is the first project I have actually tried to get all the errors removed and the game itself working properly.</p><p>However, I&#39;m still left with two errors that defy my attempts to get rid of them.  The first is a lag issue that start less than a minute after the program runs and the second is a problem with the homing algorithm of my missile.</p><p>I was wondering if someone could please look at the code and see if they can find a solution to one of these problem.  The lagging is the one that worries me that most as I&#39;ve had no success so far at even establishing which part of my code causes it, only that the game runs smoothly for about 30 - 60 seconds and then it starts lagging.</p><p>All the files needed to run the program is included above.  The bitmap files should all be put in a folder called &#39;Graphics&#39;, the wave files all in a folder called &#39;Sound&#39; and the FMP file should be put in a folder called &#39;Maps&#39;.  Other than that the files just need to be included in the project and it should compile smoothly.</p><p>I would like to thank everyone in advance for any help they may give and say that I would appreciate any help that anyone can offer.</p><p>P.S. I would also like other advice, if not too much trouble, if anyone sees something that I have done badly, as in bad coding method, or if there is something that can be done more easily and/or efficiently in another way.  Along with this comments on my variable and function names, if they help identify the purposes of different variables and function and my indentation, if it is too much, not enough etc.  Other than that comments on the amount of in code comments that I should be putting in code like this would also be appreciated.</p><p>General lowdown of the game.  It&#39;s two players on the same screen.  One player plays with WASD and the other plays with the arrow keys.  The player with WASD uses E to fire and Q to change weapon type, while the player with the arrow keys uses Space to fire and Enter to change weapon type.</p><p>Edit - Got rid of all the useless attachments, didn&#39;t realize they stayed there.  The one currently on is the latest version.  In it I&#39;ve fixed the missile homing problem, was just using the wrong variable somewhere in there.  Some advice on how to improve the code would still be appreciated.  I will try to implement what you have suggested this weekend Edgar, if I get time between all the other work I have to do.
</p></div>]]>
		</description>
		<author>no-reply@allegro.cc (Derik Botha)</author>
		<pubDate>Wed, 30 Apr 2008 13:58:18 +0000</pubDate>
	</item>
	<item>
		<description><![CDATA[<div class="mockup v2"><p>
</p><div class="quote_container"><div class="title">Quote:</div><div class="quote"><p>
The first is a lag issue that start less than a minute
</p></div></div><p>

Without having looked at the code, this smells like a memory leak or other failure to properly clean up to me.
</p></div>]]>
		</description>
		<author>no-reply@allegro.cc (X-G)</author>
		<pubDate>Wed, 30 Apr 2008 14:00:48 +0000</pubDate>
	</item>
	<item>
		<description><![CDATA[<div class="mockup v2"><div class="quote_container"><div class="title">Quote:</div><div class="quote"><p>
All the files needed to run the program is included above. The bitmap files should all be put in a folder called &#39;Graphics&#39;, the wave files all in a folder called &#39;Sound&#39; and the FMP file should be put in a folder called &#39;Maps&#39;. Other than that the files just need to be included in the project and it should compile smoothly.
</p></div></div><p>

If you put all the files in their appropriate directories in a TankWar folder that has all the source files and compress everything into a zip file for one single download then I might be tempted to look it over.
</p></div>]]>
		</description>
		<author>no-reply@allegro.cc (Edgar Reynaldo)</author>
		<pubDate>Wed, 30 Apr 2008 14:17:52 +0000</pubDate>
	</item>
	<item>
		<description><![CDATA[<div class="mockup v2"><div class="quote_container"><div class="title">X-G said:</div><div class="quote"><p>
Without having looked at the code, this smells like a memory leak or other failure to properly clean up to me.
</p></div></div><p>

Yeah, thats what I though, and still think, I just can&#39;t seem to find the leak.</p><div class="quote_container"><div class="title">Edgar Reynaldo said:</div><div class="quote"><p>
If you put all the files in their appropriate directories in a TankWar folder that has all the source files and compress everything into a zip file for one single download then I might be tempted to look it over.
</p></div></div><p>

Oops.  Didn&#39;t think to do that.  It&#39;s done now though, all the sound, graphics, map and source files in their right place, I hope.
</p></div>]]>
		</description>
		<author>no-reply@allegro.cc (Derik Botha)</author>
		<pubDate>Wed, 30 Apr 2008 14:29:54 +0000</pubDate>
	</item>
	<item>
		<description><![CDATA[<div class="mockup v2"><p>Just having looked at your <tt>main.cpp</tt>. You&#39;re calling the destructory <tt>PlayerOne-&gt;~Tank();</tt>, <tt>PlayerTwo-&gt;~Tank();</tt> and <tt>PlayingField-&gt;~Map();</tt> manually, while they were created with &quot;normal&quot; <tt>operator new</tt>, and never <tt>delete</tt>d.</p><p>This may cause some serious problems. While it may not have such an effect in those particular cases (as it happens only once a game), it could if you do that with every dynamically created object.</p><p>You should only call the destructor manually in very selected cases (which is very, very, <b>very</b> rare). Once you create an object with <tt>new</tt>, use <tt>delete</tt> to rid of it.
</p></div>]]>
		</description>
		<author>no-reply@allegro.cc (Indeterminatus)</author>
		<pubDate>Wed, 30 Apr 2008 14:46:58 +0000</pubDate>
	</item>
	<item>
		<description><![CDATA[<div class="mockup v2"><p>Thanks Indeterminatus, just changed that.  Still don&#39;t understand why it makes a difference, but that&#39;s not too important now, and I&#39;m sure I could find out with a bit of research.</p><p>EDIT:  Actually I see now how that makes a difference.  I was destroying each of my dynamically created objects in that manner, and that was coincidentally what caused that lag, as far as I can tell.  So THANK YOU SO MUCH for that.
</p></div>]]>
		</description>
		<author>no-reply@allegro.cc (Derik Botha)</author>
		<pubDate>Wed, 30 Apr 2008 14:54:20 +0000</pubDate>
	</item>
	<item>
		<description><![CDATA[<div class="mockup v2"><p>... there&#39;s your answer right there. Calling destructors doesn&#39;t free any allocated memory. That&#39;s what delete is for.
</p></div>]]>
		</description>
		<author>no-reply@allegro.cc (X-G)</author>
		<pubDate>Wed, 30 Apr 2008 14:58:09 +0000</pubDate>
	</item>
	<item>
		<description><![CDATA[<div class="mockup v2"><div class="quote_container"><div class="title">X-G said:</div><div class="quote"><p>
... there&#39;s your answer right there. Calling destructors doesn&#39;t free any allocated memory. That&#39;s what delete is for.
</p></div></div><p>

ok thanks, I know what that means atleast, and how it makes a difference.  Didn&#39;t realize it doesn&#39;t do that, releases the memory that is.  Thanks for the help all three of you.</p><p>Now I would just like some more general advice on how I could improve on the code.  As this is my first project I&#39;m not that good at optimization yet, well I really suck at it really, so any help in that regard would be apprecited.  Other than that there is still the homing for the missiles,  I&#39;ve checked over my logic for that and re-written it a couple of times but can&#39;t seem to make it work.</p><p>A solution doesn&#39;t necesarily have to be anywhere close to what I have either, all I want is a homing algorith that, while does home in on the target, isn&#39;t too good at it.</p><p>EDIT:  I&#39;ve uploaded an updated version of the game, one where the lag is fixed and some other minor tweaks have been made.
</p></div>]]>
		</description>
		<author>no-reply@allegro.cc (Derik Botha)</author>
		<pubDate>Wed, 30 Apr 2008 15:02:47 +0000</pubDate>
	</item>
	<item>
		<description><![CDATA[<div class="mockup v2"><p>For your homing algorithm you might want to keep a pointer to a tank object in your projectile class that is the current target of the missile. When one is fired , store the projectile&#39;s initial direction of movement and when it is updated find the angle from it&#39;s current position to the tank&#39;s current position and allow it to turn towards it by a set maximum angular amount. If you adjust it right it should make it so that a tank will be able to get out of the way if it moves at a right angle to it&#39;s path. If you want a dumb projectile , set the target pointer to NULL and base your projectile&#39;s turning AI off of whether there is a target.
</p></div>]]>
		</description>
		<author>no-reply@allegro.cc (Edgar Reynaldo)</author>
		<pubDate>Wed, 30 Apr 2008 15:16:45 +0000</pubDate>
	</item>
	<item>
		<description><![CDATA[<div class="mockup v2"><p>Thanks for the advice Edgar.  The suggestion seems a bit complicated for my game though.  I only have 8 directions of movement at the movement and your suggestion seems to be for a game that has many more than that, correct me if I&#39;m wrong.  Also, could you please give an example of the type of algorithm that would be used to achieve something along the lines of which you are suggesting?</p><p>Another problem I have just encountered is my collisions.  They use to throw the tank halfway into the collisable block if you collided, turned around and then tried to drive off.  I though I fixed this problem but it still seems to be present, but does not occur very often.</p><p>Another problem with the collisions is the tank seems to &#39;bounce off&#39; the collidable block.  As in get drawn over them and then a frame later gets taken out of the collidable block again, this is an undesired effect of the collision but I can&#39;t seem to get rid of that one either.  First I though it must be where the collision algorithm is called in relation to the move algorith, and it most likely is, but I just can&#39;t seem to identify the problem.</p><p>Any help on optimization of my collision algorithm would actually be greatly appreciated.</p><p>I&#39;m sorry about the trouble but I just started really using allegro a little while ago, and my C++ knowledge in general is shaky at best.
</p></div>]]>
		</description>
		<author>no-reply@allegro.cc (Derik Botha)</author>
		<pubDate>Wed, 30 Apr 2008 15:38:10 +0000</pubDate>
	</item>
	<item>
		<description><![CDATA[<div class="mockup v2"><p>You may only have 8 directions of movement for your tanks but that doesn&#39;t mean the projectiles have to stick to those directions , especially for a homing projectile. Wouldn&#39;t it look kind of strange to see a projectile traveling right all of a sudden start traveling up to the right?<br />Algorithm example :<br />1 - Find direction to target from projectile using atan2.<br />2 - Find difference in direction between current projectile direction and target direction.<br />3 - Allow missile to turn at most the minimum value between the missile&#39;s allowed angular turn rate and the difference in missile heading / target bearing.<br />4 - Update position based on current velocity and direction of travel.</p><p>For your work on collision detection , are all the tanks 32X32 sprites? I would suggest doing a simple rectangular bounding box collision detection when you go to update the tanks movement. Check for a collision where the tank would be after it is updated but before you update its position. If the resulting movement would cause a collision then prevent it from moving that direction in the first place.
</p></div>]]>
		</description>
		<author>no-reply@allegro.cc (Edgar Reynaldo)</author>
		<pubDate>Wed, 30 Apr 2008 16:49:18 +0000</pubDate>
	</item>
	<item>
		<description><![CDATA[<div class="mockup v2"><p>One naive &quot;homing&quot; algorithm:<br />Every 5 steps of moving the missile:<br />   If target is higher than self, take an extra step up<br />   Else If target is lower than self, take an extra step down<br />   If target is to the right of self, take an extra step right<br />   Else If target is to the left of self, take an extra step left</p><p>If you don&#39;t care much about movement being smooth and speed consistent, it could fit the bill.
</p></div>]]>
		</description>
		<author>no-reply@allegro.cc (Audric)</author>
		<pubDate>Thu, 01 May 2008 00:15:45 +0000</pubDate>
	</item>
	<item>
		<description><![CDATA[<div class="mockup v2"><p>Audric: I could see that working if the projectile didn&#39;t need to rotate its sprite to point along the axis of movement.
</p></div>]]>
		</description>
		<author>no-reply@allegro.cc (Neil Black)</author>
		<pubDate>Thu, 01 May 2008 00:30:41 +0000</pubDate>
	</item>
	<item>
		<description><![CDATA[<div class="mockup v2"><p>Thank you for the advice Edgar, I think I might try that.  Now the problem is getting an algorithm that can make the missile move at any of those direction.  I have a rough idea of how I&#39;d like to do it but can&#39;t go into detail now as I have to run.  Hopefully I&#39;ll get time to post it for some input later today.
</p></div>]]>
		</description>
		<author>no-reply@allegro.cc (Derik Botha)</author>
		<pubDate>Thu, 01 May 2008 02:26:08 +0000</pubDate>
	</item>
</rss>
