Jump to content

Photo

Zelda Classic 2.53 Gamma (RC) 3

Gamma Release Candidate 2.53

  • This topic is locked This topic is locked
6 replies to this topic

#1 ZoriaRPG

ZoriaRPG

    The Timelord

  • ZC Developers
  • Gender:Unspecified
  • Location:Prydon Academy

Posted 17 February 2019 - 02:52 AM

Zelda Classic 2.53.0 Gamma (RC) 3 for Windows

Includes ZLaunch, 2.6.10.

 

Changes Over Gamma 2

 

Updated qst.dat, to strip out some remaining rubbish pal cycle data.
Fixes for Palette Cycle Issues:
    Palettes above 256 were not set up to have palette cycles in 2.50.
    The array in QMisc is [256][3], where it should have been [512][3].

    Because of this, palettes above 0xFF had rubbish data associated to their cycle data.

    To remedy this, I have done the following:

        All palettes > 255 have a null palette loaded into them, in the editor and as
        palette data, to zero out their cycle information.

        This should occur both in ZC, and in ZQuest.

        I disabled clicking the Cycle button in the Level palette editor, and display
        a jwin-alert that the palette doesn't support cycling.

    Let's hope this doesn't cause crashes in any quests, in ZC.


Added leading zeros to the 'Select Item' 'Pow: ' field, so that
items with powers greater than 10 don't carry over digits to items with
powers < 10.
    ( ZoriaRPG, 17th February, 2019 )
Re-fix 1st.qst Level 9 Rupee issue. I had set the wrong type.
    ( NightmareJames, 16th February, 2019 )
Updated include 'tango.zh', and its associated demo to current versions of both.
Pressing the Enter key, or the numpad Enter key, while viewing
the Quest Header dialogue now EITHER activates the selected element,
    or saves the dialogue changes, instead of opening the
    'Change Quest password' sub-dialogue.
    It will auto-save if the selected element is OK, or any TEXT field.
    Otherwise, it triggers the selected element.
    This should also work from the numpad Enter key.
    I also made the changes as an EXAMPLE chain, for making all
    JWin DIALOGUES more user-friendly, in the future.
        See Commits:
            b479871e9d38d8245874bc6cffc2f72e93f6cd5a
            c638d67cd856cc09e2e937c5a7da3dc9e0743952
            93956d00d4bb933236c6625cb778eb6ddd5caba4
Added a new function, Link.cleanupByrna() and called it in game_loop() (zelda.cpp).
Added a sfx cleanup for the byrna beam to weapons.cpp.
Added a new LinkClass variable, byte last_cane_of_byrna, that functions similar to
    last_lens_id.
    It inits at -1, then when Link uses a cane, it is set to that cane's ID.
    It is reset to -1 in Link.cleanupByrna().
Added kill_sfx() call to three other possible places where the Cane of Byyrna
    sound should probably be terminated:
    Whenever we call stopCaneOfByrna()
    If we can't pay the cost during item / weapon init
    If the beams aren't created during init, for some reason.
Re-adjust qr_OFFSETEWPNCOLLISIONFIX in qst.cpp, to force it on for 2.50.0 build < 24,
    instead of build |< 29 (as Gleeok forced it).

    I tested SIX quest files, CREATED in three versions of ZQuest:
        2.50.0, bit set off (b24)
        2.50.0, bit set on (b24)
        2.50.1, bit set off (b28)
        2.50.1, bit set on (b28)
        2.50.2, bit set off (b29)
        2.50.2, bit set on (b29)
    If we check build < 29, then quests made in 2.50.0 and possibly 2.50.1 have
    the bit forced on, when it wasn't intended.
    
    Unless the actual BEHAVIOUR of this bit has changed (this needs verification),
    then builds 24, 28, 29, 30, 31, and 32 should never force this bit on.
    
    It is certainly possible that quests made prior to build 24 (2.50.0 release) have this wrong.
    I would need to check every RC to see, and backtrack from there.
    ( ZoriaRPG, 16th February, 2019 )
    
