For a university term project, I'm working on a graphical roguelike (I'm aware of the contradiction in terms :P) that uses an isometric display. What I'm trying to figure out is, since drawing all the tiles is stupidly expensive and unnecessary, I'm wanting to figure out a relatively fast algorithm to determine which tiles should be drawn to fit within an NxMpx window, given that the tile graphics are XxYpx.
I'm not doing smooth scrolling for this, so that's not an issue. I'm also not worried about being perfect - a little unnecessary draw is fine, I just don't want to draw a huge amount of unnecessary tiles that won't show up in-game.
You need to think about two concepts: Screen space and world space. These are very important in 3d engines, but they apply to all but the very simplest games. In the isometric engine your world-space is a 2d array of tiles.
So you are looking first of all at a way to covert between these two co-ordinate spaces. Once you've done that, it'll be obvious that screen space maps onto the world as a rectange that's turned at 45 degrees. You can determine a formula for that, but it's only important if you are trying to determine which part of the world space is visible so you only simulate monsters in that area (an efficiency necessary on 8 bit consoles, probably not on a modern PC!). When it comes to actual rendering you don't really need to determine this visible region of the world, because it's implicit in the way you render the tiles onto the screen:-
You work out which tile location is at the top-left of the screen, call this O (for origin) - that's going to be a fixed offset from your point of interest, usually the player, that you want to keep in the centre of the screen.
Once you have that you paint the tiles in the top row of the screen, stepping +1X and -1Y in world space for each tile (if you are looking north-east).
Then you paint the row below. That is offset minus one half a tile width in screen space and starts at O -1X in world space.
You repeat steps 2 and 3, modifying your starting position in world space by -1 in X and Y from what you used in the previous stage 2 until you reach the top of the screen.
Other tips:-
Obviously you don't draw any tiles that are outside the map. You might also, depending on game design, not draw any tiles outside a particular room the player is in.
There's not just floor tiles to draw, theres also players, monsters, scenary, etc. The rule is you draw everything in a paricular world location in the same pass. That way objects closest to the 'camera' will obscure stuff behind them (which is why you start drawing at the top of the screen).
Also, you don't just have floor tiles in most iso engines, you would also have furniture and wall segments. You might designate areas of the map as belonging to a particular room, when the focus is on that room (because the player is in it for example), you don't draw the wall segments for the side of the room closest to the camera.
Anyway, that's enough to be getting on with, hope it's helpful and your project goes well.
Related
I am working on a tilemap based game in cocos2d in which the player moves in four directions and I have used four images for the movement of player for example left,right,top and down. My problem is that when my background map change its position or move to other position then my sprite does not change its position. Can anyone tell me how to move a sprite with the movement of background.
Use a CCNode to contain both the background and the sprites for your players. Instead of moving the background, move that node.
There are a couple of ways to handle tilemap based games, and neither of them are very convenient. One way is to leave your character in the center of the screen at all times and move the background underneath it. If your character moves 'right', you simply slide the background to the left, and vice versa. This will give the illusion that the character moves around the map, when in reality it remains centered. Under this paradigm you must remember to convert all detection / collisions into the world's space, and not just the screen space. If you don't convert everything, then your 'range' of collision / detection is limited to the size of the screen.
The second method is to pan the camera over the world. You still keep the character in the middle of the screen, but it actually moves around in the world, and the camera follows. This makes the most intuitive sense to me because it allows you to view the game world as you see the real world. It is also much easier to deal with collisions because the position of the character and the world 'just work' and don't have to be converted. The downside here is that Cocos2D doesn't make it easy to use CCCamera, and the documentation is a little thin in that respect.
In your particular case, it sounds like you have a CCLayer problem. If your character is inside the layer you are moving, it will indeed remain in the same place relative to the map (as you are describing). Instead, float the character in a different layer on top of the map.
You could use a scrolling Parallex and then add the sprite onto the same layer as the background. They will move together.
I have a BSP tree for depth sorting in an isometric game (I've tried countless other methods) it's seems to be close, but in my game I cannot split the assets. So, items that intercept the current plane, I simply add them to both the "behind" and "ahead" nodes (as suggested in http://www.seas.upenn.edu/~cis568/presentations/bsp-techniques.pdf).
When I traverse the tree (from lowest depth to highest), I only render the sprite once (the first time I approach it) but this seems to be placing some sprites too low in the display order.
Any insight on this would be greatly appreciated. This is in (mostly) C for iOS, btw.
Thanks in advance (and I try to answer some questions on here, but y'all are so darn fast!).
I don't think a BSP tree will help you sort out the (literal) sprite sorting issues prevalent in isometric tile rendering. Especially if you have archways like doors, there will always be a point where the character just pops under/above the archway. BSP trees help sort visible areas in a 3D world quickly, but an isometric map is a 2 dimensional, layered view where other effects like size of individual tile images play a larger factor than position in space.
The most common solution is in fact to split the assets in order to render individual parts of an archway (or any larger isometric object) either in front or behind the player, depending on each part's distance to the camera.
The alternative is to add blocking so that the player and other objects can never get too close to areas where sprite rendering normally fails due to sorting issues. But that only works if it is built-in from the start (size of tiles, size of world collisions).
I got a tiled map and I want to make lava lakes. I wish to have some kind of lava texture image on the background looping diagonally slowly. I could make it with four 960x640 images and move all of them diagonally etc. But when I do, a black/white line appears between each...
... and someone suggested me "CCParallax". I have never used it and am not sure if it really can achieve the effect I am seeking.
Also note that as the player moves on the map, the parallax will need to simulate that as well etc.
So my question is, what would you do for this effect? Four looping images or "CCParallax"?
CCParallaxNode is pretty limited because you can't specify endless parallax scrolling without modifying the class. It also doesn't quite fit your use case.
Using four 960x640 images is wasteful. Just to make some lakes underneath the background this is overkill and will negatively affect performance.
The solution depends a bit on how big the lakes are. For example, if these are just 1 or 3x3 tiles in size you could add a textured sprite underneath each lake. If on the other hand your tilemap consists mostly of a few narrow pathways while the rest is lava lakes, then you need a different approach.
You might want to try GL_REPEAT to repeat a single sprite's texture over a defined area. That allows you to use a relatively small texture, for example 64x64, that will be repeated over the rectangle you specified.
You can then modify the sprite's position each frame to scroll the texture. Every time the sprite has moved 64 pixels in horizontal or vertical direction, you subtract 64 pixels (sprite.contentSize.width) from the sprite's position to reset it back to its original state. That means the sprite will never move further than 64 pixels from its initial position in any direction but you still get smooth scrolling.
This question is very similar to that posed here.
My problem is that I have a map, something like this:
This map is made using 2D Perlin noise, and then running through the created heightmap assigning types and color values to each element in the terrain based on the height or the slope of the corresponding element, so pretty standard. The map array is two dimensional and the exact dimensions of the screen size (pixel-per-pixel), so at 1200 by 800 generation takes about 2 seconds on my rig.
Now zooming in on the highlighted rectangle:
Obviously with increased size comes lost detail. And herein lies the problem. I want to create additional detail on the fly, and then write it to disk as the player moves around (the player would simply be a dot restricted to movement along the grid). I see two approaches for doing this, and the first one that came to mind I quickly implemented:
This is a zoomed-in view of a new biased local terrain created from a sampled element of the old terrain, which is highlighted by the yellow grid space (to the left of center) in the previous image. However this system would require a great deal of modification, as, for example, if you move one unit left and up of the yellow grid space, onto the beach tile, the terrain changes completely:
So for that to work properly you'd need to do an excessive amount of, I guess the word would be interpolation, to create a smooth transition as the player moved the 40 or so grid-spaces in the local world required to reach the next tile over in the over world. That seems complicated and very inelegant.
The second approach would be to break up the grid of the original map into smaller bits, maybe dividing each square by 4? I haven't implemented this and I'm not sure how I would in a way that would actually increase detail, but I think that would probably end up being the best solution.
Any ideas on how I could approach this? Keep in mind it has to be local and on-the-fly. Just increasing the resolution of the map is something I want to avoid at all costs.
Rewrite your Perlin noise to be a function of position. Then you can increase the octaves (and thus the detail level) and resample the area at a higher resolution.
OK.
I'm in essense trying to make my own interpretation of the NES hardware, so I can make a game that ideally would resemble what a NES game would look like. I'm currently stuck with how to adjust how to draw the playfield to the video memory (back buffer).
BACKBUFFER
The NES had restrictions on the nametable, or backbuffer. For my example, the backbuffer is 256x240pixels big, or the size of one screen. If I drew this to the TV, it would fill up the screen perfectly. Now, if I drew this to the screen with an offset of X=5, the entire image would be shifted and would wrap around the screen.
For example.....
ORIGINAL, NO OFFSET: DRAWN WITH OFFSET OF X=5:
ABCDEFGHIJK GHIJKABCDEF
DRAWN WITH OFFSET OF X=-5:
FGHIJKABCDE
The screen is split up into squares 8x8 pixels each, totalling 32x30 rows and columns. (256x240 pixels). The offset is represented in pixels - not columns; so in theory, I could offset the screen by 5 pixels and every column would be shifted to the right by five pixels.
LEVEL DESIGN
My stages are made up of screens, containing data that is represented in 16x15 rows and columns, each by 16x16 pixels. This is to emulate how many NES games stored level data - each tile holds info about what should be in each 8x8 block.
E.g.:
AA
BC with A,B,C,D representing what 8x8 graphic should go where
Level design is represented by this as well, with each number being a different screen and - meaning nothing, null.
-----
-123-
---4-
--54-
-----
CHARACTER PLACEMENT
This is easy. I already know how I can determine which table, row, and column my characters are on based on their absolute positioning. I can also determine the relative positioning within the screen.
With this info, I can easily figure out which columns are to the left and right of the character, if any (if the character is at the left side of screen 1, thered be no more level left)
SO HERE'S THE QUESTION DUN DUN DUN
How do I draw my levels to the screen, so that they scroll from one to the next.
It would be relatively easy to draw one full screen at a time, and when the character gets to the edge just flip to another screen.
However, the problem I'm conceptually having is that I need to 'stream' the level data onto the screen. That, lets say the character moves 24 pixels to the right. The BG needs to move as well.
So, I need to adjust the scrolling of the backbuffer by 24 pixels. However, just scrolling alone will cause the screen to wrap over, diplsaying old portion of the level. So, while scrolling I need to make sure to draw new pieces of the level to the back buffer. But before I can do that, I need to figure out which tiles need to get drawn first. And if the person goes 24 pixels to the left, I need to redraw tiles onto the backbuffer and change the offset accordingly as well.
And let's not forget that if the character moves right and there's no more level data to be drawn, there should be no offset but instead the character gets closer to the side of the screen (instead of being centered in the middle of the screen via the X axis).
Basically, I just have a lot of different numbers and values stuck in my mind right now - trying to wrap my head around many concepts and they caused my brain to turn into goo. Anyone have any perspective on how I can approach this?
EDIT: Using VB.Net. C# is applicable as well ( I program in both)
The way the NES did it was with 4 name tables, each 256x240. When you scrolled one off the screen, the adjacent one would scroll on. To get "worlds" bigger than 512x480, you update the name table at the positions that are offscreen.
Generally, a cartridge would have a giant table in ROM with all of the level data, and would track the overall position with 1 or 2 RAM variables. Then when the game scrolled, it would update the RAM variables, use those to lookup the level data table and copy in the new level data into the parts of the name table that were offscreen.
So actually your back buffer should be 512x480, and you only show a 256x240 portion of it.
Have you looked at the disassembly for any NES games that have large scrolling worlds? I think a partial disassembly of Metroid is out there somewhere...
...yeah, found some docs at romhacking.net
Metroid disassembly; not real well commented but with a little effort it shouldn't be too hard to figure it out.
Another disassembly that is commented better.
EDIT: In the 2nd disassembly posted above, look in MetroidGameEnginePage.txt at the "SetupRoom" routine and the "DrawRoom" routine; also the routine at label LEB4D shows how the name table is updated in one case. Also look at the extensive comments above the "GetNameTable" routine. In general, a text search for "name table" throughout the document will get you lots more.
EDIT EDIT: Also at romhacking.net; the memory map for SMB might be useful.
I would set up a grid of image controls and load the levels from a database that stores what column and row each picture is relative to the level. Once the image that represents the game's character gets far enough to the right (you would have to store its location in some module level variables) of the screen you would load the next column of images (while shifting all of the other images one to the left and removing the first column).