So i am new to libgdx and i am thinking about making 2D quest. I want to know how to interact with the objects on the backround image. For example, i have this location
Is it possible to get the window's coordinates so that if the player is next to it (I want to check the interaction possibilities by the player's coordinates and the interactive object's coordinates), he can press "E" or do something like that?
I was thinking about putting certain images in the background, but I don't know if that's a good idea. I also saw something about TextureRegion but I don't think it can help me because I still don't know how to get the coordinates of a specific area in the background.
Colour code the objects. From the appearance of your game its retro adventure so you are using a restricted palette. A restricted palette has advantages! So if you have windows with two colours, doors with 2 different and separate colours, objects with 2 different separate colours, then you can check when the player gets near a window, or whichever, by seeing what active colours are present on a radius around the player location.
So e.g. the floor and walls are coloured of course but they never trigger anything. This does limit you to one window per room, or one type of object per room (unless you introduce a new window colour pair to distinguish them). The code would be just sample all the pixels in the area around the player maybe a rectangle would be better.
I am currently working on a project that moves a circle from a space to space when button is pressed. I designed as following: When the button is pressed, it increments the coordinates of circle, in a for loop from 0 to 10.
The problem is, the motion I wanted with for loop doesn't show up on the screen but it only shows the object on the first and the last coordinates, so it doesn't move one by one.
Any suggestion would be appreciated,
Kutay Demireren
You need to set a frame draw length that the human eye can see in order for motion to work properly. The can be achieved in many ways, but the easiest is with a thread.sleep at the end of each for loop iteration for however long you want the different pictures to be visible for.
I've recently been looking into LibGDX and seem to have hit a wall, seen in the picture, the blue dot represents the users finger, the map generation it self is where i seem to get stuck, does LibGDX provide a method of dynamically drawing curved objects? I could simply generate them myself as images but then the image is hugely stretched to the point of the gap for the finger can fit 3! But also would need to be 1000's of PX tall to accommodate the whole level design.
Is it such that i should be drawing hundreds of polygons close together to make a curved line?
On a side not i'll need a way of determining when the object has from bottom to top so i can generate another 'chunk' of map.
You don't need hundreds of polygons to make a curve like you drew. You could get away with 40 quads on the left, and 40 on the right, and it would look pretty smooth. Raise that to 100 on each side and it will look almost perfectly smooth, and no modern device is going to have any trouble running that at 60fps.
You could use the Mesh class to generate a procedural mesh for each side. You can make the mesh stay in one spot, locked to the camera, and modify it's vertices and UVs to make it look like you are panning down an infinitely long corridor. This will take a fair amount of math up front but should be smooth sailing once you have that down.
Basically, your level design could be based on some kind of equation that takes Y offset as an input. Or it could be a long array of offsets, and you could use a spline equation or linear equation to interpolate between them. The output would be the UV and X coordinates which can be used to update each of the vertices of your two meshes.
You can use the vertex shader to efficiently update the UV coordinates, using a constant offset uniform parameter that you update each frame. That way you don't have to move UV data to the GPU every frame.
For the vertex positions, use your Mesh's underlying float[] and call setVertices() each frame to update it. Info here.
Actually, it might look better if you leave the UV's and the X positions alone, and just scroll the Y positions up. Keep a couple quads of padding off top and bottom of screen, and just move the top quad to the bottom after it scrolls off screen.
How about creating a set of curved forms that can be put together variably. Like the gap in the middle will at the top and bottom of each image be in the middle (with the same curvature at end and beginning points)...
And inbetween the start and end points you can go crazy on the shape.
And finally, you can randomly put those images together and get an endless world.
If you don't want to stop in the middle each time, you could also have like three entry and exit points (left, middle, right)... and after an image that ends left, you of course need to add an image that starts left, but might end somewhere else...
I am writing a zigzag drawer as my school assignment. Basically what is expected is to be able to draw zigzags on a canvas, to be able to move vertices of the zigzags and to be able to move the entire zigzag. Also we can change the color and thickness of the zigzags.
I could manage to draw zigzags, a left click starts and subsequent left clicks continues the zigzag, and a right click finishes it. In this way i can draw several zigzags.
What i can not do is how i can make the vertices of the zigzags movable? I am keeping the point coordinates in an arraylist of type mypoint which consists of x, y and depth values. I am drawing all the painting on a canvas which is an extended class of JPanel. in the paintcomponent method i call drawline methode for every vertex in the list. As these are just paintings i cannot figure out how i will detect that the user is clicking on the vertex. Can i have little button like controllers when clicked will do the job i want. i tried to use labels and standard buttons, but neither can i position them appropriately nor are they too large to be just handlers for vertices.
Do you have suggestions on these?
You could have two modes of operations, which must be chosen by the user by selecting a radio button, for example: one for drawing zigzags, and the other one for selecting vertices.
While the chosen mode is "zigzag", the mouse clicks allow drawing zigzags as you have already implemented. When the chosen mode is "vertex selection", then a mouse click could find a vertex whose distance from the clicked point is less than 3 pixels, and the dragging of the mouse could move the vertex from its original position, following the mouse pointer.
You could inform the user about the selected vertex by displaying a small squere around the vertex.
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.