Fixed a secret rupee in Lv9 (1st.qst) not being secret.
    ( NightmareJames, 31st January, 2019; file added to Gamma 3, 14th February, 2019 )
Reverted the patch that stopped Ganon from hurting Link if Link
    is standing on Ganon when Ganon dies.
    We can apply this as a general rule or fix to all enemy behaviour in 2.55.

    The NES Ganon hurts Link.

Cleared Link's attackclk before calling saved_Zelda().
    This prevents a charged sword, or other weapon, from carrying
    over to the ending sequence as a visual artefact.
Stop playing byrna beam sfx as soon as the beams die in Link.cpp
Fix stunned peahats hurting Link in 2.50+ quests.
    ( ZoriaRPG, 14th February, 2019 )


Full Changelog


  • ShadowTiger likes this

#2 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Gender:Male
  • Location:Chicago

Posted 20 February 2019 - 02:35 AM

It's great to see all these fixes and changes coming together and working so well.

Just a few small issues that probably don't need their own threads.

- Screenshots still wonky. In Gamma 1, pressing F12 didn't work at all. You had to hold ctrl+shift+F12 to take a screenshot, and then it would generate a program-resolution image with botched colors in bmp format with a png extension. In Gamma 2 and 3, pressing F12 works again, and now generates a game-resolution image with correct colors in correct format. However, the Gamma 1 resolution/color/format errors can still be recreated while holding shift and pressing F12 in Gammas 2 and 3.

Oddly enough, I traced this shift+F12 error all the way to 2.50.0, and it makes me wonder if the intent was to provide the option of taking program-resolution screenshots rather than game-resolution screenshots by holding a modifier key. It's actually a nice idea, but it should either work correctly, or be dropped entirely.
Reference:
Also, while ZC now supports the new screenshot naming/numbering system, ZQ is still using the old "zelda###.png" system.

- Bottom-right 8-shot projectile facing wrong direction. Originally, both the bottom-left and bottom-right projectiles in 8-shot attacks were facing up rather than sideways. The bottom-left projectile was adjusted for Beta 18, but the bottom-right projectile remains improperly oriented.
Reference:
Should be facing right. (Or perhaps both bottom-left and bottom-right should be facing down?)

Sample Quest - includes 8-shot versions of L4 Octorok, Blue Wizzrobe, Lynel, and Moblin. Mostly centered, always respawn.

(Possible 2.55 feature: allow separate diagonal sprites.)

- Magic Init Data/Link Data entry capped at 3 digits. In ZQuest's Init Data or ZC's Link Data cheat menus, the Magic fields for "Start" and "Max" are capped at 3 digits. However, the Magic Container item's Increase Counter fields for "Max" and "But Not Above" are capped at 5 digits. Picking up enough Magic Containers to push the magic stat beyond 999 will display the 4-digit or 5-digit number correctly in the Link Data cheat window, but these can only be edited after being reduced to 3 digits.
Reference:
Additionally, it's perhaps no surprise that usable magic data can't go higher than 16383, and that increasing the max beyond 32768 resets the magic counter to 0.

#3 ZoriaRPG

ZoriaRPG

    The Timelord

  • ZC Developers
  • Gender:Unspecified
  • Location:Prydon Academy

Posted 21 February 2019 - 04:20 AM

It's great to see all these fixes and changes coming together and working so well.

Just a few small issues that probably don't need their own threads.

- Screenshots still wonky. In Gamma 1, pressing F12 didn't work at all. You had to hold ctrl+shift+F12 to take a screenshot, and then it would generate a program-resolution image with botched colors in bmp format with a png extension. In Gamma 2 and 3, pressing F12 works again, and now generates a game-resolution image with correct colors in correct format. However, the Gamma 1 resolution/color/format errors can still be recreated while holding shift and pressing F12 in Gammas 2 and 3.

