41 replies to this topic

[stephena]

So, it's time for another Stella release.  First of all, I have to apologize for the amount of time since the last release.  I've mentioned in several other threads that I'm doing major renovations to my house, and haven't had a computer room for over 2 months.  As a result, this release doesn't contain all the items I wanted to include.  Anyway, enough of the apologies, have a look at what is included:

  * Many improvements to input handling, particularly with the mouse and
	paddles:
	- The mouse can now be used to emulate a joystick, booster-grip or
	  driving controller.

	- The mouse now controls only one device at a time (1 of 4 paddles,
	  1 of 2 joysticks, etc), instead of devices from both virtual ports.

	- The sensitivity for digital and mouse input (for paddles) can now
	  be set separately with the 'dsense' and 'msense' commandline
	  arguments, and from within the Input Settings UI.

  * Added support for the 2600-daptor device (http://2600-daptor.com), which is
	similar to a Stelladaptor but improves handling of paddles.  Thanks
	go to Tom Hafner for a complimentary test sample of this device.

  * Added new controller types 'Paddles_IAxis', 'Paddles_IDir', and
	'Paddles_IAxDr', which invert the paddle axis, direction, and
	axis+direction, respectively.  These are used for certain ROMs
	that have the axis or direction inverted from normal (for example,
	using the paddles causes on onscreen object to move up and down vs.
	left and right).  All applicable ROMs in the internal database
	have been updated.

  * Added preliminary support for emulating ARM code to the DPC+
	bankswitching scheme (thanks to Batari).  Related to this, fatal
	errors in the DPC+ ARM code are now caught and shown in the debugger.

  * Updated internal ROM properties database to ROM-Hunter version 6
	(thanks go to RomHunter for his tireless research in this area).

  * The ROM audit dialog now automatically selects the current
	directory in the ROM launcher, and reloads the directory after
	the audit is complete.

  * Removed the 'grabmouse' functionality; the mouse is now always
	grabbed while playing a game, and released otherwise.

  * Updated built-in version of the PNG library to the latest version.

As usual, Stella can be download from http://stella.sf.net.  Please report all bugs in this thread or by email.  I would suggest adding bugs to the Stella tracker, but it hasn't been working since AtariAge upgraded the forum software (Al, if you're listening, please fix the Stella tracker).

[Keatah]

stephena, on Sat May 28, 2011 7:06 PM, said:

So, it's time for another Stella release.  First of all, I have to apologize for the amount of time since the last release.  I've mentioned in several other threads that I'm doing major renovations to my house, and haven't had a computer room for over 2 months.  As a result, this release doesn't contain all the items I wanted to include.  Anyway, enough of the apologies, have a look at what is included:

  * Many improvements to input handling, particularly with the mouse and
	paddles:
	- The mouse can now be used to emulate a joystick, booster-grip or
	  driving controller.

	- The mouse now controls only one device at a time (1 of 4 paddles,
	  1 of 2 joysticks, etc), instead of devices from both virtual ports.

	- The sensitivity for digital and mouse input (for paddles) can now
	  be set separately with the 'dsense' and 'msense' commandline
	  arguments, and from within the Input Settings UI.

  * Added support for the 2600-daptor device (http://2600-daptor.com), which is
	similar to a Stelladaptor but improves handling of paddles.  Thanks
	go to Tom Hafner for a complimentary test sample of this device.

  * Added new controller types 'Paddles_IAxis', 'Paddles_IDir', and
	'Paddles_IAxDr', which invert the paddle axis, direction, and
	axis+direction, respectively.  These are used for certain ROMs
	that have the axis or direction inverted from normal (for example,
	using the paddles causes on onscreen object to move up and down vs.
	left and right).  All applicable ROMs in the internal database
	have been updated.

  * Added preliminary support for emulating ARM code to the DPC+
	bankswitching scheme (thanks to Batari).  Related to this, fatal
	errors in the DPC+ ARM code are now caught and shown in the debugger.

  * Updated internal ROM properties database to ROM-Hunter version 6
	(thanks go to RomHunter for his tireless research in this area).

  * The ROM audit dialog now automatically selects the current
	directory in the ROM launcher, and reloads the directory after
	the audit is complete.

  * Removed the 'grabmouse' functionality; the mouse is now always
	grabbed while playing a game, and released otherwise.

  * Updated built-in version of the PNG library to the latest version.

As usual, Stella can be download from http://stella.sf.net.  Please report all bugs in this thread or by email.  I would suggest adding bugs to the Stella tracker, but it hasn't been working since AtariAge upgraded the forum software (Al, if you're listening, please fix the Stella tracker).

[Keatah]

Well!! Looks like we have a good start with the paddle sensitivity adjustment! The slower moving response has allowed another bug to surface. I noticed the paddle is more precise and sensitive to left mouse movements than it is for movements to the right.

It is possible to move the mouse slowly enough to the right side and not have the emu sense a movement. But the same slow speed to the left produces a movement in the paddle. I was using Breakout and Kaboom to test this.

Also, moving the paddle equal amounts to the left and right for a minute or two, will allow the paddle to settle in on the left side. So it would seem there is an imbalance someplace.

I have an option in my mouse driver that is called Enhance Pointer Precision. It has something to do with slower movements producing less 'ticks' or something. This of course makes the problem worse. The problem almost, but not quite, disappears if I turn this option off.

I don't think this has anything to do with my hardware because the pointer in windows tracks perfectly and in equal amounts left and right.

[stephena]

Keatah, on Mon May 30, 2011 1:08 AM, said:

Well!! Looks like we have a good start with the paddle sensitivity adjustment! The slower moving response has allowed another bug to surface. I noticed the paddle is more precise and sensitive to left mouse movements than it is for movements to the right.

It is possible to move the mouse slowly enough to the right side and not have the emu sense a movement. But the same slow speed to the left produces a movement in the paddle. I was using Breakout and Kaboom to test this.

Also, moving the paddle equal amounts to the left and right for a minute or two, will allow the paddle to settle in on the left side. So it would seem there is an imbalance someplace.

I have an option in my mouse driver that is called Enhance Pointer Precision. It has something to do with slower movements producing less 'ticks' or something. This of course makes the problem worse. The problem almost, but not quite, disappears if I turn this option off.

I don't think this has anything to do with my hardware because the pointer in windows tracks perfectly and in equal amounts left and right.

I won't have time to look into this in more detail until next week.  I didn't notice any such imbalance.  Can you try with a standard mouse that just uses a standard driver?  Maybe a plain PS2 mouse??

EDIT:  Just wanted to add that there is a 'deadzone' area on the left and right of the paddle in Kaboom, and it's much more pronounced on the left.  That is, if you move the mouse as far as possible left and then move back to the right, it will take longer to start movement comparing to doing the same thing on the other side.  Was that confusing?   Let me rephrase: the area from extreme-left to valid-left is larger than the area from extreme-right to valid-right.  This happens for me on a real system, and also with real paddles with a Stelladaptor and 2600-daptor.

[Keatah]

I noticed the deadzone yes. I may have never noticed it before. And that isn't much of a problem.

But, since the paddles in a real system are potentiometer based, they have proportional response. For X amount of resistance in ohms, the system will place the player's object at a certain position on the screen. It doesn't matter how quickly the knob is turned. The player settles in at the designated position like clockwork. That's fine and good the way it should be.

Let us assume that the paddle controller on the real 2600 is lock to lock at 7 o'clock and 5 o'clock.
And at 12 o'clock is the center. And the paddle in breakout would be in the center of the screen. I can understand the deadzone in kaboom where the real center might be considered 1 o'clock for example. And the buckets reach the left side of the screen at 9 o'clock and the right side at, say 4 o'clock. Good enough.

The best way to reproduce the problem, for me anyways, is to turn down the sensitivity of the pointer in the windows driver. Windows will track the mouse perfectly, left and right, up and down, repeatably, for minutes on end. No matter how slow or fast I move it. Though it is possible to move it quickly enough, very very quickly, to where the camera in the mouse simply can't process the info fast enough and the tracking is lost. Understandable.

Now, in stella, you can move the mouse slowly to the left and it will track fine. It will move left pretty reliably unless you jerk it insanely quick, then it looses the lock and the paddle doesn't move. Same thing on the right side, BUT WITH ONE DIFFERENCE. If you move the mouse slowly enough, it will not track at all. Windows does, but not stella.

It would seem the minimum speed needed to effect motion in stella is much higher in the left-to-right direction, than it is in the right-to-left direction. Like I say, turning down the speed of the pointer in windows just magnifies the problem to where you can see it. If you have a higher speed pointer going, then the problem is still there, just not as bad.

I have tested and verified this with a ps2 mouse on a "more legacy" system. And a usb mouse on a more modern system. I also made sure I was using the stock windows microsoft mouse driver for both. I know my mouse is polling at 8ms, pretty slow, but I can change that to 1ms and see what happens, if it affect anything at all.

So the key point is, left to right movements need a faster velocity. Right to left movements need a slower velocity.
Throughout a game of breakout, I'll lift up the mouse and reposition it to "get a full playing-field's worth of response." If I position the virtual mouse-paddle at 12 o'clock and move it back and forth simulating movements between 10 and 2 o'clock (not touching the deadzone at all), eventually the on-screen paddle settles to the left more and more.. I even put the mouse in a box and moved it against the sides to be sure I was getting equal left and right distances.

I hope that is clear enough to get a picture of what could be causing this.

[Keatah]

I tried the 1ms/1000Hz polling rate, absolutely no difference on stella's behavior. I did, of course, note a smoother pointer in windows.

But no change in left-to-right accuracy or right-to-left accuracy.

[dwane413]

I haven't tested this as thoroughly as Keatah has and it is possible that my mouse driver could be at fault, but thought I'd mention what I noticed.... In Warlords and Medieval Mayhem, if you move the mouse quickly enough to the right then it doesn't move at all (or at least very little). In these games, you need to be able to move very quickly so you can get into position to release the ball before your opponent has time to react.

By the way, the mouse control for joystick games is nice.

[Keatah]

dwane413, on Tue May 31, 2011 9:09 AM, said:

I haven't tested this as thoroughly as Keatah has and it is possible that my mouse driver could be at fault, but thought I'd mention what I noticed.... In Warlords and Medieval Mayhem, if you move the mouse quickly enough to the right then it doesn't move at all (or at least very little). In these games, you need to be able to move very quickly so you can get into position to release the ball before your opponent has time to react.

By the way, the mouse control for joystick games is nice.

To me, Warlords is now unplayable. I didn't think to test with this game before.

[stephena]

I think I may have some idea about the mouse/paddle issues.  But I won't be able to get to it for another week or so.  Maybe after that I can do a quick point release.

[Keatah]

stephena, on Tue May 31, 2011 3:57 PM, said:

I think I may have some idea about the mouse/paddle issues.  But I won't be able to get to it for another week or so.  Maybe after that I can do a quick point release.

Well sure of course! Meantime I can jam on space invaders or missile command or something.

[dwane413]

stephena, on Tue May 31, 2011 3:57 PM, said:

I think I may have some idea about the mouse/paddle issues.  But I won't be able to get to it for another week or so.  Maybe after that I can do a quick point release.

Sounds good. Thanks.

[Firehawke]

It's been awhile. I don't know if I ever got to thank you for those controller fixes last year-- I had a master breaker fry and take me offline (and completely without power) for about four months. You'd be amazed at how much paperwork it takes to get permits to fix an outside breaker box.

Any case, I digress-- thanks for your help with the earlier issue.

I just updated to 3.4, though, and I've hit a new snag. The analog on the joystick is overriding the hat inputs *and* the keyboard inputs, even when centered and not in use. On Pitfall, if I don't touch the analog and then hold right on the keyboard or hat, he'll inch forward and *stop* in place. If I wiggle the hat (directional pad in this case) up and down while holding right, he'll inch forward repeatedly with each change from up+right to down+right and vice versa.

I tried checking the deadzone, and that had no effect-- I wasn't really expecting it to, either, considering he wasn't running anywhere with the analog centered and no other inputs. This is on Windows 7, using both x64 and x86 builds, using an X-Box 360 controller but probably can be reproduced with any controller that has D-pad on hat and analog stick as X/Y.

[stephena]

Firehawke, on Wed Jun 1, 2011 5:54 AM, said:

It's been awhile. I don't know if I ever got to thank you for those controller fixes last year-- I had a master breaker fry and take me offline (and completely without power) for about four months. You'd be amazed at how much paperwork it takes to get permits to fix an outside breaker box.

Any case, I digress-- thanks for your help with the earlier issue.

I just updated to 3.4, though, and I've hit a new snag. The analog on the joystick is overriding the hat inputs *and* the keyboard inputs, even when centered and not in use. On Pitfall, if I don't touch the analog and then hold right on the keyboard or hat, he'll inch forward and *stop* in place. If I wiggle the hat (directional pad in this case) up and down while holding right, he'll inch forward repeatedly with each change from up+right to down+right and vice versa.

I tried checking the deadzone, and that had no effect-- I wasn't really expecting it to, either, considering he wasn't running anywhere with the analog centered and no other inputs. This is on Windows 7, using both x64 and x86 builds, using an X-Box 360 controller but probably can be reproduced with any controller that has D-pad on hat and analog stick as X/Y.

This is what I get when I mess with the input handler   This is intentionally supposed to happen for Stelladaptor/2600-daptor devices, with the idea that if they're being used, they override all other types of input.  Obviously, that wasn't supposed to extend to normal analog joysticks as well.  It looks like I have some more testing to do.  But as mentioned above, I won't get to it until next week (or the one after that).

[Firehawke]

stephena, on Wed Jun 1, 2011 7:21 AM, said:

This is what I get when I mess with the input handler   This is intentionally supposed to happen for Stelladaptor/2600-daptor devices, with the idea that if they're being used, they override all other types of input.  Obviously, that wasn't supposed to extend to normal analog joysticks as well.  It looks like I have some more testing to do.  But as mentioned above, I won't get to it until next week (or the one after that).

Yeah, no problem. I had a feeling it'd be something like you described based on the feel of the problem, so I just figured I'd let you know about it for when you can get to it.

[batari]

A few point releases ago, CMD-R stopped working on the OSX version.  I didn't worry too much because I just used the OSX pull-down menu and selected "Restart."

However, now I can't even do that because Stella grabs the mouse, and I can't figure out how to release it (I don't like grabbing by default, especially in joystick games where the mouse doesn't work.)  Is there a setting to always release the mouse?

Also, the OSX menu is smaller now so I'm not sure if the "Restart" option is even there.

[dwane413]

batari, on Fri Jun 3, 2011 8:28 PM, said:

A few point releases ago, CMD-R stopped working on the OSX version.  I didn't worry too much because I just used the OSX pull-down menu and selected "Restart."

However, now I can't even do that because Stella grabs the mouse, and I can't figure out how to release it (I don't like grabbing by default, especially in joystick games where the mouse doesn't work.)

In Windows XP, I can release the mouse by pressing TAB (enter options menu mode), ` (go to debugger mode), or PAUSE.

batari, on Fri Jun 3, 2011 8:28 PM, said:

Is there a setting to always release the mouse?

I couldn't find a way. I tried manually adding "grabmouse = 0" to the stella.ini file, but that didn't work.

By the way, Random Terrain predicted this would happen.

[Nathan Strum]

First - I wanted to be sure to thank you for another update.

Quote

  * Removed the 'grabmouse' functionality; the mouse is now always grabbed while playing a game, and released otherwise.

I'd like to see 'grabmouse' returned as an option. I'm used to being able to move around the Stella window when a game is running, and now I can't do that without hitting Tab first. (A minor annoyance, admittedly.) Also, seconding what batari mentioned, it would be nice if cmd+R worked again for resetting a ROM without exiting to the game list.

[batari]

dwane413, on Fri Jun 3, 2011 8:54 PM, said:

batari, on Fri Jun 3, 2011 8:28 PM, said:

A few point releases ago, CMD-R stopped working on the OSX version.  I didn't worry too much because I just used the OSX pull-down menu and selected "Restart."

However, now I can't even do that because Stella grabs the mouse, and I can't figure out how to release it (I don't like grabbing by default, especially in joystick games where the mouse doesn't work.)

In Windows XP, I can release the mouse by pressing TAB (enter options menu mode), ` (go to debugger mode), or PAUSE.

batari, on Fri Jun 3, 2011 8:28 PM, said:

Is there a setting to always release the mouse?

I couldn't find a way. I tried manually adding "grabmouse = 0" to the stella.ini file, but that didn't work.

By the way, Random Terrain predicted this would happen.

Yep, tab works.

I read the thread you posted about Stephen's reasoning for always grabbing the mouse (other emulators do it) and I have to say what other non-full-screen emulators of classic games always grab?  I know that emulators that can run windowing operating systems, like QEMU, grab the mouse by default, and this does make sense, but even in QEMU you can release the mouse if you want.  I'd like to be able to enable manual control of mouse grabbing again, even if we have to edit the ini.

But mostly, I want CMD-R back The option is missing from the OSX menu now, so I can't restart with the mouse.

[stephena]

Grabmouse will return in the next release.  In fact, I've already committed code to fix this issue.  There will be a few minor changes:

1)  It will only have meaning in emulation mode; in other modes, the mouse is never grabbed
2)  Its setting will be changed in the 'Input Settings' UI instead of 'Video Settings' (which admittedly only made sense from a programming POV, since the mouse functionality is tied to the video system)
3)  It will be on by default

