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.
|
|
|
|
|
Update to v103r05 release.
byuu says:
Changelog:
- fc/controller: added ControllerPort class; removed Peripherals class
- md/controller/gamepad: removed X,Y,Z buttons since this isn't a
6-button controller
- ms/controller: added ControllerPort class (not used in Game Gear
mode); removed Peripherals class
- pce/controller: added ControllerPort class; removed Peripherals
class
- processor/spc700: idle(address) is part of SMP class again, contains
flag to detect mov (x)+ edge case
- sfc/controller/super-scope,justifier: use CPU frequency instead of
hard-coding NTSC frequency
- sfc/cpu: move 4x8-bit SMP ports to SMP class
- sfc/smp: move APU RAM to DSP class
- sfc/smp: improved emulation of TEST registers bits 4-7 [information
from nocash]
- d4,d5 is RAM wait states (1,2,5,10)
- d6,d7 is ROM/IO wait states (1,2,5,10)
- sfc/smp: code cleanup to new style (order from lowest to highest
bits; use .bit(s) functions)
- sfc/smp: $00f8,$00f9 are P4/P5 auxiliary ports; named the registers
better
2017-07-01 06:15:27 +00:00
|
|
|
SuperScope::SuperScope(uint port) : Controller(port) {
|
|
|
|
create(Controller::Enter, system.cpuFrequency());
|
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 = 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
|
2017-01-13 01:15:45 +00:00
|
|
|
int nx = platform->inputPoll(port, ID::Device::SuperScope, X);
|
|
|
|
int ny = platform->inputPoll(port, ID::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 v100r14 release.
byuu says:
(Windows: compile with -fpermissive to silence an annoying error. I'll
fix it in the next WIP.)
I completely replaced the time management system in higan and overhauled
the scheduler.
Before, processor threads would have "int64 clock"; and there would
be a 1:1 relationship between two threads. When thread A ran for X
cycles, it'd subtract X * B.Frequency from clock; and when thread B ran
for Y cycles, it'd add Y * A.Frequency from clock. This worked well
and allowed perfect precision; but it doesn't work when you have more
complicated relationships: eg the 68K can sync to the Z80 and PSG; the
Z80 to the 68K and PSG; so the PSG needs two counters.
The new system instead uses a "uint64 clock" variable that represents
time in attoseconds. Every time the scheduler exits, it subtracts
the smallest clock count from all threads, to prevent an overflow
scenario. The only real downside is that rounding errors mean that
roughly every 20 minutes, we have a rounding error of one clock cycle
(one 20,000,000th of a second.) However, this only applies to systems
with multiple oscillators, like the SNES. And when you're in that
situation ... there's no such thing as a perfect oscillator anyway. A
real SNES will be thousands of times less out of spec than 1hz per 20
minutes.
The advantages are pretty immense. First, we obviously can now support
more complex relationships between threads. Second, we can build a
much more abstracted scheduler. All of libco is now abstracted away
completely, which may permit a state-machine / coroutine version of
Thread in the future. We've basically gone from this:
auto SMP::step(uint clocks) -> void {
clock += clocks * (uint64)cpu.frequency;
dsp.clock -= clocks;
if(dsp.clock < 0 && !scheduler.synchronizing()) co_switch(dsp.thread);
if(clock >= 0 && !scheduler.synchronizing()) co_switch(cpu.thread);
}
To this:
auto SMP::step(uint clocks) -> void {
Thread::step(clocks);
synchronize(dsp);
synchronize(cpu);
}
As you can see, we don't have to do multiple clock adjustments anymore.
This is a huge win for the SNES CPU that had to update the SMP, DSP, all
peripherals and all coprocessors. Likewise, we don't have to synchronize
all coprocessors when one runs, now we can just synchronize the active
one to the CPU.
Third, when changing the frequencies of threads (think SGB speed setting
modes, GBC double-speed mode, etc), it no longer causes the "int64
clock" value to be erroneous.
Fourth, this results in a fairly decent speedup, mostly across the
board. Aside from the GBA being mostly a wash (for unknown reasons),
it's about an 8% - 12% speedup in every other emulation core.
Now, all of this said ... this was an unbelievably massive change, so
... you know what that means >_> If anyone can help test all types of
SNES coprocessors, and some other system games, it'd be appreciated.
----
Lastly, we have a bitchin' new about screen. It unfortunately adds
~200KiB onto the binary size, because the PNG->C++ header file
transformation doesn't compress very well, and I want to keep the
original resource files in with the higan archive. I might try some
things to work around this file size increase in the future, but for now
... yeah, slightly larger archive sizes, sorry.
The logo's a bit busted on Windows (the Label control's background
transparency and alignment settings aren't working), but works well on
GTK. I'll have to fix Windows before the next official release. For now,
look on my Twitter feed if you want to see what it's supposed to look
like.
----
EDIT: forgot about ICD2::Enter. It's doing some weird inverse
run-to-save thing that I need to implement support for somehow. So, save
states on the SGB core probably won't work with this WIP.
2016-07-30 03:56:12 +00:00
|
|
|
synchronize(cpu);
|
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
|
2017-01-13 01:15:45 +00:00
|
|
|
bool newturbo = platform->inputPoll(port, ID::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;
|
2017-01-13 01:15:45 +00:00
|
|
|
bool newtrigger = platform->inputPoll(port, ID::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
|
2017-01-13 01:15:45 +00:00
|
|
|
cursor = platform->inputPoll(port, ID::Device::SuperScope, Cursor);
|
2011-06-24 10:43:29 +00:00
|
|
|
|
|
|
|
//pause is a button; it is always edge sensitive
|
|
|
|
pause = false;
|
2017-01-13 01:15:45 +00:00
|
|
|
bool newpause = platform->inputPoll(port, ID::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;
|
|
|
|
}
|