Oddly enough, I traced this shift+F12 error all the way to 2.50.0, and it makes me wonder if the intent was to provide the option of taking program-resolution screenshots rather than game-resolution screenshots by holding a modifier key. It's actually a nice idea, but it should either work correctly, or be dropped entirely.
zc-wonkyscreens-01.png


It isn't an error. Pressing LShift or LCtl (IDR which) takes an image of the entire interface, and the other key captures using a specific palette. It's sort of silly, and not well documented, but it has been there since 2.10 or so.

Pressing the modifier keys worked because they called an alternate screenshot function. The bug was caused by a sprintf() call with an invalid parameter.

 

First, a normal F12 screenshot.

zc-wonkyscreens-02.png

Next, a shift+F12 screenshot. On first usage, it generates an entirely black image, formatted as a 1.2MB bmp but named with a png extension. ZC will generate blacked-out screenshots like this until you bring up the program menus by either clicking the screen or pressing escape.

zc-wonkyscreens-03.png

Finally, a shift+F12 screenshot after accessing the program menus and returning to the game. All screenshots from this point forward generate botched colors like these.

(In my case, I run the program at 1280x960 windowed.)


I'll try to repicate this, but I don't recall running into it. I can't imagine what causes it, either, unless the palette being used in this format isn't loaded until you use the menus.
 

Also, while ZC now supports the new screenshot naming/numbering system, ZQ is still using the old "zelda###.png" system.


Frick.
 

- Bottom-right 8-shot projectile facing wrong direction. Originally, both the bottom-left and bottom-right projectiles in 8-shot attacks were facing up rather than sideways. The bottom-left projectile was adjusted for Beta 18, but the bottom-right projectile remains improperly oriented.

Reference:
Should be facing right. (Or perhaps both bottom-left and bottom-right should be facing down?)

Sample Quest - includes 8-shot versions of L4 Octorok, Blue Wizzrobe, Lynel, and Moblin. Mostly centered, always respawn.

(Possible 2.55 feature: allow separate diagonal sprites.)


Also frick, but I'll look into it.
 

- Magic Init Data/Link Data entry capped at 3 digits. In ZQuest's Init Data or ZC's Link Data cheat menus, the Magic fields for "Start" and "Max" are capped at 3 digits. However, the Magic Container item's Increase Counter fields for "Max" and "But Not Above" are capped at 5 digits. Picking up enough Magic Containers to push the magic stat beyond 999 will display the 4-digit or 5-digit number correctly in the Link Data cheat window, but these can only be edited after being reduced to 3 digits.

Reference:
Additionally, it's perhaps no surprise that usable magic data can't go higher than 16383, and that increasing the max beyond 32768 resets the magic counter to 0.


I'll check this too, but I could swear that I fixed this in 2.53 at some point. Looks as if I only fixed Max bombs.
 
//Beta 18.1
Fixed the Cheat Menu 'Max Bombs' so that it is possible to set 
any value from 0 to 0xFFFF.

	( ZoriaRPG, 25th September, 2018 )
On a more pragmatic point: How often have any of us set Max Magic to such a high initial number? (Life is in hearts, so, you can set it to a number beyond reasonable.)

This is a one line fix, fwiw. The jwin dialogue had the number of digits for that text box capped at 3. Well, two lines, counting the cheats version of the dialogue.

#4 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Gender:Male
  • Location:Chicago

Posted 22 February 2019 - 06:36 AM

It isn't an error. Pressing LShift or LCtl (IDR which) takes an image of the entire interface, and the other key captures using a specific palette. It's sort of silly, and not well documented, but it has been there since 2.10 or so.

It's either shift key. (Can programs even differentiate between the left and right ones? I thought they were just duplicate keys.)

And it's a nice function then. Just needs to output in the correct color, once it starts outputting at all.

