Messages and keycards not shown

[GoogleCodeExporter]

Title pretty much explains it.  Messages during normal gameplay do not
show, like when you pick up some ammo or something.

Also, when you grab a keycard, it doesn't show up on your hud/status bar
like it is supposed to.

Original issue reported on code.google.com by bobberts...@gmail.com on 10 Sep 2008 at 7:57

[GoogleCodeExporter]

The messages are being displayed. The problem is that they are being displayed 
off
screen so the majority of the text is being cutoff.

The most robust fix would be to find a way to scale the entire display to fit 
the
visible area on your TV but that might prove difficult to implement. A much more
feasible solution would be to have it print messages a line or two lower on the 
screen.

As far as key cards are concerned, I've seen the code that handles drawing those
indicators on the hud but it's not clear why nothing shows up. I'd really like 
to
resolve this issue too but I have no idea how.

Original comment by richard....@gmail.com on 11 Sep 2008 at 3:00

[GoogleCodeExporter]

I've fixed messages and committed changes.

I'm working on key cards. I think I'm close.

Original comment by richard....@gmail.com on 11 Sep 2008 at 7:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This key card issue is killing me.

The way this seems to work is the graphics for each key are mapped to 
characters in a
font. For all essential purposes this is very much like wingdings. The hud code
determines what keys the player has and then constructs a string comprised of
corresponding characters.

For the most part, I've determined what characters equate to what keys. It's 
like so...

! = blue key card
" = yellow key card
# = red key card
$ = blue skull
& = red skull

I did this by changing the font used for the message widget and printing a 
message
like "ABCDEFGHI...".

Now if you're attentive you'll notice something odd. What's the character for 
the
yellow skull?

This is where I get stuck. The hud code cycles through the keys, determines if 
the
player has it and then looks up the correct glyph to print. If you compare the 
glyphs
that I know to those on an ascii lookup table, you'll see that they're all next 
to
each other which is yeilds a clue as to how this works.

It starts with ! and increments by one for each key. The hud code confirms this.

But, if this pattern is correct then the yellow key card should be mapped to 
the %
character. However, if you print this character using the key card font, nothing
shows up.

It's also worth noting that none of the other characters in this font aside 
from the
mysterious yellow skull have graphics mapped to them. If you use the key card 
font to
print a normal sentence like "Hello world", you get nothing.

Of course this means if the string constructed in the hud code is off by a few
characters you'll get nothing.

Original comment by richard....@gmail.com on 11 Sep 2008 at 10:18

[GoogleCodeExporter]

Have you considered contacting someone from the PrBoom team for information?

Oh and by the way, thanks.

Original comment by bobberts...@gmail.com on 11 Sep 2008 at 3:44

[GoogleCodeExporter]

Would it be possible to put each key into it's own 'font,' and then have it 
print "A"
or so to display the graphic?

Original comment by tbang...@gmail.com on 22 Sep 2008 at 8:20

[GoogleCodeExporter]

Original comment by lnux...@gmail.com on 23 Sep 2008 at 12:06

• Changed state: Accepted

[GoogleCodeExporter]

On my keyboard the symbols above the numbers are in this order:
!@#$%^&* and a UK keyboard would include £
Is it worth trying these?

Original comment by wilson.p...@gmail.com on 14 Jan 2009 at 7:13

[GoogleCodeExporter]

I realized today that messages show if you go through the options menu and 
enable them. The next release will have this option enabled by default. Still 
investigating keycards.

Original comment by castleva...@yahoo.com on 3 Jan 2011 at 5:57

[GoogleCodeExporter]

What function are you using to "print" the characters? Might need to use "%%" 
instead of "%" in some cases, since most C print functions interpret % as a 
special/meta character for formatting.

Original comment by benshadw...@gmail.com on 10 Sep 2011 at 7:39

[GoogleCodeExporter]

I would suspect that(i haven't analyzed the code yet) the code the prints the 
keycards maybe doesn't process the ascii text properly, and maybe the compiler 
is parsing the " symbol as an end of string, or it is just breaking somewhere 
inside one of the compiler(or game) support libraries... Just my two cents, I 
will provide my what I find when I have some time to analyze the code and 
experiment a little bit...

Original comment by zerohims...@gmail.com on 20 Jul 2013 at 4:58

[GoogleCodeExporter]

With the current code, I didn't see the weapons owned, Doom Guy's face, or the 
keycards.  It turns out the display of those was commented out to prevent a 
crash.  In st_stuff.c, lines 800 - 809:

/*
  for (i=0;i<6;i++)
    STlib_updateMultIcon(&w_arms[i], refresh);

// TODO REENABLE AND FIX THIS
  STlib_updateMultIcon(&w_faces, refresh);

  for (i=0;i<3;i++)
    STlib_updateMultIcon(&w_keyboxes[i], refresh);
*/

And in st_lib.c, lines 302 - 306:

// TODO kill this block -- CRASH HERE - FIX AND REENABLE THIS
/*
printf("STlib_updateMultIcon - calling V_DrawNumPatch...\n");
sleep(2);
      V_DrawNumPatch(mi->x, mi->y, FG, mi->p[*mi->inum].lumpnum, CR_DEFAULT, VPT_STRETCH);
*/

I uncommented those (except the printf and sleep), and sometimes I would get a 
crash related to this.  Tracking the problem down, it appears to be caused by 
the initialization routine.  In st_stuff.c, line 999:

  // weapons owned
  for(i=0;i<6;i++)
    {
      STlib_initMultIcon(&w_arms[i],
                         ST_ARMSX+(i%3)*ST_ARMSXSPACE,
                         ST_ARMSY+(i/3)*ST_ARMSYSPACE,
                         arms[i], (int *) &plyr->weaponowned[i+1],
                         &st_armson);
    }

It casts &plyr->weaponowned[i+1] to a pointer to an integer, but weaponowned in 
the player_t structure is an array of bools.  In GNU C, a bool takes up only 1 
byte and not 4.  This later causes the inum variable to generate some crazy 
subscripts. 

One solution might be to change weaponowned in d_player.h, line 136, from bool 
to an int:

  bool             weaponowned[NUMWEAPONS];

to this:

  int               weaponowned[NUMWEAPONS];

That seems to work OK, so far, but it did make my old save games incompatible.

Original comment by jo...@earthlink.net on 15 Sep 2013 at 10:39