Jump to content

Photo

[2.50+] ZQuest: palette blackouts on screens/combo/tile pages


  • Please log in to reply
6 replies to this topic

#1 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Location:Chicago

Posted 26 January 2019 - 08:12 PM

When working in any version of ZQuest from 2.50.0 and forward, certain swatches of certain palettes will black out in certain quests and certain tilesets.

Which swatches and which palettes seems to vary between .qst files.

Two examples:

Palette Blackout - DoR:H Edition
Palette Blackout - Z3 Module Edition

So let's say you're working in the Dance of Remembrance: Hybrid tileset. You're moving around the map, looking at different screens.

Eventually you come to a screen using Palette 03B - "Deluge Forest."

For a brief moment, you see the full screen:

zq-palblackout-dorh-samplescreen-01a.png

But then, a fraction of a second later, you only see part of the screen:

zq-palblackout-dorh-samplescreen-01b.png

This blackout resets every time you move to a different screen that uses Palette 03B, even if the previous screen was already using that palette.

If you access Palette 03B through the level palette editor, all the colors are there:

zq-palblackout-dorh-03-B-levelview-crop.

However, the blackout carries over to the combo and tile pages, and if you try to view or edit a tile, this is what CSets 2, 3, and 4 look like:

zq-palblackout-dorh-03-B-tileview.png

If you open the "DoR:H Edition" test file above, you'll get a cluster of 4 screens using this palette in the upper left of Map 1, along with another 4 screens using different palettes to the right. Switch between these and see the blackout happen for Palette 03B, but none of the others.

What's strange is that it seems to be related to the palette slots, not the palettes themselves, which brings me to my second example.

In the Z3 module, you may have noticed that Palettes 031 and 032 are "Dark World L1" and "Dark World L2," while Palettes 03A and 03B have entries called "Dark World L1TMP" and "Dark World L2TMP."

If you open the "Z3 Module Edition" test file above, you'll see why. There's another cluster of 4 screens in the upper left of Map 1, but this time the top row uses Palettes 031 and 032, while the bottom row uses Palettes 03A and 03B.

As before, accessing Palettes 031 and 032 through the level palette editor displays all the colors:

zq-palblackout-z3m-032-levelview-crop.pn

And as before, the blackout carries over to the combo and tile pages. However, if you try to view or edit a tile, you'll see a different series of swatches blacked out between CSets 2, 3, and 4:

zq-palblackout-z3m-032-tileview.png

Palettes 03A and 03B are unmodified copies of Palettes 031 and 032, so clearly it's not a specific combination of colors that is triggering this. However, incidents of this are so inconsistent, I have no idea what could be the trigger. All I can say is that I've only ever seen it happen to level palette colors, not main colors, and not CSet 9.

#2 Saffith

Saffith

    IPv7 user

  • ZC Developers

Posted 26 January 2019 - 09:53 PM

It's palette cycling. Click the Cycle button in the palette editor and set everything to 0, and it should be fine.

This is a remnant of corruption or some other weirdness in the default quest a long time ago. It's been fixed, but it's part of the quest file, so any affected quests need fixed individually.

#3 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Location:Chicago

Posted 27 January 2019 - 02:26 AM

Weird.

I wonder how the cycle data got so randomly scattered, but then I guess that's what corruption is.

Anyway, I changed the cycle data and the files are fixed. So, looks like it's not a ZQ bug, thankfully.

It does bring up another point though. When I said I copied the 2 palettes in Z3 Module to new slots, and they worked, that's exactly what I did. Which means, the palette copy function isn't copying cycle information. Which is why it never would have occurred to me to check cycle data. I guess that's a different potential bug though. For now, this topic's resolved.

#4 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 29 January 2019 - 05:21 AM

It's palette cycling. Click the Cycle button in the palette editor and set everything to 0, and it should be fine.

This is a remnant of corruption or some other weirdness in the default quest a long time ago. It's been fixed, but it's part of the quest file, so any affected quests need fixed individually.

 

When was this fixed in the default quest file? I'd like to confirm that the issue is not in the default packages for 2.53 and 2.55.



#5 Saffith

Saffith

    IPv7 user

  • ZC Developers

Posted 04 February 2019 - 10:55 AM

