Tag Info

New answers tagged

0

It's not quite the same, but I implemented something similar at a game jam. The game had players moving on a small circular level, wrapped around when the player reached an 'x' position of pi. Rendering was easy because we just rendered everything and then rotated an offset camera to track what was going on. You could implement something similar, as has been ...


4

I assume this is because in these cases the grid lines are not exactly on screen pixels, but somewhere in between. Is this correct? Yes, this is correct. The camera in LibGDX is based on a vector, which is made out of floats. When your camera is in between pixels (like at (1.2f, 63.5f)), then you will start to see that blur you mention because the ...


0

I think the only reasonable approach would be to implement your wrapped world in an underlying data-structure completely transparent to the game and the user. So on some Low-Level you have a function mapCoordinate() which wrap your actual coordinates to your underlying map-resource... So if your actual World is only 10units wide, the player and the game ...


2

Disconnect the rendering from the world and you can do wraparound and correct rendering without resorting to any cloning or teleporting artifacts. First, in your world you have a fixed size world, from 0 to Width. Anytime an object goes below 0 you wrap it to the end, and anytime an object is over Width wrap it to the start. This means that all logical ...


6

Remember that what you display on screen, and what's in memory are two totally different things. Imagine you have a window that you need to fill with data about the world. You fill the window from left to right. While you're parsing your data to fill the world, if you reach the end of the world, simply loop back around to the beginning of your data. Using a ...


10

The canonical solution is to use portals. In your example, there is only one level, except there is a portal connecting the left and right ends. Anything moving across that portal will have its coordinates translated to the other end of the portal, so that if something is moving left through the portal, it will reappear on the right side of the level and ...


12

This system with all these triggers sounds a bit too complicated and error prone. You could wrap the position of the player using modulo with something like playerPositionX = playerPositionX % mapWidth This way when your player reaches playerPosition == mapWidth the playerPosition will reset back to 0. This solution could be extended with the whole ...


2

Just go really simple. Add a flag to the player that tells the camera when they're jumping. If they're jumping, don't follow them up. The other situation you need to handle is when the player jumps up or down to different levels. In this case it would be pretty simple to start tracking again when the player touches down, or if the player goes below the ...


1

Sorry for late answer - I originally jumped on the love IRC where I was pointed towards love.graphics's Coordinate Functions which allows you to modify love's coordinate system to do exactly what I wanted. Credit also to NauticaMile for suggesting hump.camera, which uses this as the underlying implementation. This example replaces my original hardcoded ...


1

I believe I know why it's behaving strangely. Here's a diagram I drew conceptually demonstrating the problem: I would solve the math for you too, but it should be easy enough from here. Give it a try and if you get stuck, just comment and ask.


0

I don't think speed is a huge issue between your different methods so you might go with whichever approach you think is easiest. I would absolutely choose to access the arrays differently and not store pre-rotated versions of them. For rotating one chunk: normal rotation gives you array[x][y] -90 degrees would give you array[WIDTH-1-y][x] 180 degrees would ...


1

So you need to call renderer.setView(orthoCamera) to reset the tile map drawing view. Then don't forget to also call camera.update() after you do anything to it.


0

There are a couple things you will need to do here I believe: 1 Sorting the objects based on rendering order because they have a "Z component" 2 Translating the world coordinates into screen coordinates/scale by account for camera position 2 Touch up art assets that have a "depth" or "thickness" when portrayed in 3d space.


2

Unless you have the screens at angles greater than roughly 45 degrees, you should be able to create a viewport that covers the three screens, and have it look realistic. Instead of having a 1600x900 viewport, you would have a 4800x900 viewport. I would not recommend having three separate cameras. If the displays render slightly out of sync, it can disorient ...


2

Yes, you can implement this with three cameras. There's a few ways to approach this, and none of them are built in easy to use solutions from Unity. Create one large borderless window that spans multiple screens (for example you can use the command line argument -popupwindow). You'd then set up each camera to take up the portion of the window that is ...


0

use Screen.lockCursor in your Start() method http://docs.unity3d.com/ScriptReference/Screen-lockCursor.html



Top 50 recent answers are included