I've build a simple click and drag background for a program I've written which is all good and working. It adds on the distance moved by the mouse while held down. However thinking ahead I'd have to do this for all objects every time I moved the image as I was going to give the objects positions relative to the image and this might cause a few issues with processing power.
What I would like to do is have the background in a set position within the program and move the users view over the image without having to change the position of every object every tick, the problem I'm having is where to start and how to build something like this.
Thanks in advance
Well you need to tell your program where the objects are supposed to be drawn somehow.
It sounds like you are currently thinking to draw your frame by looping through your objects and drawing them at their location, and when you move the background, updating the object location.
If that method isn't sitting well with you, you could create a sort of 'map' (2-d array of pixels/locations) that you fill sections in on when you create new objects. Then when you go to draw your frame, you could scan through some range of positions in your 'map' and draw the objects that you find. When the background is moved, you could then keep the offset in a single location and use that when determining what range of map values to scan through.
i'm not positive how the processing implications of these two methods compare, i'm sure it depends on the size of your frame, level of detail, and number of objects that you have offscreen at any time.
I am currently in the process of making a tile based 2D platformer using lwjgl. I have a character that is able to run and jump all around the map. I have run into a strange problem when moving the window. When I move the window the game will freeze which isn't a big deal because when you let go it unfreezes, but after it unfreezes my character will end up moving down a number of tiles based on how long you hold the window or move the window for. Is there anything i should know about the library and the display, or do you need to see the code for the window initialization or the physics and collision detection? I have no idea why the movement of the window would have anything to do with the players position!
Solution:
After quite a lot of thought and attempts to fix the problem, I had realized that i am using a delta in my update methods, because delta is calculated by the time between each update, because the game freezes when the window is "moved" or "grabbed" the delta value becomes very large in a short period of time causing the player or object to be moved a very large amount at once. To fix this i simply put a limit on the delta value that gets passed into my update methods so that the player would not be able to move 10+ tiles at a time.
Ok so I am creating a ball tilting game, where you navigate a ball around a maze. The ball works, and is all good in the area however I am having some problems in the maze.
The maze is programmatically created through a .txt file that contains 1's and 0's (1's being walls, and 0's being floor.) I have a for loop that goes through the whole .txt file and places a white(wall) or black(floor) square at the proper coordinates on a canvas. This is similar to the apps-for-android Amazed game if you have seen it link. However, instead of placing wall-type detection on his tiles, he just resets the game and deducts a life point if the user rolls onto a 'void' tile.
However I am looking to have 'walls' and not 'voids'. Where if the ball touches the wall, it doesn't go beyond that point, but can still move freely on the other axis. Unless it hits a corner, of course.
The problem I am having is actually creating this detection. I have tried a number of ways but nothing so far has been successful or useful.
I have tried:
- Have an ArrayList of all of the coordinates of the wall tiles, and every game tick, it checks to see if the ball is touching one. However this just slowed the game down to a crawl and was just extremely terrible.
- Check to see what tile the ball is on, and if it's on a wall tile, to stop it on an axis but let it move freely on the other, however this still didn't work as there were some issues when the ball was to the right of the wall tile, but also under it, it couldnt move up, as the code detected it being under the ball.
And a few other ways but I really cannot remember! It's been a bit hectic.
So, I am asking, if anyone has any experience in this area could they please give me a push in the right direction? Im hoping to have the maze walls sorted by Tuesday however it's looking grim!
If you need any more information, please ask.
Thank you in advance for any and all replies.
Instead of having an ArrayList that you have to iterate over, why not store the maze the same way you do the text file? Use a 2D boolean array filled with true for wall and false for floor, or vice versa.
This simplifies finding a wall considerably. All you have to do is figure out where in your grid the ball is. Then you can just check the cells immediately surrounding it. Even if you include diagonals(which probably isn't necessary for an all-90-degree maze), this equates to checking 8 booleans from an array, basically instant.
As for the axis issue, just stop movement in that direction. No need to freeze a whole axis. For instance, if the wall is right of you, just don't allow x to go higher. No reason to not let it lower unless there's a wall to the left.
This is just a general idea, though. Since it's homework, no code for you ;)
Edit:
The 2D array is just that, a boolean[][] which holds true in each of the spots where you want a wall to be. When you read in your text file, just assign it straight away.
Assuming each line in your text corresponds to an y row, and each 0/1 is the x for that column, when you read a 1, assign map[x][y] = true.
I'm honestly not sure what else you need elaboration on. It's a common format to do simple tile-based maps, though. If you google "2d array tile map", you'll find several resources to help with it.
Simple question that i've always pondered about. When I first got into opengl I had to find a way to draw "tiles" or a bunch of triangles with 1 opengl draw call to improve performance vastly. I did that by putting all the vertices into an array and drawing the array. One problem that occurred was whenever I scrolled the tiles, I would see random placed pixels showing on and off depending on how much I scrolled the map. Around 5-8 on a 10x10 map. Now, I got back into opengl again and and this time I drew using GL_LINE_LOOP instead of GL_TRiANGLES. This never occurred to me back then but what I see when using GL_LINE_LOOP is all the triangles but when it finishes(it goes from bottom left to top right, so top right) there is a line connecting where I ended and where I began. Would the cause of those random pixels be because of this? Or does this have nothing to do with it. Does that line connecting the end and beginning appear because of GL_LINE_LOOP mode or does that also have nothing to do with and have to do with the way I created the map?
GL_LINE_LOOP is a completely different drawing mode - and no that won't be the reason why you're dropping pixels on tiles.
Most likely reason for dropping pixels when drawing a tight mesh of tiles is that you're not computing the vertices consistently. The principle is that if a vertex is shared by two adjacent triangles (or quads, lines, whatever), then the floating point coordinates of that vertex must be 100% identical for every draw call. If you do that, then you're guaranteed to render a tight mesh without any gaps in between tiles.
Your problem may have been something else though... perhaps Z fighting.. but my guess is the first thing I mention here.
So I'm building the pacman game in Java to teach myself game programming.
I have the basic game window with the pacman sprite and the ghost sprites drawn, the pacman moves with the arrow keys, doesn't move beyond the walls of the window, etc. Now I'm trying to build the maze, as in this picture:
Without giving me the direct/complete solution to this, can someone guide me as to how this can be built? I'm talking only about the boundaries and the pipes('T' marks) here which you can't go through and you have to go around. Not the dots which the pacman eats yet.
Here are my questions:
1) What's the most efficient algorithm/method for creating this maze? Will it have to be drawn each time the paint() method is called or is there a way to draw it only at the start of the game and never again?
2) How will this actually be drawn to the screen? I assume the fillRect() will be used?
3) Any hints on collision detection (so the pacman/ghosts can't go through the walls) would be helpful.
4) Any hints on how the vacant space between the pipes will be calculated so the dots can be filled between them will also be very helpful.
Thanks
I wouldn't do it that way.
I'd draw the graphical map and then create a 2D data array which represents the map. The data map would be responsible for determining collisions, eating dots, where candy is and where the ghosts are. Once all the logic for everything is handled just use the 2D array to display everything in their proper pixel coordinates over the graphical map.
For example the user is pressing the left key. First you determine that pacman is at element 3, 3. Element 3, 2 contains information denoting a wall so you can implement the code to make him ignore the command.
EDIT:
Each element would represent about where a dot could be. For example:
No, looking at the board I would say the array would look something like this.
d,d,d,d,d,d,d,d,d,d,d,d,w,w,d,d,d,d,d,d,d,d,d,d,d,d
d,w,w,w,w,d,w,w,w,w,w,d,w,w,d,w,w,w,w,w,d,w,w,w,w,d
p,w,w,w,w,d,w,w,w,w,w,d,w,w,d,w,w,w,w,w,d,w,w,w,w,p
d,w,w,w,w,d,w,w,w,w,w,d,w,w,d,w,w,w,w,w,d,w,w,w,w,d
d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d
And so on. You might want to pick a more flexible data structure than just characters however since some areas need to contain a bunch of different information. IE even though the ghost spawning area is blank, pacman isn't allowed in there. The movement of the ghosts and pacman is different for the side escapes, the candy spawn point is a blank spot but if you want to remain flexible you'll want to denote where this is on a per map basis.
Another thing you'll want to remember is that pacman and the ghosts are often inbetween points so containing information that represents a percentage of a space they're taking up between 1,2 and 1,3 is important for collision detection as well as determining when you want to remove dots, powerups and candy from the board.
You can paint the map into a BufferedImage and just drawImage that on every paint(). You'll get quite reasonable performance this way.
If you are happy with the walls being solid, you can draw each square wall block with fillRect. If you wish to get the same look as in the picture, you need to figure how to draw the lines in the right way and use arcs for corners.
The Pacman game map is made of squares and Pacman and the ghosts always move from one square to the neighbouring square in an animated step (i.e. you press right, the pacman moves one square to the right). That means that collision detection is easy: simply don't allow moves to squares that are not empty.
I do not understand what you are trying to ask here.
1) Just to give my advice on redrawing. Something that you can do if you find redrawing the entire image is slow, is determine only the elements that have changed on the screen and redraw those. An approach for this would be the following: Determine the sprites that have moved. Determine (approximate) a rectangle around those sprites. Redraw those rectangles only. This way you are only refreshing parts of the screen and not the whole screen. This should result in an increase in performance over redrawing the entire screen.
The other answers have been reasonable for the other questions you have asked.