8 replies to this topic

[connor.clark]

https://zquestclassi...eleases/2.55.9/

 

Use this thread to discuss or ask questions about the new changes.

 

Changelog:

 

# Features

 

option to disable transparent darkrooms stacking multiple transparent layers

 

show bottom 8 pixels

  The bottom 8 pixels of the screen has always been hidden. This was

  considered to be a universally bad thing, so they are now visible. A

  compat quest rule is added to control this behavior.

  

  When the bottom 8 pixels are enabled, active subscreens are still just

  168 pixels tall. Instead, active subscreens travel an extra 8 pixels

  when opened.

  

  ZC Player has a setting to configure this too. By default, it defers to

  the QR as defined in the quest, but users can override this.

 

zq: 'Reference Tiles'

  In the tile pages, 'RClick->Set as Reference'. This tile will now display

  on the left-hand side while editing any other tile, as a reference.

 

zscript: Allow '_' to be used as a spacer in numbers

  Ex. 100_000 == 100000, 2_147_483_647L = 2147483647L, 0b10_10_10_10 == 0b10101010

 

zscript: add `Game->HeroScreen`

  In 2.55, this is always equal to `Game->CurScreen`. In 3.0, this updates

  as the player moves around. Added to 2.55 for script compatability.

 

zscript: add `Screen->Index`

  In 2.55, this is always equal to `Game->CurScreen`. In 3.0 scrolling

  regions, the value of this varies depending on the context (for example,

  an npc script will have this set to the screen the enemy spawned on).

 

zscript: add `itemdata::FlashCSet`, improve `itemdata::CSet`

  `itemdata::CSet` contained both the normal and flash csets, and required

  bitwise operations to access. It also didn't allow for setting the flash

  cset. Now, `itemdata::CSet` is only for the normal cset, and the flash

  cset uses the new `itemdata::FlashCSet`.

 

zscript: add `Viewport`

  This global represents the currently visible playing field. In 2.55,

  this is all read-only and only changes during scroll transitions. In

  3.0, the visible viewport can be modified by scripts, and updates as the

  player moves around a scrolling region.

 

zscript: add `Screen->DrawOrigin`

  Determines how coordinates given to Screen drawing functions are

  interpreted. For more, see: https://docs.zquestc...-var-draworigin

 

zscript: more value range types (.., =.., ..=, =..=)

zscript: add `ComboAdjust` for getting combo position offset by some pixels

 

# Bug Fixes

 

 

System menu mouse responsiveness

  Holding left-click and dragging across menus now allows going through

  multiple 'submenus' at once, including going back up to clicked-on

  parent menus. These were features of the old menu system, which were

  lost during the system upgrade.

 

prevent crash when loading midi with 32 tracks

actually fix loading tile data for old 1.90 quests

  2.55.7 (commit be55516) attempted to fix this, but used the wrong path

  to the classic quest. This commit fixes the path, but uses a new qst

  file with only the tile data (since classic_1st.qst is going to be

  removed).

  

  See: https://discord.com/...597114594103378

 

zc: 'Platform' ffcs teleporting the player as the screen loads

zc: Game time shows in-game, even when you've 'cheated'

zc: show hero position in minimap for most special screens

  In the original Zelda, the dot in the minimap rendered even in special

  screens, except for dungeon passageways. ZC was never rendering for any

  special screens. Now, even item cellar / guy special rooms will render

  the dot on the screen the player came from.

 

zc: update dmap charted state more reliably

zc: fix bad memory access when checking for sword tap

zc: prevent OOB related to bridges in `HeroClass::checkchest`

zc: prevent many crashes related to sprite list being full

zc: off-by-one error in y-position world bounds for a few hero attacks

 

  Relevant changes:

    fix(zc): more off-by-one errors

zc: F5 map snapshot works again

zc: some collision issues related to 4-way movement with no-gridlock enabled.

zc: broken 'Z_Eventlog` output related to ExStates

zc: prevent crash when loading save files from 3.0

zq: lockblock/chest combo wizard bad field for counter amount

zq: Mixed weapon listers now show 'E ' before enemy weapons

  Previously, they would, ex., list 'Magic' twice, once for the lweapon and once for the eweapon.

  This changes it to list 'Magic' and 'E Magic' separately.

  This does NOT change listers showing only eweapons, such as the enemy editor's attack field.

 

