#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 |
Description
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)
Change History (12)
by , 21 years ago
| Attachment: | bs-rebuild.diff added |
|---|
comment:1 by , 21 years ago
| Owner: | set to |
|---|
comment:2 by , 21 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 , 21 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 , 21 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 , 21 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 , 21 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 , 21 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 , 21 years ago
Don't look at me - I'm the one who has never even seen the bug in action, remember? :-)
comment:9 by , 21 years ago
Commited to 0.6.0, I'll backport this and the .pal changes to head later today (after release :)
comment:10 by , 21 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:11 by , 6 years ago
| Component: | → Engine: Sword1 |
|---|---|
| Game: | → Broken Sword 1 |
Patch against a February 28 CVS branch snapshot