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.
Printable View
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.Quote:
Originally Posted by BFeely
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)?Quote:
Originally Posted by ZoriaRPG
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.
Quote:
Originally Posted by BFeely
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
Beta 10, Updated 2nd October, 2017 at 16:22GMT with --fixdrawint --fixgamecombo to include a reversion of the entire set of Game->Get/SetCombo* functions. This should un-break quests that rely on them.
The patch also fixes the output of DrawInteger() with zero decimal places; and both the array size, and the permitted values of Game->LKeys[] and Game->LITems[]. The new array sizes are [512] and the assigned values have a valid range of 0 to 255.
Proposed additions to std.zh:
Code: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.
Code: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.
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.Quote:
Originally Posted by ZoriaRPG
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. :pQuote:
Originally Posted by Saffith
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.