View unanswered posts | View active topics It is currently Tue Dec 10, 2019 5:38 am



This topic is locked, you cannot edit posts or make further replies.  [ 283 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10, 11, 12  Next
bsnes v0.036 released 
Author Message
Post 
Quote:
You know that's essentially the same thing given a couple more variables ?


Yes, of course. The math part's easy. It'd just complicate mouse control, especially without exclusive access + hiding the hardware cursor. I'm planning to just snap to mouse to the center whenever the mouse is acquired.

And damn am I not looking forward to writing a mouse cursor renderer. I'm planning to overlay it onto the PPU output, pre-filter. I'll just draw four of them for each possible mode. That will make the movement a lot more fluid than drawing it post filter / resize.

And speaking of which ...

Quote:
Give me an hour to download the Q3 packages and dig through the input wrapper, then I should have something for xorg natively.


Neat! Thanks a million!

I didn't know about SDL_WM_GrabInput(), but Xorg native would probably be a lot better. I don't want to acquire exclusive keyboard access, too.

But if you fail, the SDL approach will probably work, too. Will have to try it out to be sure.


Fri Oct 03, 2008 8:13 pm
Buzzkill Gil

Joined: Wed Jan 12, 2005 7:14 pm
Posts: 4249
Post 
grinvader wrote:
You probably got that covered, but just in case...

byuu wrote:
Essentially, for SNES mouse support, I need to capture raw "moved N pixels in X, Y direction", and not "mouse is currently at X, Y pixel."

You know that's essentially the same thing given a couple more variables ?
Until you hit the edge of the screen.

Not that Jurassic Park is really worth playing with OR without a mouse, but...


Fri Oct 03, 2008 8:38 pm
Profile
Lurker

Joined: Tue Apr 10, 2007 4:30 pm
Posts: 152
Location: Sweden
Post 
I know that the turbo button really was part of the on/off switch. It had three settings, off, on and rappid fire. It would be a menu option and not something that people need to change in the middle of action.

And the super scope will work well with out of window behavior, so locking is not mandatory, but should dam well be supported.

This + that mouse speed thing is all explained in the development manual, book two. You do have that one, right?


Fri Oct 03, 2008 9:49 pm
Profile WWW
Post 
Hmm, another neat controller ... the Twin Tap:
http://page5.auctions.yahoo.co.jp/jp/auction/e76318370

You hook them into the multi-tap, too. 16-player, anyone?

Quote:
This + that mouse speed thing is all explained in the development manual, book two. You do have that one, right?


No, those manuals are copyrighted and confidential. Emulation is protected as fair-use under reverse engineering, and reading those manuals would violate that; and I'd like to keep my emulation work completely legal. I hear from others that the information within them is pretty inaccurate / incomplete, anyway.


Fri Oct 03, 2008 10:17 pm
Veteran

Joined: Wed Aug 04, 2004 5:43 pm
Posts: 861
Location: Sloop
Post 
byuu wrote:
Hmm, another neat controller ... the Twin Tap:
http://page5.auctions.yahoo.co.jp/jp/auction/e76318370

You hook them into the multi-tap, too. 16-player, anyone?


It would be nice to know what games support it. I don't suppose you could use your Japanese skills to hunt for special controller lists similar to the ones we collected for English games?


Sat Oct 04, 2008 12:41 am
Profile
Regular
User avatar

Joined: Mon Nov 21, 2005 3:43 am
Posts: 236
Post 
henke37 wrote:
It would be a menu option and not something that people need to change in the middle of action.


I'm going to have to disagree with you there. I'll switch to turbo mode in the middle of fighting some of the ST's in Battle Clash. Pressing fire rapidly sometimes just wont cut it when there's a barrage of non-charged shots being thrown at you. :D I'm a bit lazy too.

As for the off/on/turble stuff having two states instead of three would be fine. Who's going to turn off the super scope anyway in an emulator? Being able to unplug the thing should be good enough, but maybe it could be stuck in as an advanced option to turn it off.


Last edited by powerspike on Sat Oct 04, 2008 4:28 am, edited 1 time in total.



Sat Oct 04, 2008 3:16 am
Profile
Post 
Okay, great news.

After discussing things with FitzRoy, we decided that I needed a permanent solution for the BS-X; as he needs to resell his eventually to recoup the losses.

So I purchased one from Matthew Callis, who generously offered me one of his for a very reasonable price.

That arrived today, and I finally got it hooked up and working. I had quite a bit of trouble getting the BS-X cartridge to work, but it turned out to just be a bad connection. I had to take the cart apart and clean the contacts with Isopropyl Alcohol. Though there does appear to be quite a few scrapes along the contacts (some of my other carts also have these), it works great now.

So yeah, be sure to thank Matthew Callis and FitzRoy for their help; and of course blargg for the devcart+serial controller, hopefully with this I can start to improve Satellaview emulation in bsnes in the future.

This setup is really getting wild:
Satellaview base <> SNES <> UFO8.3j / SNES RAMcart <> serial interface controller <> PC

I should take pictures sometime.


Sat Oct 04, 2008 9:17 am
Regular

Joined: Sat Mar 04, 2006 3:17 pm
Posts: 307
Post 
byuu wrote:
Okay, great news.

After discussing things with FitzRoy, we decided that I needed a permanent solution for the BS-X; as he needs to resell his eventually to recoup the losses.

So I purchased one from Matthew Callis, who generously offered me one of his for a very reasonable price.

That arrived today, and I finally got it hooked up and working. I had quite a bit of trouble getting the BS-X cartridge to work, but it turned out to just be a bad connection. I had to take the cart apart and clean the contacts with Isopropyl Alcohol. Though there does appear to be quite a few scrapes along the contacts (some of my other carts also have these), it works great now.

So yeah, be sure to thank Matthew Callis and FitzRoy for their help; and of course blargg for the devcart+serial controller, hopefully with this I can start to improve Satellaview emulation in bsnes in the future.

This setup is really getting wild:
Satellaview base <> SNES <> UFO8.3j / SNES RAMcart <> serial interface controller <> PC

I should take pictures sometime.


Pictures would indeed be cool


Sat Oct 04, 2008 10:40 am
Profile
Rookie

Joined: Sat Aug 07, 2004 7:20 pm
Posts: 46
Post 
Ok, digging through the Quake 3 sources took a bit longer than I expected. It looks like there's something called XGrabPointer() that seems to do the trick, but Q3 has also put up it's own function for creating a hidden cursor. Right now I'm busy digging through the xlib manuals to see if they have any useful information...

[edit]I think I've got it, if I've interpreted the code correctly, it puts the cursor in the middle of the window using XWarpPointer(), then changes mouse acceleration to normal with XChangePointerControl(). Then it just keeps on taking the difference between current pointer position and the middle, and uses that while resetting the position to middle of the screen. Hope that helps some...[/edit]


Last edited by wertigon on Sat Oct 04, 2008 3:50 pm, edited 1 time in total.



Sat Oct 04, 2008 12:05 pm
Profile
Veteran

Joined: Wed Aug 04, 2004 5:43 pm
Posts: 861
Location: Sloop
Post 
byuu wrote:
That arrived today, and I finally got it hooked up and working. I had quite a bit of trouble getting the BS-X cartridge to work, but it turned out to just be a bad connection. I had to take the cart apart and clean the contacts with Isopropyl Alcohol. Though there does appear to be quite a few scrapes along the contacts (some of my other carts also have these), it works great now.


The absolute best way to do this is to remove the cartridge shell and erase the gunky contacts with leverage and pressure. Just make sure you're using a quality eraser like this, and not one of those shitty smear erasers.

http://www.officedepot.com/a/products/4 ... rs-Medium/

Anything else either doesn't work or takes forever in comparison.


Sat Oct 04, 2008 3:21 pm
Profile
Post 
New WIP. About 12 hours of non-stop programming ...

I've added full mouse support to nall::input, hiro and ruby::DirectInput. With that, I added some really hacked-together support for the mouse, super scope and justifiers. Yes, all there -- now please stop bugging me about this already.

Caveats:
- Mouse support doesn't honor the speed setting.
- Super Scope doesn't currently let you go offscreen, which I should allow by at least a few pixels to allow the offscreen flag to be set for any games that might need it.
- Dual Justifier mode is fucked. I don't understand where PIO is supposed to be raised, and I used a hack to get the "shoot offscreen to reload" thing to work for the single Justifier mode for now. The dual one tends to desync when you go offscreen and stuff, not very pleasant.
- I'm not going to support SS / Justifiers in port 1. Since they can't latch counters anyway, and no games make use of them, I don't see much point in cluttering the menu more and confusing new people. Both multitap and mouse have games that can use port 1, so they stay.
- There's no input config panel to map buttons. You have to edit the config file directly.
- The mouse delta absolutely sucks. It's just a simple div 5, so moving the mouse really slowly won't even register, and moving it fast has only a linear curve. This one's going to be a real pain in the ass to get right on everyone's system, as the ranges DirectInput gives for mice tends to vary based on resolution, software and hardware mouse speed settings.
- Joystick delta range is -32768 to +32767, so div 5 means it'll be pretty much unplayable with the joystick.
- Input capture window binds mouse clicks now. This needs to be expanded quite a lot to support selective axis and mouse assignment.
- The software-rendered cursor doesn't work right in hires / interlace modes.
- To get the PIO latching behavior 100% correct without a dead spot during DRAM refresh, I'd have to test the cursor coordinates every single clock cycle. That would be way too damn slow, so I used a huge hack instead. I just test once per scanline and fake the latch counters to the cursor position. This is really shitty, and some timing-sensitive code that was looking for this could easily detect the emulator because of this, but it's either a ~10-20% speed hit, or no speed hit at all and hacky SS / Justifier support. Since it seems to work with all the games anyway, I'll go with the latter for now.
- No Linux support for any of this stuff yet, sorry.

If you want to try it, the config file keysyms are:
"x_axis" - mouse x axis
"y_axis" - ...
"button_00" - "button_07" - mouse buttons; hope you have the side buttons on your mouse for the Super Scope, otherwise have fun using a keyboard + mouse at the same time.
"joypad00.axis_00" - "joypad00.axis_03" - joypad axes (only 0,1 work with DirectInput; 0-3 for SDL.)

Yes, I'll rename the mouse ones to "mouse.foo" in the future.

Aside from all that, not really looking for bug reports at the moment. Way too preliminary for that.

Oh, and you have to click inside the video output to acquire the mouse. You'll know as the mouse cursor goes away. You can release the mouse by pressing escape on the keyboard.

If the mouse is acquired, escape overrides any GUI key assignment to that button. You can also toggle fullscreen mode and the mouse will stay acquired.

You can't acquire the mouse unless you have a mouse/SS/justifier attached to a controller port, and a game loaded.


Sun Oct 05, 2008 3:08 pm
Lurker

Joined: Tue Apr 10, 2007 4:30 pm
Posts: 152
Location: Sweden
Post 
You forgot to mention that you have to restart bsnes after setting up the new input settings.

I know you are not looking for bug reports, but here is one to do later, much later:
some, but only a few shots in Yoshi's safari is off. Only the ones where it's important with accuracy, like the aiming screen and the level choosing screen. Well, it's not like I'd notice the other stray shots if any...
Edit: that is, the first few shots at those screens can be way off, but after one or two shots, it's accurate.


Last edited by henke37 on Mon Oct 06, 2008 9:13 pm, edited 1 time in total.



Sun Oct 05, 2008 8:09 pm
Profile WWW
Veteran

Joined: Wed Aug 04, 2004 5:43 pm
Posts: 861
Location: Sloop
Post 
Quote:
- The mouse delta absolutely sucks. It's just a simple div 5, so moving the mouse really slowly won't even register, and moving it fast has only a linear curve. This one's going to be a real pain in the ass to get right on everyone's system, as the ranges DirectInput gives for mice tends to vary based on resolution, software and hardware mouse speed settings.


Does the same problem exist on joypad analog sticks? I can't get them to work right, so I can't tell. When I assign these, the cursor just warp around on movements. Assigning to my mouse works a lot better.

Double clicking to configure a button in the gui also assigns it to a mouse button now, button_00.

Hmm, am I gonna have to draw a mouse graphic now? :P


Sun Oct 05, 2008 10:36 pm
Profile
Lurker

Joined: Tue Apr 10, 2007 4:30 pm
Posts: 152
Location: Sweden
Post 
Of course! And the other controllers too!


Mon Oct 06, 2008 6:10 am
Profile WWW
Post 
If the Super Scope is going out of alignment on some games, then they must be polling PIO manually, or having something else latch the counters or something. I'll see if I can get the speed hit below 1-2% when SS/Justifiers are disabled; if I can do that, I'll latch when needed, rather than ~700 cycles in advance.

I already mentioned the issue with joypads, but I'll elaborate.

Joypads return a position, -32768 to +32767, for each axis. Mice return the distance travelled since the last poll, in exact pixels. Even for high-speed mice, you typically can't move more than -300 to +300 pixels in 1/60th of a second.

Right now, I don't differentiate between the two internally. Joypads would need to scale that down by ~200x, mice by ~5x or so, to get the thing to move at a reasonable rate for a 256x224 screen.

In truth, I don't know what a good value would be, and I imagine it changes based on the video output size, the user's mouse speed settings, etc etc. I don't know how to handle it properly for all cases.

I also mentioned the auto-mouse-assignment thing. I can fix that the same way I prevent auto-assignment of enter / spacebar. I'm just kind of burned out at the moment.

Quote:
Hmm, am I gonna have to draw a mouse graphic now? :P


Would be nice :)
Though we'd also want Super Scope / Justifier if you do that -- those would be really tough. And I don't even want to see what you come up with for the Exertainment ;)

