Jump to content

Photo

More Level-Dependent CSets


  • Please log in to reply
10 replies to this topic

#1 P-Tux7

P-Tux7

    💛

  • Members

Posted 04 June 2021 - 11:47 PM

Requested for the Z3 tileset project, and also useful for recreating other 8/16-bit graphics styles such as SMB's two per-level sprite palettes (Goomba colours and Koopa colours). "Static" means that the palette is never changed by ZC at runtime, and "dynamic" means that ZC can update it upon changing DMaps/Levels, or picking up an item in the case of Link.
 
Current ZC:
CSet 0: Static
CSet 1: Static
CSet 2: Dynamic (intended for combos but can be used by any tile)
CSet 3: Dynamic (intended for combos but can be used by any tile)
CSet 4: Dynamic (intended for combos but can be used by any tile)
CSet 5: Static
CSet 6: Dynamic, only changes upon obtaining a Ring. Can be combined with 8-bit mode to have 15 dynamic colours combined with all the other colours (such as dynamic colours for tunic, static colours from another CSet for skin, boots, held shield, held sword, etc.
CSet 7: Static
CSet 8: Static
CSet 9: Dynamic (intended for sprites but can be used by any tile)
CSet 10: Static
CSet 11: Static
CSet 12: Static, unpreviewable in ZQuest. Unknown purpose
CSet 13: Dynamic, only changes upon a boss palette-enabled enemy spawning.
CSet 14: System/Overlay
CSet 15: System/Overlay
 
What I am requesting is for CSets 0, 1, 5, 7, 8, 10, and 11 to be level-dependent (AKA read from the level palette), or at least as many as can be.
 
This would likely also entail a compatibility rule that only loads CSets 2, 3, 4, and 9 from the level palette, so that when running (or even editing) old quests they do not replace colours in any other CSets with the default entry (black).

  • Anthus, Shane, Jared and 2 others like this

#2 Shane

Shane

    💙

  • Moderators
  • Pronouns:He / Him
  • Location:South Australia

Posted 04 June 2021 - 11:56 PM

This would actually be a gamechanger, if it can be implemented.



#3 Emily

Emily

    Scripter / Dev

  • ZC Developers

Posted 05 June 2021 - 07:05 AM

I don't think there's any chance of this


  • Mani Kanina likes this

#4 Mani Kanina

Mani Kanina

    Rabbits!

  • Members

Posted 05 June 2021 - 04:41 PM

I don't see much benefit in this change, in the wast majority of instances you'd want to load in the same ramps for those anyway given all the global elements you'd have in a given quest. Furthermore, 2.55 already supports writing to the the palette yourself via scripts which is way more powerful, so if you wanted true enemy based palette loading you could do that by checking screen enemies and allocating colours to given CSets accordingly.



#5 P-Tux7

P-Tux7

    💛

  • Members

Posted 06 June 2021 - 08:59 PM

I don't see much benefit in this change, in the wast majority of instances you'd want to load in the same ramps for those anyway given all the global elements you'd have in a given quest. Furthermore, 2.55 already supports writing to the the palette yourself via scripts which is way more powerful, so if you wanted true enemy based palette loading you could do that by checking screen enemies and allocating colours to given CSets accordingly.

Firstly, you understand that ALTTP itself disproves this, right? If I could replicate the amount of colour changes that LTTP does when switching between areas, I wouldn't need to request this. Also, I'm not talking about enemy-based palette loading, I'm talking about area-dependent, the kind that changes upon warping. I think the one per-enemy CSet (CSet 13?) already in ZQuest will suffice just fine for bosses. And what's this about changing the palette via scripts? I know in 2.55 you can change the currently-loaded DMap palette via scripts... but that's just the same four that you can do with warps. There's also the tinting feature, but that's, uh... a tint.

 

Timelord has requested a more user-friendly LTTP tileset, and there's already a few out there (Orion's, Phoenix, Dance of Remembrance) so if he feels that he needs a new one before he can add all the scripted LTTP features, I trust him. He doesn't want it to just feel like the SNES game, he wants it to look authentic as well, and this request of mine would go a long way in helping make that more possible than previous ZC versions.


  • Anthus, Shane and Jenny like this