zq: 'BtnCounter' subscreen widget ui was crunched

std_zh: wrap angle in `AngleDir4` and `AngleDir8`

zscript: keep modifications made during last frames before scrolling

  When scrolling between screens, scripts can run for a few frames just

  before scrolling begins, but modifications to the temporary screen were

  not persisting during the actual scroll.

 

zscript: prevent many out-of-bounds reads/writes

zscript: use correct upper limit when setting itemdata Tile

zscript: properly revert scope when processing class

 

# Refactors

 

remove classic NES quests from release package

zc: show play time even when recording a replay

zq: better error messages related to loading enhanced music files

zq: drop "Load Tileset" and consolidate loading tilesets via File>New

 

# Tests

 

add nargads_trail_crystal_crusades/ffc_carryover.zplay

add freeform_shutters.zplay

 

# CI

 

[win] update vcpkg to 2024.12.16

upgrade actions due to node 16 deprecation

 

 

 

[Twilight Knight]

 

show bottom 8 pixels

  The bottom 8 pixels of the screen has always been hidden. This was

  considered to be a universally bad thing, so they are now visible. A QR

  rule is added to control this behavior, and by default all existing

  quests have been opted into it, except for those known to have issues

  related to script drawing.

I love this feature, but enabling it by default even on old quests seems like a bad idea to me. Because a lot of questmakers designed the screens with the knowledge the bottom 8 pixels wouldn't be visible, potentially hiding some ugly stuff f.e.

 

In addition I don't think it should be a ZC player setting, but a conscious decision by the quest maker. Hiding the bottom 8 pixels is true NES Zelda behaviour, and in the past many questmakers intended to match that.

 

Definitely a feature I will use in my own quests, but I think every quest maker should be in control of this one themselves.

[coolgamer012345]

I love this feature, but enabling it by default even on old quests seems like a bad idea to me. Because a lot of questmakers designed the screens with the knowledge the bottom 8 pixels wouldn't be visible, potentially hiding some ugly stuff f.e.

 

In addition I don't think it should be a ZC player setting, but a conscious decision by the quest maker. Hiding the bottom 8 pixels is true NES Zelda behaviour, and in the past many questmakers intended to match that.

 

Definitely a feature I will use in my own quests, but I think every quest maker should be in control of this one themselves.

tbh I think having it as a player compat option is good. it covers a lot of bases by being both a player and editor option. I am neutral as to whether it's set on by default or not, I could go either way.

[connor.clark]

I don't think it's bad, but we seem to be optimizing for different things, and I believe it's a very small minority of quests that may need to hide those pixels:

 

1) the author really desires that quirk of retro gaming 

2) the quest accidentally shows bad graphics on the half tile row 

3) the quest has script drawing that decided to draw only 168 pixels instead of 176

 

The majority of quests benefit from those pixels being visible. If the proportions were flipped I'd agree it should be treated like any other compat QR, but I think this is overall a slight positive change across nearly all quests. If there are quests that it works poorly for, I suspect it's a small number, and it's not going to be game breaking.

 

However... to the extent that it's not desirable, there are some mitigations:

 

1) there's a hard coded list of quests that treat this as a compat rule. Right now it's just Yuurand, since it has issues with script drawing

2) the player configuration is a release valve for whatever is missed, without needing to wait for a new ZC release (the main reason I included it)

 

BUT: If you know of quests where showing the bottom 8 pixels would result in graphical issues, or if you have authored quests where your preference would be that, please let me know and I will add them to the hardcoded list.

 

 

Hiding the bottom 8 pixels is true NES Zelda behaviour

 

 

There's actually a lot of nuance to this and it isn't strictly true. Here's some videos of people playing Z1.

 

* https://youtu.be/Tpj...3LP7EySK0&t=236(visible)

* https://youtu.be/6g2...MdXnvpsQ&t=2393(hidden)
 

As I understand it, it's not the NES that is not drawing those bottom pixels, but some CRT televisions with certain overscan properties. As such, it's kinda like a real-life Berenstain Bears situation: some people remember it being there on the NES, others don't; but unlike the Berenstein Bears they're both right.

[connor.clark]

Thanks to some speedy testing, a couple bugs were fixed and I've updated the prerelease build linked in the first post.

[Twilight Knight]

Alright, that actually does make sense to me Connor! Then it is a very fine feature.

