Jump to content
IGNORED

Stella 4.7 released


stephena

Recommended Posts

So it's time for a new release of Stella. I've been sick over the past few months, and didn't get to work on Stella as much as I'd have liked. Anyway, here it is:

* Improved paddle emulation in several ways:


- Added ability to specify the maximum range of movement for paddles when using a mouse or digital device to emulate the paddle. This is useful since on a real console most paddle games use very little of the paddle range, and could result in moving the mouse onscreen with nothing appearing to happen (when in effect it was as if you turned a real paddle all the way to the end of the range). This eliminates issues in (for example) Kaboom, where there was a huge 'deadzone' when moving to the left. All applicable ROMS in the internal database have been updated.

- The range for paddle emulation now takes an integer from 1 - 20, indicating how much to scale movement (ie, how fast the onscreen paddle will move when you move the mouse). The movement itself is now also smoother than before.

* Fixed bug in 'Score mode' in TIA emulation; the TIA object colours were correct, but the associated priority was sometimes incorrect.

* Fixed bug in ROM launcher; selecting 'Options -> Game Properties' after loading a ROM would always point to the last opened ROM, not to the one currently selected.

* Fixed bug in storing ROM properties; in some cases, a copy of the ROM properties was being stored in the external file when it was exactly the same as the internal entry.

* Added 'CV+' bankswitching scheme, developed by myself and LS_Dracon (of AtariAge). This scheme contains RAM like the CV scheme, and also switchable 2K ROM segments by writing to $3D.

* Added more C++11 updates all over the codebase, and ran Stella through Coverity for the first time. I'm proud to say that Stella now has a 0.00 defect rate!

 

A number of bugs from the '4.6.5 release thread' have been fixed, but there's still a few more to go. As usual, Stella can be downloaded here, and donations are welcome here. Feedback can be in this thread or by PM.

  • Like 14
Link to comment
Share on other sites

Awesome!

 

I've had some ideas on making the screen jitter work better - it should take multiple frames, not just one, to recover from a large variance in scanline count (i.e. a screen roll). I'll make sure to get the latest source this weekend before I work on it.

Link to comment
Share on other sites

Both the 'digital paddle sensitivity' and 'mouse paddle sensitivity' can now go to 20, but the former is for digital inputs (ie, digital joystick, keyboard, etc), and the latter is for the mouse. So if you're using the mouse for paddle movement, the latter is what you should be changing.

 

The range of movement is per-ROM, and as such is accessed in 'Game Properties' for each ROM. It basically says how far left the mouse/digital input can move before it stops sending 'paddle events'. It eliminates a huge deadzone on the left which is the result of real paddles not using the full range of rotation. All paddle games in the internal ROM database have already had this adjusted, so you shouldn't need to mess with it. If you do want to change it, see Game Properties -> Controller -> Mouse axis range.

  • Like 1
Link to comment
Share on other sites

I don't see how the right side would have changed. This corresponds to turned 'completely clockwise' on a real paddle, and wasn't addressed at all by my code changes (unless I accidentally introduced a bug). I concentrated specifically on the left side/counter-clockwise movement.

Link to comment
Share on other sites

Perhaps a taboo question, but I am not sure what the ROM database is that you are referencing. Is it the ROMs or just the data that recognizes when specific ROM is opened? I'll look more carefully on the Stella website, but if you can point me in the right direction, that would be helpful.

Link to comment
Share on other sites

The internal database I refer to is one that's built into Stella. You can see if by referencing the code here. All I meant is that I've manually went through all the paddle ROMs in the internal database and added an appropriate range for each one. So you shouldn't need to change the range at all. Now, if you're using a ROM that isn't in the database, then of course you're free to change the range. I just meant that it's currently as plug-and-play as possible; you shouldn't need to do anything for common ROMs; I've already taken care of it.

  • Like 2
Link to comment
Share on other sites

I've had some ideas on making the screen jitter work better - it should take multiple frames, not just one, to recover from a large variance in scanline count (i.e. a screen roll). I'll make sure to get the latest source this weekend before I work on it.

Think this turned out pretty good. The blog entry has a test build for OS X, as well as the 2 source files that were changed in case somebody wants to build and test it on Linux or Windows.

Link to comment
Share on other sites

Spice, I'll look at the code soon. I just wanted to report I found a bug with the new 'paddle range' stuff for Medieval Mayhem; the range is adjusted too low, so you can't select the # of players :( I've already committed a fix, which will be in the 4.7.1 release.

  • Like 1
Link to comment
Share on other sites

Hey Stephen, congrats on the release! Looking forward to playing some paddle games to test it out.

 

By the way, a potentially strange request: can you post the changelog more prominently on your website? Even just a sidebar link on the stella site to the current text version of the changelog/whatsnew would be useful.

Link to comment
Share on other sites

Three ways to do light-gun support.

 

1- You'd have to simulate the light-gun "pointed-to" area by way of crosshairs overlayed on the game screen, and controlled with a mouse.

 

2- Build a sensing array and controller that transmits it's position, not unlike wii and xbox.

 

3- Have the lightgun analyze the game frame, and tell the console/emulator what pixels it just pointed at when the trigger was pulled. Tell that information to the emulator. The emulator would need to be aware of where it was in the screen rendering process along and correlate that with the gun timing to determine if a target was hit.

 

There are other means, but I don't have time to type them in at the moment.

  • Like 1
Link to comment
Share on other sites

The lightgun, KidVid, and Compumate controllers are something I want to work on when I find more time. But since they only affect a few games each, there are other more serious issues that have higher priority.

 

About the Supercharger though, what bugs are there??

Link to comment
Share on other sites

CPU usage bug report for 4.7:

 

I noticed that the rom selector screen makes my older laboratory machine run at 100% usage. That's not good.

However, when playing Miniature Golf the usage is 20-50% which is what I would expect for this level of hardware.

 

Version 3.9.3 shows 0-2% usage while in the rom selector screen, essentially nothing.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...