We could leave them off, though. I imagine most know what a mouse looks like, and I believe it's relatively safe to auto-assign buttons 0 and 1. Same for Justifier with trigger/start. But Super Scope will need something, few people have mice with 4+ buttons.

Another idea is to auto-assign everything except SS pause+turbo, put those to keyboard or mouse clicks. But then that sucks for dual Justifiers (or dual mice). That pretty much will require two mice (and something like ManyMouse), or a way to map either analog controller axis and/or mice. We could always just leave dual Justifier / mouse mode disabled. I doubt that many people want to play Lethal Enforcers in 2-player mode (or 1-player mode, for that matter). And it would make configuration a lot easier for people.

But I have to admit, it really sucks playing with an analog stick. Games like Mario Paint fly swatting is ~10x harder this way. It might just be a good idea to leave dual Justifier mode hidden and always use the mouse. At least it'll be emulated internally.

Also, I can draw any kind of cursor. I chose red because of the fact that the light guns can't detect red, so it's the least likely color to appear in those games. But if someone wants to make a fancier one with more colors, we can do that too. Just keep in mind the really low resolution.


Last edited by byuu on Mon Oct 06, 2008 6:40 pm, edited 1 time in total.



Mon Oct 06, 2008 5:28 pm
Seen it all
User avatar