I'll try to repicate this, but I don't recall running into it. I can't imagine what causes it, either, unless the palette being used in this format isn't loaded until you use the menus.

For reference, I was using the Windows DirectDraw display driver.

I tried again using the Windows GDI (Slow) display driver and got the same result, so it seems to happen independent of display drivers.

(Probably obvious, but still...)

I'll check this too, but I could swear that I fixed this in 2.53 at some point. Looks as if I only fixed Max bombs.

I remember max bombs being fixed. I don't think magic was ever brought up. If it was, it probably wasn't by me. I came across it once before, but according to my reports file, I forgot about it until now.

On a more pragmatic point: How often have any of us set Max Magic to such a high initial number? (Life is in hearts, so, you can set it to a number beyond reasonable.)

Oh it's not remotely practical at all. I just prod and report whatever limits I find and break. The team can determine how significant they are. If there's one thing I've learned tracking bugs over the years, it's to never underestimate what seemingly insignificant issues can lead to genuinely fatal ones. I mean, look what the stray palette cycle data uncovered.

As far as personal application goes, I had a 16-magic-container quest that I'd occasionally try to set to a 1024 init to test. For an update, I had to split each container into double containers and accordingly double/halve the functionality of the other magic items in the game because the Boots drain magic way too fast and that was the only way to cut their drain rate in half. That resulted in needing a 2048 magic init sometimes. But I haven't tested it for a while, so that's why I forgot until now.

#5 ZoriaRPG

ZoriaRPG

    The Timelord

  • ZC Developers
  • Gender:Unspecified
  • Location:Prydon Academy

Posted 25 February 2019 - 09:13 PM

It's either shift key. (Can programs even differentiate between the left and right ones? I thought they were just duplicate keys.)

And it's a nice function then. Just needs to output in the correct color, once it starts outputting at all.
For reference, I was using the Windows DirectDraw display driver.

I tried again using the Windows GDI (Slow) display driver and got the same result, so it seems to happen independent of display drivers.

(Probably obvious, but still...)
I remember max bombs being fixed. I don't think magic was ever brought up. If it was, it probably wasn't by me. I came across it once before, but according to my reports file, I forgot about it until now.
Oh it's not remotely practical at all. I just prod and report whatever limits I find and break. The team can determine how significant they are. If there's one thing I've learned tracking bugs over the years, it's to never underestimate what seemingly insignificant issues can lead to genuinely fatal ones. I mean, look what the stray palette cycle data uncovered.

As far as personal application goes, I had a 16-magic-container quest that I'd occasionally try to set to a 1024 init to test. For an update, I had to split each container into double containers and accordingly double/halve the functionality of the other magic items in the game because the Boots drain magic way too fast and that was the only way to cut their drain rate in half. That resulted in needing a 2048 magic init sometimes. But I haven't tested it for a while, so that's why I forgot until now.

 

Max/Starting Magic should be fixed. The screenshot thing, is well, basically how it works. I haven't had a chance to look into why it isn't working as it should for those options, but they're archaic. I'm not sure if we should revise them, strip them, or leave them be.

 

I'm honestly unsure if anyone uses that particular feature. Can you tell me if it is identical in 2.50.2 please?



#6 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Gender:Male
  • Location:Chicago

Posted 27 February 2019 - 12:08 PM

I'm honestly unsure if anyone uses that particular feature.

I only found it by accident while trying to shake the habit of using Gamma 1's modifier keys, so that may be telling.

Can you tell me if it is identical in 2.50.2 please?

It behaves the same in all 2.5x.x versions.

#7 Omega

Omega

    Yes

  • Members
  • Gender:Male

Posted 28 February 2019 - 08:52 PM

Why does ZQuest in full screen look all discolored and orange on windows 7? Including older versions that worked fine on my Windows 7 laptop.



Also tagged with one or more of these keywords: Gamma, Release Candidate, 2.53

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users