[D1X-R 0.58.1, Windows 7] scoresb.pcx not properly supported
#1
Scoresb.pcx exists in the high-resolution add-on, but it's not used at all unless the Mac game data is being used. Since the Mac data already has a high-resolution scoresb.pcx, this behavior is pointless and is obviously a mistake. I think the problem lies in line 135 of main/newmenu.c:
Code:
#define MENU_BACKGROUND_BITMAP (HIRESMODE?MENU_BACKGROUND_BITMAP_HIRES:MENU_BACKGROUND_BITMAP_LORES)

From what I can tell, "HIRESMODE" is true only if the Mac data is being used. I think changing this line to the following (to behave more like the *h.pcx files) will fix the bug, although I can't test it myself:
Code:
#define MENU_BACKGROUND_BITMAP ((SWIDTH>=640&&SHEIGHT>=480)?MENU_BACKGROUND_BITMAP_HIRES:MENU_BACKGROUND_BITMAP_LORES)
Reply
#2
verified ~ scoresb.pcx doesnt show up, but scores.pcx does.

it also looks like it needs to be scaled, scores.pcx seems to be zoomed-in.
Reply
#3
After observing D1XR's menus and comparing "scores.pcx" to "scoresb.pcx" in an image viewer with the former enlarged so the sizes were similar, I think I see what's happening here. Indeed, D1XR doesn't support "scoresb.pcx", which for now can be renamed to "scores.pcx" so that it at least loads. As for the scaling oddity that ThugsRook noticed …
  • Descent's menu windows have a 3D-looking border around their rim. "scores.pcx" contains the border's top and left edges, but not the bottom and right edges. I'm guessing the game renders those rather than loading them from a file?
  • The 320 x 200 "scores.pcx" has thick top and left edges. When D1XR loads it, the game renders matching thick bottom and right edges. This is the behavior of DOS Descent.
  • The 640 x 480 "scoresb.pcx" also has thick top and left edges. When D1XR loads it (renamed of course), the game renders mismatched thin bottom and right edges. As Yarn noticed in another topic, this is surprisingly the behavior of Mac Descent. This YouTube video shows the Mac version's mismatched menu borders.

I hope these extra details help in deciding how to handle the bugs. Should we "fix" the Mac menu borders, or leave them old school? Smile Regardless, it'll be nice to have Rebirth load "scoresb.pcx", "iplogo1h.pcx", "order01h.pcx", and "warningh.pcx" so that we can make a "d1xr-hires.zip" that allows the game to load low-res graphics when below 640 x 480.
Reply
#4
^ yup, i agree wih your assesment there.

as soon as they are all enabled correctly ill update the unofficial hires pack with the Bs and Hs for dual hi/low res use... and force Zico to post it as official! (so i can be done with it) Wink
Reply
#5
The main reason because this is currently that messed up is how Descent 1 differs in terms of High Res content to Descent 2. Descent 1 only has High Res content in Mac version which however doesn't have the low res equivalents. So there is some sort of fixed behaviour involved to support the Mac and PC versions properly while the High Res pack was - back in the day - meant to work similar to Descent 2.

So basically what's a very easy thing in Descent 2 becomes more complicated in Descent 1.

I have certain ideas on how to improve that - especially I would like to make the engines use such content in regards of availability - not on "what is expected in terms of the game content you have installed".
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Reply
#6
(10-22-2013, 11:21 AM)zico link Wrote:The main reason because this is currently that messed up is how Descent 1 differs in terms of High Res content to Descent 2. Descent 1 only has High Res content in Mac version which however doesn't have the low res equivalents. So there is some sort of fixed behaviour involved to support the Mac and PC versions properly while the High Res pack was - back in the day - meant to work similar to Descent 2.

So basically what's a very easy thing in Descent 2 becomes more complicated in Descent 1.

I have certain ideas on how to improve that - especially I would like to make the engines use such content in regards of availability - not on "what is expected in terms of the game content you have installed".
Have you tried the change that I suggested in the original post?
Reply
#7
That's what I mean: This solution  only works for the PC version and only if the Hires AddOn is actually installed. If it's missing or Mac version is running, the game will not work properly i.e. crash. My goal is a solution that checks for the availability of files and then decides what to use.
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Reply
#8
(10-23-2013, 09:03 PM)zico link Wrote:That's what I mean: This solution  only works for the PC version and only if the Hires AddOn is actually installed. If it's missing or Mac version is running, the game will not work properly i.e. crash. My goal is a solution that checks for the availability of files and then decides what to use.

I'm pretty sure that this is done by the two lines immediately above the one that I was referring to. Here they are:
Code:
#define MENU_BACKGROUND_BITMAP_HIRES (PHYSFSX_exists("scoresb.pcx",1)?"scoresb.pcx":"scores.pcx")
#define MENU_BACKGROUND_BITMAP_LORES (PHYSFSX_exists("scores.pcx",1)?"scores.pcx":"scoresb.pcx")

And, for your convenience, here is the original post:
(08-07-2013, 01:38 AM)Yarn link Wrote:Scoresb.pcx exists in the high-resolution add-on, but it's not used at all unless the Mac game data is being used. Since the Mac data already has a high-resolution scoresb.pcx, this behavior is pointless and is obviously a mistake. I think the problem lies in line 135 of main/newmenu.c:
Code:
#define MENU_BACKGROUND_BITMAP (HIRESMODE?MENU_BACKGROUND_BITMAP_HIRES:MENU_BACKGROUND_BITMAP_LORES)

From what I can tell, "HIRESMODE" is true only if the Mac data is being used. I think changing this line to the following (to behave more like the *h.pcx files) will fix the bug, although I can't test it myself:
Code:
#define MENU_BACKGROUND_BITMAP ((SWIDTH>=640&&SHEIGHT>=480)?MENU_BACKGROUND_BITMAP_HIRES:MENU_BACKGROUND_BITMAP_LORES)

So, it looks like the game does try to use only what is available.

If you prefer, another possible way to fix this is to replace the three lines mentioned above with this one, which is identical to how the *h.pcx files are handled:
Code:
#define MENU_BACKGROUND_BITMAP (((SWIDTH>=640&&SHEIGHT>=480) && PHYSFSX_exists("scoresb.pcx",1))?"scoresb.pcx":"scores.pcx")
Reply
#9
I was just referring to the resolution condition, assuming HIRES is high res version, LORES means low res version - not an additional redundancy where beasically every define has another set of fallbacks. 

The suggestion you did here:
Code:
#define MENU_BACKGROUND_BITMAP (((SWIDTH>=640&&SHEIGHT>=480) && PHYSFSX_exists("scoresb.pcx",1))?"scoresb.pcx":"scores.pcx")
Comes close to what I want to do but I rather want to make this into a function which first would be a more central approach working for both games - considering the merge and secondly it could possibly be expanded with widescreen versions, too.
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Reply
#10
You mean something like this?
Code:
char* [whatever](char *lores, char *hires, char *wide) { //replace [whatever] with the name that you want
    int lores_exists = PHYSFSX_exists(lores,1)
    int hires_exists = PHYSFSX_exists(hires,1)
    int wide_exists = PHYSFSX_exists(wide,1)

    //widescreen
    if (((float)SWIDTH / (float)SHEIGHT > 1.5) || (!lores_exists && !hires_exists)) {
        return wide;
    }

    //hi-res
    if ((SWIDTH >= 640 && SHEIGHT >= 480) || !lores_exists) {
        return hires;
    }

    //lo-res
    return lores;
}
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)