I'm wondering if doing pseudo-3D graphics on the NES in the same fashion Tactics Ogre did for the SNES would be abordable. I have pretty much trouble to understand how their work on the SNES, everything looks to be diagonal-based, allowing tiles to have an actual Z-index. Speaking about quality (but not quantity), Tactics Ogre looks much closer to a PSX game than a SNES game.
Any ideas ?
I totally believe the NES can do games along the lines of Tactics Ogre (haven't played the game yet though, I've just seen some screenshots). The NES already has a few isometric titles such as Snake Rattle n Roll, Solstice...
I believe that the hardest part in building an isometric game for the NES is due to the low resolution of attributes (palettes applied to 16x16 pixel areas). When your view is 2D that is not much of a problem since most games are based on 16x16 pixel blocks anyway, but in isometric views, the level's blocks are not aligned to the screen's blocks, and a wall will often share the same 16x16 pixel area with a floor. If they use the same colors, it will look kinda dull, and if they use different colors the graphics can't be very "textured" as the little ammount of colors left for each are barely enough for a "plastic" kind of texture.
It surelly is easier on systems with multiple background layers, since one of them can hold the basic structure (floors and walls) and another one can hold the ornaments (as, I think, is done on Sonic 3D Blast for the megadrive) so you get a lot more colors.
Another issue is the number of avaliable tiles. Just as different types of things (walls and floors) share the same attribute blocks, they also share many tiles. So, you must have a tileset prepared for every combination of encounters.
Using MMC5 will surelly help with both problems. By using the ExAttribute mode we would have more attribute resolution and access to a bunch of tiles. It could never look as good as a SNES game, specially because the NES has only 4 BG palettes, in my opinion.
EDIT: Oh, of course, there are non-graphical issues too. Representing a 3D map can be very memory intensive. However, since most isometric games will not let you go under a floor (like in a tunnel, for example), the map can be a 2D array of heights, plus the types of walls and floors. Translating the 2D map to a 3D view could be a little tricky too, since we have little time to write to the screen.
Yeah, I was wondering it with both attributes and internal structure.
Tilesets could be a little problems, and the attributes will definitely be a bigger one. I think it is can be done by having some remniscent colors between BG palettes (black and another standardised color, such as grass green).
I didn't know about isometric NES games, I'll try them when I'll got time.
Snake Rattle n Roll does a pretty decent job producing an isometric view out of the NES, but the color limitations do show:
http://prezkennedy.org/modules/myalbum/photos/354.jpg
The megadrive got nice colorfull trees, while the NES got... uh... spiky... piramid... ah... things...!
Also, in the NES version the floor has the same color as the walls, when in the megadrive they are different, making it all prettier. And in the NES version you can see small color glitches here and there. This game looks nice, but I believe it is possible to do better.
I won't say anything about Solstice (wich looks very nice) because it seems to belong to another category... It is all set inside small rooms and is generally easier to design. I guess the focus here are the larger, outdoor maps... right?
Then there's Starcraft, which pretends to be isometric but isn't.
Yeah, I looked at those games. Solstice really suck, but it's graphics looks really nice, but they "cheated", because all rooms uses only one single palette.
Snakes'n'stuff looks graphically decent, but also the game itself suck (I don't understand your goal).
Scince it seems to be possible to have this style of graphics on the NES, my new question is now how. I think things are getting a LOT simpler if the height of a metatile can only be supperior or equal to the one just as its left and to the one just as its right. That would remove some dexterity from the game, but I thing that would simplyfy a lot the engine, making stuff like having a metatile half-hidden behind the one previous to it impossible.
Now how to process to maze it to the screen ? Having a normal 2D map plus a Z-index of all metatiles relative to the ones at its bottom and at its right would probalbly work pretty well. But mazing the wole stuff on the screen seems nerly impossible both at the tileset level and at the nametable level. And, how make a metatile looks higher than the other one ? Put some "cliff" between two seems the correct answer, but how to handle that in 2D nametables ? And I don't even mention attribute tables. Also, for a strategy game, it would be fear to fetch unit's graphics to BG when they doesn't moove, to avoid having too much sprites on the screen. This will make stuff harder, but I think the result would be worth it. I mentionned that just for cusiosity, but if I would be able to pass over all problems and do it, I'd be ready to code a game using that.
I don't think we should use the concept of "right" and "left". I think the map has to be stored as any 2D array would, and be converted to 3D at drawing time, like this:
I propose that each position in the array holds the type and the height of that block. Then, we draw the map from back to front, begining at the top right corner (3, 0) of the 2D array, wich will be at the very top of the 3D view. then we move to the next block, at position (3, 1) in the 2D array, and update the drawing coordinates a bit to the right and a bit down and draw it as high as it is, overlaping the column behind it if needed. And we go through all the map like this.
The hard part will be the scrolling. Suppose you rendered the initial view, of the place where the level starts. Suppose there are some large columns behind the player, hiding anything back there (green thing is the player):
Then the player goes UP, and we have to decide what to draw over there. Should we read the map from the wall back until we find the first thing that shows? That could be slow... You see, this is the hard part, drawing what's behind the wall without destroying it. Drawing the full view is easy, the hard part is to draw it little by little as has to be done on the NES.
Since the columns can have any height, there is no way to compute what should be where on the screen. We can compute where a height 0 block would be. maybe that is the way: When the screen goes up and we have to draw what's behind the wall, calculate what position in the map represents that space, supposing a height of 0. Then render from there to the wall, only if the columns are higher than the wall...
Well, still sounds too complex... I'll think about it for a while and maybe I'll have any ideas...
I was saying to not allow any tile to have a Z index lower than the tile just below it or the tile at its left would correct the wall problem : If there is a wall, there would be no "behind" the wall, because the engine simply wouldn't allow it. Quite restrictive, but that would still give a 3rd dimention to the game and allow the player to battle trough mountain, even if there would not be "hidden parts" in the field. Anyway, "hidden parts" aren't profitable to the player (unless he can rotate the map), scince he cannot see the whole hole. To allow the player to rotate the map means have a 3d polygon-based engine, so wihtout any rotation hole can only be small.
However, a such wall could represent a cliff or a wall that marks the end of the map.
Don't forget using the PPU's VRAM ($0000-1FFF) gives you almost direct access to the video buffer. If you set the 960 tiles to 0, 1, 2, 3, 4 etc. in the pattern table then you have 2-bit colour access.
WedNESday wrote:
Don't forget using the PPU's VRAM ($0000-1FFF) gives you almost direct access to the video buffer. If you set the 960 tiles to 0, 1, 2, 3, 4 etc. in the pattern table then you have 2-bit colour access.
The trouble is, the PPU can only address 256 background tiles - if you want to use more per screen, you need to either do carefully timed bank switches OR use the MMC5 (which generally also restricts you to CHR ROM).
Exept that the BG pattern table is limited to 256 tiles (assuming I want to use the other one as well) and that, when scrooling, it would be WAY too slow to calculate each pixel in VRAM.
However, I think VRAM can calculate tiles given from two diagonal halves dinamicly for each stage, that *may* be usefull to gain tile spce. However, I'm not sure about how to handle tilesets with such graphics.
SNES games definitely have a single palette and priority control per tile, making a great advantages (another advantage is that palettes are 16-colors and no 4-colors, so multiple color scales are possible).
Holding attribute with an isometric view is definitly difficult (but not impossible). Assuming that each tile have to be square, but rotated, that make a metatile using either 4 tiles fully and 8 tiles half that are arround the full tiles (large) or 1 tile full and 4 tiles half with smaller gird.
Handling attribute with the large gird would be pretty comfortable. The 2x2 square that sure is the metatile is its proper color, and about the others, I think there would be a "default" color for tile border (I'm not sure it would work fine). With the smaller configuration, holding attribute pointlessly is impossible, but holding them grossierly is abordable.
Bregalad wrote:
Exept that the BG pattern table is limited to 256 tiles (assuming I want to use the other one as well)
You could overwrite the areas in VRAM to produce more tiles.
WedNESday wrote:
Bregalad wrote:
Exept that the BG pattern table is limited to 256 tiles (assuming I want to use the other one as well)
You could overwrite the areas in VRAM to produce more tiles.
Even if you consume the Sprite tiles as well, you still get only 512 tiles, which is not enough for the entire screen. Remember, you can NOT update CHR RAM during rendering - the only thing you can do is bankswitch it.
Sure but 512 tiles could be enough. Especially if you only used part of the screen. Super Mario Bros. is a good example, the top and bottom of the screen is either blank of repeats the ground over again.
hum...
Reducing the screen could help, but CHR RAM is not the way. If RAM is used, the game will run at, like, less than 1 frame per second! And we can't use the whole 512 tiles for the background 'cause we'd have nothing left for sprites! Unless you want to do an MSX kind of game you can't just draw the sprites to the BG.
I say MMC5 is the way to go. ExAttribute mode will give access to enough tiles, and improve attribute resolution, wich I think is the bigger problem here. 256 tiles would be enough for a fairly good isometric game though, if you keep the design somewhat simple (not many slopes, not many types of surfaces, etc).
EDIT: Actually, I think that the MSX had sprites... it was the Spectrum that didn't, right? And then it was just a mess because the "sprite" had to use the same color as the background or the color of one would spill to the other... anyway, it was just a mess, real ugly.
Quietust wrote:
Even if you consume the Sprite tiles as well, you still get only 512 tiles, which is not enough for the entire screen. Remember, you can NOT update CHR RAM during rendering - the only thing you can do is bankswitch it.
Isn't the CHR /A13 (CHR /CE) is inactive during the image rendering? by replacing the RAM with extremely fast one (with 15ns or so) would allow to write to CHR RAM during the HBlank perioid?
Does MMC5 have the ability to bankswitch vram away so it's writable, then switch it back?
sepi wrote:
Isn't the CHR /A13 (CHR /CE) is inactive during the image rendering? by replacing the RAM with extremely fast one (with 15ns or so) would allow to write to CHR RAM during the HBlank perioid?
Such notes doesn't help at all because :
- They need to modify the hardware to work
- I DO need tiles for sprites
- This makes BG scrooling impossible (or at one frame per second, which isn't reasonable at all), and it's not what I want to get.
Okay, MMC5 with ExGrafix would help, because of infinite tileset and tile-limited palette attribute.
Quote:
Does MMC5 have the ability to bankswitch vram away so it's writable, then switch it back?
I didn't understand the meaing of this senstence, but MMC5 can only run CHR ROM.
However, even with one-tile limited attribute, that still doesn't allow me to change attributes diagonally, this only allow me to have one-tile precision instead of four-tiles precision. Color glitches would definitely be less horrible with MMC5, but that doesn't help me to know how to planify tilesets (which are, okay, indefinite with MMC5) or how to planify nametables.
I think the map should first be converted in 2D in RAM, then drawn on the screen. That's the only way to make the screen scolling and have a game decently working with isometric graphics.
But how convert a map from isometric to 2D ?
Bregalad wrote:
But how convert a map from isometric to 2D ?
You do it at compile time. Go buy
Starcraft and play with its map editor.
Bregalad, you said that, for practical reasons, a column shouldn't have anything smaller than itself behind it. But then all the maps would end up looking like this:
And that could get pretty boring. What will all the levels be about? Climbing mountains? I know that clipping the sprites so that they can go behind blocks can be a pain, but there must be a way. Even if we clip at the 8x8 tile level, as happens in
Sonic 3D Blast sometimes (when entering tunnels or with the loops). However, I think sprite masks could do the job, if one is feeling generous about sprites.
Think about it... if there is such a limitation, simple things like this would not be possible:
We should just play isometric games to get some ideas... I'm not saying to copy anything, it's just so we can get a light on the attribute thing...
Dwedit wrote:
Does MMC5 have the ability to bankswitch vram away so it's writable, then switch it back?
He means mapping VRAM (writable) or VROM (read only). ^_^;;
Bregalad wrote:
This makes BG scrooling...
Scrolling not scrooling. No offense whatsoever but it cracks me up when you do that! lmao
tokumaru : You got well the limitation I was thinking about. Do you really think it would be that boring ? With just green blocks it may look boring, but with more complex backgrounds and much, much larger maps with threes, rivers, etc... on it, I don't fell it would be boring.
There is a lot of problems with a block being behind another one.
Look :
Doesn't that green surface looks both to be above the others (as you would it to be), if you look from the bottom to the top, or look to be the one "behind" the one you would it to be, if you look from the top to the bottom ? In that case, the two yellow cliffs would "hide" this particular block, and in the case you would show, the block that is higher than the others mask 100% of the block behind it. That is really anoying in games when its happen, making me prefer 2D games, simply because I like to see everything clearly on screen. However, if that block would be twice less high, one small portion of the one behind would still be visible, making thing looks a bit clearer.
So the ideal would be to allow only a "behind" block to be one half of the base map's lenght lower than the one in front of it, making confusion impossible, and give to the game a bit of depht. That's what I think Tactics Ogre does. If you want more, you should play on a 3D system that is able to rotate the map.
And please let me know how did you draw those samples blocks, else I'll get upset. I really don't understand how that works.
For sprite clipping, it would just need some sprites with higher priority but backgroudn bit set. That would work fine, but the 8-sprite limitation can get all things to gabrage.
Edit : The problem I mention above appears in Tactics Ogre
That blocks seems to the user bo be non-existing
since this one is higer, and has the same on-screen position
Quote:
And that could get pretty boring. What will all the levels be about?
It worked well for
one particular game in the 1980s. :)
blargg wrote:
It worked well for one particular game in the 1980s.
Sure it worked well but that doesn't satisfy everyone, especially not in this post. IMO, Qbert was rubbish anyway, and the NES deserves much better.
Yeah, but with much, much larger maps and combination it could work just fine, or am I wrong ? Also, the blocks don't HAVE to be higher than the other ones. It is possible to put long flat aeras between cliffs, and additional background else than grass, to make a pretty decent game with an isometric system.
Actually, the first level of Snake 'n' Roll DOES have that limitation. Scince I'm unable to even know how I'm suposed to get the second level, I cannot say about the rest of the game.
Bregalad wrote:
Look :
Yeah, I know what you mean. There is no way to tell if that square belongs to the top of the block or to the floor behind it...
Quote:
However, if that block would be twice less high, one small portion of the one behind would still be visible, making thing looks a bit clearer.
Sure, sure. But that will be one more issue for our already existent attribute problem. Unless half-sized blocks used the same palette as the block behind, then there would be no attribute problem. Smaller blocks do add to the visuals, that's for sure.
Quote:
And please let me know how did you draw those samples blocks, else I'll get upset. I really don't understand how that works.
MSPAINT all the way. I just used basic blocks like these:
In fact, these blocks show very well what we're dealing with. With blocks this size, we'd have to be prepared for some floor/floor, floor/wall, wall/wall encounters, but not too many. Of course it will get more complex when you add slopes, half-height blocks, etc.
A while ago I was thinking of making an isometric game, and drew some tests images like this:
The structure of the blocks (just flat blocks, better textures were to come) here is a bit different from what I proposed above. I did it like this so that when black lines crossed there would be no weird visual effects, but this method requires some extra tiles, beyond the ones presented before.
Quote:
For sprite clipping, it would just need some sprites with higher priority but backgroudn bit set. That would work fine, but the 8-sprite limitation can get all things to gabrage.
Yeah, that's exactly what I meant by "masks". The sprite limitation is a pain.
Quote:
Actually, the first level of Snake 'n' Roll DOES have that limitation. Scince I'm unable to even know how I'm suposed to get the second level, I cannot say about the rest of the game.
When you said that I spent some time thinking and figured you were right. But then I checked and there seems to be some hidden areas in there:
http://www.nesstuff.kit.net/snake2.png I took the image from the web and circled one of the hidden areas. I don't know if they're accessible or not, since I haven't played this in a while.
EDIT: Yeah, I played the game and it turns out these are not hidden areas, but areas with angled walls, so the player can't go there and that makes sense. HOWEVER, the player can go behind blocks when inside the water. In the case of this game, it is easy to implement this if the water's color is color 0.
isn't marble madness also isometric?
danimal wrote:
isn't marble madness also isometric?
Yes it is, but more in that "puzzle game kinda way", as the game blargg pointed out. A game that is just "blocky" for the sake of it is very different from a game that wants to simulate a real enviroment in a pseudo-3D way. But, due to the low-end hardware we have we end up having to represent the world with blocks, but a more realistic world nonetheless.
WedNESday wrote:
Scrolling not scrooling. No offense whatsoever but it cracks me up when you do that! lmao
Haha... Well, I, like Bregalad, am not a native english speaker, and I don't know about him, but I always think of the word "scrooling" before "scrolling", and have to pay attention to this when writing here.
Quote:
But, due to the low-end hardware we have we end up having to represent the world with blocks, but a more realistic world nonetheless.
I for one enjoy older games due to their blocky world. To me it's not a limitation in recreating the "real" world, it
is the basic structure of that world. The same goes for pixel art being seen as an approximation of how the characters really look; to me it is how the characters look. The somewhat abstract nature of the worlds is one of their appeals. I'll take Mario over a 3D game any day.
tokumaru wrote:
But, due to the low-end hardware we have we end up having to represent the world with blocks, but a more realistic world nonetheless.
Anyway, the goal of a game isn't to be realistic, else you wouldn't be able to use magic, the ennemy would not make his stages in a way you can get trough, etc, etc... People talking about relistic games are just contradicting themselves.
Quote:
You do it at compile time. Go buy Starcraft and play with its map editor.
You can do it at compile time, but the real 3D map should also be here for collision and sprite positionning. So you can either code both 2D map and 3D map in ROM, hoping that you won't create bugs so both won't correspond, or do a programm that mazes a 3D map in 2D.
For now I think I just have to play with tile layer and try to have isometric graphics, and think if this is doable in a NES game or not. Maybe I should wait to code on the SNES to think about isometric games, because SNES have tiles precision palettes and layering effects. I can have up to 4 BG layers if using mode 0, but then the BGs have only 4 colors per tile.
blargg wrote:
The same goes for pixel art being seen as an approximation of how the characters really look; to me it is how the characters look.
In the player's viewpoint, I agree, because you'll always keep how the characters looks in games in mind, and no matter how is the real artwork. But in the designer's viewpoint, he will design their character on paper before doing them in pixels, and so the character will never look just as he wanted it to be, so it's approximation.
I found a wonderfull isometric game, "Energy Breaker" for the SNES. The game looks just awesome !! Unfortunatly, it is in japaneese and I undestand nothing to battle system.
The games use the SNES' multi-BG feature for layering system, so yeah, having an isometric game on the NES would definitely be very tough.
Wow... everyone missunderstood what I said... =)
blargg: I wasn't taking away the merit of older games at all. I'd also take them over 3D stuff any day. I takes a lot of creativity for a 3D game to captivate me (I liked Shadow of the Colossus recently!). Maybe I used the wrong word, "realistic", when I meant "recognizable" (wich also responds Bregalad).
When was the last time you have been to a blue and yellow "mountain", with marbles rolling from the top of it? Never, I'd guess. But what about an open field, with GRASS, TREES, BRIDGES and other stuff that actually exist? That was my point.
Bregalad: I'm sure the SNES is much better equiped to run a game like this. But isn't the challenge half the fun in doing a game? At least I think so... If it gets all too easy, what is the point? You'll just make a game like tons of others. You wouldn't be pushing anything "to the limit", as the thread title says. =)
tokumaru wrote:
Bregalad: I'm sure the SNES is much better equiped to run a game like this. But isn't the challenge half the fun in doing a game? At least I think so... If it gets all too easy, what is the point? You'll just make a game like tons of others. You wouldn't be pushing anything "to the limit", as the thread title says. =)
Yeah, sure. But doing it on the SNES wouldn't cut the challenge at all. Actually, doing an isometric game on the SNES instead of the PSX is already a challange. So doing an isomertic game on the NES is even more challenging. Push the system to its limit is good, but if it is the limits of the system that push your ideas down, that's bad. I now tried to make isometric graphics with tile layer, and it looks pretty easy to do. Scince the map will be 3D, that will impressive the player, so the graphics themselves doesn't have to be outstanding (at least not on the NES). I'll have only a few different metatiles, including grass, water, etc... The hard part will be to handle all possible combinations. About palettes, I've almost fixed the problem, using an MMC5 isn't even needed. I got 4 main metatiles : grass, water, stone and earth (variant of them could exist). So I have 4 combinations of palettes that works with every combination of metatiles exept grass&water, which I'll exclude. I think I just have to design the game without having adjacent tiles of grass and water. That will also simplyfy the tileset, which should include combinations of every metatiles together with every "cliff" possible.
One last thing !
I'm almost sure that convert a map from 3D to 2D in software could cause sloweowns and graphical glitches, because 256 tiles really isn't enough to store all combination of an isometric gane (if supposing I'm not using any MMC5). However, having a map direcly stored in 2D can fix all theese problems, and it would also be stored in 3D for collision and gameplay calculations. So the limits of the NES wouldn't show too much, scince tile combination can be deleted and avoided when design map without risking glitches, and the game wouldn't look weird. However... both maps have to mach !
About block behind, I think that you were right, tokumaru. It is lazy to want avoid that, especially if storing maps in both 2D and 3D. What do you think ?
Bregalad wrote:
However, having a map direcly stored in 2D can fix all theese problems, and it would also be stored in 3D for collision and gameplay calculations. So the limits of the NES wouldn't show too much, scince tile combination can be deleted and avoided when design map without risking glitches, and the game wouldn't look weird.
I had never thought of storing 2 maps for an isometric game before this discussion started. I seems a very good idea. But I can't avoid thinking it will eat a lot of ROM to define the 2D representations of the 3D view, and the level may end up beeing too short because of it. I think the levels in
Snake Rattle n Roll are ridiculously short, for example.
Quote:
However... both maps have to mach !
That is easy to guarantee if you have your level editor handle this. Since a PC has virtually no limits when it comes to processing stuff (and the fact that an editor doesn't need fluid scrolling, for example), the level could be designed the optimal way, with the 2D height map. Then, when saving the level, it would render a 2D map of the 3D view of it, for use with the game engine in 6502 asm code.
Quote:
About block behind, I think that you were right, tokumaru. It is lazy to want avoid that, especially if storing maps in both 2D and 3D. What do you think ?
Yeas, sure! Having a 2D map really helps in this case. Since the worls is already rendered, you only have the player's (and other objects?) coordinates to translate to 3D, wich is not very CPU intensive. But how would you know the player is behind anything? Using the 2D map? Maybe looking at it diagonally will tell if there is anything in front of the player.
Quote:
Yeas, sure! Having a 2D map really helps in this case. Since the worls is already rendered, you only have the player's (and other objects?) coordinates to translate to 3D, wich is not very CPU intensive. But how would you know the player is behind anything? Using the 2D map? Maybe looking at it diagonally will tell if there is anything in front of the player.
Yeah, I don't think it would be hard doing so. Scince tilesets can be customizable and the map can be 3D, this fixes all problems. Thanks everyone.
tokumaru wrote:
...(and the fact that an editor doesn't need fluid scrolling, for example)..
Do you really need fluid scrolling? It'd be nice to have, but there also exists the option of having transistions when you hit an edge of the screen, ala Zelda or whatever. That could make things easier for you. You can also refer to Deadly Towers (NES)... It's got scrolling within each scene, but the scenes are pretty small and always soon have a transition when you walk through a door or past the edge. Actually, they use some isometric pseudo 3D stuff too.. though theirs is simple and there are a lot of other examples of that kind of thing.
augnober wrote:
Do you really need fluid scrolling? It'd be nice to have, but there also exists the option of having transistions when you hit an edge of the screen, ala Zelda or whatever.
I think scrolling adds a lot to a game. I guess it helps to keep the "action" mood going. Since it's Bregalad's project, it's his call, but for me scrolling is almost always mandatory.
Quote:
That could make things easier for you. You can also refer to Deadly Towers (NES)... It's got scrolling within each scene, but the scenes are pretty small and always soon have a transition when you walk through a door or past the edge.
Yeah, unless you use some clever encoding (not necessarily compression) of the 3D maps they can get really big, wich will not allow fluid scrolling for much long.
Quote:
Actually, they use some isometric pseudo 3D stuff too.. though theirs is simple and there are a lot of other examples of that kind of thing.
I don't know if this game can be called isometric, though. I believe the word "isometric" refers to a view that's been rotated 45 degrees and lacks perspective, having the lines of the blocks measure the same. That's something I read, I don't know how accurate that is.
The game definately uses some sort of pseudo 3D, but only part of the view is angled. Doing it that way is easier than the real isometric way.
tokumaru wrote:
The game definately uses some sort of pseudo 3D, but only part of the view is angled. Doing it that way is easier than the real isometric way.
Yeah, you're right. It's kind of different than isometric.. There's mostly just some perspective illusion. Anyway, it has some things in common. You can see what they do on the perspective edges. They just have a divided tile and limited colours. You can see the colour schemes in the levels are pretty limited.
augnober wrote:
Anyway, it has some things in common. You can see what they do on the perspective edges. They just have a divided tile and limited colours. You can see the colour schemes in the levels are pretty limited.
Yes, from the technical side, this kind of view also presents a lot of the issues related to isometric views, but a little less since one of the walls is still aligned with the screen, and with isometric stuff nothing is aligned with the screen, everything is rotated, X, Y and Z.
Also, this kind of view is not as good looking as isometric ones, in my opinion. Isometric is more believable, this one looks a bit distorted, don't you think?
Deadly Towers, Earthbound Prototype, and Earthbound are in what is called
oblique projection.
tepples wrote:
Deadly Towers, Earthbound Prototype, and Earthbound are in what is called
oblique projection.
I've never seen the Earthbound examples and I didn't read into the oblique projection links beyond looking at some little diagrams, but I think Deadly Towers doesn't qualify as oblique projection since the depths lines can converge rather than just being parallel. They happen to all be 45 degrees, but because they use both angles instead of just one, they would converge.. so it's a perspective projection rather than orthogonal. (ah, I don't even care -- just trying to correct it for the sake of it)
Anonymous wrote:
I've never seen the Earthbound examples and I didn't read into the oblique projection links beyond looking at some little diagrams, but I think Deadly Towers doesn't qualify as oblique projection since the depths lines can converge rather than just being parallel.
Both games have both modes:
Figure 1: EB and DT areas using faked perspective projection.
Figure 2: EB and DT areas using oblique projection.
I like isometric stuff better. The bottom screenshots for these look good, but when the lines converge it looks very ugly. My brain refuses to see those as believable enviroments. DT looks just plain ugly and I would never believe that the carpet from the EB shot is really on the floor.