[HELP]

[kevingpo]

Ok. Regarding the Doom source code.

1. What is fixed_t type? And during gameplay why does players->mo->x,y,z,angle contain hugemungous numbers? I scale them down manually by /10,000,000 to get appropriate numbers for my 3D engine. But the angle skips a section of the 360 degrees. What is the proper scale-down?

2. Regarding question 1. I tried using << FRACBITS but that was no use. I get zero. I suppose it should be a multiple of 2 for the scale-down.

3. Am using MD2 models to display my Doom level things/map_objects. It's very similar to Doom3D,DoomGL use of the MD2 models. Does anyone know how to animate them w.r.t. the original Doom frames/states? I can display the MD2 models and animate them from start to end. But obviously all the frames/states are in the model.

Regards
Kevin

[Quasar]

fixed_t is a typedef for int, and splits the 32-bit dword into two 16-bit words. This is called fixed-point math. The 16 most significant bits form the integer part of the number, and the lower 16 bits are binary decimal places.

The proper scale-down factor from fixed_t to int is 65536 (2^16). This value is defined as "FRACUNIT" in the DOOM source. You can also scale a positive value down by "FRACBITS", which is defined as 16, but you cannot do this with negative values.

Angle fields are different, however, and use a system called Binary Angle Measurement (or BAM), which spreads the angles from 0 to 360 over the range of a 32-bit integer such that most of the bits are used for decimal places. 45 degrees is represented by BAM 0x20000000, 90 degrees by 0x40000000, 180 degrees by 0x80000000, etc. 1 degree is equal to 0x20000000 / 45.

The easiest way to convert from an integer degree value to BAM is with this operation:

int bam = (int)(((ULong64)angle << 32) / 360);

Substitute your compiler's 64-bit integer type for ULong64. On MSVC++, this is __int64, and on GNU compilers it's "long long".

[kevingpo]

Wow Quasar, you know some rock stuff!

Well, am using my own little 3D Engine to display a Doom map and objects. Am using SDL & OpenGL. All I need are the fixed_t values scaled down to around +-10. No more than +10 and no less than -10.

So basically for x,y,z I need to x << FRACBITS which is same as x << 16? That's same as x/65536?

And for angle I need to (angle << 32)/360.

[auxois]

He knows some metal stuff too. :nodnods:

[Quasar]

kevingpo said:

Wow Quasar, you know some rock stuff!

Well, am using my own little 3D Engine to display a Doom map and objects. Am using SDL & OpenGL. All I need are the fixed_t values scaled down to around +-10. No more than +10 and no less than -10.

So basically for x,y,z I need to x << FRACBITS which is same as x << 16? That's same as x/65536?

And for angle I need to (angle << 32)/360.

First off, left shift is equivalent to multiplication, not division. But you should not use right shift to do division, because it will destroy negative numbers. If you need to preserve the decimal part, cast to float or double and then divide by 65536.0

Second, the casts that I showed you in the angle conversion are extremely important. If you shift the angle up without casting it to a 64-bit integer type first, you'll lose all the data and it will be equal to zero. That's useless.

Also, I assume you could figure this out on your own, but if you already have a BAM and need the integer angle, then you must cast to 64-bit integer, then multiply by 360, and then right shift 32. Its just the inverse operation of integer -> BAM.

[DarkWolf]

I know Legacy has a function called FixedtoAngle(), which is useful, but I'm not sure if it's in the original source.

[kevingpo]

Quasar said:

First off, left shift is equivalent to multiplication, not division. But you should not use right shift to do division, because it will destroy negative numbers. If you need to preserve the decimal part, cast to float or double and then divide by 65536.0

Second, the casts that I showed you in the angle conversion are extremely important. If you shift the angle up without casting it to a 64-bit integer type first, you'll lose all the data and it will be equal to zero. That's useless.

Also, I assume you could figure this out on your own, but if you already have a BAM and need the integer angle, then you must cast to 64-bit integer, then multiply by 360, and then right shift 32. Its just the inverse operation of integer -> BAM.

Erm. Am using Dev-C++ (mingw). So what is the 64bit casting like then?

Damn, no wonder am getting 0 all the time. All my models were stuck in one spot.

[Fredrik]

(long long int) foo should do a 64-bit cast.

[toxicfluff]

I got a src question. I'm just starting to mess around with programming for the first time, so I'm sorry if this is a retarded query. But where is the code which determines what an item does if a player runs over it? Like picking up health, or ammunition. Because I'm adding a new ammo type, and I need an item to supplement it.

[Quasar]

Well, in the original source, its in p_inter.c in a function called P_TouchSpecialThing. It's still in that location in Eternity, although it has been rewritten a bit.