It is currently Thu Dec 14, 2017 2:08 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Fri Sep 29, 2017 3:04 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Sun Oct 01, 2017 8:34 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2143
Location: Minneapolis, Minnesota, United States
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?


Top
 Profile  
 
PostPosted: Sun Oct 01, 2017 9:59 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Fri Oct 06, 2017 2:17 am 
Offline
User avatar

Joined: Tue Jun 11, 2013 1:04 pm
Posts: 60
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?


Top
 Profile  
 
PostPosted: Fri Oct 06, 2017 7:17 am 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.

Quote:
- 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.


Top
 Profile  
 
PostPosted: Mon Oct 09, 2017 7:18 am 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2143
Location: Minneapolis, Minnesota, United States
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:
;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.


Top
 Profile  
 
PostPosted: Mon Oct 09, 2017 2:37 pm 
Offline
User avatar

Joined: Tue Jun 11, 2013 1:04 pm
Posts: 60
Thanks for the info! Your map setup is more complex than mine, but your tile-detection code is still faster. :oops:


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 10 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group