As for 'Cmd-R', it is now 'Control-r'.  Almost all the commands for the OSX version that used Shift-Cmd now use Control.  I did this to create parity with other systems.  Basically, the OSX Cmd corresponds to Alt on other systems, and the OSX Control is Control on other systems.  So the functionality is still there, it's just tied to another key.  Probably the best long-term solution is to make this configurable, but for now it's hard-coded.

As for Randoms prediction, yes I agreed basically as soon as I did the last release

[Nathan Strum]

stephena, on Sat Jun 4, 2011 7:13 AM, said:

As for 'Cmd-R', it is now 'Control-r'.  Almost all the commands for the OSX version that used Shift-Cmd now use Control.  I did this to create parity with other systems.  Basically, the OSX Cmd corresponds to Alt on other systems, and the OSX Control is Control on other systems.  So the functionality is still there, it's just tied to another key.  Probably the best long-term solution is to make this configurable, but for now it's hard-coded.

Ooooohh... Control+R. That explains it. (I have the left Control key mapped as P0 fire, so I never thought of using it for anything else.)

[israelg]

How much faster is the 64 bit version ?

Because when running the CRT emulation it becomes very slow when I set color bleeding to medium and Higher...

And changes in this area in the near future ?

Thanks

I.G

[stephena]

israelg, on Sun Jun 5, 2011 5:30 AM, said:

