Opened 22 years ago
Closed 22 years ago
#415 closed defect (fixed)
ZAK256: fades vanish
| Reported by: | SF/logicdeluxe | Owned by: | SF/ender |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Zak McKracken |
Description
Built on Aug 16 2002 11:57:40 win As long as you control Zak, fades are fine. But as soon as you switch to another person, there are no more fades, including controlling Zak again. All scenes then appear instantly.
Ticket imported from: #596018. Ticket imported from: bugs/415.
Attachments (1)
Change History (4)
by , 22 years ago
| Attachment: | zak256.s02 added |
|---|
comment:1 by , 22 years ago
comment:2 by , 22 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:3 by , 22 years ago
I'm going to close this, if the main problem is fixed.
<waves bye-bye and closes the bug>
Note:
See TracTickets
for help on using tickets.
What happens: when a "Switch" is done, apparently o5_oldRoomEffect() gets called, setting _switchRoomEffect to 4 and _switchRoomEffect2 to 0.
But there is no fadein effect 4 (only 1, 2, 3), nor a fadeOut 0 (0 for fadeOut will not do any fading to be precise).
So I looked at how to fix this. It turns out, adding fade mode 4 is trivial, we already have the data table needed for it, we just weren't using it! This is fixed now in CVS.
However, fades still will look weird, because the fadeOut mode is set to 0, which means no fadeout happens, which in turn results in a bad looking fade (palette clashes...). I am not sure if there is ever code that legall sets fadeOut to 0, maybe we just should check for a 0 here and convert it to a 1? But that might break other games. Oh well...