It is currently Tue Oct 24, 2017 4:41 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 32 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Wed Nov 16, 2016 6:25 pm 
Offline

Joined: Thu Aug 28, 2008 1:17 am
Posts: 591
Punch wrote:
I spent the day trying to code something better, and since I dropped the "multiple boxes per metasprite" requirement, I did just as tokumaru said. No more indirection for what I'm doing, at least. It's buggy and not working properly but I'll see what I can do tomorrow.

Compare the old collision table with the new one:
Old: https://gitlab.com/aleff/BrixBattle/blo ... lision.txt
New: https://gitlab.com/aleff/BrixBattle/blo ... lision.txt

Way simpler huh? This is the new collision code: https://gitlab.com/aleff/BrixBattle/blo ... lision.asm . Less stupider. :lol:

tomaitheous wrote:
psycopathicteen wrote:
I noticed that most of his code is spent looking up "collision box data" and setting everything up to do the collision detection.

Oh wow, you're right.


Punch: That looks waaaaay over kill. What are you trying to do? (Something out of the norm?)

Why are you doing position translations of all corners? ;Obj2.x1 + Obj2.Posx

What is OBJ_COLLISION, x and what is OBJ_METASPRITE, x ? Are these projectiles? Destructible player objects? Enemy projectiles? Enemy objects?


It is now that I think about it. The translations are done because the center of the object is arbitrary, it's not always the left corner of the sprite. See https://gitlab.com/aleff/BrixBattle/blo ... r/anim.txt for the format.

OBJ_COLLISION is a byte for registering which object from the list is currently colliding with the object. I might think of something better later but that will do for now.
OBJ_METASPRITE is the metasprite id for the object. One metasprite is paired with one or more bounding boxes. (now just one box per metasprite)
The objects can be anything, from projectiles to enemies to players to static sprites to anything really. They all have the same attributes for now since I have lots of free RAM.


Is there any particular reason why you need center points?

As far as collision design goes, I think it should be tailored specifically to your game. If enemies collision don't affect one another, or enemy bullets don't affect other enemies - then don't check for them. In other words, have multiple collision routines. For instance, I have one that checks player projectiles only with enemies and their bullets. It doesn't check enemy projectiles against other enemy projectiles or other enemies (unless they are supposed to be destructible, but then I have them as spawns "enemies" rather than projectiles), and I don't check collision with other friendly projectiles or the player (or other player objects). In other words, I don't check for friendly fire collisions.

I also tend to avoid center point positions for objects, because if you have to cycle through all those objects more than once, then you have the overhead of translating them into a box every time. But then again, that depends on the design of your game. You might have no projectiles and only the player to check collision against (no attacks, only dodging).

Anyway, the idea is to remove redundancy in the collision routines. And like others have said, best to avoid using indirection of you can.

Also, since this is 65x related - I'm gonna post this here (I'm surprised sik didn't post this)
Quote:
Sik, on another forum, brought up a method he uses for his game logic on his work (Genesis). He uses a center coord system. So you only have Ax, Ay, and width/height. The compare logic is as follows; if [Ax-Bx]<= ((AxWidth+BxWidth)/2) then check Y. Although, he doesn't use the absolute value of Ax-Bx. If the value is negative, he uses the negative of (AxW+BxW)/2 as the compare. Now, that takes care of checking both Xn values (normally two compares) in a single compare, so you cut out one potential process right there. But now there's the added overhead of (AxW+BxW)/2, which can be optimize to (AxW+BxW)>>1 but it's still has additional overhead on every compare. Here's where he optimizes his engine; (AxW+BxW)/2 is not calculated on a per object box compare basis but rather it's calculated once and at assemble time. Now you're probably thinking that means he can only have one bounding size. He gets around this be having a set of box collision sizes. Usually, in a game of the PCE era, collision doesn't happen between every object. Or rather, only certain objects only interact with other objects. So there isn't a general need to check every object against every other object. And so you can write a few different collision routines to compare two hardcoded box sizes against each other. The other advantage is that you don't have to add movement offset to 4 coords, but only two coords (for when the object moves onscreen).


Though on the 65x, 4 corner compares should be relatively fast..

A simple 4 corner 8bit value check system:
Code:
CollisionAB:
  lda ObjAx2,y     
  cmp ObjBx1,x     
  bcc .nohit   
  lda ObjBx2,y
  cmp ObjAx1,x
  bcc .nohit
  lda ObjAy2,y
  cmp ObjBy1,x
  bcc .nohit
  lda ObjBy2,y
  cmp ObjAy1,x
  bcc .nohit
 ;hit
  jsr DoCollisionAB
 
.nohit

And obviously that can be optimized further if the routine is comparing one object to the whole list of other object (using a preload of 4 zp regs before the loop). Have lots of different arrays with all sorts of flags and attributes, but make sure they all have the same index value for the main object. Though that might be easier said than done if you're limited to the stock 2k ram of the NES.

The last thing I would check is; does optimizing your collision routine slow down other parts of object handling code? If so, is the trade off worth it? Maybe you're keeping track of objects that exist in a larger virtual map; everyone one of their positions would need to be evaluated and changed as you scroll about the camera window. If that's the case, and these objects stopping moving around (become inactive), outside of the camera view, it might be worth using a center point system on those - and then switch to corner offset positioning once active (moved to an active list). Dunno. But things like that weigh in on how you optimize your collision routine(s).

_________________
__________________________
http://pcedev.wordpress.com


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 3:02 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2295
Sumez wrote:
Did anyone actually do that thing where you check your frame timing to see if you need to delay certain routines until the next frame?
I've heard it mentioned several times before, and I know some commercial games do it, but to me it just sounds incredibly flaky... At least when it affects logic as critical to gameplay as collisions.

As I said in my previous post, apart from optimizing your algorithms and indexing your data, etc. the most effecient thing you could do, should always be building your game logic around what you know you can "afford", and how much stuff you're actually expecting to happen. If you're planning to often have 10 or more enemies on screen at the same time, your collision detection should be able to handle all of them, and if you need to spread collisions of certain objects between multiple frames in order to handle them all, I would personally prefer to do this unconditionally, rather than depending on whether your program is "running slow".
Checking if you need to delay some collisions to the next frame would add extra overhead to your code even when it's not relevant, and certainly allows for more bugs and erratic behavior, making testing more cumbersome.

I guess what I'm getting to is that if your program has special features that allows it to handle critical situations with a lot of action going on, it should be able to handle it well enough that it might as well do the same thing when nothing much is going on? Maybe I'm just being judgmental, but it sounds like bad design to me. :)


What's ironic is that the games I've seen mentioned for this are always games that have a lot of slowdown. Does using this trick actually make the game slower?


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 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