How much faster is the 64 bit version ?

Because when running the CRT emulation it becomes very slow when I set color bleeding to medium and Higher...

And changes in this area in the near future ?

Thanks

I.G

The 64-bit version might be a bit faster in general, but I don't think it will fix the performance problems you're having.  The CRT emulation code is basically unmaintained at this point, and is due to be swapped to Blargg filtering instead.  The plan for the next major release of Stella (probably 4.0) is to move to OpenGL entirely, and also add more filters which work a lot faster than the current CRT stuff.  I am hoping to get this done by the end of this summer.

[Keatah]

stephena, on Tue Jun 7, 2011 4:04 AM, said:

israelg, on Sun Jun 5, 2011 5:30 AM, said:

How much faster is the 64 bit version ?

Because when running the CRT emulation it becomes very slow when I set color bleeding to medium and Higher...

And changes in this area in the near future ?

Thanks

I.G

The 64-bit version might be a bit faster in general, but I don't think it will fix the performance problems you're having.  The CRT emulation code is basically unmaintained at this point, and is due to be swapped to Blargg filtering instead.  The plan for the next major release of Stella (probably 4.0) is to move to OpenGL entirely, and also add more filters which work a lot faster than the current CRT stuff.  I am hoping to get this done by the end of this summer.

That's great! I've been messing around with the Atari800 Emulator 2.2.1 and like how Blargg's NTSC libraries are working on on many of my older pc's. With openGL 1.3! And the amount of control over the artifacting and NTSC 'anomalies' is simply outstanding. I can tweak the settings to make my high-end LCD to look like a 1970's colour-TV!

