Update to v106r35 release.
byuu says:
Changelog:
- sfc/ppu-fast: fixed overscan crash
- sfc/ppu-fast: fixed direct color mode
- sfc: reconnected MSU1 support
- higan: game.sfc/msu1/data.rom, game.sfc/msu1/track-#.pcm
- bsnes: game.msu, game-#.pcm
- bsnes: added cheat code editor
- bsnes: added cheat code database support
- sfc/ppu-fast: clear overscan lines when overscan disabled
- sfc: output 223/239 lines instead of 224/240 lines
- bsnes: fix aspect correction calculation
- bsnes: crop line 224 when overscan masking is enabled
- bsnes: exposed Expansion Port menu; but hid “21fx” from the list of
devices
- bsnes: tools menu is hidden until a game is loaded
- ruby/input/keyboard/quartz: fixed compilation error
So only bsnes the automated overscan cropping option. In higan, you can
crop however many lines you like from the top or bottom of the image.
But for bsnes, it automatically eats sixteen lines. My view right now is
that if bsnes is meant to be the casual gaming emulator, that it should
eat line 224 in this mode. Most games show content here, but because of
the way the SNES PPU works, the very last line ends up on its very own
tile row (line 0 isn't rendered), if the scroll registers don't account
for it. There's a small number of games that will draw junk data to the
very last scanline of the frame as a result of this. So I chose, at
least for now, to hide it. Users can obviously disable overscan cropping
to see this scanline. I'm open to being convinced not to do this, if
someone has a compelling reason.
We're pretty much screwed one way or the other with no overscan masking.
If we output 239 lines, then most games will render 7 blank lines + 224
drawn lines + 8 blank lines, and the black top and bottom aren't
centered. But if we output 240 lines to get 8 + 224 + 8, then games that
do use overscan will have a blank line at the very bottom of the window.
I'm also trying out a modified cheat code file format. It's been forever
since I bothered to look at it, and the “cartridge” parent node doesn't
match what I'm doing with trying to rename “cartridge” to “game” in
manifests. And indeed, the idea of requiring a root node is rather
superfluous for a cheat code file. Current format looks like this:
cheat
description: foo
code: 7e2000=20+7e2001=30?40
enabled
cheat
description: bar
code: 7e4000=80
Open to discussing this, and I'd like to sync up with Snes9X before they
push out a new release, and I'll agree to finalize and never change this
format again.
I chose to use .cht for the extension when using game files (eg
gamename.cht)
2018-06-03 13:14:42 +00:00
|
|
|
struct CheatDatabase : Window {
|
|
|
|
CheatDatabase();
|
|
|
|
auto findCheats() -> void;
|
|
|
|
auto addCheats() -> void;
|
|
|
|
|
|
|
|
public:
|
|
|
|
VerticalLayout layout{this};
|
|
|
|
ListView cheatList{&layout, Size{~0, ~0}};
|
|
|
|
HorizontalLayout controlLayout{&layout, Size{~0, 0}};
|
|
|
|
Button selectAllButton{&controlLayout, Size{100, 0}};
|
|
|
|
Button unselectAllButton{&controlLayout, Size{100, 0}};
|
|
|
|
Widget spacer{&controlLayout, Size{~0, 0}};
|
|
|
|
Button addCheatsButton{&controlLayout, Size{100, 0}};
|
|
|
|
};
|
|
|
|
|
2018-06-04 02:44:57 +00:00
|
|
|
struct CheatWindow : Window {
|
|
|
|
CheatWindow();
|
|
|
|
auto show(TableViewItem item = {}) -> void;
|
|
|
|
auto doChange() -> void;
|
|
|
|
auto doAccept() -> void;
|
|
|
|
|
|
|
|
public:
|
|
|
|
TableViewItem item;
|
|
|
|
|
|
|
|
VerticalLayout layout{this};
|
|
|
|
HorizontalLayout nameLayout{&layout, Size{~0, 0}};
|
|
|
|
Label nameLabel{&nameLayout, Size{40, 0}};
|
|
|
|
LineEdit nameValue{&nameLayout, Size{~0, 0}};
|
|
|
|
HorizontalLayout codeLayout{&layout, Size{~0, 0}};
|
|
|
|
Label codeLabel{&codeLayout, Size{40, 0}};
|
|
|
|
LineEdit codeValue{&codeLayout, Size{~0, 0}};
|
|
|
|
HorizontalLayout controlLayout{&layout, Size{~0, 0}};
|
|
|
|
Widget spacer{&controlLayout, Size{40, 0}};
|
|
|
|
CheckLabel enabledOption{&controlLayout, Size{~0, 0}};
|
|
|
|
Button acceptButton{&controlLayout, Size{80, 0}};
|
|
|
|
Button cancelButton{&controlLayout, Size{80, 0}};
|
|
|
|
};
|
|
|
|
|
|
|
|
struct CheatEditor : TabFrameItem {
|
|
|
|
CheatEditor(TabFrame*);
|
|
|
|
auto swap(uint x, uint y) -> void;
|
|
|
|
auto synchronizeCodes() -> void;
|
|
|
|
auto addCheat(string name, string code, bool enabled = false) -> void;
|
|
|
|
auto loadCheats() -> void;
|
|
|
|
auto saveCheats() -> void;
|
|
|
|
|
|
|
|
public:
|
|
|
|
VerticalLayout layout{this};
|
|
|
|
TableView cheatList{&layout, Size{~0, ~0}};
|
|
|
|
HorizontalLayout controlLayout{&layout, Size{~0, 0}};
|
|
|
|
Button upButton{&controlLayout, Size{0, 0}};
|
|
|
|
Button downButton{&controlLayout, Size{0, 0}};
|
|
|
|
Button findCheatsButton{&controlLayout, Size{120, 0}};
|
|
|
|
Widget spacer{&controlLayout, Size{~0, 0}};
|
|
|
|
Button resetButton{&controlLayout, Size{80, 0}};
|
|
|
|
Button appendButton{&controlLayout, Size{80, 0}};
|
|
|
|
Button modifyButton{&controlLayout, Size{80, 0}};
|
|
|
|
Button removeButton{&controlLayout, Size{80, 0}};
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
Update to v106r35 release.
byuu says:
Changelog:
- sfc/ppu-fast: fixed overscan crash
- sfc/ppu-fast: fixed direct color mode
- sfc: reconnected MSU1 support
- higan: game.sfc/msu1/data.rom, game.sfc/msu1/track-#.pcm
- bsnes: game.msu, game-#.pcm
- bsnes: added cheat code editor
- bsnes: added cheat code database support
- sfc/ppu-fast: clear overscan lines when overscan disabled
- sfc: output 223/239 lines instead of 224/240 lines
- bsnes: fix aspect correction calculation
- bsnes: crop line 224 when overscan masking is enabled
- bsnes: exposed Expansion Port menu; but hid “21fx” from the list of
devices
- bsnes: tools menu is hidden until a game is loaded
- ruby/input/keyboard/quartz: fixed compilation error
So only bsnes the automated overscan cropping option. In higan, you can
crop however many lines you like from the top or bottom of the image.
But for bsnes, it automatically eats sixteen lines. My view right now is
that if bsnes is meant to be the casual gaming emulator, that it should
eat line 224 in this mode. Most games show content here, but because of
the way the SNES PPU works, the very last line ends up on its very own
tile row (line 0 isn't rendered), if the scroll registers don't account
for it. There's a small number of games that will draw junk data to the
very last scanline of the frame as a result of this. So I chose, at
least for now, to hide it. Users can obviously disable overscan cropping
to see this scanline. I'm open to being convinced not to do this, if
someone has a compelling reason.
We're pretty much screwed one way or the other with no overscan masking.
If we output 239 lines, then most games will render 7 blank lines + 224
drawn lines + 8 blank lines, and the black top and bottom aren't
centered. But if we output 240 lines to get 8 + 224 + 8, then games that
do use overscan will have a blank line at the very bottom of the window.
I'm also trying out a modified cheat code file format. It's been forever
since I bothered to look at it, and the “cartridge” parent node doesn't
match what I'm doing with trying to rename “cartridge” to “game” in
manifests. And indeed, the idea of requiring a root node is rather
superfluous for a cheat code file. Current format looks like this:
cheat
description: foo
code: 7e2000=20+7e2001=30?40
enabled
cheat
description: bar
code: 7e4000=80
Open to discussing this, and I'd like to sync up with Snes9X before they
push out a new release, and I'll agree to finalize and never change this
format again.
I chose to use .cht for the extension when using game files (eg
gamename.cht)
2018-06-03 13:14:42 +00:00
|
|
|
struct CheatEditor : TabFrameItem {
|
|
|
|
enum : uint { Slots = 128 };
|
|
|
|
|
|
|
|
CheatEditor(TabFrame*);
|
|
|
|
auto doChangeSelected() -> void;
|
|
|
|
auto doModify() -> void;
|
|
|
|
auto doRefresh() -> void;
|
|
|
|
auto doReset(bool force = false) -> void;
|
|
|
|
auto doErase() -> void;
|
|
|
|
auto synchronizeCodes() -> void;
|
|
|
|
auto addCode(bool enabled, string code, string description) -> bool;
|
|
|
|
auto loadCheats() -> void;
|
|
|
|
auto saveCheats() -> void;
|
|
|
|
|
|
|
|
public:
|
|
|
|
struct Cheat {
|
|
|
|
bool enabled = false;
|
|
|
|
string code;
|
|
|
|
string description;
|
|
|
|
};
|
|
|
|
Cheat cheats[Slots];
|
|
|
|
|
|
|
|
VerticalLayout layout{this};
|
|
|
|
TableView cheatList{&layout, Size{~0, ~0}};
|
|
|
|
HorizontalLayout codeLayout{&layout, Size{~0, 0}};
|
|
|
|
Label codeLabel{&codeLayout, Size{70, 0}};
|
|
|
|
LineEdit codeValue{&codeLayout, Size{~0, 0}};
|
|
|
|
HorizontalLayout descriptionLayout{&layout, Size{~0, 0}};
|
|
|
|
Label descriptionLabel{&descriptionLayout, Size{70, 0}};
|
|
|
|
LineEdit descriptionValue{&descriptionLayout, Size{~0, 0}};
|
|
|
|
HorizontalLayout controlLayout{&layout, Size{~0, 0}};
|
|
|
|
Button findCodesButton{&controlLayout, Size{120, 0}};
|
|
|
|
Widget spacer{&controlLayout, Size{~0, 0}};
|
|
|
|
Button resetButton{&controlLayout, Size{80, 0}};
|
|
|
|
Button eraseButton{&controlLayout, Size{80, 0}};
|
|
|
|
};
|
2018-06-04 02:44:57 +00:00
|
|
|
*/
|
Update to v106r35 release.
byuu says:
Changelog:
- sfc/ppu-fast: fixed overscan crash
- sfc/ppu-fast: fixed direct color mode
- sfc: reconnected MSU1 support
- higan: game.sfc/msu1/data.rom, game.sfc/msu1/track-#.pcm
- bsnes: game.msu, game-#.pcm
- bsnes: added cheat code editor
- bsnes: added cheat code database support
- sfc/ppu-fast: clear overscan lines when overscan disabled
- sfc: output 223/239 lines instead of 224/240 lines
- bsnes: fix aspect correction calculation
- bsnes: crop line 224 when overscan masking is enabled
- bsnes: exposed Expansion Port menu; but hid “21fx” from the list of
devices
- bsnes: tools menu is hidden until a game is loaded
- ruby/input/keyboard/quartz: fixed compilation error
So only bsnes the automated overscan cropping option. In higan, you can
crop however many lines you like from the top or bottom of the image.
But for bsnes, it automatically eats sixteen lines. My view right now is
that if bsnes is meant to be the casual gaming emulator, that it should
eat line 224 in this mode. Most games show content here, but because of
the way the SNES PPU works, the very last line ends up on its very own
tile row (line 0 isn't rendered), if the scroll registers don't account
for it. There's a small number of games that will draw junk data to the
very last scanline of the frame as a result of this. So I chose, at
least for now, to hide it. Users can obviously disable overscan cropping
to see this scanline. I'm open to being convinced not to do this, if
someone has a compelling reason.
We're pretty much screwed one way or the other with no overscan masking.
If we output 239 lines, then most games will render 7 blank lines + 224
drawn lines + 8 blank lines, and the black top and bottom aren't
centered. But if we output 240 lines to get 8 + 224 + 8, then games that
do use overscan will have a blank line at the very bottom of the window.
I'm also trying out a modified cheat code file format. It's been forever
since I bothered to look at it, and the “cartridge” parent node doesn't
match what I'm doing with trying to rename “cartridge” to “game” in
manifests. And indeed, the idea of requiring a root node is rather
superfluous for a cheat code file. Current format looks like this:
cheat
description: foo
code: 7e2000=20+7e2001=30?40
enabled
cheat
description: bar
code: 7e4000=80
Open to discussing this, and I'd like to sync up with Snes9X before they
push out a new release, and I'll agree to finalize and never change this
format again.
I chose to use .cht for the extension when using game files (eg
gamename.cht)
2018-06-03 13:14:42 +00:00
|
|
|
|
|
|
|
struct ToolsWindow : Window {
|
|
|
|
ToolsWindow();
|
|
|
|
auto setVisible(bool visible = true) -> ToolsWindow&;
|
|
|
|
auto show(uint index) -> void;
|
|
|
|
|
|
|
|
public:
|
|
|
|
VerticalLayout layout{this};
|
|
|
|
TabFrame panel{&layout, Size{~0, ~0}};
|
|
|
|
CheatEditor cheatEditor{&panel};
|
|
|
|
};
|
|
|
|
|
|
|
|
extern unique_pointer<CheatDatabase> cheatDatabase;
|
2018-06-04 02:44:57 +00:00
|
|
|
extern unique_pointer<CheatWindow> cheatWindow;
|
Update to v106r35 release.
byuu says:
Changelog:
- sfc/ppu-fast: fixed overscan crash
- sfc/ppu-fast: fixed direct color mode
- sfc: reconnected MSU1 support
- higan: game.sfc/msu1/data.rom, game.sfc/msu1/track-#.pcm
- bsnes: game.msu, game-#.pcm
- bsnes: added cheat code editor
- bsnes: added cheat code database support
- sfc/ppu-fast: clear overscan lines when overscan disabled
- sfc: output 223/239 lines instead of 224/240 lines
- bsnes: fix aspect correction calculation
- bsnes: crop line 224 when overscan masking is enabled
- bsnes: exposed Expansion Port menu; but hid “21fx” from the list of
devices
- bsnes: tools menu is hidden until a game is loaded
- ruby/input/keyboard/quartz: fixed compilation error
So only bsnes the automated overscan cropping option. In higan, you can
crop however many lines you like from the top or bottom of the image.
But for bsnes, it automatically eats sixteen lines. My view right now is
that if bsnes is meant to be the casual gaming emulator, that it should
eat line 224 in this mode. Most games show content here, but because of
the way the SNES PPU works, the very last line ends up on its very own
tile row (line 0 isn't rendered), if the scroll registers don't account
for it. There's a small number of games that will draw junk data to the
very last scanline of the frame as a result of this. So I chose, at
least for now, to hide it. Users can obviously disable overscan cropping
to see this scanline. I'm open to being convinced not to do this, if
someone has a compelling reason.
We're pretty much screwed one way or the other with no overscan masking.
If we output 239 lines, then most games will render 7 blank lines + 224
drawn lines + 8 blank lines, and the black top and bottom aren't
centered. But if we output 240 lines to get 8 + 224 + 8, then games that
do use overscan will have a blank line at the very bottom of the window.
I'm also trying out a modified cheat code file format. It's been forever
since I bothered to look at it, and the “cartridge” parent node doesn't
match what I'm doing with trying to rename “cartridge” to “game” in
manifests. And indeed, the idea of requiring a root node is rather
superfluous for a cheat code file. Current format looks like this:
cheat
description: foo
code: 7e2000=20+7e2001=30?40
enabled
cheat
description: bar
code: 7e4000=80
Open to discussing this, and I'd like to sync up with Snes9X before they
push out a new release, and I'll agree to finalize and never change this
format again.
I chose to use .cht for the extension when using game files (eg
gamename.cht)
2018-06-03 13:14:42 +00:00
|
|
|
extern unique_pointer<ToolsWindow> toolsWindow;
|