[Orithan]

 

I don't think it's bad, but we seem to be optimizing for different things, and I believe it's a very small minority of quests that may need to hide those pixels:

 

1) the author really desires that quirk of retro gaming 

2) the quest accidentally shows bad graphics on the half tile row 

3) the quest has script drawing that decided to draw only 168 pixels instead of 176

 

The majority of quests benefit from those pixels being visible. If the proportions were flipped I'd agree it should be treated like any other compat QR, but I think this is overall a slight positive change across nearly all quests. If there are quests that it works poorly for, I suspect it's a small number, and it's not going to be game breaking.

 

However... to the extent that it's not desirable, there are some mitigations:

 

1) there's a hard coded list of quests that treat this as a compat rule. Right now it's just Yuurand, since it has issues with script drawing

2) the player configuration is a release valve for whatever is missed, without needing to wait for a new ZC release (the main reason I included it)

 

BUT: If you know of quests where showing the bottom 8 pixels would result in graphical issues, or if you have authored quests where your preference would be that, please let me know and I will add them to the hardcoded list.

 

 

 

There's actually a lot of nuance to this and it isn't strictly true. Here's some videos of people playing Z1.

 

* https://youtu.be/Tpj...3LP7EySK0&t=236(visible)

* https://youtu.be/6g2...MdXnvpsQ&t=2393(hidden)
 

As I understand it, it's not the NES that is not drawing those bottom pixels, but some CRT televisions with certain overscan properties. As such, it's kinda like a real-life Berenstain Bears situation: some people remember it being there on the NES, others don't; but unlike the Berenstein Bears they're both right.

 

Showing the bottom 8 pixels of the screen should be exclusively an opt-in feature for old quests because old quests were not designed around having it and it being an opt out feature absolutely does not sit right with me in principle. Let the quest authors who are active decide if they want the bottom 8 pixels of the screen be shown in their old quests and then make a list of exceptions for them, rather than enabling it for all old quests and asking quest authors to put their quests on a blacklist.
Right now you are pushing for sweeping changes to the way old quests are displayed without their respective authors' consent and anybody who missed this thread or the discussion on it would have the gameplay experience of their quest changed without their knowledge and it will cause a fair few issues on quests that did not anticipate this change, particularly quests that use scripted dark room drawing effects.

Edited by Orithan, 14 March 2025 - 03:38 PM.

[connor.clark]

Prior I've mentioned only seeing an issue wrt script drawing + bottom pixels in Yuurand, which is still true (I've looked at other potential problem quests and have not _seen_ any issues). However, I realized I could search the ZASM of all quests to find indications of drawing commands that hardcoded a value less than 176 for "filling the screen" - by searching for values of 168, 167, 167.87, etc. This heuristic catches the quests of people that have mentioned writing scripts that could possibly present issues. It was 72 quests. I suspect it's an overcount, but there's a chance it may cover all of the quests that could have issues.

 

> Showing the bottom 8 pixels of the screen should be exclusively an opt-in feature for old quests because old quests were not designed around having it

 

I'm not viewing whether the very bottom pixels are visible or not as the sort of thing that can lead to critical design choices. It's a small implementation detail, and is something that seems pretty difficult to incorporate into the design of a quest on purpose (short of the already mentioned script drawing deficiencies). And if authors want as much control as you suggest, they have options: insist people play in a certain version (or, of course, drop us a message in the Dev Discord).

 

However, in the interest of stability and not making large changes to 2.55, I'll change 2.55 to not display the bottom pixels by default for existing quests.

 

In the meantime, this will remain an improvement applied in 3.0. This can settle in the pre-release builds for awhile and if any large unexpected issues arise it can always be reverted.

 

tldr:

• 2.55 will not enable the bottom 8 pixels by default for existing quests made prior to 2.55.9.
• 3.0 will, but also will include the list of quests I mentioned above as exceptions. If it's found that this creates issues for an existing quest, it should be treated as a bug and reported.

 

I request that further discussion on this as it relates to 3.0 continues in the thread related to this feature on Discord: https://discord.com/...951759581413386

 

[Matthew Bluefox]

Since which version is the waiting time after picking up the Triforce to return to the exit warp (usually overworld) so long? I noticed that in every quest. Is there a ruleset that can be turned on or off to make the waiting time normal again?