The one thing missing from those libraries is real-time snow effects, or any real-time interference and noise and waviness or instability. A minor point, to be sure..

Will Stella's openGL version requirements for TV FILTERING remain at 2.0+ or, by use of the Blargg libraries will it work on openGL 1.3 ??

Edited by Keatah, Tue Jun 7, 2011 2:56 PM.

[stephena]

Keatah, on Tue Jun 7, 2011 2:12 PM, said:

Will Stella's openGL version requirements for TV FILTERING remain at 2.0+ or, by use of the Blargg libraries will it work on openGL 1.3 ??

I'm pretty sure we won't need 2.0+.  Actually, I use very little of the advanced features of OpenGL, so 1.x will suffice.  It's just that any version of OpenGL at all (with working drivers) will be much faster than software rendering.  As for the new effects, the stuff from Atari800 should give you a good idea of what it will look like, because I'm basing it partly on that code.

[stephena]

Firehawke, on Wed Jun 1, 2011 5:54 AM, said:

It's been awhile. I don't know if I ever got to thank you for those controller fixes last year-- I had a master breaker fry and take me offline (and completely without power) for about four months. You'd be amazed at how much paperwork it takes to get permits to fix an outside breaker box.

Any case, I digress-- thanks for your help with the earlier issue.

I just updated to 3.4, though, and I've hit a new snag. The analog on the joystick is overriding the hat inputs *and* the keyboard inputs, even when centered and not in use. On Pitfall, if I don't touch the analog and then hold right on the keyboard or hat, he'll inch forward and *stop* in place. If I wiggle the hat (directional pad in this case) up and down while holding right, he'll inch forward repeatedly with each change from up+right to down+right and vice versa.