Joined: Mon Jan 03, 2005 5:04 pm
Posts: 2302
Location: Germany
Post 
byuu wrote:
Joypads return a position, -32768 to +32767, for each axis. Mice return the distance travelled since the last poll, in exact pixels. Even for high-speed mice, you typically can't move more than -300 to +300 pixels in 1/60th of a second.

Right now, I don't differentiate between the two internally. Joypads would need to scale that down by ~200x, mice by ~5x or so, to get the thing to move at a reasonable rate for a 256x224 screen.

In truth, I don't know what a good value would be, and I imagine it changes based on the video output size, the user's mouse speed settings, etc etc.

When in doubt, make it an option. ;)

You could also get the horz. & vert. value of LastTravelledMouseDistance / CurrentScreenSize, and apply that ratio to the SNES screen (with some additional amount of offscreen area).

_________________
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list


Mon Oct 06, 2008 6:19 pm
Profile WWW
Post 
For the sake of comparison, here's what the other emulators do.

ZSNES v1.42:

Using an older version as the 7 key no longer changes input, and I'm too lazy to figure out how that works in v1.51.

ZSNES gains exclusive access to the mouse, so clicking outside the window has no effect. Releasing the mouse is kind of annoying, you have to go into the UI first (or maybe swap controllers). Delta response even for the most subtle mouse movement works great. ZSNES easily wins for best mouse support.

