Opened 16 years ago

Closed 16 years ago

Last modified 11 months ago

#8333 closed patch (fixed)

BS: Possible fix for cutscene palette issue

Reported by: eriktorbjorn Owned by: SF/ender
Priority: normal Component: Engine: Sword1
Keywords: Cc:
Game: Broken Sword 1


This patch causes the BS cutscene code to rebuild the
lookup table when the "screen changed" event is
received. This should fix Mac palette issues when
changing to/from fullscreen mode, but I have no way of
actually testing this.

It would be nice if there was some heuristic to prevent
it from rebuilding the table unless it's actually
necessary, though. And I haven't even tried to compile
the 8-bit version of the players...

Ticket imported from: #906936. Ticket imported from: patches/438.

Attachments (1)

bs-rebuild.diff (4.8 KB ) - added by eriktorbjorn 16 years ago.
Patch against a February 28 CVS branch snapshot

Download all attachments as: .zip

Change History (12)

by eriktorbjorn, 16 years ago

Attachment: bs-rebuild.diff added

Patch against a February 28 CVS branch snapshot

comment:1 by eriktorbjorn, 16 years ago

Owner: set to SF/ender

comment:2 by fingolfin, 16 years ago

Looks good to me. I'd say, commit it to HEAD. Might consider it for the
0.6.0 branch, too - I see no problems with it, except that 8bit compilation
needs to be tested... and the best way to get that done is to let some
porter run into problems with it, no? 8-)

comment:3 by eriktorbjorn, 16 years ago

Come to think of it, I don't think the patch does any good
if the screen change happens between cutscenes. Only during.
That's because the lookup table lives even after the
cutscene player dies.

On my computer, the delay caused by building the table is
noticeable when it happens during a cutscene, but it's still
less than a second so I don't think I would notice if it was
rebuilt every time a new cutscene is started.

(For reference, my computer is a 450 MHz PIII which, while
it still feels pretty fast to me, is probably on the lower
end of the spectrum nowadays.)

comment:4 by SF/ender, 16 years ago

I'd say commit it to both. AFAIK nobody is actually using the
8-bit stuff, but if it doesn't compile we'll find out soon enough :)

As far as changes so, just keep a static var in the cutscene
class signifying what mode the lookup table was built in
(fullscreen or no) and use property(PROP_GET_FULLSCREEN)
- branch/ getFeatureState(kFeatureFullscreenMode) - head to
check if the table needs to be rebuilt.

comment:5 by fingolfin, 16 years ago

I don't think it's a good idea to let this depend on fullscreen mode or not.
A custom backend could easily, besides scalers and FS mode, offer other
mode switches, which then could also induce a change between 555 and
565 mode.

Rather, how about keeping the output of RGBToColor(255,0,255) and
comparing that. It will catch 555<->565 changes (although it may not
catch all other kind of color changes, but I can't imagine right now which
others there should be...)

comment:6 by fingolfin, 16 years ago

Erhm, why was this still not applied? A pity nobody even responded to
my question... it seems like a very good idea to apply this patch, at least
for Mac users (dunno who else is affected by the problem)...

As it is, I hope it'll be at least in 0.6.1 ?

comment:7 by SF/ender, 16 years ago

I'll commit it tommorow. I was just hoping somebody would
update it based on one of the below suggestions :)

comment:8 by eriktorbjorn, 16 years ago

Don't look at me - I'm the one who has never even seen the
bug in action, remember? :-)

comment:9 by SF/ender, 16 years ago

Commited to 0.6.0, I'll backport this and the .pal changes to head later
today (after release :)

comment:10 by SF/ender, 16 years ago

Resolution: fixed
Status: newclosed

comment:11 by digitall, 11 months ago

Component: Engine: Sword1
Game: Broken Sword 1
Note: See TracTickets for help on using tickets.