zdoom/raze: Build engine port backed by GZDoom tech. Currently supports Duke Nukem 3D, Blood, Shadow Warrior, Redneck Rampage and Powerslave/Exhumed.

zdoom/raze

mirror of https://github.com/ZDoom/Raze.git synced 2024-11-16 09:21:36 +00:00

Build engine port backed by GZDoom tech. Currently supports Duke Nukem 3D, Blood, Shadow Warrior, Redneck Rampage and Powerslave/Exhumed.

doom-engine free-software

Find a file

hendricks266 6cc62ea2bf Fix the display of numbers with TEXT_GAMETEXTNUMHACK and TEXT_XOFFSETZERO. (Fix level stats, part 2.) The commit revises the definition of qstrdim when TEXT_[XY]OFFSETZERO are used. With these flags, the offsets the user specifies are now the only dimensions the function cares about in terms of tile placement, so depending on the difference between the offset(s) and the size of the final tile, it may be slightly more or less than the dimensions actually displayed on the screen because tile size is never taken into account. (For example, if your font is nominally 9x7 like the Duke bluefont and you use a TEXT_XOFFSETZERO of 5 with a string five characters long, the total x dimension will be 25 even though the last character will overhang that amount by four pixels. If you use a TEXT_XOFFSETZERO of 12 with the same string, the total x width will be 60 even though there will be three pixels of empty space on the right edge.) This change was made because assigning text an arbitrary constant width in general implies an intent to keep character positions constant even with a variable width font, but returning the visible span of pixels on the screen that the tiles cover would have caused the string to move when alignment options other than the top-left were used. In other words, you can now safely use TEXT_[XY]OFFSETZERO with the alignment options and the text won't jiggle. Also, with TEXT_GAMETEXTNUMHACK, numerals are now effectively TEXT_XOFFSETZERO text that respect the above paragraph, so number count displays can look nice with alignment options too. Having to modify the extent/offset code makes me realize that I'm not quite happy with its structure because it gets tangled juggling different concepts like character width, X offset, and spacing, and how they relate when the line wraps or in terms of the final size. Fortunately, it produces correct results as far as I know, and it's not necessarily ugly, just hard to understand. Handle with care. git-svn-id: https://svn.eduke32.com/eduke32@3850 1a8010ca-5511-0410-912e-c29ae57300e0	2013-06-03 05:26:44 +00:00
polymer	Fix the display of numbers with TEXT_GAMETEXTNUMHACK and TEXT_XOFFSETZERO. (Fix level stats, part 2.)	2013-06-03 05:26:44 +00:00
.gitignore	Remove polymer-perf related lines from .gitignore	2012-10-05 22:37:26 +00:00

hendricks266 6cc62ea2bf Fix the display of numbers with TEXT_GAMETEXTNUMHACK and TEXT_XOFFSETZERO. (Fix level stats, part 2.)

The commit revises the definition of qstrdim when TEXT_[XY]OFFSETZERO are used. With these flags, the offsets the user specifies are now the only dimensions the function cares about in terms of tile placement, so depending on the difference between the offset(s) and the size of the final tile, it may be slightly more or less than the dimensions actually displayed on the screen because tile size is never taken into account. (For example, if your font is nominally 9x7 like the Duke bluefont and you use a TEXT_XOFFSETZERO of 5 with a string five characters long, the total x dimension will be 25 even though the last character will overhang that amount by four pixels. If you use a TEXT_XOFFSETZERO of 12 with the same string, the total x width will be 60 even though there will be three pixels of empty space on the right edge.) This change was made because assigning text an arbitrary constant width in general implies an intent to keep character positions constant even with a variable width font, but returning the visible span of pixels on the screen that the tiles cover would have caused the string to move when alignment options other than the top-left were used. In other words, you can now safely use TEXT_[XY]OFFSETZERO with the alignment options and the text won't jiggle.

Also, with TEXT_GAMETEXTNUMHACK, numerals are now effectively TEXT_XOFFSETZERO text that respect the above paragraph, so number count displays can look nice with alignment options too.

Having to modify the extent/offset code makes me realize that I'm not quite happy with its structure because it gets tangled juggling different concepts like character width, X offset, and spacing, and how they relate when the line wraps or in terms of the final size. Fortunately, it produces correct results as far as I know, and it's not necessarily ugly, just hard to understand. Handle with care.

git-svn-id: https://svn.eduke32.com/eduke32@3850 1a8010ca-5511-0410-912e-c29ae57300e0

2013-06-03 05:26:44 +00:00

polymer

Fix the display of numbers with TEXT_GAMETEXTNUMHACK and TEXT_XOFFSETZERO. (Fix level stats, part 2.)

2013-06-03 05:26:44 +00:00

.gitignore

Remove polymer-perf related lines from .gitignore

2012-10-05 22:37:26 +00:00