Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Switch Problem

edited 2006 May 14 in Developers
<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the category: Games.</i>

I am having a problem with switches not being animated. I gather a SWITCHES lump has been added, but is it supposed to be always present? My numswitches counter remains at zero (which causes the lack of animation in the switches) because apparently no SWITCHES lump is found.

Comments

  • Yeah I was just about to report switches were not animated.
  • Do none of the switches animate? For example the first switch in DOOM E1M1 on the side of pillar to the right of the stairs leading to the armor on the plinth?

    If none are animating then there is a bug. They animate fine in Windows.

    The way it works is that the there is a built-in array in GAME/p_switch.c (not in __JHEXEN__ yet), by default the switches are added from alphSwitchList as normal unless a SWITCHES lump is found; in which case it reads them from there.

    Set the verbosity level to 1 should result in various messages about the SWITCHES and ANIMATED defs being posted to the console.

    This functionality was implemented for BOOM support.
  • Ah, I see the problem now. It's this one:<pre>SHORT(sList.episode)</pre> In the hardcoded list, the episode numbers are already in the native byte order, so SHORT() will reverse them unnecessarily. I'll figure out a suitable solution for this.
  • Ah that makes sense. I'd forgotten that they would be in host byte order.

    When fixing this remember that sList can be either a ptr to the internal array alphSwitchList or the SWITCHES lump from a PWAD.

    I really must get into the habit of considering endianness In my code.
  • This is now fixed. I added macros for making the order conversion at compile time, so the alphaSwitchList array can be always specified in little-endian order.
Sign In or Register to comment.