|
Joined: Aug 2009
Posts: 1,261 Likes: 193
Very Senior Member
|
OP
Very Senior Member
Joined: Aug 2009
Posts: 1,261 Likes: 193 |
Thanks for the info On an unrelated note: Do you know the exact reason about why Puzzle Bobble / Bust-A-Move sprites gets gradually offsetted in vertical?
|
|
|
|
Joined: Jun 2008
Posts: 205
Senior Member
|
Senior Member
Joined: Jun 2008
Posts: 205 |
No, I'll guess that it's related to offset-per-tile mode. Seems silly to use it in puzzle games, but I know there's a version of Tetris that does just that.
|
|
|
|
Joined: Mar 2001
Posts: 17,234 Likes: 260
Very Senior Member
|
Very Senior Member
Joined: Mar 2001
Posts: 17,234 Likes: 260 |
Super Tetris 3 I believe - I fixed a lot of problems that prevented it from starting when I last did major work on the driver, but I wanted no part of offset-per-tile
|
|
|
|
Joined: Dec 2005
Posts: 443
Senior Member
|
Senior Member
Joined: Dec 2005
Posts: 443 |
compared to Mode 5/6, offset per tile is rather straight forward, IMO.
|
|
|
|
Joined: Aug 2009
Posts: 1,261 Likes: 193
Very Senior Member
|
OP
Very Senior Member
Joined: Aug 2009
Posts: 1,261 Likes: 193 |
It's confirmed, Puzzle Bobble uses MIXED gfx modes 1/4, Lines 33-166 is gfx mode 4, gfx mode 1 otherwise. Needless to say, the mode 4 is used on the playfield... I wonder how to handle all of this mode mixing...post processing with a VIDEO_EOF?
|
|
|
|
Joined: Dec 2005
Posts: 443
Senior Member
|
Senior Member
Joined: Dec 2005
Posts: 443 |
I'm confused.
Aside from Mode 5/6, where does mode-mixing matter? Nothing else changes the resolution. The output's all 256 pixels wide for 0-4 and 7, and it's all 15-bit BGR color. How does the mode mixing require a post-process (again, aside from using 5 or 6)?
Now, if it's "when mode 5 is mixed in, we have issues", I can understand that. But Mode 1 and 4 seems like the standard scanline updates should handle this well enough? (ie, as well as you'll get without a dot-based PPU)
|
|
|
|
Joined: Aug 2009
Posts: 1,261 Likes: 193
Very Senior Member
|
OP
Very Senior Member
Joined: Aug 2009
Posts: 1,261 Likes: 193 |
I was talking in general, obviously modes 1/4 doesn't need post processing ;P
|
|
|
|
Joined: Dec 2005
Posts: 443
Senior Member
|
Senior Member
Joined: Dec 2005
Posts: 443 |
Ok. So it's the standard "uh-oh, h resolution doubled" issue every SNES emulator has to deal with.
Most wind up doubling everything up to that point, and from then on as well. No idea what byuu does, so he might have a better way than what the old emulators did.
|
|
|
|
Joined: Aug 2009
Posts: 1,261 Likes: 193
Very Senior Member
|
OP
Very Senior Member
Joined: Aug 2009
Posts: 1,261 Likes: 193 |
Don't know what byuu does, but generally resolution changes are processed at the start of a v-blank, so if we delay the snes_htmult variable to be changed only on these occasions then...
EDIT: still doesn't work, needs post-processing with VIDEO_EOF...
EDIT again: actually my first thought was right but forgot to do a video modification, will finish it soonish...
Last edited by Kale; 08/16/09 01:22 PM.
|
|
|
|
Joined: Aug 2009
Posts: 1,261 Likes: 193
Very Senior Member
|
OP
Very Senior Member
Joined: Aug 2009
Posts: 1,261 Likes: 193 |
Last edited by Kale; 08/16/09 02:06 PM.
|
|
|
2 members (2 invisible),
197
guests, and
0
robots. |
Key:
Admin,
Global Mod,
Mod
|
|
Forums9
Topics9,328
Posts122,128
Members5,074
|
Most Online1,283 Dec 21st, 2022
|
|
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!
|
|
|
|