I was using Tiled as my tilemap editor. I right clicked my tile representing my wall and set tile properties for that specific tile. Notice I´m not setting the property for the layer or anything in the map: I´m using the specific tile. That way all tiles on the map have the same property. I had a property name "checkCollision", since different tiles reacted differently to collision. Walls were solid and Conveyor belt sped up the entity checking for collision.

Anyway, in my levelloader I wrote something like this:



Note that this code is based on the old TiledMap API in LibGDX, but I figured it might be easier to read in code...

So basically I read the tilemap and check each tile if it has the property name "CheckCollision". If it returns the property value "solid" I create a new wall with position and tilesize and store it in the list.

I made a class called Wall and I set a tileproperty for my walltile to "solid" in my tilemap editor. Then when I read the .tmx file I made a new Wall object and stored it in a list. That way I had a list of bounding boxes to test collision against.

I think you´re complicating it and thereby introducing more bugs that´s gonna be harder to debug. Try to keep it simple. If you need two rectangles and two AABB you´re doing it wrong and should go back to the drawing board. For example, you shouldn´t need to do two intersection test since you can get all the information you need from one test. In your case you check which axis has the smallest overlap and then the collision will occur on that axis.

That´s the spirit: More "programming games" and less "thinking about the best way to get started programming games".

Let´s say we have object A and B. If object A is 1 pixel away from object B and the speed of A is 5 pixels per frame you will only get a "true" from the collision check when A is overlapping with 4 pixels. What you want to do is to correct the overlap by the minimum amount. I wrote a bit about this in your last thread about collision detection so I won´t repeat myself, but read it and hopefully you´ll get some ideas.

Sounds like a Sweep and prune. You check all AABBs for overlaps on first the x axis and then the y axis. Basically you check all points one dimension at a time. Then, if two objects overlap on both axes, there´s an intersection. Then you can keep an almost sorted list since an objects position change very little frame... It´s the basic idea, but google "Sweep and prune" and you will find a lot of better explanations.

ps1. I actually came up with something like this idea a couple of months ago when thinking about how to solve collisions. "How come no one has come up with this idea before?", I tought. Of course someone already did: David Baraff in 1992! I guess I wasn´t that groundbreaking after all...

ps2. "Nearby" should be "overlapping".

Something like this should do the trick

bulletDirection = mousePosition - gunPosition
normalize the vector bulletDirection
multiply bulletDirection with the desired speed

Did you read my reply?

Platformer in the last 5 years? Super Mario Galaxy 1 and 2. Great games!

I belive that this is a common problem. First you check if there´s a collision in the y-axis and stops velocity if intersection returns true, then you do the same in the x-axis. The problem is that when intersection is true in the x-axis, it will also be true in the y-axis since for a collision to be true you have to be "in" a collision. H3ckboys solution is one, another one is the one I posted in your last topic about collisions here http://www.java-gaming.org/topics/corner-collision-detection-need-help/29399/msg/269818/view.html#msg269818: Check for intersection. If it returns true you check how much the objects overlap and then push back one object the amout of overlap. This way you´ll always be just outside of collision.

Nice going! I have fond memories of Wings of fury so this is kind of a blast from the past.

I have a huge problem with the game though and that´s the controls. First of all, it get´s very cramped on the keyboard with the Z, A, Space and B. It doesn´t fit right in the hand at all, so it would be a good idea to look it over. Secondly, the Left and Right is totally opposite to my intuition. At the very least you should add an options to invert the steering. If you feel like fixing this I´ll gladly be looking forward to an update.

Looks great! I like the little Santa-looking guy...

You´re not really stating a problem. You have a tmx file and then you load the data into an array which sets each tile as blocked or not blocked. What else do you want to do?

You´re welcome! Feel free to press the "appreciate" buttons...

Yeah, it´s the same idea. But since I also wrote some stuff about how to deal with a collision I thought it was worth the extra post.

I posted a AABB method a couple of days back. Hope it helps.

http://www.java-gaming.org/topics/corner-collision-detection-need-help/29399/msg/269818/view.html#msg269818

Here´s the classic Java gaming text on game loops: http://www.java-gaming.org/index.php?topic=24220.0

