Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Palettefade Module - a decker module for smoothly fading between palettes

A topic by Millie Squilly created Aug 05, 2024 Views: 599 Replies: 8
Viewing posts 1 to 4
(+4)

I've worked up a Decker module that does a few fun tricks with fading between palettes! Check it out and let me know if you use it! https://micpp.itch.io/palettefade-module


(+3)

This is genius...... i cant wait to use this

(+2)

I look forward to seeing what you do with it!

(+2)

I made an update that I've called version 1.1 of the contraption - now when you use the crossfade effect any buttons won't flicker on and off disabled at the end of the transition

(1 edit)

Hi! I ran into an issue when using the palettefade function, i don’t know if i’m calling it incorrectly or if it’s related to how it interacts with other parts of the script(s).

This is the relevant part (i think) of the deck-level script (the palettes are also defined at this level, i don’t think they’re the culprit since everything worked fine when i only used setpalette):

                  #changes palette depending on the time of day
if t.value=1           
  pf.setpalette[deck morningpalette]
elseif t.value=2
  pf.palettefade[deck morningpalette noonpalette 60]
elseif t.value=3
  pf.palettefade[deck noonpalette sunsetpalette 60]
else
  pf.palettefade[deck sunsetpalette nightpalette 60]
end

t:choice.widgets.time

              #makes time pass(called after spending time at any location)
on timepass do
 t.value:t.value+1
end

and this is the script of one of the cards where the problem occurs:

on view do
 if !visited.value   
 visited.value:1
  sleep[60]
  dd.open[deck (r).speed:3]
  dd.say[scripts.widgets.city.value]
  dd.close[]
 end
end

The card’s script seems to run correctly, but something weird happens when i click on the button (on the same card) with the following script:

on click do
  timepass[]
  dd.open[deck (r).speed:3]
   dd.say["Let's go back."]
  dd.close[]
  if city_seen.value & beach_seen.value & forest_seen.value
   go["night" "SlideLeft"]
  else
   go["choice" "SlideLeft"]
  end
end

i think something goes wrong as soon as timepass[] is called, because right after clicking the button nothing seems to happen but the script keeps running, it just stays like this until i stop it manually:

Am i accidentally creating some sort of event loop (possibly with the animate event)? (?)

Thanks in advance! :>

(1 edit) (+1)

Hi,

So I think the issue is having the pf commands in the root of the script instead of inside an event. I think what's happening is that when palettefade runs, it likely refreshes all the stuff in the root level script, which then gets itself into a loop where it's calling itself over and over. I'm not fully sure myself of the logic of when these are called, generally except for like setting constants (like palettes and such) I put all my logic inside events.

If you put the commands inside the "timepass" event, so that they're only called when this event is called, does that help?


Edit: so I did an experiment with the unlocked version of your deck and this seems to fix things. Remove the setpalette and palettefade commands from the root of the script and put them inside "timepass" like this

on timepass do
 t.value:t.value+1
 if t.value=1           
  pf.setpalette[deck morningpalette]
 elseif t.value=2
  pf.palettefade[deck morningpalette noonpalette 60]
 elseif t.value=3
  pf.palettefade[deck noonpalette sunsetpalette 60]
 else
  pf.palettefade[deck sunsetpalette nightpalette 60]
 end
end
(+1)

Yup, i tried doing the same and it worked perfectly, thank you so much! ✿

Also true, having the logic inside an event seems much safer (especially against unintended consequences like the one i had before), i’m relatively new to programming/writing code but i seem to have a real knack for accidentally creating recursions or infinite rerenders :’D

Developer(+3)

Code you add to the deck-level script is run every time any event is processed. Likewise, code in a card or widget script executes whenever an event is sent to that card (or a widget on the card), or an event is sent to that widget, respectively.

If the top-level script is just defining functions (aka event handlers) and constants this is fine and normal. If there's lots of code it can start to chew up a lot of the per-frame execution quota; this is when you might consider moving some scripts into different cards or modules.

There are some situations where more elaborate "bare" code outside event handlers is useful, but Millie is correct: most of the time, most of your code ought to go inside event handlers so that it only has a chance to start doing things when a specific event occurs.

(+2)

Makes perfect sense, thanks for clarifying! My galaxy brain thought “ah i’ll just put that one if-else in the top-level script so it can constantly and automatically check for the time”, but i definitely see how this kind of uncontrolled approach could very easily backfire, i’ll keep it in mind for the future :)