Celtic Minstrel said:
If a value is used by the program, then it's stored in the executable (or an external file). So yes, there would be "hex data" for it.
There would be "hex data" in the form of machine instructions, but what I meant to say is that there can be no sort of table that encodes the directions and locations of sprites, since that's a dynamic thing that changes at runtime. The "locations of sprites" can only be stored as an algorithm that determines the physics and rules of the game.
If you're talking about their starting positions, then yes all NPC locations are stored in the .pxe file, and the starting coordinates and map of the player come from either the executable or a saved game file. Everything after that though must be a function of the game's logic + the player's input.
Bingo! That's 32768% false! A C preprocessor macro does not appear in the executable. It is substituted before the code is even compiled!
Most likely the "macro" in question is a function in the original code.
EDIT: Also, as I understand it, a macro (other than C preprocessor macros) is actually a function that returns a function, or something like that.
Well if you want to be picky about it, then yes of course there is no
ACTUAL macro. What I meant to say is that I can tell that the source code was USING a macro, since the final assembly code is exactly the same every time, except for variations in the "plugged in" constants.
For example, there is another common code sequence I know was generated by a macro, which is the macro that animates all the NPCs and enemies. It looked something like this:
PHP:
#define ANIMATE(SPEED, FIRSTFRAME, LASTFRAME) \
{ \
if (++o->animtimer > SPEED) \
{ \
o->animtimer = 0; \
if (++o->frame > LASTFRAME) o->frame = FIRSTFRAME; \
} \
}
So he'd call like
ANIMATE(2, 0, 5) every time through an AI func and the sprite would loop from frames 0 through 5 at a rate of one frame changed every 2 ticks.
Here's the good part. The reason I know this is a macro and not just repeated similar C code is that
sometimes he would want a sprite to change it's frame EVERY tick. So he said:
Which results in:
PHP:
if (++o->animframe > 0) { o->animframe = 0; if (++o->frame > 5) { o->frame = 0; } }
Now why would ANYONE code that?
++o->animframe will
ALWAYS ALWAYS be greater than zero. It's a waste of typing and code space and makes no sense. A human would write:
PHP:
if (++o->frame > 5) o->frame = 0;
...for these instances.
UNLESS they were used to using a macro for all their animations. Then they just see it as passing in a "speed" value of 0 meaning they want to change frames every tick.
ANIMATE(0, 0, 5);
looks nice and neat in the source.
That's why I said it's a macro, because I'm 99% certain it came from a macro. If you want to be picky about it, the executable doesn't really have any "variables" or "functions" in it either, does it? It's just a big blob that writes to various memory addresses. And sometimes, it pushes the IP onto the stack and jumps to other places. And sometimes, it pulls a DWORD off the stack and copies that value into the instruction pointer. We call these things "macros", "variables", and "functions" because that's how the programmer thought of them when he laid them out. So even though the macros are now all expanded out, I still think it's ok to think of them as macros, and a good idea too, since it enhances our understanding of the code.