I don´t really have a great relationship with general purpose game programming books. They come out strong and say they will cover everything but in the end that means they doesn´t really cover anything. On top of that most Java game programming books focus on the Java API for game development but if you browse the forum you´ll find that few belive that this is a good idea. The really good game programming books I´ve come across are the one that focuses on specific areas, like "Real time collision detection" (a hard core collision detection book) and... Some AI book I can´t remember that name of on top of my head. One general purpose book I am interested in though, but haven´t had a chance to check out, is "Beginning Android Games" by one of the creators of LibGDX, Mario Zechner. It looks promising... Anyway, since you have so much Java experience there are a lot of tutorials out there that will get you started on understanding the basics of a real time game and I would also suggest reading a lot of game code.

Regarding the fact that you want to don´t want to use a library I would suggest starting out with LWJGL, a Java port for OpenGL. OpenGL may sound like it´s for 3d only (it did to me when I got started) but it´s just as good for 2d games and is really the only way to go if you want to get serious.

So to sum it up: Tutorials, code and LWJGL. Good luck and welcome!

Looks really nice! Somehow that old school graphics makes me think of the Sierra game "Codename: Iceman" (yes. I´m that old). And a simple mechanic can still make a great game. I´m looking forward to try it out!

You need to put the player in the same coordinate system as your map so they have the same point of reference. Don´t spawn the player at zero, spawn the player at some coordinate on the map that´s... Not zero...

Why and how could the tilemap have negative coordinates? I think you´ll have to explain more...

Eh? Perhaps i misunderstood. Did you get a stranger result when changing x,y to floats? The cast to int was for the drawing only.

...and add 0.5 to round it off to the nearest int

I meant I tried my little snippet and it didn´t stretch... But all is well that ends well! 

If you want to do a "AABB vs AABB" test here´s a vector based way to do it.

You need some vectors for the boxes: center, half the width and half the height.
You also need a vector to store the result: minimum translation vector.



What this mean is that you test one axis at a time for overlap. The absolut value ( = positive value) of "(this.center - other.center)" puts the center position close to zero and then you add half the size of the box. If the "subtracted position" is greater than the size of the boxes, you get a positive value and there is no overlap. If the "subtracted position" is smaller than the size of the boxes, you get a negative value.

That is all if we just want to test intersection, but what is the "minimum translation vector" (I´m just gonna call it by it´s abbreviation "mtv" from now on)? This is a little bonus: it is the smallest amount you have to push back an object for it to NOT be intersecting. This is often a problem in collision detection, that you get stuck too deep in a collision so you can´t get out. So how do you use the mtv? One way is to see what axis is has the smallest intersection and push it back that way. Let´s say you´re testing collision between a Player and a Wall:

1) Get the vector from the center of the player to the center of the wall: Wall.center - Player.center.
2) Find out on which axis has the smallest intersection (let´s just say in this case it is x)
3) player.position.x += mtv.x.

The result is that the player is positioned precisely outside the collision every collision check.

I hope it helps.

(any errors I blame on the very, very late hour over here... )

Tried it. Didn´t stretch.

This is a question that´s asked a lot, so I suggest you start out by searching the forum. There are also a lot of good tutorials out there, both text and video, so a google search will get you a long way. LibGDX has a lot of stuff on their site and a very simple "this is how LibGDX works"-game code example that is really useful for understanding how it works.

Try adding this to your resize method:



This should set the viewport to the same size as the window.

I´m not really sure I understand your problem, but the way you describe it is the way it´s supposed to behave. If you resize your window everything will scale to the new resolution.

One thing that is important to understand is that you´re actually not loading 16x16 pixels that you can plot to the screen: You´re loading a texture that is pasted on a rectangle. A rectangle doesn´t have "pixel size", just coordinates, and will clamp the image within these coordinates .This mean that when you resize the window, you also scale the rectangle (= sprite) to fit the new window resolution and since texture coordinates are relative to the rectangle you´ll also scale the texture. Hence, everything will stretch.

So if what you are experiencing are that the "stretch ratio" of the tile is equal to the new window size, this is expected. You may not like it but it is normal. If not, I think you need to clarify your problem.

It looks absolutly fantastic! I really, really hope I´ll get to play this on my iPhone soon!