Super Scope leaves turbo as always on, which makes the Metal Combat instruction mode confusing, and omits the pause button entirely. Left click is rapid fire, right click is cursor.

Justifier seems to emulate a SNES pad, rather than an actual Justifier. Moving the mouse moves all the sprites onscreen. Left click is fire onscreen, right click is fire offscreen (eg reload gun.) This makes reloading easy, but requires the joypad "Start" button to be pressed to select game mode. It also draws the software cursor in-game, rather than the manual one as seen in the Super Scope mode. Overall, ZSNES wins for best Justifier playability, but it's really bizarre to move the title screen when you move your mouse ...

Not sure how to use ManyMouse with it, nor do I even have two mice.

Snes9X v1.51:

Uses pseudo-exclusive mode for the mouse, non-exclusive for the Scope and Justifier. When moving mouse over the window, it disappears and Snes9X begins to move the emulated mouse instead. But a really fast mouse movement will be enough to knock the mouse out of the window. Obviously using the native Win32 API, rather than DirectInput.

Super Scope works by using left for trigger, right for cusor. I maps to pause, and F maps to turbo toggle.

Justifier works as expected. Left for trigger, right for start. I see why Snes9X has all the black border now. This allows you to easily shoot offscreen to reload. Black border is not visually pleasing, though.

