Problem doing some calculations

Started by
8 comments, last by Staryon 18 years, 3 months ago
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]
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
"The pioneers of a warless world are the youth who refuse military service" - Albert Einstein
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.
_______________________"You're using a screwdriver to nail some glue to a ming vase. " -ToohrVyk
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]
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?
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.
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.
I think your ranges for your block numbers are off. According to my calculations it's more like:
0	31	032	63	164	95	296	127	3128	159	4160	191	5192	223	6224	255	7256	287	8288	319	9320	351	10352	383	11384	415	12416	447	13448	479	14480	511	15512	543	16544	575	17576	607	18608	639	19640	671	20672	703	21704	735	22736	767	23768	799	24800	831	25832	863	26864	895	27896	927	28928	959	29960	991	30992	1023	311024	1055	321056	1087	331088	1119	341120	1151	351152	1183	361184	1215	371216	1247	381248	1279	39

So 1152 to 1183 is block 36 and 1184 to 1215 is block 37. So 1168 being mapped to 36 is right.
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.
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

This topic is closed to new replies.

Advertisement