Zelda Classic 2.53.0 ( Beta 10 )

Didn't I hear somewhere that Allegro 4.4 uses DirectX8?
However, I installed DXGL (version 0.5.12) on this build and apparently it in fact ZC uses DirectX7 for the graphics, as it took the ddraw.dll, apparent when I set it to stretch mode.

BFeely wrote:Didn't I hear somewhere that Allegro 4.4 uses DirectX8?
However, I installed DXGL (version 0.5.12) on this build and apparently it in fact ZC uses DirectX7 for the graphics, as it took the ddraw.dll, apparent when I set it to stretch mode.

DirectDraw is indeed used, and it is in DX8.

Why are you using DXGL?

ZoriaRPG wrote:DirectDraw is indeed used, and it is in DX8.

Why are you using DXGL?

I was using it for testing purposes. I guess Allegro 4.4 does use other DirectX APIs in version 8 though (DirectDraw was discontinued after version 7)?

By the way, by turning on Aspect corrected stretch and setting aspect to 14:9 (or crop to aspect on 4:3 screens) it fixes the game to a perfect 4:3 aspect.

BFeely wrote:I was using it for testing purposes. I guess Allegro 4.4 does use other DirectX APIs in version 8 though (DirectDraw was discontinued after version 7)?

By the way, by turning on Aspect corrected stretch and setting aspect to 14:9 (or crop to aspect on 4:3 screens) it fixes the game to a perfect 4:3 aspect.

DirectDraw was included in the DirectX SDK, Feb 2010. It was discontinued in the DirectX SDK, June 2010. Both of these were > DirectX 7. Whether ddraw changed at all during the time between 7 and 8, is another matter. (It would seem unlikely, at best, that Microsoft changed anything about it.)

If you want to make a little tutorial for the userbase on DXGL, I would not object. It is not our preferred (internal) solution to all of these issues--although I am not opposed to it--but it is certainly something that would benefit a great number of users.

--------------

And now, for something you'll really like... - Rocket J. Squirrel

[FONT=Courier New]Beta 10, Updated[/font] [FONT=Courier New]2nd October, 2017 at 16:22GMT with --fixdrawint --fixgamecombo [/font][FONT=Georgia]to include a reversion of the entire set of[/font] [FONT=Courier New]Game->Get/SetCombo[/font]*[FONT=Georgia] functions. This should un-break quests that rely on them.[/font]

[FONT=Georgia]The patch also fixes the output of[/font] [FONT=Courier New]DrawInteger()[/font][FONT=Georgia] with zero decimal places; and both the array size, and the permitted values of[/font] [FONT=Courier New]Game->LKeys[][/font] [FONT=Georgia]and [/font][FONT=Courier New]Game->LITems[][/font]. [FONT=Georgia]The new array sizes are [FONT=Courier New][512][/font] and the assigned values have a valid range of [FONT=Courier New]0[/font] to [FONT=Courier New]255[/font]. [/font]

Proposed additions to std.zh:

bool HasKey(int level)
bool HasKey()
 * Returns true if Link has any keys, either global or level-specific.
 * If level is not specified, the current level is used.
int NumKeys(int level)
int NumKeys()
 * Returns the total number of keys, both level-specific and global, Link has
 * in the given level.
 * If level is not specified, the current level is used.
bool ConsumeKey(int level)
bool ConsumeKey()
 * Removes a key if Link has any, preferring level-specific keys. Returns true
 * if a key was consumed, false if Link didn't have any keys.
 * If level is not specified, the current level is used.

bool HasKey(int level)
{
    return Game->LKeys[level]>0 || Game->Counter[CR_KEYS]>0;
}
bool HasKey()
{
    return HasKey(Game->GetCurLevel());
}
int NumKeys(int level)
{
    return Game->LKeys[level]+Game->Counter[CR_KEYS];
}
int NumKeys()
{
    return NumKeys(Game->GetCurLevel());
}
bool ConsumeKey(int level)
{
    if(Game->LKeys[level]>0)
    {
        Game->LKeys[level]--;
        return true;
    }
    else if(Game->Counter[CR_KEYS]>0)
    {
        Game->Counter[CR_KEYS]--;
        return true;
    }
    else
        return false;
}
bool ConsumeKey()
{
    return ConsumeKey(Game->GetCurLevel());
}

That all looks good. My only question:

Why ConsumeKey() and not UseKey()?

( Did I have no levelkey functions in std.zh v2.0? I'll need to check. )

Anyway, I'll add these to Beta 12.

ZoriaRPG wrote:Why ConsumeKey() and not UseKey()?

Saffith wrote:Just seemed a bit more logical to me; I tend to think "using" a key means doing something in addition to consuming one. Doesn't matter much, though.

I suppose it's fine. I don;t think most usersd would latch onto ConsimeKey as an identifier, simply because it is nonstandard language for hos the typical user would use the function. I remembered where I saw UseKey(): I thought it was from my work on std.zh, or on my lockblock scripts, but it was from link.cpp. 😛

I put the functions in std.zh as-is for now. I had previously added NumLevelKeys(), but that's unimportant, as that is in the 2.0 version of the header.

I need to update this thread to beta 11, and the update will be in beta 12.

One thing that I would like to do, before the release of 2.53, is to go through and optimise the std.zh functions. In particular, in any case where we can use ++n instead of n++, I want to change the syntax; purely for performance reasons. (++n is 33% faster.)

If you have any ointerest in assisting with std.zh stuff, that would be fantastic. I'm going to clean up std.zh v2 in a few weeks, and we can all start debating that.