Jump to content
IGNORED

Feature Request


MausBoy

Recommended Posts

In my recent programming with bB I've run into something that I'm having a hard time working around. It's something that I can do manually, but that costs me a dozen variables or more.

 

It's almost impossible for me to create any kind of decent collision detection with playfield objects in a scrolling game. I use a single pixel missile shifting to each corner of the sprite to detect a playfield hit. This works fine if the sprite can't walk thru/sink into any part of the playfield, but what if I have walls to run into AND bushes to walk past? In a single screen game, I can use variables to do if/then's on specific screen locations that sort of match up with playfield blocks, but with scrolling that would use all the variables up for one task.

 

What would fix this for me is some kind of playfield pixel color detection. Right now there is a command to detect if a pixel is on or off, would it be possible to alter it or add one for colors? That way my sprites can walk through green bushes but bangs into red walls, drive over the yellow lines but slam into the orange roadblock, etc, without using up enough variables to make the game useless and receding my hairline at least a half inch.

Link to comment
Share on other sites

In my recent programming with bB I've run into something that I'm having a hard time working around. It's something that I can do manually, but that costs me a dozen variables or more.

 

It's almost impossible for me to create any kind of decent collision detection with playfield objects in a scrolling game. I use a single pixel missile shifting to each corner of the sprite to detect a playfield hit. This works fine if the sprite can't walk thru/sink into any part of the playfield, but what if I have walls to run into AND bushes to walk past? In a single screen game, I can use variables to do if/then's on specific screen locations that sort of match up with playfield blocks, but with scrolling that would use all the variables up for one task.

 

What would fix this for me is some kind of playfield pixel color detection. Right now there is a command to detect if a pixel is on or off, would it be possible to alter it or add one for colors? That way my sprites can walk through green bushes but bangs into red walls, drive over the yellow lines but slam into the orange roadblock, etc, without using up enough variables to make the game useless and receding my hairline at least a half inch.

The 2600's collision hardware can't discern colors - only if there is a collision or not. Something like you are describing isn't impossible to implement in software, but it has to be done in the kernel (i.e. check collisions after every playfield row and store data in RAM somewhere.) Instead of a color, it would be easier to simply store the lowest playfield row where a collision occured. Unfortunately, I need around 8 or 9 cycles for that, which aren't there unless you are willing to lose an(other) object.

 

With any kernel mod, I'd want to be sure that such a thing would be useful for a wide variety of games. If not, it wouldn't make sense to make it a standard feature, so I could just recommend how to hack the kernel to suit your game in particular.

 

Regardless, even without kernel mods, I think that detecting collisions is very possible. Instead of using up lots of variables, standard practice is to use calculations and/or funky tables. Calculations tend to take up less ROM space at the expense of cycles, abd tables usually take up more space but fewer cycles. Also, tables can be tough to maintain. But either way, the two methods can be essentially RAM-less.

Link to comment
Share on other sites

My colors suggestion wasn't based on any knowledge of the hardware or it's limits unforunately. I was just hoping for a universal way to seperate elements of the playfield, so some can only be walked on, some walked through, some not, etc, based on something besides coordinates. What I meant was something independent of collision detection. I just meant a function that would be able to detect the color of a specific playfield pixel at any time, and hold the color #, something like:

 

PFPIXEL 4, 1 on

PFPCOLOR 4, 1

IF PFPCOLOR = 33 then a = a + 1

 

OR

 

PFPCOLOR A,B

IF COLLISION(player0, playfield) && !PFPCOLOR = 44 then a = a + 1

 

Then you could for example put a flashing, moving playfield pixel on screen that moves through blue playfield pixels but turns around when it runs into a red one. The reason I thought this might be possible is because of the PFREAD command.Trying to come up with anything like this in my program is extremely frustrating, workarounds turn into spagetti messes that I give up on.

 

As far as just detecting a collision, I'm already losing a missile to do it myself, and the method I use works well so I don't think it needs to be included as an option. When the game is paused, the missile used for collision detection becomes a meter on a different part of the screen too, so taking away that missile for a built in command wouldn't work.

 

If there is no way to seperate playfield elements by color, is there any other way to do it that someone like me can understand and implement? I don't understand how tables would work for this.

Edited by MausBoy
Link to comment
Share on other sites

btw batari, what I meant about not being able to come up with decent collision detection was that I can't figure out how to tell what the sprite is colliding with, when it comes to elements of the playfield. The method I mentioned above works great for just basic detection.

 

I think my big problem is that I'm thinking in terms of NES type games. I need to stick to single screen at a time games and forget about side scrollers for the 2600. Trying to match up a sprites x,y coordinates that span multiple screens to a 32x11 playfield that spans multiple screens is over my head, and storing the coordinates of every bush/cloud/tree etc in a table so they can be walked through just isn't practical for decent sized levels anyway.

 

I'm really bummed that my suggestion isn't possible, it would have made for some awesome games. If anyone has any other suggestions, or some source code that shows how you handled coordinate storage, I'd really appreciate it.

Link to comment
Share on other sites

Well I've been thinking outside the little grey box, and I developed a method that deals with this, but it completely and utterly sucks. Each playfield 'object' trees, rocks, hills, etc, has it's own function, ie

 

tree(22,10)

 

So it can be placed anywhere on screen and it's coordinates can be used to detect collision based on it's size and shape. So each object requires 3 variables, can only occur once on screen at a time, and requires lots of fun math to figure out if the player is touching a tree vs a hill at any given time. If only I could do

 

If collision (player0, tree)

 

hehe, dream on right? But a few defined playfield objects/psuedo-sprites sure would be awesome if they included collision detection and were excluded from the regular (x, playfield) detection. Without that or playfield pixel color detection, I think I'm done with trying to put things on the screen just because they look nice. If it isn't a wall or a platform, it causes more headache than it's worth.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   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...