2011-06-24 10:43:29 +00:00
|
|
|
//The Super Scope is a light-gun: it detects the CRT beam cannon position,
|
|
|
|
//and latches the counters by toggling iobit. This only works on controller
|
|
|
|
//port 2, as iobit there is connected to the PPU H/V counter latch.
|
|
|
|
//(PIO $4201.d7)
|
|
|
|
|
2011-06-26 12:51:37 +00:00
|
|
|
//It is obviously not possible to perfectly simulate an IR light detecting
|
|
|
|
//a CRT beam cannon, hence this class will read the PPU raster counters.
|
|
|
|
|
2011-06-24 10:43:29 +00:00
|
|
|
//A Super Scope can still technically be used in port 1, however it would
|
|
|
|
//require manual polling of PIO ($4201.d6) to determine when iobit was written.
|
|
|
|
//Note that no commercial game ever utilizes a Super Scope in port 1.
|
|
|
|
|
2015-10-10 02:16:12 +00:00
|
|
|
SuperScope::SuperScope(bool port) : Controller(port) {
|
Update to v098r12 release.
byuu says:
Changelog:
- higan/video: added support for Emulator::Sprite
- higan/resource: a new system for accessing embedded binary files
inside the emulation cores; holds the sprites
- higan/sfc/superscope,justifier: re-enabled display of crosshairs
- higan/sfc/superscope: fixed turbo toggle (also shows different
crosshair color when in turbo mode)
- higan/sfc/ppu: always outputs at 512x480 resolution now
- causes a slight speed-hit from ~127fps to ~125fps;
- but allows high-resolution 32x32 cursors that look way better;
- also avoids the need to implement sprite scaling logic
Right now, the PPU code to always output at 480-height is a really gross
hack. Don't worry, I'll make that nicer before release.
Also, superscope.cpp and justifier.cpp are built around a 256x240
screen. But since we now have 512x480, we can make the cursor's movement
much smoother by doubling the resolution on both axes. The actual games
won't see any accuracy improvements when firing the light guns, but the
cursors will animate nicer so I think it's still worth it. I'll work on
that before the next release as well.
The current 32x32 cursors are nicer, but we can do better now with full
24-bit color. So feel free to submit alternatives. I'll probably reject
them, but you can always try :D
The sprites don't support alpha blending, just color keying (0x00000000
= transparent; anything else is 0xff......). We can revisit that later
if necessary.
The way I have it designed, the only files that do anything with
Emulator::Sprite at all are the superscope and justifier folders.
I didn't have to add any hooks anywhere else. Rendering the sprite is
a lot cleaner than the old code, too.
2016-05-26 11:20:15 +00:00
|
|
|
create(Controller::Enter, 21'477'272);
|
|
|
|
sprite = Emulator::video.createSprite(32, 32);
|
|
|
|
sprite->setPixels(Resource::Sprite::CrosshairGreen);
|
|
|
|
|
2015-10-10 02:16:12 +00:00
|
|
|
latched = 0;
|
|
|
|
counter = 0;
|
|
|
|
|
|
|
|
//center cursor onscreen
|
|
|
|
x = 256 / 2;
|
|
|
|
y = 240 / 2;
|
|
|
|
|
|
|
|
trigger = false;
|
|
|
|
cursor = false;
|
|
|
|
turbo = false;
|
|
|
|
pause = false;
|
|
|
|
offscreen = false;
|
|
|
|
|
Update to v098r12 release.
byuu says:
Changelog:
- higan/video: added support for Emulator::Sprite
- higan/resource: a new system for accessing embedded binary files
inside the emulation cores; holds the sprites
- higan/sfc/superscope,justifier: re-enabled display of crosshairs
- higan/sfc/superscope: fixed turbo toggle (also shows different
crosshair color when in turbo mode)
- higan/sfc/ppu: always outputs at 512x480 resolution now
- causes a slight speed-hit from ~127fps to ~125fps;
- but allows high-resolution 32x32 cursors that look way better;
- also avoids the need to implement sprite scaling logic
Right now, the PPU code to always output at 480-height is a really gross
hack. Don't worry, I'll make that nicer before release.
Also, superscope.cpp and justifier.cpp are built around a 256x240
screen. But since we now have 512x480, we can make the cursor's movement
much smoother by doubling the resolution on both axes. The actual games
won't see any accuracy improvements when firing the light guns, but the
cursors will animate nicer so I think it's still worth it. I'll work on
that before the next release as well.
The current 32x32 cursors are nicer, but we can do better now with full
24-bit color. So feel free to submit alternatives. I'll probably reject
them, but you can always try :D
The sprites don't support alpha blending, just color keying (0x00000000
= transparent; anything else is 0xff......). We can revisit that later
if necessary.
The way I have it designed, the only files that do anything with
Emulator::Sprite at all are the superscope and justifier folders.
I didn't have to add any hooks anywhere else. Rendering the sprite is
a lot cleaner than the old code, too.
2016-05-26 11:20:15 +00:00
|
|
|
oldturbo = false;
|
2015-10-10 02:16:12 +00:00
|
|
|
triggerlock = false;
|
|
|
|
pauselock = false;
|
|
|
|
|
2016-02-09 11:51:12 +00:00
|
|
|
prev = 0;
|
|
|
|
}
|
2011-06-26 12:51:37 +00:00
|
|
|
|
Update to v098r12 release.
byuu says:
Changelog:
- higan/video: added support for Emulator::Sprite
- higan/resource: a new system for accessing embedded binary files
inside the emulation cores; holds the sprites
- higan/sfc/superscope,justifier: re-enabled display of crosshairs
- higan/sfc/superscope: fixed turbo toggle (also shows different
crosshair color when in turbo mode)
- higan/sfc/ppu: always outputs at 512x480 resolution now
- causes a slight speed-hit from ~127fps to ~125fps;
- but allows high-resolution 32x32 cursors that look way better;
- also avoids the need to implement sprite scaling logic
Right now, the PPU code to always output at 480-height is a really gross
hack. Don't worry, I'll make that nicer before release.
Also, superscope.cpp and justifier.cpp are built around a 256x240
screen. But since we now have 512x480, we can make the cursor's movement
much smoother by doubling the resolution on both axes. The actual games
won't see any accuracy improvements when firing the light guns, but the
cursors will animate nicer so I think it's still worth it. I'll work on
that before the next release as well.
The current 32x32 cursors are nicer, but we can do better now with full
24-bit color. So feel free to submit alternatives. I'll probably reject
them, but you can always try :D
The sprites don't support alpha blending, just color keying (0x00000000
= transparent; anything else is 0xff......). We can revisit that later
if necessary.
The way I have it designed, the only files that do anything with
Emulator::Sprite at all are the superscope and justifier folders.
I didn't have to add any hooks anywhere else. Rendering the sprite is
a lot cleaner than the old code, too.
2016-05-26 11:20:15 +00:00
|
|
|
SuperScope::~SuperScope() {
|
|
|
|
Emulator::video.removeSprite(sprite);
|
|
|
|
}
|
|
|
|
|
2016-02-09 11:51:12 +00:00
|
|
|
auto SuperScope::main() -> void {
|
Update to v098r12 release.
byuu says:
Changelog:
- higan/video: added support for Emulator::Sprite
- higan/resource: a new system for accessing embedded binary files
inside the emulation cores; holds the sprites
- higan/sfc/superscope,justifier: re-enabled display of crosshairs
- higan/sfc/superscope: fixed turbo toggle (also shows different
crosshair color when in turbo mode)
- higan/sfc/ppu: always outputs at 512x480 resolution now
- causes a slight speed-hit from ~127fps to ~125fps;
- but allows high-resolution 32x32 cursors that look way better;
- also avoids the need to implement sprite scaling logic
Right now, the PPU code to always output at 480-height is a really gross
hack. Don't worry, I'll make that nicer before release.
Also, superscope.cpp and justifier.cpp are built around a 256x240
screen. But since we now have 512x480, we can make the cursor's movement
much smoother by doubling the resolution on both axes. The actual games
won't see any accuracy improvements when firing the light guns, but the
cursors will animate nicer so I think it's still worth it. I'll work on
that before the next release as well.
The current 32x32 cursors are nicer, but we can do better now with full
24-bit color. So feel free to submit alternatives. I'll probably reject
them, but you can always try :D
The sprites don't support alpha blending, just color keying (0x00000000
= transparent; anything else is 0xff......). We can revisit that later
if necessary.
The way I have it designed, the only files that do anything with
Emulator::Sprite at all are the superscope and justifier folders.
I didn't have to add any hooks anywhere else. Rendering the sprite is
a lot cleaner than the old code, too.
2016-05-26 11:20:15 +00:00
|
|
|
uint next = cpu.vcounter() * 1364 + cpu.hcounter();
|
Update to v079r06 release.
byuu says:
It does add some more code to the CPU::step() function, so performance
probably went down actually, by about 1%. Removing the input.tick() call
didn't compensate as much as I'd hoped.
Hooked up Super Scope and Justifier support. The good news is that the
Justifier alignment doesn't get fucked up anymore when you go
off-screen. Never could fix that in the old version.
The bad news is that it takes a major speed hit for the time being.
I need to figure out how to run the CPU and input threads out of order.
Every time I try, the input gets thrown off by most of a scanline.
Right now, I'm forced to sync constantly to get the latching position
really accurate. But worst case, I can cut the syncs down by skipping
large chunks around the cursor position, +/-40 clock cycles. So it's
only temporarily slow.
Lastly, killed the old Input class, merged Controllers class into it.
I actually like Controllers as a name better, but it doesn't jive with
video/audio/input, so oh well.
2011-06-25 12:56:32 +00:00
|
|
|
|
Update to v098r12 release.
byuu says:
Changelog:
- higan/video: added support for Emulator::Sprite
- higan/resource: a new system for accessing embedded binary files
inside the emulation cores; holds the sprites
- higan/sfc/superscope,justifier: re-enabled display of crosshairs
- higan/sfc/superscope: fixed turbo toggle (also shows different
crosshair color when in turbo mode)
- higan/sfc/ppu: always outputs at 512x480 resolution now
- causes a slight speed-hit from ~127fps to ~125fps;
- but allows high-resolution 32x32 cursors that look way better;
- also avoids the need to implement sprite scaling logic
Right now, the PPU code to always output at 480-height is a really gross
hack. Don't worry, I'll make that nicer before release.
Also, superscope.cpp and justifier.cpp are built around a 256x240
screen. But since we now have 512x480, we can make the cursor's movement
much smoother by doubling the resolution on both axes. The actual games
won't see any accuracy improvements when firing the light guns, but the
cursors will animate nicer so I think it's still worth it. I'll work on
that before the next release as well.
The current 32x32 cursors are nicer, but we can do better now with full
24-bit color. So feel free to submit alternatives. I'll probably reject
them, but you can always try :D
The sprites don't support alpha blending, just color keying (0x00000000
= transparent; anything else is 0xff......). We can revisit that later
if necessary.
The way I have it designed, the only files that do anything with
Emulator::Sprite at all are the superscope and justifier folders.
I didn't have to add any hooks anywhere else. Rendering the sprite is
a lot cleaner than the old code, too.
2016-05-26 11:20:15 +00:00
|
|
|
if(!offscreen) {
|
|
|
|
uint target = y * 1364 + (x + 24) * 4;
|
2016-02-09 11:51:12 +00:00
|
|
|
if(next >= target && prev < target) {
|
|
|
|
//CRT raster detected, toggle iobit to latch counters
|
|
|
|
iobit(0);
|
|
|
|
iobit(1);
|
Update to v079r06 release.
byuu says:
It does add some more code to the CPU::step() function, so performance
probably went down actually, by about 1%. Removing the input.tick() call
didn't compensate as much as I'd hoped.
Hooked up Super Scope and Justifier support. The good news is that the
Justifier alignment doesn't get fucked up anymore when you go
off-screen. Never could fix that in the old version.
The bad news is that it takes a major speed hit for the time being.
I need to figure out how to run the CPU and input threads out of order.
Every time I try, the input gets thrown off by most of a scanline.
Right now, I'm forced to sync constantly to get the latching position
really accurate. But worst case, I can cut the syncs down by skipping
large chunks around the cursor position, +/-40 clock cycles. So it's
only temporarily slow.
Lastly, killed the old Input class, merged Controllers class into it.
I actually like Controllers as a name better, but it doesn't jive with
video/audio/input, so oh well.
2011-06-25 12:56:32 +00:00
|
|
|
}
|
2016-02-09 11:51:12 +00:00
|
|
|
}
|
Update to v079r06 release.
byuu says:
It does add some more code to the CPU::step() function, so performance
probably went down actually, by about 1%. Removing the input.tick() call
didn't compensate as much as I'd hoped.
Hooked up Super Scope and Justifier support. The good news is that the
Justifier alignment doesn't get fucked up anymore when you go
off-screen. Never could fix that in the old version.
The bad news is that it takes a major speed hit for the time being.
I need to figure out how to run the CPU and input threads out of order.
Every time I try, the input gets thrown off by most of a scanline.
Right now, I'm forced to sync constantly to get the latching position
really accurate. But worst case, I can cut the syncs down by skipping
large chunks around the cursor position, +/-40 clock cycles. So it's
only temporarily slow.
Lastly, killed the old Input class, merged Controllers class into it.
I actually like Controllers as a name better, but it doesn't jive with
video/audio/input, so oh well.
2011-06-25 12:56:32 +00:00
|
|
|
|
2016-02-09 11:51:12 +00:00
|
|
|
if(next < prev) {
|
|
|
|
//Vcounter wrapped back to zero; update cursor coordinates for start of new frame
|
Update to v098r03 release.
byuu says:
It took several hours, but I've rebuilt much of the SNES' bus memory
mapping architecture.
The new design unifies the cartridge string-based mapping
("00-3f,80-bf:8000-ffff") and internal bus.map calls. The map() function
now has an accompanying unmap() function, and instead of a fixed 256
callbacks, it'll scan to find the first available slot. unmap() will
free slots up when zero addresses reference a given slot.
The controllers and expansion port are now both entirely dynamic.
Instead of load/unload/power/reset, they only have the constructor
(power/reset/load) and destructor (unload). What this means is you can
now dynamically change even expansion port devices after the system is
loaded.
Note that this is incredibly dangerous and stupid, but ... oh well. The
whole point of this was for 21fx. There's no way to change the expansion
port device prior to loading a game, but if the 21fx isn't active, then
the reset vector hijack won't work. Now you can load a 21fx game, change
the expansion port device, and simply reset the system to active the
device.
The unification of design between controller port devices and expansion
port devices is nice, and overall this results in a reduction of code
(all of the Mapping stuff in Cartridge is gone, replaced with direct bus
mapping.) And there's always the potential to expand this system more in
the future now.
The big missing feature right now is the ability to push/pop mappings.
So if you look at how the 21fx does the reset vector, you might vomit
a little bit. But ... it works.
Also changed exit(0) to _exit(0) in the POSIX version of nall::execute.
[The _exit(0) thing is an attempt to make higan not crash when it tries
to launch icarus and it's not on $PATH. The theory is that higan forks,
then the child tries to exec icarus and fails, so it exits, all the
unique_ptrs clean up their resources and tell the X server to free
things the parent process is still using. Calling _exit() prevents
destructors from running, and seems to prevent the problem. -Ed.]
2016-04-09 10:21:18 +00:00
|
|
|
int nx = interface->inputPoll(port, Device::SuperScope, X);
|
|
|
|
int ny = interface->inputPoll(port, Device::SuperScope, Y);
|
2016-02-09 11:51:12 +00:00
|
|
|
nx += x;
|
|
|
|
ny += y;
|
|
|
|
x = max(-16, min(256 + 16, nx));
|
|
|
|
y = max(-16, min(240 + 16, ny));
|
2016-04-09 05:20:41 +00:00
|
|
|
offscreen = (x < 0 || y < 0 || x >= 256 || y >= ppu.vdisp());
|
Update to v098r12 release.
byuu says:
Changelog:
- higan/video: added support for Emulator::Sprite
- higan/resource: a new system for accessing embedded binary files
inside the emulation cores; holds the sprites
- higan/sfc/superscope,justifier: re-enabled display of crosshairs
- higan/sfc/superscope: fixed turbo toggle (also shows different
crosshair color when in turbo mode)
- higan/sfc/ppu: always outputs at 512x480 resolution now
- causes a slight speed-hit from ~127fps to ~125fps;
- but allows high-resolution 32x32 cursors that look way better;
- also avoids the need to implement sprite scaling logic
Right now, the PPU code to always output at 480-height is a really gross
hack. Don't worry, I'll make that nicer before release.
Also, superscope.cpp and justifier.cpp are built around a 256x240
screen. But since we now have 512x480, we can make the cursor's movement
much smoother by doubling the resolution on both axes. The actual games
won't see any accuracy improvements when firing the light guns, but the
cursors will animate nicer so I think it's still worth it. I'll work on
that before the next release as well.
The current 32x32 cursors are nicer, but we can do better now with full
24-bit color. So feel free to submit alternatives. I'll probably reject
them, but you can always try :D
The sprites don't support alpha blending, just color keying (0x00000000
= transparent; anything else is 0xff......). We can revisit that later
if necessary.
The way I have it designed, the only files that do anything with
Emulator::Sprite at all are the superscope and justifier folders.
I didn't have to add any hooks anywhere else. Rendering the sprite is
a lot cleaner than the old code, too.
2016-05-26 11:20:15 +00:00
|
|
|
sprite->setPosition(x * 2 - 16, y * 2 - 16);
|
|
|
|
sprite->setVisible(true);
|
Update to v079r06 release.
byuu says:
It does add some more code to the CPU::step() function, so performance
probably went down actually, by about 1%. Removing the input.tick() call
didn't compensate as much as I'd hoped.
Hooked up Super Scope and Justifier support. The good news is that the
Justifier alignment doesn't get fucked up anymore when you go
off-screen. Never could fix that in the old version.
The bad news is that it takes a major speed hit for the time being.
I need to figure out how to run the CPU and input threads out of order.
Every time I try, the input gets thrown off by most of a scanline.
Right now, I'm forced to sync constantly to get the latching position
really accurate. But worst case, I can cut the syncs down by skipping
large chunks around the cursor position, +/-40 clock cycles. So it's
only temporarily slow.
Lastly, killed the old Input class, merged Controllers class into it.
I actually like Controllers as a name better, but it doesn't jive with
video/audio/input, so oh well.
2011-06-25 12:56:32 +00:00
|
|
|
}
|
2016-02-09 11:51:12 +00:00
|
|
|
|
|
|
|
prev = next;
|
|
|
|
step(2);
|
Update to v079r06 release.
byuu says:
It does add some more code to the CPU::step() function, so performance
probably went down actually, by about 1%. Removing the input.tick() call
didn't compensate as much as I'd hoped.
Hooked up Super Scope and Justifier support. The good news is that the
Justifier alignment doesn't get fucked up anymore when you go
off-screen. Never could fix that in the old version.
The bad news is that it takes a major speed hit for the time being.
I need to figure out how to run the CPU and input threads out of order.
Every time I try, the input gets thrown off by most of a scanline.
Right now, I'm forced to sync constantly to get the latching position
really accurate. But worst case, I can cut the syncs down by skipping
large chunks around the cursor position, +/-40 clock cycles. So it's
only temporarily slow.
Lastly, killed the old Input class, merged Controllers class into it.
I actually like Controllers as a name better, but it doesn't jive with
video/audio/input, so oh well.
2011-06-25 12:56:32 +00:00
|
|
|
}
|
|
|
|
|
2015-10-10 02:16:12 +00:00
|
|
|
auto SuperScope::data() -> uint2 {
|
2011-06-24 10:43:29 +00:00
|
|
|
if(counter >= 8) return 1;
|
|
|
|
|
|
|
|
if(counter == 0) {
|
|
|
|
//turbo is a switch; toggle is edge sensitive
|
Update to v098r03 release.
byuu says:
It took several hours, but I've rebuilt much of the SNES' bus memory
mapping architecture.
The new design unifies the cartridge string-based mapping
("00-3f,80-bf:8000-ffff") and internal bus.map calls. The map() function
now has an accompanying unmap() function, and instead of a fixed 256
callbacks, it'll scan to find the first available slot. unmap() will
free slots up when zero addresses reference a given slot.
The controllers and expansion port are now both entirely dynamic.
Instead of load/unload/power/reset, they only have the constructor
(power/reset/load) and destructor (unload). What this means is you can
now dynamically change even expansion port devices after the system is
loaded.
Note that this is incredibly dangerous and stupid, but ... oh well. The
whole point of this was for 21fx. There's no way to change the expansion
port device prior to loading a game, but if the 21fx isn't active, then
the reset vector hijack won't work. Now you can load a 21fx game, change
the expansion port device, and simply reset the system to active the
device.
The unification of design between controller port devices and expansion
port devices is nice, and overall this results in a reduction of code
(all of the Mapping stuff in Cartridge is gone, replaced with direct bus
mapping.) And there's always the potential to expand this system more in
the future now.
The big missing feature right now is the ability to push/pop mappings.
So if you look at how the 21fx does the reset vector, you might vomit
a little bit. But ... it works.
Also changed exit(0) to _exit(0) in the POSIX version of nall::execute.
[The _exit(0) thing is an attempt to make higan not crash when it tries
to launch icarus and it's not on $PATH. The theory is that higan forks,
then the child tries to exec icarus and fails, so it exits, all the
unique_ptrs clean up their resources and tell the X server to free
things the parent process is still using. Calling _exit() prevents
destructors from running, and seems to prevent the problem. -Ed.]
2016-04-09 10:21:18 +00:00
|
|
|
bool newturbo = interface->inputPoll(port, Device::SuperScope, Turbo);
|
Update to v098r12 release.
byuu says:
Changelog:
- higan/video: added support for Emulator::Sprite
- higan/resource: a new system for accessing embedded binary files
inside the emulation cores; holds the sprites
- higan/sfc/superscope,justifier: re-enabled display of crosshairs
- higan/sfc/superscope: fixed turbo toggle (also shows different
crosshair color when in turbo mode)
- higan/sfc/ppu: always outputs at 512x480 resolution now
- causes a slight speed-hit from ~127fps to ~125fps;
- but allows high-resolution 32x32 cursors that look way better;
- also avoids the need to implement sprite scaling logic
Right now, the PPU code to always output at 480-height is a really gross
hack. Don't worry, I'll make that nicer before release.
Also, superscope.cpp and justifier.cpp are built around a 256x240
screen. But since we now have 512x480, we can make the cursor's movement
much smoother by doubling the resolution on both axes. The actual games
won't see any accuracy improvements when firing the light guns, but the
cursors will animate nicer so I think it's still worth it. I'll work on
that before the next release as well.
The current 32x32 cursors are nicer, but we can do better now with full
24-bit color. So feel free to submit alternatives. I'll probably reject
them, but you can always try :D
The sprites don't support alpha blending, just color keying (0x00000000
= transparent; anything else is 0xff......). We can revisit that later
if necessary.
The way I have it designed, the only files that do anything with
Emulator::Sprite at all are the superscope and justifier folders.
I didn't have to add any hooks anywhere else. Rendering the sprite is
a lot cleaner than the old code, too.
2016-05-26 11:20:15 +00:00
|
|
|
if(newturbo && !oldturbo) {
|
2011-06-24 10:43:29 +00:00
|
|
|
turbo = !turbo; //toggle state
|
Update to v098r12 release.
byuu says:
Changelog:
- higan/video: added support for Emulator::Sprite
- higan/resource: a new system for accessing embedded binary files
inside the emulation cores; holds the sprites
- higan/sfc/superscope,justifier: re-enabled display of crosshairs
- higan/sfc/superscope: fixed turbo toggle (also shows different
crosshair color when in turbo mode)
- higan/sfc/ppu: always outputs at 512x480 resolution now
- causes a slight speed-hit from ~127fps to ~125fps;
- but allows high-resolution 32x32 cursors that look way better;
- also avoids the need to implement sprite scaling logic
Right now, the PPU code to always output at 480-height is a really gross
hack. Don't worry, I'll make that nicer before release.
Also, superscope.cpp and justifier.cpp are built around a 256x240
screen. But since we now have 512x480, we can make the cursor's movement
much smoother by doubling the resolution on both axes. The actual games
won't see any accuracy improvements when firing the light guns, but the
cursors will animate nicer so I think it's still worth it. I'll work on
that before the next release as well.
The current 32x32 cursors are nicer, but we can do better now with full
24-bit color. So feel free to submit alternatives. I'll probably reject
them, but you can always try :D
The sprites don't support alpha blending, just color keying (0x00000000
= transparent; anything else is 0xff......). We can revisit that later
if necessary.
The way I have it designed, the only files that do anything with
Emulator::Sprite at all are the superscope and justifier folders.
I didn't have to add any hooks anywhere else. Rendering the sprite is
a lot cleaner than the old code, too.
2016-05-26 11:20:15 +00:00
|
|
|
sprite->setPixels(turbo ? Resource::Sprite::CrosshairRed : Resource::Sprite::CrosshairGreen);
|
2011-06-24 10:43:29 +00:00
|
|
|
}
|
Update to v098r12 release.
byuu says:
Changelog:
- higan/video: added support for Emulator::Sprite
- higan/resource: a new system for accessing embedded binary files
inside the emulation cores; holds the sprites
- higan/sfc/superscope,justifier: re-enabled display of crosshairs
- higan/sfc/superscope: fixed turbo toggle (also shows different
crosshair color when in turbo mode)
- higan/sfc/ppu: always outputs at 512x480 resolution now
- causes a slight speed-hit from ~127fps to ~125fps;
- but allows high-resolution 32x32 cursors that look way better;
- also avoids the need to implement sprite scaling logic
Right now, the PPU code to always output at 480-height is a really gross
hack. Don't worry, I'll make that nicer before release.
Also, superscope.cpp and justifier.cpp are built around a 256x240
screen. But since we now have 512x480, we can make the cursor's movement
much smoother by doubling the resolution on both axes. The actual games
won't see any accuracy improvements when firing the light guns, but the
cursors will animate nicer so I think it's still worth it. I'll work on
that before the next release as well.
The current 32x32 cursors are nicer, but we can do better now with full
24-bit color. So feel free to submit alternatives. I'll probably reject
them, but you can always try :D
The sprites don't support alpha blending, just color keying (0x00000000
= transparent; anything else is 0xff......). We can revisit that later
if necessary.
The way I have it designed, the only files that do anything with
Emulator::Sprite at all are the superscope and justifier folders.
I didn't have to add any hooks anywhere else. Rendering the sprite is
a lot cleaner than the old code, too.
2016-05-26 11:20:15 +00:00
|
|
|
oldturbo = newturbo;
|
2011-06-24 10:43:29 +00:00
|
|
|
|
|
|
|
//trigger is a button
|
|
|
|
//if turbo is active, trigger is level sensitive; otherwise, it is edge sensitive
|
|
|
|
trigger = false;
|
Update to v098r03 release.
byuu says:
It took several hours, but I've rebuilt much of the SNES' bus memory
mapping architecture.
The new design unifies the cartridge string-based mapping
("00-3f,80-bf:8000-ffff") and internal bus.map calls. The map() function
now has an accompanying unmap() function, and instead of a fixed 256
callbacks, it'll scan to find the first available slot. unmap() will
free slots up when zero addresses reference a given slot.
The controllers and expansion port are now both entirely dynamic.
Instead of load/unload/power/reset, they only have the constructor
(power/reset/load) and destructor (unload). What this means is you can
now dynamically change even expansion port devices after the system is
loaded.
Note that this is incredibly dangerous and stupid, but ... oh well. The
whole point of this was for 21fx. There's no way to change the expansion
port device prior to loading a game, but if the 21fx isn't active, then
the reset vector hijack won't work. Now you can load a 21fx game, change
the expansion port device, and simply reset the system to active the
device.
The unification of design between controller port devices and expansion
port devices is nice, and overall this results in a reduction of code
(all of the Mapping stuff in Cartridge is gone, replaced with direct bus
mapping.) And there's always the potential to expand this system more in
the future now.
The big missing feature right now is the ability to push/pop mappings.
So if you look at how the 21fx does the reset vector, you might vomit
a little bit. But ... it works.
Also changed exit(0) to _exit(0) in the POSIX version of nall::execute.
[The _exit(0) thing is an attempt to make higan not crash when it tries
to launch icarus and it's not on $PATH. The theory is that higan forks,
then the child tries to exec icarus and fails, so it exits, all the
unique_ptrs clean up their resources and tell the X server to free
things the parent process is still using. Calling _exit() prevents
destructors from running, and seems to prevent the problem. -Ed.]
2016-04-09 10:21:18 +00:00
|
|
|
bool newtrigger = interface->inputPoll(port, Device::SuperScope, Trigger);
|
2011-06-24 10:43:29 +00:00
|
|
|
if(newtrigger && (turbo || !triggerlock)) {
|
|
|
|
trigger = true;
|
|
|
|
triggerlock = true;
|
|
|
|
} else if(!newtrigger) {
|
|
|
|
triggerlock = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
//cursor is a button; it is always level sensitive
|
Update to v098r03 release.
byuu says:
It took several hours, but I've rebuilt much of the SNES' bus memory
mapping architecture.
The new design unifies the cartridge string-based mapping
("00-3f,80-bf:8000-ffff") and internal bus.map calls. The map() function
now has an accompanying unmap() function, and instead of a fixed 256
callbacks, it'll scan to find the first available slot. unmap() will
free slots up when zero addresses reference a given slot.
The controllers and expansion port are now both entirely dynamic.
Instead of load/unload/power/reset, they only have the constructor
(power/reset/load) and destructor (unload). What this means is you can
now dynamically change even expansion port devices after the system is
loaded.
Note that this is incredibly dangerous and stupid, but ... oh well. The
whole point of this was for 21fx. There's no way to change the expansion
port device prior to loading a game, but if the 21fx isn't active, then
the reset vector hijack won't work. Now you can load a 21fx game, change
the expansion port device, and simply reset the system to active the
device.
The unification of design between controller port devices and expansion
port devices is nice, and overall this results in a reduction of code
(all of the Mapping stuff in Cartridge is gone, replaced with direct bus
mapping.) And there's always the potential to expand this system more in
the future now.
The big missing feature right now is the ability to push/pop mappings.
So if you look at how the 21fx does the reset vector, you might vomit
a little bit. But ... it works.
Also changed exit(0) to _exit(0) in the POSIX version of nall::execute.
[The _exit(0) thing is an attempt to make higan not crash when it tries
to launch icarus and it's not on $PATH. The theory is that higan forks,
then the child tries to exec icarus and fails, so it exits, all the
unique_ptrs clean up their resources and tell the X server to free
things the parent process is still using. Calling _exit() prevents
destructors from running, and seems to prevent the problem. -Ed.]
2016-04-09 10:21:18 +00:00
|
|
|
cursor = interface->inputPoll(port, Device::SuperScope, Cursor);
|
2011-06-24 10:43:29 +00:00
|
|
|
|
|
|
|
//pause is a button; it is always edge sensitive
|
|
|
|
pause = false;
|
Update to v098r03 release.
byuu says:
It took several hours, but I've rebuilt much of the SNES' bus memory
mapping architecture.
The new design unifies the cartridge string-based mapping
("00-3f,80-bf:8000-ffff") and internal bus.map calls. The map() function
now has an accompanying unmap() function, and instead of a fixed 256
callbacks, it'll scan to find the first available slot. unmap() will
free slots up when zero addresses reference a given slot.
The controllers and expansion port are now both entirely dynamic.
Instead of load/unload/power/reset, they only have the constructor
(power/reset/load) and destructor (unload). What this means is you can
now dynamically change even expansion port devices after the system is
loaded.
Note that this is incredibly dangerous and stupid, but ... oh well. The
whole point of this was for 21fx. There's no way to change the expansion
port device prior to loading a game, but if the 21fx isn't active, then
the reset vector hijack won't work. Now you can load a 21fx game, change
the expansion port device, and simply reset the system to active the
device.
The unification of design between controller port devices and expansion
port devices is nice, and overall this results in a reduction of code
(all of the Mapping stuff in Cartridge is gone, replaced with direct bus
mapping.) And there's always the potential to expand this system more in
the future now.
The big missing feature right now is the ability to push/pop mappings.
So if you look at how the 21fx does the reset vector, you might vomit
a little bit. But ... it works.
Also changed exit(0) to _exit(0) in the POSIX version of nall::execute.
[The _exit(0) thing is an attempt to make higan not crash when it tries
to launch icarus and it's not on $PATH. The theory is that higan forks,
then the child tries to exec icarus and fails, so it exits, all the
unique_ptrs clean up their resources and tell the X server to free
things the parent process is still using. Calling _exit() prevents
destructors from running, and seems to prevent the problem. -Ed.]
2016-04-09 10:21:18 +00:00
|
|
|
bool newpause = interface->inputPoll(port, Device::SuperScope, Pause);
|
2011-06-24 10:43:29 +00:00
|
|
|
if(newpause && !pauselock) {
|
|
|
|
pause = true;
|
|
|
|
pauselock = true;
|
|
|
|
} else if(!newpause) {
|
|
|
|
pauselock = false;
|
|
|
|
}
|
|
|
|
|
2016-04-09 05:20:41 +00:00
|
|
|
offscreen = (x < 0 || y < 0 || x >= 256 || y >= ppu.vdisp());
|
2011-06-24 10:43:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
switch(counter++) {
|
Update to v079r06 release.
byuu says:
It does add some more code to the CPU::step() function, so performance
probably went down actually, by about 1%. Removing the input.tick() call
didn't compensate as much as I'd hoped.
Hooked up Super Scope and Justifier support. The good news is that the
Justifier alignment doesn't get fucked up anymore when you go
off-screen. Never could fix that in the old version.
The bad news is that it takes a major speed hit for the time being.
I need to figure out how to run the CPU and input threads out of order.
Every time I try, the input gets thrown off by most of a scanline.
Right now, I'm forced to sync constantly to get the latching position
really accurate. But worst case, I can cut the syncs down by skipping
large chunks around the cursor position, +/-40 clock cycles. So it's
only temporarily slow.
Lastly, killed the old Input class, merged Controllers class into it.
I actually like Controllers as a name better, but it doesn't jive with
video/audio/input, so oh well.
2011-06-25 12:56:32 +00:00
|
|
|
case 0: return offscreen ? 0 : trigger;
|
2011-06-24 10:43:29 +00:00
|
|
|
case 1: return cursor;
|
|
|
|
case 2: return turbo;
|
|
|
|
case 3: return pause;
|
|
|
|
case 4: return 0;
|
|
|
|
case 5: return 0;
|
|
|
|
case 6: return offscreen;
|
|
|
|
case 7: return 0; //noise (1 = yes)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-10-10 02:16:12 +00:00
|
|
|
auto SuperScope::latch(bool data) -> void {
|
2011-06-24 10:43:29 +00:00
|
|
|
if(latched == data) return;
|
|
|
|
latched = data;
|
|
|
|
counter = 0;
|
|
|
|
}
|