I believe it was build 1820. If you want to verify it's fixed, just check whether palette 03B has any palette cycling set up in a new quest.

#6 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Location:Chicago

Posted 17 February 2019 - 12:07 AM

Palette 03B isn't actually an issue since 2.50 versions. The reason the DoR:H tileset has garbage data in palette 03B is likely because it was ported over from earlier versions of the tileset created in 1.92 B182.

The Z3 module was initially created using 2.50.2, which apparently has a different collection of garbage data scattered about.

I went through the default quest in 2.53.0 Gamma 3 and confirmed following palettes have cycle data that needs to be cleared:

031
032
056
057
058
059

I checked individual palettes up to 09F, because this is exceptionally tedious and that seemed like a good place to stop. That covers the first literal 160 palettes, which should be more than anybody would ever use.

I did, however, spot-check a few later palettes out of curiosity, and found that 100-104 also had garbage data.

Then, starting at 122, every single palette until the end of the list has garbage data. I confirmed 122-19F individually, then spot-checked 1A0-1FF. This is all using 2.53.0 Gamma 3.

Further, the data regarding palettes 000-09F is true starting in 2.50.0 and carrying through 2.50.2, 2.53.0 Gamma 3, and 2.55 Alpha 12. However, 2.55 Alpha 12 expands the 100's garbage data range up to 107 instead of 104, but a spot check of 122+ indicates most of those palettes don't have garbage data, whereas in 2.50.x, a lot of the palettes had garbage data, but some didn't.

So the corruption level seems to be changing as versions progress, increasing from 2.50.x to 2.53.0, then decreasing in 2.55.

tbh, you may just want to automate a program that resets all palette cycle data to 0. This isn't just the default quest, it's in the Z3 module, and probably any other module bases you want to use as well.

#7 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 17 February 2019 - 01:52 AM

Palette 03B isn't actually an issue since 2.50 versions. The reason the DoR:H tileset has garbage data in palette 03B is likely because it was ported over from earlier versions of the tileset created in 1.92 B182.

The Z3 module was initially created using 2.50.2, which apparently has a different collection of garbage data scattered about.

I went through the default quest in 2.53.0 Gamma 3 and confirmed following palettes have cycle data that needs to be cleared:

031
032
056
057
058
059

I checked individual palettes up to 09F, because this is exceptionally tedious and that seemed like a good place to stop. That covers the first literal 160 palettes, which should be more than anybody would ever use.

I did, however, spot-check a few later palettes out of curiosity, and found that 100-104 also had garbage data.

Then, starting at 122, every single palette until the end of the list has garbage data. I confirmed 122-19F individually, then spot-checked 1A0-1FF. This is all using 2.53.0 Gamma 3.

Further, the data regarding palettes 000-09F is true starting in 2.50.0 and carrying through 2.50.2, 2.53.0 Gamma 3, and 2.55 Alpha 12. However, 2.55 Alpha 12 expands the 100's garbage data range up to 107 instead of 104, but a spot check of 122+ indicates most of those palettes don't have garbage data, whereas in 2.50.x, a lot of the palettes had garbage data, but some didn't.

So the corruption level seems to be changing as versions progress, increasing from 2.50.x to 2.53.0, then decreasing in 2.55.

tbh, you may just want to automate a program that resets all palette cycle data to 0. This isn't just the default quest, it's in the Z3 module, and probably any other module bases you want to use as well.

 

Here is the base, default quest file. Do you care to clear this data, if you know precisely which palettes have it?

 

Oh, I see the issue. There are only 256 possible palettes for palette cycling, but 512 palettes, so it's loading nonsensical data. Remember, that the palette IDs are in hex. I can't truly fix this in 2.53, because then, the quest format would not play in 2.50.x. (Cannot add 768 bytes--char [256][3] additional indices--in the middle of QMisc).

 

I'll fix it properly in 2.55. For now, all that I can do (that I have done), is to point a null palette cycle at all level palette cycles where the level is > 0xFF.

 

Gamma 3 should be free of this issue. I am worried about using palettes > 0xFF potentially causing a crash, but I think that the instability that I noticed was caused by trying to write to a palettecycle with an index > 255, and I made that impossible.

 

I also cleared out the palcycle data from the default quest using a special build.

 

If you need a build that does this, in the future, it's easy-enough for me to produce one.




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users