|
Title: Code question - (FRAME)COMMANDER_PMAP_ANIM Post by: ptx on December 04, 2007, 05:28:08 pm Hi All,
This is more of a C question than anything. I've been trying to figure out this piece of code: Code: comm/starbas/starbas.c: (FRAME)COMMANDER_PMAP_ANIM, /* AlienFrame */ If I'm reading the code correctly: * COMMANDER_PMAP_ANIM is a long value that doesn't change: Code: comm/comandr/igfxres.h:#define COMMANDER_PMAP_ANIM 0x00200002L * FRAME is a pointer to a frame_desc structure Code: libs/gfxlib.h:typedef FRAME_DESC *FRAME; Code: libs/gfxlib.h:typedef struct frame_desc FRAME_DESC; Code: libs/graphics/drawable.h: struct frame_desc { DRAWABLE_TYPE Type; UWORD Index; HOT_SPOT HotSpot; EXTENT Bounds; TFB_Image *image; struct drawable_desc *parent; }; What does (FRAME)COMMANDER_PMAP_ANIM do? Pardon the silly question, I think I'm missing a key concept here. Thanks, -Pavel Title: Re: Code question - (FRAME)COMMANDER_PMAP_ANIM Post by: meep-eep on December 04, 2007, 06:48:25 pm That is very bad code. Something which should not be imitated and which we intend to remove from the UQM code in time.
Basically, the "AlienFrame" field, which has type "FRAME" (which through these typedefs is a "struct frame_desc *"), is abused to store something of a different type ("RESOURCE", which is a 32 bits integer). I assume that lateron this resource idenitifier is used to load the actual "frame_desc", which is then put in the field. This sort of thing yields unreadable code, and can introduce bugs (what if the type of the stored data takes up more space than fits in the field?), especially when porting to different platforms where the sizes of the types may be different. A better way to reuse the same space for storing two different things would be to use a union of the two types for the field. Title: Re: Code question - (FRAME)COMMANDER_PMAP_ANIM Post by: ptx on December 04, 2007, 06:53:51 pm Whew! Thanks. I thought I was going crazy.
-pc |