EASy68K  
It is currently Wed Jan 22, 2020 11:27 am

All times are UTC




Post new topic Reply to topic  [ 4 posts ] 
Author Message
PostPosted: Tue Apr 01, 2014 7:09 pm 
Offline

Joined: Tue Apr 01, 2014 6:59 pm
Posts: 2
So ive been writing a small game in 68000 asm and im needning to write some collision detection.

The game engine is tile based (16x16 pixel tiles). Im using a 1024x1024 tilemap array (thats 64 tiles across and 64 down) for the gameplay background that makes up the landscape and another 1024x1024 tilemap array that is the collision layer. This way the collision layer is lined up with thebackground layer at 1:1 ratio.

Currently ive got the players X position in d2 (word) and y pos in d3 (word) (keep in mind this is the top left corner of the bitmap(0,0,)

Im trying to figure the best way possible to convert these values INTO an index into collision tilemap array and then do a cmp.b command to see if the index is a 1 or 0 (1 = solid, 0= nothing). From there i guess since i have the x/y position i can then do some bounding box collision and figure out if the player is hitting this item in the map.

Has anyone been down this path already and care to lend some advice or maybe point me in a good direction or point out any flaws in this method? Im hoping this is the right way to do this instead of brute force checking all tiles in one frame (major performance hit and very inefficient)


Top
 Profile  
 
PostPosted: Fri Apr 04, 2014 7:36 am 
Offline

Joined: Tue Nov 15, 2005 7:58 am
Posts: 129
Location: Oregon, USA
Sounds to me like you're already pretty far into video game theory, so I presume your question has to do strictly with indexing into the arrays, a well-known technique. Unfortunately, your question isn't quite completely specified... :(

Assuming the X and Y positions are byte offsets, not tile numbers:
If you're just wanting to convert the Column and Row numbers of a table (same as X and Y of a 2-d array) into a 1-d offset into the table, just multiply one (R or C) by its dimension (1024 for either, in this case) and add the other (C or R). Which you multiply depends on whether R or C increases slowest as you step through the table in order. E.g., the byte at [6,9] is (1024*6)+9 bytes into the array, assuming the second number (9) is the fastest-increasing.

In your case, you just need to use the same order each time when you access the various arrays.

This assumes zero-based indices {running from 0 to 1023}; If 1-based {1 to 1024}, use (index-1) in the calculation.

If your table cells are larger than one byte, multiply the offset by the size of a cell. E.g., if they're double-words, multiply the offset by 4. This may not apply to your problem, but see paragraph below about tile sizes.

If X and Y are actually (16x16) tile numbers, and you need a tile number offset as the result, just make the dimension (1024/16 = 64). If they're tile numbers but you need a byte offset, either multiply X and Y by 16 then use the byte method, or use the tile method but multiply the result by (16*16 = 256) before using it as a byte offset. If, further, the bytes of a tile are not stored contiguously (e.g., they're in video scan order), then it's more complicated still, but the same principles hold. I think in that case you'd treat it as a 1-d array of 2-d arrays of 1x8 sub-tiles. I'd have to draw some pictures of the layout and write in offsets, a method I recommend. :D Different representations would have different impacts on other parts of the code.

I hope that was reasonably clear. (And that I haven't confused myself :D )

Note: If the multiplication is too slow, you can make a table of the starting addresses of each row and index off of them into the column you want. Classic trade-off of space for time. But a multiplication by 2^n is just a shift, so it should be pretty fast on a 68K. (Vs. an 8-bit machine) For that matter, on a more advanced 680x0, the multiply instruction is fast enough not to be a concern.

For questions beyond the above, I'd need to know even more about how your tiles and arrays are constructed; for instance, are you using sprites? Are they 16x16? Do they always align with a background tile? Are there "empty" spots around the edges of the sprites? Here I'd be working out of a textbook; I've no actual experience programming this sort of thing. (Lee? Are you out there?)


Top
 Profile  
 
PostPosted: Mon Apr 07, 2014 2:56 am 
Offline

Joined: Tue Apr 01, 2014 6:59 pm
Posts: 2
gtippery wrote:
Sounds to me like you're already pretty far into video game theory, so I presume your question has to do strictly with indexing into the arrays, a well-known technique. Unfortunately, your question isn't quite completely specified... :(

Assuming the X and Y positions are byte offsets, not tile numbers:
If you're just wanting to convert the Column and Row numbers of a table (same as X and Y of a 2-d array) into a 1-d offset into the table, just multiply one (R or C) by its dimension (1024 for either, in this case) and add the other (C or R). Which you multiply depends on whether R or C increases slowest as you step through the table in order. E.g., the byte at [6,9] is (1024*6)+9 bytes into the array, assuming the second number (9) is the fastest-increasing.

In your case, you just need to use the same order each time when you access the various arrays.

This assumes zero-based indices {running from 0 to 1023}; If 1-based {1 to 1024}, use (index-1) in the calculation.

If your table cells are larger than one byte, multiply the offset by the size of a cell. E.g., if they're double-words, multiply the offset by 4. This may not apply to your problem, but see paragraph below about tile sizes.

If X and Y are actually (16x16) tile numbers, and you need a tile number offset as the result, just make the dimension (1024/16 = 64). If they're tile numbers but you need a byte offset, either multiply X and Y by 16 then use the byte method, or use the tile method but multiply the result by (16*16 = 256) before using it as a byte offset. If, further, the bytes of a tile are not stored contiguously (e.g., they're in video scan order), then it's more complicated still, but the same principles hold. I think in that case you'd treat it as a 1-d array of 2-d arrays of 1x8 sub-tiles. I'd have to draw some pictures of the layout and write in offsets, a method I recommend. :D Different representations would have different impacts on other parts of the code.

I hope that was reasonably clear. (And that I haven't confused myself :D )

Note: If the multiplication is too slow, you can make a table of the starting addresses of each row and index off of them into the column you want. Classic trade-off of space for time. But a multiplication by 2^n is just a shift, so it should be pretty fast on a 68K. (Vs. an 8-bit machine) For that matter, on a more advanced 680x0, the multiply instruction is fast enough not to be a concern.

For questions beyond the above, I'd need to know even more about how your tiles and arrays are constructed; for instance, are you using sprites? Are they 16x16? Do they always align with a background tile? Are there "empty" spots around the edges of the sprites? Here I'd be working out of a textbook; I've no actual experience programming this sort of thing. (Lee? Are you out there?)


Sorry i dont have too much time to write but ill try to answer as many questions as i can.

As far as the arrays i have two. One that i build the tilemap from and one for the collision. The tilemap one isnt really important at this point, but is size wise a 1:1 ratio with the collision map.

The collision map however is setup like such...

MAP:
dc.b 0,0,0,0,0,0,0,0,0,0
dc.b 0,0,0,0,0,0,0,0,0,0
dc.b 0,0,0,1,1,0,0,0,0,0
dc.b 0,0,0,1,1,0,0,0,0,0
dc.b 0,0,0,0,0,0,0,0,0,0
dc.b 0,0,0,0,0,0,0,0,0,0
dc.b 0,0,0,0,0,0,0,0,0,0

However there are 64 individual bytes on each line and 64 rows... thus giving 4096 tiles. A 0 indicates no collision on that tile, a 1 would indicate there is a collision.

The players X/Y position is in words always however. Ive been able to find the closest tile to the player (multiple of 16) however this usually is from 0,0 (top left corner) of the sprite unless i add some sort of offset to the player x/y position prior to running the short bit of code to find the nearest "tile" to the player.

As for the sprites, i am literally using raw .RGB graphics. The 68k processor on the hardware im working with runs at 13.2mhz so muls and divs commands shouldnt take too much of a hit at all.

Sprites are 16x16 for tiles only. The sprite im using for the player is 8x10 right now and some of the space around the player in that 8x10 has a color of 0,0,0 (R,G,B) (absolute black).


Top
 Profile  
 
PostPosted: Tue Apr 08, 2014 9:40 am 
Offline

Joined: Tue Nov 15, 2005 7:58 am
Posts: 129
Location: Oregon, USA
Not much time now either :D

Did you still have a question?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group