Closed Baker7 closed 6 months ago
Quake (conchars living in gfx.wad):
OUM (conchars living in gfx/conback.lmp):
The letters are not in the same columns.
The OUM character set columns are different, notice "@" is in the first column vs. last column, I'll have to see what a vanilla engine does to notice this "special" need.
Crazy.
There is no bug.
DarkPlaces finds a gfx/conchars.lmp in the pak file and uses that data and the conchars.lmp for OUM is "wrong".
I don't think any other engine checks for the .lmp, but for DarkPlaces that is "standard procedure".
there's been a few people making screwy conchars lumps. :( the conchars lump is NOT a qpic. it is a raw 128*128 headerless blob of raw palette indexes with 0 as transparent instead of 255. In vanilla quake it was marked as a miptex lump. If a tool writes such a lump, flagged as a qpic, as a 16392-byte lump, with an extra 8-byte qpic header with appropriate size info in said header... then you MUST fuck up parsing and instead treat that header as raw bytes ignoring the trailing 8 bytes instead. Whoever made that qpic lump doesn't know what they were doing and drew their glyphs in all the wrong slots in order to work around their tool being poop/misused.
but yes, content bug, not an engine one.
Here is a fun one told to me by jakub1
Operation Uearth Majik : https://www.quaddicted.com/reviews/oum.html
Every DarkPlaces including 2014 stable and Zircon gets this, all you have to do is "gamedir oum":
The text in the console buffer is not screwed up, so maybe the character set loads weird or the DarkPlaces text rendering is getting a special character screwing it up. I have a feeling I can fix this rather quick.