Jump to content
  • Advertisement
Sign in to follow this  
janta

Why FORCE_DWORD = 0x7FFFFFFF ?

This topic is 4559 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

Hey :) Thats maybe a silly question... Why do all DX enum use 0x7FFFFFFF ? Couldn't 0x1FFFF have done the trick ? So I figured that they wanted to leave as much room as possible for their real enum "members" (like someone would create an enum with 0x1FFFF = 131,000+ values anyway - unless it is auto-generated code maybe -) but then, why not use 0xFFFFFFFF ? Maybe they wanted to reserve the last bit for some error code ? I wonder ^^ (BTW if someone doesn't know, this trick enforces that all the enum is at least 32bits, which is most memory efficient (?) amongst possibly other reasons) Janta

Share this post


Link to post
Share on other sites
Advertisement
0x7FFFFFFF is a 31 bit value, which would work given that enum is a signed integer in VStudio.

I'm pretty sure its down to a "standard" C/C++ feature tbh. Off the top of my head, I think the compiler is free to pick a suitably sized type for enums were the values aren't specifically stated (or, even if they are, a size that allows at least the maximum specified). Thus some enums could conceivably fit into an 8 or 16 bit format.

That makes it a little bit messy with things like SetRenderState() and SetTextureStageState() as the parameter is declared as a DWORD yet the actual enum used is dependent on the first D3DRENDERSTATETYPE value.

Whilst the various MS-SDK's seems tailored toward VStudio you could use them with other compilers. Other compilers could have different rules, thus you get into a nasty grey area where the same code results in different functionality based on the compiler and nothing else [oh]

Anyway, I could be completely wrong - but thats my take on it [grin]

hth
Jack

Share this post


Link to post
Share on other sites
Jack, you are not wrong.

A c++ compiler can use any data type for an enumeration that has the same or larger range than all elements of the enumeration.

If you don’t define values for the different elements there is a rule, too:

Every elements get’s the value of the elements that is defined before plus 1. If there is no element before it get’s a zero.

Share this post


Link to post
Share on other sites
Quote:
Original post by Demirug
Jack, you are not wrong.
Excellent [grin]

Quote:
Original post by Demirug
Every elements get’s the value of the elements that is defined before plus 1. If there is no element before it get’s a zero.
Yup, I know of and use that rule... but Il still occasionaly see slightly obvious constructs like:

enum D3D10_QUERY
{
D3D10_QUERY_EVENT = 0,
D3D10_QUERY_OCCLUSION = ( D3D10_QUERY_EVENT + 1 ) ,
D3D10_QUERY_TIMESTAMP = ( D3D10_QUERY_OCCLUSION + 1 ) ,
D3D10_QUERY_TIMESTAMP_DISJOINT = ( D3D10_QUERY_TIMESTAMP + 1 ) ,
D3D10_QUERY_PIPELINE_STATISTICS = ( D3D10_QUERY_TIMESTAMP_DISJOINT + 1 ) ,
D3D10_QUERY_OCCLUSION_PREDICATE = ( D3D10_QUERY_PIPELINE_STATISTICS + 1 ) ,
D3D10_QUERY_SO_STATISTICS = ( D3D10_QUERY_OCCLUSION_PREDICATE + 1 ) ,
D3D10_QUERY_SO_OVERFLOW_PREDICATE = ( D3D10_QUERY_SO_STATISTICS + 1 )
}
D3D10_QUERY;


Was never to sure why they bothered with that [smile]

Cheers,
Jack

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!