Qbasicnews.com
May 31, 2020, 08:16:20 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Back to Qbasicnews.com | QB Online Help | FAQ | Chat | All Basic Code | QB Knowledge Base
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: Array sizes (memory) and collission detection  (Read 1832 times)
annunaki10
New Member

Posts: 23



« on: June 25, 2004, 12:44:30 PM »

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.
Logged
adosorken
*/-\*
*****
Posts: 3655



WWW
« Reply #1 on: June 25, 2004, 08:56:32 PM »

Quote from: "annunaki10"
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. Cheesy

Quote from: "annunaki10"
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. Cheesy
Logged

I'd knock on wood, but my desk is particle board.
annunaki10
New Member

Posts: 23



« Reply #2 on: June 26, 2004, 03:13:09 PM »

Can you please explain this a little bit more or direct me to a tutorial:
Quote
PEEKs with a y*320+x offset method


Thanks for your time.
Logged
Oz
I hold this place together
*****
Posts: 923



« Reply #3 on: June 26, 2004, 04:30:29 PM »

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~
Logged
na_th_an
*/-\*
*****
Posts: 8244



WWW
« Reply #4 on: June 26, 2004, 09:23:54 PM »

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

SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
annunaki10
New Member

Posts: 23



« Reply #5 on: June 28, 2004, 01:27:23 PM »

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.
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!