We Keep Coding

Using world coordinates

I am currently using pixels as units for placing objects within my world, however this can get tedious because I only ever place objects every 16 pixels. For example, I would like to be able to place an object at position 2 and have the object rendered at the pixel position 32.
I was wondering if the best way to do this is simply having a pixel-to-unit variable and multiplying/dividing based on what I need to be doing with pixels or if there is a better way.

You shouldn't use constant a pixel-to-unit conversion, as this would lead to different behavior on different screen sizes/resolutions.
Also don't forget about different aspect ratios, you also need to take care about them.
The way you should solve this problem is using Viewports.
Some of them support virtual screen sizes, which are what you are looking for. You can calculate everything in your virtual space, and Libgdx converts those things to pixels for you.
They also take care about different aspect ratios in different ways.
The FitViewport for example shows black borders, if the aspect ratio is not the same as the virtual one.
The StretchViewport instead of showing black borders stretches the image to fit the screen.

Best way to load big background in libgdx

I am developing a game using libgdx. Now i'd like to have a Background all over my map (Map size is not fixed yet i'll decide later). My map is tile based but i don't use TiledMaps. So i create and load the map with own code/editor.
My question now: How should i implement the background thing?
I thought about different ways:
Loading a huge Image, which covers all the map. This is not realy good cause i render things, which are not in my viewport (80 Tiles X,50 Tiles Y).
Deviding the Image in 4 or more Images and loading the one in the viewport. The Problem: At some point maybe part of all Images is in viewport so all Images are sent to GPU right?
Having 1 Image which cover the viewport (80,50) and follows the camera. Best performance i think, but it will look stupid...
Or every tile has an own Image and the Objects are drawn above them. Notice that i only render Tiles inside the viewport. But on Gamestart it would need to load Information about every tile in the level.
For Information: My Game is Topdown and the Background Shows the floor so no detailed hills etc are needed, just maybe some simple desert sand look and things like that. Is there another even better way?
What would be the best way for performance and optic?

If your game is Tile Based. It would make much more sense to have the background tiled aswell. Just use another layer for it. If your editor/loader does not support multiple layers, then I would recommend you to switch to another one, or add those features to it (if possible).
The Background Shows the floor so no detailed hills etc are needed, just maybe some simple desert sand look and things like that.
It is very easy to reuse tiles in something like a desert, because all their tiles are very similar (sand).

Java advanced image manipulation

I am having a problem with manipulating images in java 7. I have researched the problem I am having for three weeks and have failed to find a solution,
I am trying to set an image over an area, basically setting the corner posistions.
I am using a BufferedImage.
This is for a 3D game where I am writing the 3D conversion code. I have managed to create a 3d world, and populate it with cubes, filling in the sides with graphics.fillPolygon():
What I would like to do is draw an image that fills a polygon's shape.
Any help I will be grateful for (even if it is formating this post better).

You can use transformations on your graphics. Here is a little tutorial on it. With that you can transform already drawn stuff. If you want to transform multiple images in different ways, you can draw them on different canvases and transform then separately. Then you can merge the images together...
But I would recommend using a 3D engine (JOGL, jMonkeyEngine, or others) for that (unless you want to learn about the geometric calculations with this task). It is also much faster to use OpenGL than drawing the stuff by yourself and doing the calculations in code (most probably meaning: on the CPU and not the GPU).

Have you tried using the drawImage? instead of .fillPolygon?

2-Dimensional Tile-Based Game: Each tile as an object impractical?

I've been trying various ways of creating a two-dimensional tile-based game for a few months now. I have always had each tile be a separate object of a 'Tile' class. The tile objects are stored in a two-dimensional array of objects. This has proven to be extremely impractical, mostly in terms of performance with many tiles being rendered at once. I have aided in this by only allowing tiles within a certain distance of the player being rendered, but this isn't that great either. I have also had problems with the objects returning a null-pointer exception when I try to edit the tile's values in-game. This has to do with the objects in the 2D array not being properly initialized.
Is there any other, simpler way of doing this? I can't imagine every tile-based game uses this exact way, I must be overlooking something.
EDIT: Perhaps LWJGL just isn't the correct library to use? I am having similar problems with implementing a font system with LWJGL... typing out more than a sentence will bring down the FPS by 100 or even more.

For static objects (not going anywhere, staying where they are) 1 tile = 1 object is OK. That's how it was done in Wolf3d. For moving objects you have multiple options.
You can, if you really really want to, store object sub-parts in adjacent cells/tiles when an object isn't contained fully within just one of them and crosses one or more cell/tile boundaries. But that may be not quite handy as you'd need to split your objects into parts on the fly.
A more reasonable approach is to not store moving objects in cells/tiles at all and process them more or less independently of the static objects. But then you will need to have some code to determine object visibility. Actually, in graphics the most basic performance problems come from unnecessary calculations and rendering. Generally, you don't want to even try to render what's invisible. Likewise, if some computations (especially complex ones) can be moved outside of the innermost loops, they should be.
Other than that it's pretty hard to give any specific advice given so little details about what you're doing, how you're doing it and seeing the actual code. You should really try to make your questions specific.

A two-dimensional array of Tile objects should be fine........ this is what most 2D games use and you should certainly be able to get good enough performance out of OpenGL / LWJGL to render this at a good speed (100FPS+).
Things to check:
Make sure you are clipping to only deisplay the visible set of tiles (According to the screen width and height and the player's position)
Make sure the code to draw each tile is fast... ideally you should be drawing just one textured square for each tile. In particular, you shouldn't be doing any complex operations on a per-tile basis in your rendering code.
If you're clever, you can draw multiple tiles in one OpenGL call with VBOs / clever use of texture coordinates etc. But this is probably unnecessary for a tile-based game.

Collidable color Java/Android game

I'm trying to develop side scrolling game for android involving many many textures so I was thinking if I could create a separate layer, all a single unique color (very similar to a green screen effect) make a collidable and make it invisible to the player.
(foreground layer) visual Image
(2nd layer)collidable copy of foreground layer with main character
(3rd layer)Background image
I not sure if this is possible or how to implement it efficiently, the idea just came to me randomly one day.
Future regards, Thanks

I assume your game is entirely 2D, using either bit-blits or quads (two 3D triangles always screen-aligned) as sprites. Over the years there have been lots of schemes for doing collision detection using the actual image data, whether from the background or the sprite definition itself. If you have direct access to video RAM, reading one pixel position can quickly tell if you've collided or not, giving pixel-wise accuracy not possible with something like bounding boxes. However, there are issues greatly complicating this: figuring out what you've collided with, or if your speed lands you many pixels into a graphical object, or if it is thin and you pass through it, or how to determine an angle of deflection, etc.
Using 3D graphics hardware and quads, you could potentially change render states, rendering in monochrome to an off-screen texture, yielding the 2nd collidable layer you described. Yet that texture is then resident in graphics memory, which isn't freely/easily accessible like your system memory is. And getting that data back/forth over the bus is slow. It's also costly, requiring an entire additional render pass (worst case, halving your frame rate) plus you have all that extra graphics RAM used up... all just to do something like collision-detect. Much better schemes exist, especially using data structures.
It's better to use bounding boxes, or even a hierarchy of sub-bounding boxes. After that, you can determine if you've landed on the other side of, say, a sloped line, requiring only division/addition operations. Your game already manages all the sprites you're moving, so integrate some data structures to help your collision detection. For instance, I just suggested in another thread the use of linked lists to limit the objects you must collision-detect against one another.
Ideas like yours might not always work, but your continual creative thinking will lead to ones that do. Sometimes you just have to try coding them to find out!