I tried checking the deadzone, and that had no effect-- I wasn't really expecting it to, either, considering he wasn't running anywhere with the analog centered and no other inputs. This is on Windows 7, using both x64 and x86 builds, using an X-Box 360 controller but probably can be reproduced with any controller that has D-pad on hat and analog stick as X/Y.

I'm unable to duplicate this behaviour.  And after looking at the code, it seems to be not related to the recent 2600-daptor changes as I initially suspected.  I've tried with a Logitech Dual-Action pad, which does have a D-pad hat and analog axes.  Both of these work fine for me, as does the keyboard (and they're all mapped to the same virtual joystick device).  I can also try with an XBox 360 controller in the next day or so, when I get access to my Linux machine again.

Can you try setting all event mappings to the defaults, and increase the deadzone as much as possible?  Because from my analysis of the code, the deadzone setting is being used, and it really seems to me to be a deadzone issue, as if the analog stick is firing by a small amount and reseting the axis value to zero.

Feel free to communicate this by PM if you like.  I'd like to get this fixed for version 3.4.1.

Edit: I've confirmed this issue with my XBox 360 controller.  So it isn't just a device with hats and analog stick; it also seems to be XBox-specific.  I'll try to figure out what's going on.

Edit 2:  I've found the issue and fixed in the SVN.  This will be included in the 3.4.1 release.