Game Programming Gems 4: Large World Coordinates
Author
I'm building a large world coordinate system into my game (been thinking about it for a long long time), and I decided to use the LWC in GPG4, except I've come across what I think is a bug in Mr Freese's code. Well, that's why I'm here. To me it seems obvious, but perhaps I'm misinterpreted the usage conditions of the code.
Hopefully I don't have to explain fully what the book says (hoping there are some readers familar with that section), but basically he has a segment:offset system going. It's the normalisation code that appears incorrect to me.
snippet..
if (fabs(m_offset.z) >= s_segmentSize)
{
m_segment.z += FloatToInt(m_offset.z / s_segmentSize);
m_offset.z = fmodf(m_offset.z, s_segmentSize);
}
He then says that the resulting offset will be in the range (-s_segmentSize, +s_segmentSize). This is true, however:
Assume s_segmentSize is 1000.
Starting at 0, increment position to 1001. Your offset is then normalized back to 1, while your segment gets incremented to 1. Nice. If you then go backwards, you need to go to -1001 in order to get the segment to flip back to 0.
If you had of gone backwards from the start, you'd now be in segment -1, not 0.
So, in my mind, you actually need to take the modded offset and subtract it from (s_segmentSize / 2) (having correctly multiplied it by 1 or -1 depending whether we're going forward or backward.
Obviously I belive I have a solution to the problem, but I mainly came here to find out if it is known or not whether this was an oversight, or whether I'm not using the code correctly.
First of all, let me say that I don't like it when people assume that people are familiar with an article. I have access to the book, but it would have been easier for me had you mentioned that it's section 2.3, instead of quoting an incomplete article name, and making me go over the table of content.
I haven't read the article in detail, but it's my understanding (as it's been from the code), that the offset is either positive or negative, and it's therefore perfectly okay to describe 999 (with a segment size of 1000) as both (0,999) and (1,-1). Assuming the rest of the code doesn't depend on each value having a single representation, there's no problem with this.
I haven't read the article in detail, but it's my understanding (as it's been from the code), that the offset is either positive or negative, and it's therefore perfectly okay to describe 999 (with a segment size of 1000) as both (0,999) and (1,-1). Assuming the rest of the code doesn't depend on each value having a single representation, there's no problem with this.
Quote:Assume s_segmentSize is 1000.
Starting at 0, increment position to 1001. Your offset is then normalized back to 1, while your segment gets incremented to 1. Nice. If you then go backwards, you need to go to -1001 in order to get the segment to flip back to 0.
If you had of gone backwards from the start, you'd now be in segment -1, not 0.
According to the code you posted, your two unrelated statements are correct.
First paragraph:
Start at 0:0. Increment to pos=1001. End up at 1*1000:1. Decrement until pos=-1001. End up at 0:-1. In this sequence, the Offset goes from 0 to 1001; then from 1 to -1001 (for a delta of -1002); total offset change = -1.
Second paragraph:
Start at 0:0. Decrement to offset = -1001. End up at -1*1000:-1 == -1001. Total offset change = -1001.
It sounds like your trying to equate these two different sequences of movement.
Can you better describe your concern?
Author
Thanks for the replies. I'm very sorry for the assumption, I should have listed a page number or section.
ET3D has hit the nail on the head. In my code I want a coordinate to have only one single representation, whereas, the article allows at least 2 representations of the same location. I should have put two and two together when he mentioned it was analogus to the segment:offset archtecture of the older 16bit x86 machines, in that one memory address can have several representations in segment:offset form.
ET3D has hit the nail on the head. In my code I want a coordinate to have only one single representation, whereas, the article allows at least 2 representations of the same location. I should have put two and two together when he mentioned it was analogus to the segment:offset archtecture of the older 16bit x86 machines, in that one memory address can have several representations in segment:offset form.
You could adapt the representation to use bounds of 0 to segment_size instead of -segment_size to segment_size. Shouldn't be too hard to do (just need a little care).
Author
I think that would be easier than -seg to +seg. I just tried it that way and I have trouble if I give it an offset of 2 or more segments at once, the offset ends up larger than a segment with no way to correct itself without calling normalize() again immediately.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
