Object data storing schemes -- as opposed to background data

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

User avatar
tokumaru
Posts: 11858
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Object data storing schemes -- as opposed to background

Post by tokumaru » Fri Sep 29, 2017 3:04 pm

Celius wrote:The problem is, if that object becomes active, if the player decides to stop moving, that object could walk outside of the active zone pretty easily (thereby deactivating itself, and not respawning because you've already crossed the "spawn" point). To prevent this, I actually have a "frozen" zone, where objects are "active", but they don't move or do anything until the player gets a little closer to them. Not perfect, but it helps minimize scenarios like this.
To solve this problem I only deactivate/unload an object if both its current position AND its spawn position are out of bounds. This way players don't run into that awkward situation when an enemy misteriously vanishes until they move away from the spawn point and close to it again.

Celius
Posts: 2157
Joined: Sun Jun 05, 2005 2:04 pm
Location: Minneapolis, Minnesota, United States
Contact:

Re: Object data storing schemes -- as opposed to background

Post by Celius » Sun Oct 01, 2017 8:34 pm

tokumaru wrote:To solve this problem I only deactivate/unload an object if both its current position AND its spawn position are out of bounds.
That's actually a really good idea. Logically, that makes more sense than my method.

However, for my engine (and possibly others), it might present a different problem to use that method. I have a rolling window of decompressed map data in RAM that is used for collision detection. This window is about the same size as the active zone. In the scenario where the spawn point is on screen, but the object is outside of the active zone, the object would be using bad map data for collision detection. Therefore, it kind of makes sense to prevent the object from moving, and colliding with bad tiles.

Is your AI able to decompress your level on the fly for collision detection?

User avatar
tokumaru
Posts: 11858
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Object data storing schemes -- as opposed to background

Post by tokumaru » Sun Oct 01, 2017 9:59 pm

Oh yeah, I can see that being a problem. You could freeze objects like you suggested when they're outside of the active zone but their respawn points aren't.

My level compression scheme does allow random access to any part of the level map at any time, but even then it might make sense to implement a "frozen" state to save CPU time.

User avatar
Lazycow
Posts: 105
Joined: Tue Jun 11, 2013 1:04 pm
Location: Germany
Contact:

Re: Object data storing schemes -- as opposed to background

Post by Lazycow » Fri Oct 06, 2017 2:17 am

Celius wrote:I have a rolling window of decompressed map data in RAM that is used for collision detection.
Interesting! :D
How did you implement this window, if I may ask? If I would try to include this in my code, then I think I would face two problems:
- Mapping of the map-coordinates to "window-coordinates", e.g. for collision detection. How did you manage this? Using "nice" windows-sizes like 32x16 blocks? (then you maybe could use the "and" opcode to modify the coordinates?!)
- decrunching data on the fly: This needs cpu time and free space in the window, right? How does this work in your example?

User avatar
tokumaru
Posts: 11858
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Object data storing schemes -- as opposed to background

Post by tokumaru » Fri Oct 06, 2017 7:17 am

Lazycow wrote:Using "nice" windows-sizes like 32x16 blocks? (then you maybe could use the "and" opcode to modify the coordinates?!)
That's how I'd do it. As long as the lower bits match, using AND to clear the high bits should work just fine.
- decrunching data on the fly: This needs cpu time and free space in the window, right?
This shouldn't be any different than decoding metatiles for drawing new parts of the level to the name tables. It's tied to the scroll: every N scrolled pixels, load new data. Graphics data goes to the name/attribute tables, collision data goes to the rolling window. The rolling windows might even simply contain metatiles, which can be used for both collision and rendering. Using a neat power-of-two size for the window helps with this too.

Celius
Posts: 2157
Joined: Sun Jun 05, 2005 2:04 pm
Location: Minneapolis, Minnesota, United States
Contact:

Re: Object data storing schemes -- as opposed to background

Post by Celius » Mon Oct 09, 2017 7:18 am

Lazycow wrote:How did you implement this window, if I may ask?
Well, I actually do have an advantage, because my game only scrolls horizontally. I was able to dedicate $600-$7FF to my rolling window, and have every 16 bytes represent a column of metatiles (so $600-$60F holds a column, $610-$61F holds the column right next to it, etc.). It breaks it down to the 16x16 pixel metatile. My screens are only 13 metatiles tall, but I still dedicate an entire 16 byte segment to each column for the sake of simplicity. The beauty of this is that finding the metatile at a given set of coordinates is very easy:

Code: Select all

;XHigh/XLow/YLow represent a set of in-game X/Y coordinates. X is 16-bit, Y is 8-bit due to no vertical scrolling.

lda XHigh
and #$01
clc
adc #$06
sta TempAddH

lda XLow
and #$F0
sta TempAddL

lda YLow
lsr a
lsr a
lsr a
lsr a
tay

lda (TempAddL),y   ;Your tile type
I'm not sure if that's the exact same code I use, but it's roughly the same.

User avatar
Lazycow
Posts: 105
Joined: Tue Jun 11, 2013 1:04 pm
Location: Germany
Contact:

Re: Object data storing schemes -- as opposed to background

Post by Lazycow » Mon Oct 09, 2017 2:37 pm

Thanks for the info! Your map setup is more complex than mine, but your tile-detection code is still faster. :oops:

Post Reply