nesdev.org

In my game,,collision detection is OK,,
For the operation of the vram will be difficult
But :

LDA #$20
STA $2006
LDA #$00
STA $2006
LDA #$90
STA $01
LDA #$e0
STA $00
LDY #$00
LDX #$04
loop: LDA ($00),Y
STA $2007
INY
BNE loop
INC $01
DEX
BNE loop

So:The location of the player will be mapped to the $90E0~$XXXX.
In the direction of the player.
For the next tileID judge .
if(tile ID>81){
not modify coordinates;
}else{
modify coordinates;
}

You can't simply "not move" when your objects can move faster than 1 pixel per frame, you want them to get as close as possible to the solid block(s). Another challenge in colliding with the background is knowing WHICH blocks to check.

Another challenge in colliding with the background is knowing WHICH blocks to check.

In my game it was a piece of cake, as there is only scrolling or only collision but never both at the same time, so the collision is made with a static map, and also I aligned the bits in the X and Y coordinates so that they would match with the metatile #, this way no additional bit shifts has to be made.
In a previous version I had both X and Y coordinates in 8-bits but it sucked, it wasn't precise and I had problem with things wrapping around the screen. Now it is in 16-bit and it's much cleaner. High 8 bits is metatile #, low 8 bits are 1/256 of a metatile (16x16 metatiles), this means the pixel position is the middle 8 bits.

In the case of a scrolling game it wouldn't be much harder, exept you'd have to decompress and store in RAM 2 (single direction) or 4 (multi-directional) screens at the same time, and select the correct screen. At least that's the approach I'd use.

I actually ended up decompressing a "window" of the level into RAM (2 screens wide; the full screen that the player sees, and 1/2 screen off either direction. Scrolls only horizontally. Decompressed into 2x2 metatiles). So I ended up using 2 pages of RAM, every $10 bytes represented a column of metatiles. The way it was decompressed made it so you could use 9 bits of an object's coordinates in the entire level to calculate where it would be in the rolling window. I think the formula to get the byte of RAM that represents the tile at which an object's coordinates are located was ((ObjectX AND #$01F0)) + (ObjectY / 16) + $300 ($300 and $400 are the two pages used). Takes very little time to get that tile ID. Working through compression on the fly is a nightmare, so the 2 pages of RAM was worth it in my opinion.

Super Mario Bros. uses almost exactly the same sliding window method that you mentioned. But there is a tradeoff if you want to implement both backtracking and destructible environments without paying extra for an extra 8 KiB of PRG RAM.

I can think of a good way to get destructible environments without using that much RAM. Sparse map of 8x8 destroyed region cells, 8 bytes for the destroyed bit for an 8x8 region, and the map is sparse.

Or you could have have 16 or so blocks in the whole level that are destructible and remember those so they can be spaced and used in the level a few places.

3gengames wrote:Or you could have have 16 or so blocks in the whole level that are destructible and remember those so they can be spaced and used in the level a few places.

16 is negligible, you can easily implement that many as regular game objects, no need for special treatment.

Dwedit's idea makes a lot of sense, specially considering that destructible blocks are commonly used to block passages, so it's natural that they be placed in large chunks of 64 blocks. I believe most people can spare a good number of 8-byte block in RAM, so you can block a lot of passages in one level! You can also limit backtracking halfway through the level with the level's layout, so you can reuse the RAM for more breakable blocks, if you really need that many breakable blocks.

This has nothing to do with collision though.

tepples wrote:Super Mario Bros. uses almost exactly the same sliding window method that you mentioned. But there is a tradeoff if you want to implement both backtracking and destructible environments without paying extra for an extra 8 KiB of PRG RAM.

Just change out the 2kb RAM in your NES for 8kb, problem solved!

About Super CV4, when the level is rotating, it's not a complicated setup. There is the flat floor that begins rotating. It would be more complicated if the platforms that rotated were not flat. As I suggested with the swinging chandelier, the actual game may just have a hidden object you collide with rather than a tilemap.

Yeah but there is not only the flat floor (which is only flat before the rotation begins) but also a spike wall on the left and another wall on the right. The collision is kept accurate all during the rotation, and the level has been designed so that if you don't grab the thing that stays still, you die crushed on the spikes by gravity.

I think they did that by simply making the gravity rotating, this way it feels like the level is rotating. That's the approach I'd have at least.

tepples wrote:Super Mario Bros. uses almost exactly the same sliding window method that you mentioned. But there is a tradeoff if you want to implement both backtracking and destructible environments without paying extra for an extra 8 KiB of PRG RAM.

I thought SMB used a method where the entire contents of the buffer were updated to match exactly what the player saw on screen. It was almost as if the bytes "scrolled" in RAM as the player moved throughout the level... Perhaps what I saw was for something else. Perhaps I'm imagining the whole thing... I'll have to check again.

Play SMB1 with a RAM editor pointed at 500, and watch what happens as you scroll or hit blocks. There are two maps, one at 500, and one at 5D0.
Background objects like bushes and clouds don't exist on those maps, they seem to only exist in the nametables.

I seem to remember that right after the table at $5D0, there's another 13-byte array which is the column where the map is actually decoded. Inert background objects, such as clouds and water and the 8-3 wall, aren't copied from the column to the sliding window because their metatile number exceeds the maximum metatile number for each of the four groups ($00-$3F, $40-$7F, $80-$BF, $C0-$FF).

I think the idea was to have those background objects separate from the main layout in the first place. This helps with the variety a bit.