#6 Anthus

Anthus

    Lord of Liquids

  • Members
  • Location:Ohio

Posted 06 June 2021 - 11:11 PM

I will always and forever be a fan of more c-sets/ colors in general. Being limited to 64 unique colors per level palette is a bit of a mood. That said, I know ZC is old as bones, and it is probably really hard to actually do, but it would still be awesome.


  • Shane likes this

#7 Mani Kanina

Mani Kanina

    Rabbits!

  • Members

Posted 07 June 2021 - 10:14 AM

Firstly, you understand that ALTTP itself disproves this, right? If I could replicate the amount of colour changes that LTTP does when switching between areas, I wouldn't need to request this.

Vaguely gesturing in the direction of ALTTP isn't really an argument, and nothing about what I said at all is directly contradicted by ALTTP itself. Because none of the arguments I even made is about ALTTP itself or how it handles colour loading. You're suggesting an engine feature change to ZC and, ZC isn't ALTTP, or even on the snes, so completely different restrictions apply. If you were on the SNES you could code your palette loading as you see fit completely.

But for the sake of clarity I will clarify what exactly I said in my original post and what you're arguing against:

 

1. Given how ZC works, and given what you'd need in a given quest. Turning essentially all global CSets to local ones is a gonna be a waste. And the reason why is because you're going to have global elements that you want to have be the same colours no matter where you are. This really shouldn't be a controversial take. So assuming essentially all global ones are converted to local ones as posed in the original post, most quests or other projects in ZC are going to end up having to load in the same colour ramps in the same CSet for a lot of those anyway in order to keep the global consistency of elements that uses those. How much is obviously going to vary from tileset to tileset and quest project to quest project, but unless you're doing something avant-garde then you're going to have some.

Now the obvious counter argument to what I posed is "okay, but I want more local ones than we have now, and we really don't need 7 global ones, and a better disposition would be more practical". Which I would agree with, but that argument wasn't made. (I guess you could be pedantic and say that the original post read as "as many as can be" to mean as many as practical, but it really sounds more like as many as it's technically feasible to convert within ZC)

2. Next I argued that since you can already with scripts write to CSets to change them dynamically, a lot of the benefits of this proposed change is gone. Now, I will freely admit that I have not used this myself I have simply heard of other scripters talk about it in passing so I did misunderstand the feature slightly. But I did ask around about it before making this reply now, and I don't think it changes my argument too much. Turning all global CSets into local ones obviously means you need to set up enemy CSets locally too, this is not actually bad and is sorta closer to how SNES games do things (since that was an important factor here), so I made my argument based on my experience hacking a SNES game. The scripted feature to be able to write an entire CSet on the spot (which is a 2.55 scripted feature), is extremely relevant here, because that means you could better replicate how the SNES handles it, since it can, when coded to, arbitrarily change part of the loaded palette, rather than all of it. This is extremely useful in the case of enemies since you could have it re-configure CSets on the spot depending on what enemies are on a given screen. But because this feature exists it lessens the need of excessively many local palettes to begin with. Not only that, it's a superior solution because you would save Csets by only keeping as many loaded as you need for the enemies on a given screen.

Personally? I think this sounds like a pain in the arse either way compared to just have a lot of enemies configured in global palettes. And the reason why is that you get a lot more overhead since you need to more carefully manage what enemies go together in a given room without fucking up the palette of other enemies. But it's undoubtedly closer to how some SNES games manages things. But making them all local without also doing this would mean that you have all the downsides of being stuck with an enemy colour set for the entire dungeon without any of the benefits of writing on the spot as needed. Hence why I felt it was relevant.

 

 

Also, I'm not talking about enemy-based palette loading, I'm talking about area-dependent, the kind that changes upon warping. I think the one per-enemy CSet (CSet 13?) already in ZQuest will suffice just fine for bosses.

Anyway, to get back to your reply; I don't think anything I said was that weird given that this is such a sweeping change to how CSets are managed. Therefore the consequences of that should be considered from every angle.

