I'm having way more fun doing 6502 asm again rather than actually making a game. :p

This seemed useful enough to share, a fast divide by 240 with modulo. Allows you to store scroll offsets in > 8 bits, and quickly get the scroll value and starting page. 12 bits gives you lots of room to work with.

Which classic era games use a map taller than 3840 pixels (16 screens), for which the 12-bit limit would cause a problem? I know the outdoor map in Jurassic Park for Super NES is about that tall. Metroid for NES is about twice that tall, but it's broken up into general areas that are in turn broken up into smaller sections 1 screen wide or tall. Each map in Blaster Master is 2048 by 2048 pixels tall.

The alternative technique, which I first learned about from tokumaru, is to have the scrolling engine store both the camera's Y position in world space and its Y tile position (0-29) in VRAM space.

I do indeed like to keep two versions of the Y scroll, one relative to the level map and the other relative to the name tables, wrapping around at 256 and 240, respectively.

I'm not a fan of redundant variables though, so the idea of being able to quickly convert coordinates from level space to NT space is very attractive! When I finally finish my platformer though, I expect to have a few really tall levels, so the 12 bit thing might be a problem.

Yeah, storing the scroll twice did occur to me as (probably) being more efficient, but as you say, not very DRY.

After sleeping on it, I think it's possible to get a full 16 bit divide with a little more work. Since the overflow happens on a multiple of 16, I think you can just add the upper nibble to the lower one before starting... Testing now.

Another problem I have with the limited number of bits is that I expect to have vertically wrapping levels, like is the case of some Sonic levels. In these cases, the vertical camera coordinate doesn't wrap when the level map ends, what happens is that the game starts reading/drawing mirrors of the level map, while the full coordinates are used for objects and such. The vertical coordinate only wraps after 65535, regardless of the height of the level map.

Metroid for NES is about twice that tall, but it's broken up into general areas that are in turn broken up into smaller sections 1 screen wide or tall.

It's not really broken up as far as the data structure is concerned. Metroid has one unified big map where all areas are laid out, though not every "slot" in that map is used. It works by:

1) Having a room ID for each room. Each screen slot points to a room ID. The same room can be and is extensively reused multiple times. Saves a lot of space for its travel length.2) Area switch objects - if you pass it (use the elevator), another set of room data and tiles will be used to "dress" the following rooms on the world map. This means multiple rooms with different layout across the different areas share the same room ID. While metroid doesn't expoit this, this half-intentional feature effectively means you can create position-overlapping rooms and criss-crossing corridors in layers even though the world map is a flat ractangle. Btw, you can also cross the boundary to get to the other side of the map if you wanted an effectively nonrectangular shape on your world map. 3) Palette switch objects - if you pass it the palette will switch for the next room - this puts on a facade of variation and helps the player to orient despite the monotonous levels.

As far as the game is concerned, you can fill the whole world map with one long tunnel with an endless seam; vertical or horizontal.

I think the similar engine used in kid icarus has some elevations up to 13 screens or so. between 13 and 20-21. I can't think of any other.Megaman 2: crashman - 14 screens high, i think.

Who is online

Users browsing this forum: No registered users and 8 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum