Array sizes (memory) and collission detection

[annunaki10]

i read several posts regarding collission detection and what not. i saw a few which suggested to place a "mask" in a different color of the borders or objects and use the point function with the coordinates of the character to determine if they can or cannot go there. Then overlay this mask with the real map. i didn't want to use this exact method but something similiar.

Instead, i'm using a 2D array that has either a 1 or 0. 1 is a impassable, 0 is fine. This method works quite nicely the only issue is this. Since my array is the size of the screen (320, 200) i have to use the /ah method in order for the game to load up. Will this be a problem to run if i make an exe?

Also about the collission, i've thought about making a "type" of map that x, y, object, and passable are its properties. Then just check the character coords against the map.passable and be done. The problem with that is that some of the objects aren't a perfect square and the player can move around a little within the square. This "type" method seems to only work with a perfect square object. Would it be possible to use the map type and have not perfect squares?

The method i currently use would handle the uneven borders because my "object mask" of 1s and 0s is pixel based whereas the "map type" method is tile based. Thanks for your time and i hope this all makes sense.

[adosorken]

Instead, i'm using a 2D array that has either a 1 or 0. 1 is a impassable, 0 is fine. This method works quite nicely the only issue is this. Since my array is the size of the screen (320, 200) i have to use the /ah method in order for the game to load up. Will this be a problem to run if i make an exe?

No, but that method is horribly inefficient. You're better off making an array more along the lines of:

Code:

DIM blockingLayer(31999) AS INTEGER

and then using PEEKs with a y*320+x offset method. Not only will it take half the memory, but you won't have to use the Huge memory model (the /AH switch) and you'll get a bit of a performance boost. The way you have it right now will compile just fine, you're just not being very efficient at the moment.

Also about the collission, i've thought about making a "type" of map that x, y, object, and passable are its properties. Then just check the character coords against the map.passable and be done. The problem with that is that some of the objects aren't a perfect square and the player can move around a little within the square. This "type" method seems to only work with a perfect square object. Would it be possible to use the map type and have not perfect squares?

You can try using like mini blocking layers for individual objects. It can get a little complicated though, so if you do that, make sure you plan ahead for it.

[annunaki10]

Can you please explain this a little bit more or direct me to a tutorial:

PEEKs with a y*320+x offset method

Thanks for your time.

[Oz]

here is what he means

Code:

DIM Collide(32001) AS INTEGER

FOR x% = 1 to 320
FOR y% = 1 to 200
   i% = y% * 320 + x%
   Collide(i%) = INT(RND * 1)
NEXT
NEXT

to extract if the pixel is passible:

Code:

index% = pixely * 320 + pixelx
IF Collide(index%) = 1 then
'Not passible code
END IF

You could jsut use this to outline where you can and can't go

Oz~

[na_th_an]

Oz, the code you posted will throw "subscript out of range" errors. When y%=100, x%=2 , 320 * 100 + 2= 32002 which is out of bounds.

What Adosorken suggest, though, is somewhat different. It's about accessing the array using PEEK and POKE.

A 32000 integers array (DIM s%(31999)) takes 64000 bytes, 'cause one INTEGER takes two bytes. So you allocate those 64000 bytes for the collision map.

To set a "pixel" inside the array:

Code:

DEF SEG = VARSEG(s%(0))
POKE (VARPTR(s%(0)) + y%*320& + x%), value%
DEF SEG

and to read a pixel inside the array:

Code:

DEF SEG = VARSEG(s%(0))
value% = PEEK (VARPTR(s%(0)) + y%*320& + x%)
DEF SEG

As you may know, POKE puts a byte value somewhere in memory, and PEEK reads a byte value from somewhere in memory. DEF SEG defines the current segment, and it takes the segment where s%() is (using VARSEG which returns the segment where a variable or array is). VARPTR(s%(0)) is the offset of s%(0) inside the segment (which will be most likely "0", but let's include it here for compatibility "just in case"). As you have 64000 linear pixels stored in "imaginary" rows of 320 pixels, the way to go is 320*y + x.

Anyhow I find this method very memory consumming. If your game is tile based, you could have an asociated map for each tile, and look in the correct map.

[annunaki10]

Thanks na_th_an for the detailed explanation. i will save it in case i need an example another time. i will try and stay away from that method.

My game is tile based so i was planning on checking the position of the character versus the neighboring tiles only. It seems to be the most efficient way but as my trial 1st version attempt, i made the huge array.

Anyway, thanks again.