Isometric Game Programming - 7800

[+saxmeister]

I've been thinking about isometric games, especially the ones on platforms like the Speccy, that were high-res and monochromatic. I really think the 7800 could excel at games in this isometric (or 3/4) view. The 7800 didn't get many isometric games (Desert Falcon, the last Congo bongo demo I saw... anything else?) so I am taking that into consideration as a new development option.

 

I've never programmed an isometric game and I'm wondering  about the approach. I've seen the bitmapping demos that have been posted on here before and feel most comfortable plotting graphics in a bitmapped format (I grew up on a Commodore VIC-20) but I also think a tiled approach could work. But, I'm thinking mathematically about the whole thing and thinking that bitmapped with projection makes more sense, especially because character and NPC movements would have to take the view into consideration.

 

Any thoughts or suggestions from anyone (I know, like anyone has free time... ha ha ha)? I would hope that something could be developed that could be reused to create other games after this as well.

 

 

[+Muddyfunster]

I think this is an interesting angle (no pun intending..well maybe just a little one ) .

 

I looked at this last summer, experimentally, as I've never tried to write anything isometric before either and it looked like it could be fun. I personally do like these games and I'm thinking about titles like Sweevo's World, Head over Heels, Knightlore etc. The bit I needed to give a bit of thought to, and this is pretty much as far as I got last year, is around the draw order. By this I mean having the character or objects pass in front and behind each other at different positions etc. I think it would be doable but would need a bit of figuring out.

 

Where this is less of an issue is where the playfield is less "freeform" (or arcade like) and more fixed (strategy) like in games such as HeroQuest.

 

If an engine was built then you could of course reuse it to make more games. That's pretty much what the Ultimate did back with their "Filmation" engine back in the day  Linky

 

The engine developed over time to add new features like scrolling rather than being totally flip screen.

 

Would also likely work well in 320 modes with the nice crisp mono look.

 

 

[SlidellMan]

I found a video by Adam Younis that is pertinent.

Though you may have to do some paring down in order for it to work.

[+splendidnut]

If you're referring to the Congo Bongo demo that I made, the approach I used involved using rectangular tiles since the 7800, like the NES, is mainly a tile-based system.  The 7800 Maria chip is more geared towards sprites/objects than the tilemap layer, so that's something to keep in mind.

 

For Congo Bongo, the background for the screen is using indirect (tilemap) mode to do most of the background graphics (8x16 pixel tiles).  That by itself uses almost an entire 4k tileset.  Things like the water, the bridge, the trees, etc. are overlaid on top of the background layer using direct ("sprite"/object) mode using a different 4k tileset shared with the sprites.

 

For movement, I keep track of the world coordinates (X,Y,Z) then convert to screen coordinates when necessary.  The math needed for converting into screen coordinates is not too difficult (this is from the Congo Bongo demo):

screenX = LevelOfsX + mapX + mapY
screenY = LevelOfsY + (32 - spriteHeight) + mapY - (mapZ * 2) - mapX

I had the same thing in mind about developing a reusable engine, but got waylaid/distracted by other projects.

[+Muddyfunster]

30 minutes ago, SlidellMan said:

I found a video by Adam Younis that is pertinent.

Though you may have to do some paring down in order for it to work.

For something like the 7800, I'd probably stick to 4 facings.

[+SmittyB]

Having isometric (or dimetric as the case may be) games on the 7800 is something I've given a fair bit of thought about. Regardless of whether you go with tiled graphics or bitmaps the tricky bit is obscuring graphics where appropriate. As soon as you allow the possibility for something to be drawn in front of or behind something else based on its position you need a way of hiding the thing that's supposed to be behind it which isn't always possible.

 

In the below mockup I made years ago you can see there's no spot on the map where one of the people could stand behind part of the level (except for that one guy in the top middle, but it would be easy to stop him walking 'behind' the walls with generous collision checks). If someone were allowed to wander around in the purple area and walk under the bridge there would need to be a way to selectively chop bits off of the graphics which just wouldn't be feasible without bitmapping.

 

 

 

Providing speed isn't a requirement, the way I'd do it is bitmap the screen as either 320A or 160A. It would be possible to draw the static elements of the screen and then have the dynamic parts keep track of what they're overwriting each frame (to avoid redrawing the entire screen), or have a copy of the entire background and just restore from that which, while having more of an upfront RAM and speed penalty would make memory management easier, and you can just restore the screen in one go instead of walking back through each object to restore what it overwrote. There wouldn't be a reason why objects couldn't be drawn on top of the bitmap but read their graphics from it in order to have different colour palettes (albeit with a bit of spectrum-like colour clash depending on how it's done).

 

[+Pat Brady]

1 hour ago, saxmeister said:

I've been thinking about isometric games, especially the ones on platforms like the Speccy, that were high-res and monochromatic. I really think the 7800 could excel at games in this isometric (or 3/4) view. The 7800 didn't get many isometric games (Desert Falcon, the last Congo bongo demo I saw... anything else?) so I am taking that into consideration as a new development option.

 

I've never programmed an isometric game and I'm wondering  about the approach. I've seen the bitmapping demos that have been posted on here before and feel most comfortable plotting graphics in a bitmapped format (I grew up on a Commodore VIC-20) but I also think a tiled approach could work. But, I'm thinking mathematically about the whole thing and thinking that bitmapped with projection makes more sense, especially because character and NPC movements would have to take the view into consideration.

 

Go for it!

 

A Spectrum-style game should be doable in 320C or maybe even 320A — and without colour clash.

 

I'm curious what you mean by "bitmapped with projection." 7800 zones are horizontal. I suppose you could adjust horizontal positioning line-by-line during HBLANK (I haven't done anything like that myself).

 

