Jump to content

Rudy's Blog

  • entries
    8
  • comments
    28
  • views
    5,658

Targeting code update


Rudy

522 views

I looked at the batari source code for a very simple game, and was a sequence in the code to allow you to have a crosshair fire at a blue circle, and it used sprite collision to tell if you were aiming at the circle or not. I couldn't get it to consistently score a hit even when the crosshair was visually on the target, and I didn't know how to make it work better. So that's why I'm going to focus on learning the language now instead of experimenting with code. Although I think I might have conceptually figured out a way to do it; based on the coordinates, but it would be hard to implement. The code used x/y coordinates to tell where the sprites were on the screen. You could say if the xy coordinates of the crosshair were within an arbitrarily defined range of the targets x/y coordinates, && (Boolean and) f (fire button) = 1 then you have a hit. But it would be difficult to figure out the ranges and avoid false hits and failure to hit when you were over the target.

 

I did some work with sprites and colors, I'm unsatisfied with the target sprite. It's too small and looks nothing like a plane. Next I think is a better target algorithm but that sprite has to get better. Maybe I have to look at more example code?

2 Comments


Recommended Comments

The 2600 GPU (the TIA) has a group of registers which indicate whether two elements had overlapping active (colored) pixels since the previous time the registers were cleared. This is super accurate compared to a simple x/y comparison (termed bounding box detection), but it will have problems if the elements can overlap without having overlapping active pixels and in cases where elements are reused before the registers are tested & cleared.

Link to comment

The 2600 GPU (the TIA) has a group of registers which indicate whether two elements had overlapping active (colored) pixels since the previous time the registers were cleared. This is super accurate compared to a simple x/y comparison (termed bounding box detection), but it will have problems if the elements can overlap without having overlapping active pixels and in cases where elements are reused before the registers are tested & cleared.

Thanks for the information in my experiment I was unable to consistently create sprite collision on Stella so I was wondering if there was a better way to do it. I think I'm going to back to commenting code for now. I have 30 source code files so that may be more productive than trying to write in a language I simply do not know and without using techniques to accomplish things I also do not know.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...