Opened 20 years ago

Closed 20 years ago

Last modified 6 years ago

#8333 closed patch (fixed)

BS: Possible fix for cutscene palette issue

Reported by: eriktorbjorn Owned by: SF/ender
Priority: normal Component: Engine: Sword1
Version: 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 20 years ago.
Patch against a February 28 CVS branch snapshot

Download all attachments as: .zip

Change History (12)

by eriktorbjorn, 20 years ago

Attachment: bs-rebuild.diff added

Patch against a February 28 CVS branch snapshot

comment:1 by eriktorbjorn, 20 years ago

Owner: set to SF/ender

comment:2 by fingolfin, 20 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, 20 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, 20 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, 20 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, 20 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, 20 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, 20 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, 20 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, 20 years ago

Resolution: fixed
Status: newclosed

comment:11 by digitall, 6 years ago

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