15 minutes ago, SmittyB said:

Providing speed isn't a requirement, the way I'd do it is bitmap the screen as either 320A or 160A. It would be possible to draw the static elements of the screen and then have the dynamic parts keep track of what they're overwriting each frame (to avoid redrawing the entire screen), or have a copy of the entire background and just restore from that which, while having more of an upfront RAM and speed penalty would make memory management easier, and you can just restore the screen in one go instead of walking back through each object to restore what it overwrote. There wouldn't be a reason why objects couldn't be drawn on top of the bitmap but read their graphics from it in order to have different colour palettes (albeit with a bit of spectrum-like colour clash depending on how it's done).

 

Do you mean one bitmap that includes both static and dynamic elements? That seems like a lot of CPU work and a lot of RAM in this case.

 

To me the obvious way to do it is use separate MARIA objects for the dynamic elements and order the DLs corresponding to object depth. I *think* that ordering can be calculated fairly efficiently. Where this gets tricky is if the static screen has objects (meaning conceptual objects, like a boulder or a pillar, not MARIA objects) at different depths within one zone. Possible solutions to that: 1) separate MARIA objects for different depths of static objects within a zone (taking care to not run out of DMA time); 2) level designs that prevent this situation; 3) accept some clipping.

 

[+SmittyB]

31 minutes ago, Pat Brady said:

Do you mean one bitmap that includes both static and dynamic elements? That seems like a lot of CPU work and a lot of RAM in this case.

That's why I mentioned the speed, and the amount of RAM isn't an issue because a 256*192 bitmap is only 6K, so with 16K cart RAM that leaves plenty of space. The point of my old mockup was to see what something would look like using just a background layer and objects on top so I'm not saying it can't be done, just that everything has to be designed so that things can't go 'behind' the background whereas with bitmapping that's not necessarily an issue.

 

[+Pat Brady]

4 minutes ago, SmittyB said:

That's why I mentioned the speed, and the amount of RAM isn't an issue because a 256*192 bitmap is only 6K, so with 16K cart RAM that leaves plenty of space. The point of my old mockup was to see what something would look like using just a background layer and objects on top so I'm not saying it can't be done, just that everything has to be designed so that things can't go 'behind' the background whereas with bitmapping that's not necessarily an issue.

 

Understood.

 

Using the separate object approach I do think it is possible to arrange it so that sprites can go behind parts of the background. But it would obviously require some extra logic and probably a fair bit of thought about how to represent everything. And, to properly get 3 layers of depth per zone, which is very desirable for this type of game, you'd have to jump through some hoops to not run out of DMA time.

 

Brainstorming on your idea: with 16K cart RAM, a full-screen 320C bitmap would fill 12K. 320C provides 4 foreground colors. You could use 3 of those to draw different depths of static objects, and the other color for dynamic objects, and then it would be easy to decide, for each dynamic object pixel, which one goes on top. Might look good with the colors being slightly different shades of the same hue, lighter colors in front.

 

Or: use 1 MARIA object, all 4 colors, for the static objects. That bitmap could go in RAM or ROM, given sufficient ROM. Draw dynamic objects on top, in 320A or 320C, but put their bitmaps in RAM, and mask any pixel pairs that should appear to be behind a static object. Again, that's fairly easy to detect since the static object's color indicates depth.

 

Getting fancier, you could adjust the colors mid-screen so that lower zones have brighter colors. For example, in the screenshot in post #1, the background walls are entirely in the top half of the screen. So below that midline, there's no need for that color to be in the palette. You could shift the other 3 colors up in the palette and add another color for static objects at the very front. 320 resolution with 10 colors.

 

Bottom line: there are a lot of different ways to do this!

[The Usotsuki]

Doing it with tiles must have been possible, because the NES has Solstice...

[+saxmeister]

Solstice was one of my absolute favorite NES titles - especially for the Tim Follin soundtrack! That was the first time I had heard a British chip musician (I live in the USA) and the use of those lovely arpeggiated chords! I instantly fell in love with the sound. Oh, and that prog rock influence...

 

@splendidnut that is exactly what I was referring to in my earlier post.

Edited February 6, 2022 by saxmeister

[+Pat Brady]

6 hours ago, The Usotsuki said:

Doing it with tiles must have been possible, because the NES has Solstice...

 

Solstice presumably uses sprites to draw any element — even static ones — that can be in front of any other element, and background tiles only for elements that are always in back.

 

The 7800 equivalent would be direct mode objects for any element that can be in front of any other element, and character maps for elements that are always in back. That's definitely a good way to do it.

[RevEng]

3 hours ago, Pat Brady said:

The 7800 equivalent would be direct mode objects for any element that can be in front of any other element, and character maps for elements that are always in back. That's definitely a good way to do it.

I made a simple "occlude" demo a while back that worked along these lines. Any tile graphics that should be in front of the player are loaded into sprites. One could also just put another set of ram-backed tiles in front of the player, and update those tile/char indexes as needed, if DMA isn't going to be tight.

 

(js7800 link for the curious)

 

Occlude Sprite Demo (20200219).a78

 

[+saxmeister]

On 2/5/2022 at 6:34 PM, RevEng said:

I made a simple "occlude" demo a while back that worked along these lines. Any tile graphics that should be in front of the player are loaded into sprites. One could also just put another set of ram-backed tiles in front of the player, and update those tile/char indexes as needed, if DMA isn't going to be tight.

 

(js7800 link for the curious)

 

Occlude Sprite Demo (20200219).a78 32.13 kB · 20 downloads

 

@RevEng I have marveled at this since I first saw it. Such great work! Thanks for sharing.