Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Jan 2014
Offline Last Active Jun 19 2014 03:30 AM

Posts I've Made

In Topic: Wall collision resolution question

23 May 2014 - 10:47 AM

This is not such a good solution, though. With this method you can't adjust the speed of something. Of course, if you have no need to adjust the speed, like in a runner, this would be fine, but otherwise you would have to have all objects moving at a static speed, and you would have to set the right offset for every object. One way you could solve this is to have a ray cast between the current and last position and check if the ray collides with anything, and if it does, just set the position of the object to where the collision occured and resolve your collision from there.

In Topic: Space Game Parts falling off

07 April 2014 - 09:34 AM


But how would you place the different animating parts together so that the proportions are correct?

Each ship part would have a transform that specifies its offset from the ship's local origin. With a suitable vector/matrix math library, it should be relatively easy to overlay the additional parts onto the base enemy structure - which itself might just be a part, just with a transform that does nothing!

Just to expand upon this answer, if rotations are not needed, you could just specify the center of your ship as an origin point, and then draw the parts of the ship at an offset from the origin.

For example: If you have your origin at your ships center, then you could draw a part of the ship at origin - part.offset. This way the parts will always be drawn at the offset specified for any given part.


And so that every ShipPart holds a texture for its wings for example and when the parts are destroyed I just create a new Object with that texture and rotate it like in the video?


The other way you could this is to create the Objects with the ship, by for example including them in a list in your ship class,  and then just update the positions of the Objects with the origin and offsets. The advantage of this would be that you could have each part behave differently and animate while still being attached to the ship, so just having more customization really. I think the method you described would be faster, but I don't imagine either method will make much of a difference performance wise unless you're thinking of having thousands of ships on-screen.


Good luck with your game smile.png

In Topic: Space Game Parts falling off

06 April 2014 - 05:53 AM

I assume the video is not from your game?


You could make your ships have multiple hitboxes, and when one has lost all its health it triggers the event that makes the ship lose the part the hitbox was hitboxing (?) for. Then the easiest way would probably be to make the ship consist out of multiple animated sprites (just make a class, like ShipPart or something like that) that you can easily make fall off. Or you could have multiple ship sprites for different damage conditions, and then when the wing falls off just create a new game object where the wing was.


I probably explained that quite badly, but I was a bit confused by the question. If you could elaborate a bit, that would be great :)

In Topic: spriteBatch.Draw slow?

05 March 2014 - 12:19 PM

Yes, that is my plan. I haven't had time to start yet, but I think I'm gonna use this opportunity to properly learn hlsl shaders. I've been meddling a bit with them, but not enough to properly understand them, so it'll be fun :)

In Topic: spriteBatch.Draw slow?

05 March 2014 - 11:34 AM

I'm pretty certain that I'm drawing everything correctly. I've found out that I can draw aound 100 000 sprites on my test project before it slows down, though. There must have been some slowdown on my computer when I tested.


Here is the draw code on my test project:


            // TODO: Add your drawing code here
            for (int i = 0; i < 100000; i++)
                spriteBatch.Draw(pixel, rect, Color.ForestGreen);


Rect and pixel are created in the initialization, and are never changed after that.