how to have unique movement paths for BG/ fine tuned BG collision

[+grafixbmp]

Its me again. Sorry to be a bother, but was wondering about a small snag. In my current game design, I have sections of the BG broken up into groups 6 down by 2 across. Each group has unique graphic data that may or may not cover that whole block area leaving no BG color visible, depending on which ones are shown, unique full screen backdrops can be drawn with many diffrent combinations. I will want my single character sprite to move in certain areas and not in others. The sprite may also have some spots inside some of the groups he cannot go. The lower 3 by 2 should be the only groups he can go in anyway for the uper 3 by 2 are just for show, effects, atmosphere, etc.

 

If you all get the just so far, would it be best to do this virtualy in software or with intermitint (I think I spelt that wrong) BG to player 0 collision checks. for this would be hard enough to do as it is. I could maybe do something between the 2. perhaps do a check between where the last part of the sprite isdrawn along with group collision checks and then the current reset trigger for horizontal positioning. or something like that. What do you guys think? ever had thisproblem before with a BG FULL of stuff?

 

I had intended to place this into the 2600 programming section BTW. That is where it was meant to go.

Edited February 13, 2008 by grafixbmp

[SeaGtGruff]

Its me again. Sorry to be a bother, but was wondering about a small snag. In my current game design, I have sections of the BG broken up into groups 6 down by 2 across. Each group has unique graphic data that may or may not cover that whole block area leaving no BG color visible, depending on which ones are shown, unique full screen backdrops can be drawn with many diffrent combinations. I will want my single character sprite to move in certain areas and not in others. The sprite may also have some spots inside some of the groups he cannot go. The lower 3 by 2 should be the only groups he can go in anyway for the uper 3 by 2 are just for show, effects, atmosphere, etc.

 

If you all get the just so far, would it be best to do this virtualy in software or with intermitint (I think I spelt that wrong) BG to player 0 collision checks. for this would be hard enough to do as it is. I could maybe do something between the 2. perhaps do a check between where the last part of the sprite isdrawn along with group collision checks and then the current reset trigger for horizontal positioning. or something like that. What do you guys think? ever had thisproblem before with a BG FULL of stuff?

 

I had intended to place this into the 2600 programming section BTW. That is where it was meant to go.

There is no way to test for a collision between the background and anything else, if that is what you're talking about. On the other hand, I think I *may* understand what you're trying to do, but I'm not certain. And I'm confused as to whether you mean the 2600 or the 5200/800, because even though you say it's meant to go in the 2600 forum, you sound like you're talking about character-based graphics.

 

Anyway, what I *think* you're trying to do is create a sort of "tiled" screen display, and have a sprite that moves around-- and is restricted-- on the basis of a type of "collision detection" system that's too complicated to be based on the normal register-driven collision detection. If I've understood that much correctly, then that's similar to something I've been wanting to do in a tile-based game, so I've already given the matter some thought. The only solution I can think of is to create a sort of literal bit map, in which each bit represents a block or tile on your screen display, or maybe a portion of a tile. This bit map is not something that would be drawn, but would be used purely for determining if your sprite is able to move into a particular spot (e.g., 0 = clear, 1 = blocked). For example, if your display has 20 "tiles" across, and 20 "tiles" down, then you could have a "collision" bit map that is 20 bits wide and 20 bits down.

 

Michael

[TROGDOR]

It's a 2600 question.

 

What you're describing is difficult to visualize without a screenshot.

 

The best answer is likely a mix of both methods. That was certainly the case for me, when working on Stellar Fortress. Originally I only used coordinate constraints, which meant the player ship couldn't move in the center of the screen at all (where the fortress is.) When I used a mixed solution, I only had to check for collisions when the collision register was flagged, and then the coordinate constraints were used to determine which side I had collided with. This helped determine which direction the ship should ricochet away from the fortress.

[+grafixbmp]

ok here is a basic visual break down of what I need to do. The main gameplay area is the yellow pars as 6 by 2. each part is pulled from diffrent screen data and drawn together. This can allow for many diffrent gameplay screens without having to store every screen independently. I will have a sprite grasphic that needs tor move across the lower 3 by 2 and depending on which sections are displayed, it will be blocked or allow free movement. some of the sections may even have smaller parts of them which restrict movement. Some may restrict movement diagonaly. Others may have 1/4th of it restrict movement. and some areas may even alter the players movement. This is a demo layout of the screen data. The upper and lower bars are for icons and HUD stuff. The acreen data that will be displayed in each section may be rather complicated layouts so this could hinder standard playfield collisions.

 

No real screen data is in the mock up. This is just to show the boundaries and sections relative to each other.

 

As a side note, for any relation from the player to the playfield, only the lower 2 to 4 lines or so of player 0 will need to be the spot where player 0 actualy is. anything above that is just visual.like so

 

 

"OOO"

"OOO"

"OOO"

"OOO"

"OOO"

"OOO"

"XXX"

"XXX"

 

The X's are all I need to use for player location.

 

atari_gamescreen_survival.bmp

 

On another side note, since the background sections/tiles naturaly only need 20 bits and load from 3 bytes per half a scan line, the other 4 bits of each line will be used for text data storage. this relates to another topic of mine.

 

http://www.atariage.com/forums/index.php?showtopic=120406

 

from this part dealing with text, I only have to incriment the address pointer for text every 3 byes for 6 scanlines per character and then merge 2 characters per sprite in memory per scanline. that way, I only need 6 bytes in RAM to hold real-time character data. and text stored in RAM memory only needs to be used when text is displayed. I intend to do a similar process with the backgrounds. So that 2 sections are addressed at a time but I may need to have all 12 adressed in ram anyway so that as each section is displayed, their address pointers are incremented by one each scanline. I may also need to preload all 6 bytes for each scanline into RAM also. Does anyone have a better/fasater way to do this or any additional thoughts?

Edited February 15, 2008 by grafixbmp

[Robert M]

You are going to have to go with a mathematical solution I think.

 

You will have an array with the tile types.

 

Map the player to a tile.

 

Call a custom routine for that tile type passing in the position of the player inside that tile. The routine will return a movement restrictor mask that you can logically OR with the joystick bits to block the player from going in certain directions based on their position within the tile.