Jump to content
  • Advertisement
Sign in to follow this  
Staryon

Problem doing some calculations

This topic is 4609 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I'm developing a 2D platform game. I have created a 8000x3000 (pixels) map. The map is divided in 32x32 blocks. For example, if I want to get the block placed in 2,1 (in blocks) I should really get the block placed in 64,32 (in pixels) On the other hand if I want to get the block placed in 80,15 (in pixels) I would get the block placed in 2,0 because 80/32 = 2.5 and 15/32 = 0.468 The problem is the following, if I have a block placed in 1200,0 (in pixels) and I want to get the position in blocks, I would do 1200/32 = 37.5 and 0/32 = 0 However the x coordinate of the block is REALLY placed in 38 instead of 37. What am I doing wrong? Do you know a better algorithm for doing that? Thanks! [Edited by - Staryon on January 3, 2006 7:41:08 PM]

Share this post


Link to post
Share on other sites
Advertisement
Seems fine to me.

Since it's a zero-based index (block 0 through block 37 is actually 38 blocks total) your getting the "block" index. If you're trying to figure out how wide the map is in blocks just do:

width in blocks = int(width in pixels / 32) + 1;

--
Kory

Share this post


Link to post
Share on other sites
There isn't a lot of information here... You could do a cheap and dirty (int) cast of your block and it will round down instead of up...

I am not sure what your problem is though, you haven't described what you are expecting and why. You say it should be 37 but it ends up at 38, but I have no idea what you're using to draw these things so I can only assume that it is rounding up for some reason.

*edit: of course, if you're storing it in an array it would be a 0 based index which means you'd be grabbing the wrong block, but you never really specified that so I misinterpreted to mean your screen position was messed up.

Share this post


Link to post
Share on other sites
Thanks for your answers.

I'm basically trying to create a collision map.
I understand that it's a zero-based index, but I cannot always add +1
because it would fail in some cases.

This is what I have:

Pixels
(0->31) Block 0
(32->63) Block 1
(64->95) Block 2
... ...
(1168->1199) Block 37
(1200->1231) Block 38
... ...

If we take...

Pixel 15 -> Int(15/32) = Block 0 GOOD!
Pixel 40 -> Int(40/32) = Block 1 GOOD!
Pixel 83 -> Int(83/32) = Block 2 GOOD!
Pixel 1168 -> Int(1168/32) = Block 36 ERROR!!

Why doesn't work all the time?

[Edited by - Staryon on January 3, 2006 8:57:19 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Staryon

Pixel 1168 -> Int(1168/32) = Block 36 ERROR!!

Why doesn't work all the time?


I dont see what the problem is- 1168 / 32 = 36.5, so the computer rounding it to 36 is what is to be expected. Do you expect a different value?

Share this post


Link to post
Share on other sites
Quote:
Original post by ender7771

I dont see what the problem is- 1168 / 32 = 36.5, so the computer rounding it to 36 is what is to be expected. Do you expect a different value?


Yes, check the list that I posted in my previous post.
Quote:

(1168->1199) Block 37


Pixel 1168 is in that range, so it should be Block 37 instead of 36.

Share this post


Link to post
Share on other sites
if you expect 1168 to be 37 then you should expect 48 to be 2

48/32 = 1.5, in your logic it should be 2
but you said 32..63 = 1

so... you arent consistent, decide what you want.

if you want 1.5 tiles to round to two then use "Int((pixels+16)/32)"

edit:
the series will be-
Pixels
(0->15) Block 0
(16->47) Block 1
(48->79) Block 2
... ...
(1168->1199) Block 37
(1200->1231) Block 38
... ...

Iftah.

Share this post


Link to post
Share on other sites
I think your ranges for your block numbers are off. According to my calculations it's more like:

0 31 0
32 63 1
64 95 2
96 127 3
128 159 4
160 191 5
192 223 6
224 255 7
256 287 8
288 319 9
320 351 10
352 383 11
384 415 12
416 447 13
448 479 14
480 511 15
512 543 16
544 575 17
576 607 18
608 639 19
640 671 20
672 703 21
704 735 22
736 767 23
768 799 24
800 831 25
832 863 26
864 895 27
896 927 28
928 959 29
960 991 30
992 1023 31
1024 1055 32
1056 1087 33
1088 1119 34
1120 1151 35
1152 1183 36
1184 1215 37
1216 1247 38
1248 1279 39


So 1152 to 1183 is block 36 and 1184 to 1215 is block 37. So 1168 being mapped to 36 is right.

Share this post


Link to post
Share on other sites
As the above poster posted, the general equation for figuring out the starting pixel for each block is:

block# * 32 = starting_pixel

so block zero starts at 0, and block 37 ( the offending block) starts at 1184.

Share this post


Link to post
Share on other sites
Thanks guys. Yes, there was an error in my table. Sorry for wasting your time...

Let me do some more testing and I will let you know if I still have problems.

Regards

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!