Dual Justifier mode only accepts input for one Justifier. Maybe it uses ManyMouse, too?

Non-exclusive mode for Scope and Justifier work great; except SNES9x is only updating the cursor coordinates when the SNES polls the hardware. This makes the movement freeze up between scenes.

SNESGT v0.230b6 and SNEeSe v0.853:

Both of these are the same. Only supports the mouse. It is not exclusive, so your mouse easily moves offscreen and will interact with your desktop. Doesn't seem usable at all.

Super Sleuth v1.04e:

Non-exclusive mouse access.

The mouse doesn't work very well, similar to SNESGT. Since the system mouse doesn't move at the same speed, it easily goes out of the window and you end up clicking on other windows.

Super Scope, since it uses an absolute positioning system, works fantastically even without exclusive mouse access. It also draws its own hardware cursor, which is both hit and miss. On the plus side, it feels more responsive and works with your native desktop mouse speed. On the down side, you'd need lots of different cursor sizes to handle multiple window sizes, and it gives a false sense of additional precision that's not really there. It would also need a black border to handle the Justifier, if it emulated it. But overall, I'd say Super Sleuth has the best Scope emulation bar none.

` toggles turbo, left is trigger, right is cursor. I don't know what pause is, but I'm sure it's there.


Mon Oct 06, 2008 6:40 pm
Veteran

Joined: Wed Aug 04, 2004 5:43 pm
Posts: 861
Location: Sloop
Post 
I think the best way to simulate that offscreen shot stuff is just to have an assignment for it. The black border thing just seems like a highly undesirable thing to do just to support that.

You're probably right about not drawing the mouse. It's not exactly hard to figure out. And the super scope is simply too large, I'd want the graphics to be proportionate.

I'm surprised at how poorly some games implement mouse support, or why nintendo thought it could get away with two buttons when they couldn't on the controller itself. I tried Lord of the Rings, and there's basically four things to do: move, attack, defend, and enter the menu. Right click changes the cursor to enter the menu, but its also how you defend when its hovering over your character. Left click moves, but it attacks when its hovering on your character. They could have used a graphic for entering the menu, at least.

I owned a Super Scope when I was a kid. It was uncomfortably large and didn't work well at all. Super Scope games are more fun in emulation than they ever were in real life. I had a power glove, too, what a hyped up waste of money that was. I did NOT buy a Virtual Boy, haha. After getting burned with the GBA, I learned to just stop buying Nintendo hardware. :/


Last edited by FitzRoy on Mon Oct 06, 2008 8:38 pm, edited 1 time in total.



Mon Oct 06, 2008 8:17 pm
Profile
Regular

Joined: Sat Mar 04, 2006 3:17 pm
Posts: 307
Post 
We could take 2 approaches to offscreen reload.
1. Assignment
2. Offsceen reload outside of the image border when screen resolution is higher than the snes image. (this would probably require a lot of extra coding and/or black borders)

Offscreen reload is just plain wierd without the real gun.

What about support for the LCD-Topgun ;)


Mon Oct 06, 2008 8:31 pm
Profile
Post 
Right now, I handle offscreen reload by giving the screen borders a 16-pixel window to go offscreen by. Try it, the cursor will disappear a bit. You can fire here, and it'll reload the gun.

It pretty much demands exclusive mouse access, but it also eliminates the need for black borders.

I have to admit that a button assignment is damn convenient, though. Even if it does make the game five times easier than it should be. Then again, I should also say that a button to reload the gun would be difficult for proper cycle-timed emulation of the guns, if we ever go that route.

And really, if you want to cheat like that, just use an infinite bullet Game Genie code or something. What's the difference?


Mon Oct 06, 2008 9:02 pm
Veteran

Joined: Wed Aug 04, 2004 5:43 pm
Posts: 861
Location: Sloop
Post 
Well, sounds like you got that one figured out then. Hope it works in fullscreen, too.


Mon Oct 06, 2008 9:35 pm
Profile
Post 
Well, I'm still open to suggestion, just throwing ideas out there. This seems like an area that all emulators need work on, so I'd like to get it right the first time.

Speaking of which, I tried adding a test for SS / Justifier to allow for cycle-accurate latch triggering. It results in a frame loss from 71.5fps to 69.5fps, or a little under 3%, for non-SS/Justifier games. That's literally just for if(snes.input.pio_access) snes.tick(); added to the code, where the test is always false. It's just a really heavily used section of code.

You'd lose roughly ~6-15% speed with those enabled, of course. But rather than fake the actual latch writes by manipulating OPHCT, OPHCT and PIO before the actual action happens, I can set it at the exact point desired. So, up to you guys. Would you prefer we treat peripherals like special chips and just worry about speed and playability, or treat it like the base unit and worry about all-out precision? Note that if anyone were ever crazy enough to write a PIO tester, they could conceivably support dual Super Scopes or quad Justifiers. The slower precise method would be absolutely required for that to work, since you can't latch the counters from the first joypad port.

Maybe we can talk d4s into it. What do you think? World's first four-player SNES light gun game?

I also found a Super Scope bug with the SNES Test Program where it was using the previous latch positions for your last shot. I fixed that by latching the counters every frame, even when trigger is not held down. anomie says it has to be held down, so maybe there's some other logic bug? Hmm ... at least with this change, the Yoshi's Safari thing should be fixed.


Last edited by byuu on Mon Oct 06, 2008 10:27 pm, edited 1 time in total.



Mon Oct 06, 2008 10:21 pm
Veteran

Joined: Wed Aug 04, 2004 5:43 pm
Posts: 861
Location: Sloop
Post 
I don't think that's a large enough drop to be considering hackish solutions. Especially since it's coming like a year after the last drop. Average computing power is advancing faster than that.

Were you thinking of at least showing the assignments of these controllers via the gui, even if they can't be changed from there?

You also may as well use mouse buttons 1-4 for the scope, with the 4th being pause since it's the most useless and people without 4button mice won't suffer.


Last edited by FitzRoy on Mon Oct 06, 2008 10:33 pm, edited 1 time in total.



Mon Oct 06, 2008 10:24 pm
Profile
Post 
Quote:
I don't think that's a large enough drop to be considering hackish solutions.


Yeah, especially since it's something we really can get right, unlike most special chips. And hell, if and when we ever get that cycle-level PPU core, I can simulate the phosphor issue with reds, too. That'd be pretty neat.

Just hate all these tiny speed dips. SuperFX and SA-1 support is going to cause quite a large hit, even for non-SFX/SA-1 games, due to the need for scheduler changes.

Quote:
Were you thinking of at least showing the assignments of these controllers via the gui, even if they can't be changed from there?


Not sure what you mean. You mean you want it to say what's currently connected on the Input Configuration panel? It's still accessible from the System menu of the main window, but we can mirror it on the config panel, too.

Oh, or do you mean the mouse button assignments? They'll be configurable from there before the next release. Going to try out that setup from the "Input driver" thread to get joypad axes working better, and allow the extra Super Scope buttons to be mapped either to the mouse or the keyboard (or a gamepad, if you want.)


Mon Oct 06, 2008 10:31 pm
Post 
I also forgot to mention that my speed hit was for frameskip = 9, which bypasses all the RTO calculations to add extra stress to the CPU. With frameskip = 0, the speed hit is less than 1% with no light guns, but it's ~11% with.

But definitely worth it, I was quickly able to track down and fix all the remaining issues, and the code no longer requires accessing private implementations for the CPU and PPU.

It seems that PIO and the controller IOBit are actually a bit different. PIO is just a mask for IOBit states, and the controllers can still latch the counters even if PIO.d7 is clear. Very interesting.

So, recap:

- Super Scope latches regardless of the trigger position, just like the Justifier. Looks like anomie's doc was wrong, or I'm missing something major. That's what was throwing off Yoshi's Island.
- The 'L' flag for the Justifier in anomie's doc was very unclear. He mentioned that Gun 1 = 1, Gun 2 = 0. This is because it inverts upon latching the controller data; but when you actually "look for the CRT beam cannon", you are supposed to use Gun 1 = 0, Gun 2 = 1. That should've been obvious, oh well. That fixes the two guns going out of alignment, and negates the need for PIO raising magic when the gun is offscreen.
- Neither SS or Justifier clear $4201.d7. They simply latch the counters, which sets the counter_latched flag for $213f.d6. This is how the two determine if the gun is onscreen or not.


Tue Oct 07, 2008 12:54 am
Display posts from previous:  Sort by  
This topic is locked, you cannot edit posts or make further replies.   [ 283 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10, 11, 12  Next

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software.