Actually making progress: tricked out metasprite routine

[Drew Sebastino]

I didn't think I had it in me, but apparently I do. (Press A to go to numbers, and B to go to letters)

Vram Engine V2.zip

(237.42 KiB) Downloaded 123 times

Just so you know, what's going on here is that the vram engine detects that the requested frame isn't the same as the current frame, so it goes and follows the linked list of the current frame, setting each slot in vram to be #$0000, which means it's empty so it can be overwritten. Then, the requested frame is uploaded to where it'll fit, and because the beginning of vram is now empty (in this case, because there are no other objects except the one) it uploads the tiles there.

I originally had some trouble, because the last tile in a frame kept getting overwritten, and that was because I then realized that because the last entry in the frame doesn't lead to anywhere, it stays #$0000, which means it's empty, not that it points to the beginning of vram (which it doesn't, #$0002 does, as the table is offset by -2). Luckily though, that was an easy fix.

What I don't get, however is if you disable the delete slot feature I implemented, (comment out delete_vram_loop, but not delete_vram) but have it to where it thinks that are no frames of that kind, (so the vram available to sprites is completely filled) then this happens:

SNES VRAM 4bpp.png (1.59 KiB) Viewed 3244 times

Yeah, I have no clue what's going on there... What's interesting is that the tile number is still correct for the sprites, (so they appear blank, because vram is blank there) it's just that the actual tiles are wacked. Every time I'd alternate between A and B (which created that pattern in vram) instead of going forward, it seemed to overwrite itself in that weird way. I don't know if this is the vram engine's fault, or the tile uploader's, but I'll investigate.



When I find out how to fix that, I wonder what I'll do then... I'll probably try and get a tilemap updater created for whenever the level scrolls. I also want to try and find a way to have it to where new tiles are uploaded for BGs whenever the level scrolls, but I don't know how I'm going to accomplish this. It'll be a lot more hardcoded than objects, that's for certain.

Edit: Wow, the aforementioned problem was caused by me making my "VramAddressToTranferAddressTable" incorrect. Here's the correct table, for anyone who cares:

Code: Select all

VramAddressToTransferAddressTable:
  .word $0000,$0020,$0040,$0060,$0080,$00A0,$00C0,$00E0
  .word $0200,$0220,$0240,$0260,$0280,$02A0,$02C0,$02E0
  .word $0400,$0420,$0440,$0460,$0480,$04A0,$04C0,$04E0
  .word $0600,$0620,$0640,$0660,$0680,$06A0,$06C0,$06E0
  .word $0800,$0820,$0840,$0860,$0880,$08A0,$08C0,$08E0
  .word $0A00,$0A20,$0A40,$0A60,$0A80,$0AA0,$0AC0,$0AE0
  .word $0C00,$0C20,$0C40,$0C60,$0C80,$0CA0,$0CC0,$0CE0
  .word $0E00,$0E20,$0E40,$0E60,$0E80,$0EA0,$0EC0,$0EE0
  .word $1000,$1020,$1040,$1060,$1080,$10A0,$10C0,$10E0
  .word $1200,$1220,$1240,$1260,$1280,$12A0,$12C0,$12E0
  .word $1400,$1420,$1440,$1460,$1480,$14A0,$14C0,$14E0
  .word $1600,$1620,$1640,$1660,$1680,$16A0,$16C0,$16E0
  .word $1800,$1820,$1840,$1860,$1880,$18A0,$18C0,$18E0
  .word $1A00,$1A20,$1A40,$1A60,$1A80,$1AA0,$1AC0,$1AE0
  .word $1C00,$1C20,$1C40,$1C60,$1C80,$1CA0,$1CC0,$1CE0
  .word $1E00,$1E20,$1E40,$1E60,$1E80,$1EA0,$1EC0,$1EE0

That's a relief though, I was really concerned for a minute!

[psycopathicteen]

You can have a linked list for empty slots, and when your clearing a metasprite, you can link the last sprite to the beginning of the empty slot list, and use the first sprite as the new entry point for the empty slot list.

[Drew Sebastino]

This is actually really random, but I got to looking at BG layer information, and I saw how priorities are arranged for BG layers. What's odd though is looking at the information for BG 3 in mode 1:

The background priority is (from ‘front’ to ‘back’):BG3 tiles with priority 1 if bit 3 of $2105 is set
Sprites with priority 3
BG1 tiles with priority 1
BG2 tiles with priority 1
Sprites with priority 2
BG1 tiles with priority 0
BG2 tiles with priority 0
Sprites with priority 1
BG3 tiles with priority 1 if bit 3 of $2105 is clear
Sprites with priority 0
BG3 tiles with priority 0

This seems to imply that it's impossible to have BG3 between BG1 and BG2, which I know isn't the case.

Now, the more relevant question, which is is it impossible to efficiently update a tilemap on its sides using DMA? I mean, The data isn't continuous like it is on the top or the bottom, so you can't just update it all in one shot.

You know, I think this discussion has already been had, but how would you have the tilemap for a level out in rom? I think I'll have it to where instead of acting like a bunch of 32x32 tilemaps like the system does, it'll just be one giant tilemap instead of a bunch of 32x32's put together.



It appears a new post came in while I was writing this...

You can have a linked list for empty slots, and when your clearing a metasprite, you can link the last sprite to the beginning of the empty slot list, and use the first sprite as the new entry point for the empty slot list.

What do you mean by clearing? Anyway, I think I'll worry about optimizing this more later when I run into CPU time problems, otherwise I'll just end up freaking myself out.

[Nicole]

This seems to imply that it's impossible to have BG3 between BG1 and BG2, which I know isn't the case.

You know it isn't the case? How exactly?

is it impossible to efficiently update a tilemap on its sides using DMA?

No, it's possible to change bits in $2115 (VMAIN) to change how the VRAM address auto-increments. By doing that, you can have the address increment by 32 words each write, allowing you to efficiently update columns.

[koitsu]

This is actually really random, but I got to looking at BG layer information, and I saw how priorities are arranged for BG layers. What's odd though is looking at the information for BG 3 in mode 1:

The background priority is (from ‘front’ to ‘back’):BG3 tiles with priority 1 if bit 3 of $2105 is set
Sprites with priority 3
BG1 tiles with priority 1
BG2 tiles with priority 1
Sprites with priority 2
BG1 tiles with priority 0
BG2 tiles with priority 0
Sprites with priority 1
BG3 tiles with priority 1 if bit 3 of $2105 is clear
Sprites with priority 0
BG3 tiles with priority 0

This seems to imply that it's impossible to have BG3 between BG1 and BG2, which I know isn't the case.

See attached image for ordering, including how OBJ (sprites) fit into it. Yeah, this one is a little hard to understand, but it should help explain how and "where" BG3 (and OBJ!) fit into the "render layering process" based on if priority bits are set for BG3 and/or in each individual sprite.

[Drew Sebastino]

You know it isn't the case? How exactly?

Look at the factory levels and the cliff side levels in DKC3. Those are the examples that pop up immediately.




Having BG3 in the middle is really useful for things like silhouettes:

No, it's possible to change bits in $2115 (VMAIN) to change how the VRAM address auto-increments. By doing that, you can have the address increment by 32 words each write, allowing you to efficiently update columns.

Oh, cool. The one problem that would still remain though would be the offset for the source, unless there's a way around this too.

[Nicole]

I looked into it, and yes, BG3 does end up getting rendered in the middle. How it does it is pretty clever, though; what it does is take advantage of the subscreen and color math.

Taking DKC3's factory levels as an example, only BG1 (the foreground), BG3 (the back wall), and the sprites are on the main screen. So, with no color math, the backdrop color would show through the windows.

However, it then has that backdrop color set to black, puts BG2 (the sky) on the subscreen, and uses color math to add the subscreen to only the backdrop layer. The effect is that wherever the backdrop appears, BG2 will appear instead.

[Drew Sebastino]

So I guess based on that, you can't really have a transparent BG3 in the middle? Well, you can't do everything. Also, can BG2, which is in the background, have color 0 showing behind it and not affect BG3? Actually, no, you're saying that BG2 has to use color math, so they make color 0 black and just add the BG layer over it. Can it not be opaque? I'm not entirely sure how the whole main screen and subscreen thing works, but it seems like it's just two screens that go over one another for color math. I know you can't have two color math things over one another and have the effect show through both of them, but can you also not have two different types of transparencies going on at the same time?

But yeah, I know this sounds ridiculous, but I suppose for updating a tilemap on its sides, you could have a sideways large tilemap in rom. That, or you'd copy the data into a small buffer using the CPU, and then DMA the data from that small buffer in ram to vram. That, or you could just copy the data without DMA in the first place. I suppose you could break it up to where you're only partially updating the sides of the tilemap per frame if you're not scrolling at over 8 pixels per frame (or 16, depending on the BG tile size). How do you guys approach this?

[tepples]

But yeah, I know this sounds ridiculous, but I suppose for updating a tilemap on its sides, you could have a sideways large tilemap in rom.

Haunted: Halloween '85 does exactly this. Its maps are stored as a list of columns compressed with a mixture of RLE and a predictive scheme. Each frame, if the camera code deems it necessary, it decompresses a single column of the nametable to a buffer in VRAM, and then it schedules a copy to take place during the next vblank. Many other games' metatile expansion is column-oriented as well.

[Drew Sebastino]

I actually meant having two maps of the same thing, one of rows, and one of columns. I don't know if that's what you meant, but for what I'm doing, I want to be able to scroll both vertically and horizontally. That is kind of stupid though, I'll just have a 128 byte buffer for the sides of the screen where I'll upload the tilemap there with the CPU, and then DMA it, as apposed to with the top of the screen where I won't copy it to a buffer and will instead just go from rom straight to vram.

I guess for handling the camera, you'd have a "CameraX" and a "CameraY". There will also be a previous camera X and Y, and depending on if the camera variable is bigger or smaller, the tilemap will be updated on the right or left, top or bottom. I also want to have some BG layer specific controls, like how much should a BG layer be affected (in terms of movement) by the camera moving.

Man though, just thinking, one thing that's going to kind of suck is that a 64x32 tilemap is really two 32x32 tilemaps, so there will be some break up. Kind of annoying, but should be easy enough to work around. I really think I'll just use a 64x32 tilemap, because that covers the whole screen when it's being scrolled to the side. I really wish there were such thing as a 264x232 pixel tilemap.

The one thing that sucks about trying to make a tilemap for the SNES is that there are no tools for making one... I guess I'll have to make a test one manually...

[tepples]

Yes, 64x32 is probably the most practical for most Super NES scrolling games.

If you just want to update a map in columns, no metatile compression or anything, you can read a column out of the map during draw and DMA it to VRAM in vblank. If you're doing metatiles, you'll have to do it that way.

How would your preferred type of map editor work? Would you design the tile set and then the map, or would you convert a level-sized PNG file to a tile set and map?

[Drew Sebastino]

you can read a column out of the map during draw and DMA it to VRAM in vblank.

Yeah, like in a buffer. You don't have to do it for rows though, only columns.

Would you design the tile set and then the map

Yeah, like this. I wouldn't like the large PNG thing because I want to change the tiles as the level scrolls, and this will make the PNG thing not work.

[psycopathicteen]

There's also 16x16 tile mode.

For transparency, is there also transparency enable bits that have to be set as well as the sub screen and main screen? I'm surprised the sub screen can be used for reordering priority.

What do you mean by clearing? Anyway, I think I'll worry about optimizing this more later when I run into CPU time problems, otherwise I'll just end up freaking myself out.

Freeing up the slots when you have a frame change. You can just have it where all the empty slots are linked up together, and just connect the object's linked list to the empty slot linked list, when there is a frame change.

[Nicole]

The subscreen priority trick uses transparency, so to speak.

The SNES has four different color math modes. One adds the subscreen's colors to the main screen's colors and divides by two, averaging them, which is the classic transparency effect. Another doesn't do the division, which means the colors are simply added, which can be used for light effects, as subscreen colors would always brighten the screen. It's this one which is important, because adding a color to black just yields that same color, since black is (0,0,0), and (r+0,g+0,b+0) is just (r,g,b).

It's possible to set it so color math only operates on certain main screen layers, though you can't use different color math modes at once. In this case, it's using color addition only on the backdrop, which, since it's black, means the subscreen appears unaltered on the backdrop. And since BG2 is enabled on the subscreen, it shows up where the backdrop would.

If it used the color averaging mode, the subscreen would appear half as bright as it should, as it would be averaged with black.

(Something interesting to note is that, with the color averaging mode, any transparent areas on the subscreen will only cause the subscreen backdrop color (set with COLDATA) to be added to the main screen, not averaged. This is to avoid halving the color of the screen outside of, say, sprites you want to appear transparent.)

[Drew Sebastino]

So, whenever you use the subscreen, color math is always enabled? It does kind of stink though, because color 0 can't necessarily be whatever you want it to be. I've found that DKC3 does a couple of cool tricks with the video hardware that the other games didn't, like I really like how the tree levels put a window layer behind each tree to have it to where each BG tile can look like it's partially over sprites instead of all or nothing:



About camera movement, wouldn't this be the way to detect what direction the camera has moved in? (assuming it doesn't move #$8000 in one frame )

Code: Select all

  lda CameraX
  sec
  sbc PreviousCameraX
  beq camera_x_not_moved
  cmp #$8000
  bcc camera_moved_right