Regardless, you did talk about enemy based palette loading solutions in your original post:

and also useful for recreating other 8/16-bit graphics styles such as SMB's two per-level sprite palettes (Goomba colours and Koopa colours).

 

I would have brought it up anyway though since I think it's relevant here. Since moving away from global palettes completely would mean all enemy palettes would need to be local, right?

 

 

And what's this about changing the palette via scripts? I know in 2.55 you can change the currently-loaded DMap palette via scripts... but that's just the same four that you can do with warps. There's also the tinting feature, but that's, uh... a tint.

This is correct, I was under the impression that it could be done to the global ones too since the way it was talked about made it seem like you could do that to CSet 6 as well, etc. I don't think this changes particularly much though given the arguments made here. I didn't really bring up palette tinting and I don't think that's relevant here, so.

 

 

 

Timelord has requested a more user-friendly LTTP tileset, and there's already a few out there (Orion's, Phoenix, Dance of Remembrance) so if he feels that he needs a new one before he can add all the scripted LTTP features, I trust him.

Now this is just like, completely unrelated to anything I even said or argued, and poses it as if I'm somehow in the opposition to both an alttp tileset being made and Zoria, which I don't think either is true here.
 

He doesn't want it to just feel like the SNES game, he wants it to look authentic as well, and this request of mine would go a long way in helping make that more possible than previous ZC versions.

See, I think a good keyword to take away here is "feel" and "look". The only way to make something be like it's SNES is code it for the SNES or write an engine that operates on the same basis, luckily, we need to do neither in order to make something authentic to the experience of playing a SNES game.

Obviously, this is going to be my own paradigm, but I don't think it should be an controversial take: The important part is replicating the output of SNES games, not the internal mechanics used to get to that output. You could argue that making all CSets local is closer to how the SNES mechanically work, but not only would that not be the full story (it's way more powerful than that), it would also be kinda missing the point.



That being said, after considering things a bit more with this post, I do see the value in converting a few of the global ones to local. Seven is a lot of them and there is really not a need for that many in low colour tilesets where it mostly serves as a convenience, and in higher colour count based tilesets you go through them quicker and more local would be more beneficial than many global. But in that case it seems more reasonable to convert one or two, maybe three, global ones to local, any more than that and you'd in my opinion cause more problems than you'd solve.



#8 Emily

Emily

    Scripter / Dev

  • ZC Developers

Posted 07 June 2021 - 12:42 PM

Proper script control of every element of the palette *IS A PLANNED 2.55 FEATURE ON THE TODO LIST*.


  • Mani Kanina and Deedee like this

#9 Deedee

Deedee

    Bug Frog Dragon Girl

  • Moderators
  • Real Name:Deedee
  • Pronouns:She / Her, They / Them
  • Location:Canada

Posted 08 June 2021 - 11:47 AM

Oh naive mortals who do not yet fathom the true way of ZQuest, I have descended from above to bring you an utmost blessed knowledge:

You can use palette cycling to turn any CSet into a level dependent CSet.

Bless.


  • Valerie likes this

#10 Valerie

Valerie

    Illustrious

  • Members
  • Real Name:Valerie
  • Location:K-Town

Posted 08 June 2021 - 02:31 PM

Oh naive mortals who do not yet fathom the true way of ZQuest, I have descended from above to bring you an utmost blessed knowledge:

You can use palette cycling to turn any CSet into a level dependent CSet.

Bless.

Awesome! I had wondered in the past if that was possible, but never got around to trying it out myself.

#11 P-Tux7

P-Tux7

    💛

  • Members

Posted 08 June 2021 - 05:27 PM

Oh naive mortals who do not yet fathom the true way of ZQuest, I have descended from above to bring you an utmost blessed knowledge:

You can use palette cycling to turn any CSet into a level dependent CSet.

Bless.

Yeah okay but how many can you do that with? It sounds like only one at a time, and I've also heard it has issues with fading (i.e. dark rooms and staircase warps). Wait, do overworld entrances even have fading instead of just iris-ins? I should probably request that...


  • Shane likes this


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users