Jump to content

stephena

+AtariAge Subscriber
  • Content Count

    3,726
  • Joined

  • Last visited

  • Days Won

    5

stephena last won the day on April 7 2019

stephena had the most liked content!

Community Reputation

2,272 Excellent

5 Followers

About stephena

  • Rank
    River Patroller
  • Birthday 02/02/1974

Contact / Social Media

Profile Information

  • Custom Status
    Stella maintainer
  • Gender
    Male
  • Location
    Newfoundland, Canada
  • Interests
    Computer Programming, Emulation of old/ancient systems

Recent Profile Visitors

35,866 profile views
  1. I can't guarantee that those will work with Stella, as I've never tested them. But I would guess that they'd be fine. I should have been clearer. It's not just two different devices you'd need, but two separate cursors. If both mice move the same cursor onscreen, then they're in effect only one mouse. That's why I don't think it's possible with current OS's; there is only ever one cursor shown, and hence only one pointing device.
  2. I don't know how feasible this is. Basically it depends on what the operating system allows. For example, can you plug in two mice (in Windows, Linux, or whatever you're using) and have the OS recognize them as two separate devices? If not, then there's no chance for Stella to do it, since Stella can only use what the OS provides. And I think most (all?) OS's don't allow that. To be honest, I would recommend skipping the mice entirely, and look into getting a 2600-daptor (http://www.2600-daptor.com) and a set of real paddles. Stella can use this without issue, and the paddle emulation is much more realistic compared to a mouse.
  3. Glad you got the problem fixed @SpiceWare, and just as glad that it wasn't a Stella issue 😈
  4. The Retron77 link has been updated to 6.2.1 now. This is the first release since 6.1.2; we missed the 6.2 release for R77.
  5. Stella 6.2.1 is now available. This fixes most of the bugs mentioned in this thread so far, and even adds a few new features. Changelog as follows: Fixed Pitfall II ROM not working correctly. Fixed crashes when using some combinations of bankswitching schemes on incorrect ROMs, or when using invalid ROM file sizes, etc. Fixed RIOT timer behaviour on reading/writing at the wraparound cycle. Fixed incorrectly setting D6 bit on TIA reads in some cases. Related to this, improve 'tiadriven' option to randomize only D5..D0 bits. Fixed custom palette and TV effects adjustable slider rounding issue. Fixed some bugs in 3E+ scheme when using non-standard ROM sizes. Fixed crash in Audio & Video dialog when opened from debugger, and the debugger window sometimes being resized when using the Options dialog. Make NTSC custom phase shift not affect Yellow anymore. Fixed '1x' snapshot mode; TV effects are now disabled. This mode now generates a clean, pixel-exact image. Fixed mappings sometimes not being saved in the Retron77 port. A ROM properties file may now be placed next to the ROM (with the same name as the ROM, except ending in .pro), and Stella will automatically apply the properties to the ROM. [NOTE: this was present in 6.2, but was mistakenly left out of the changelog] Added button to Game Info dialog to save properties of the currently loaded ROM to a separate properties file (in the default save directory). This is useful in conjunction with the previous item. Allow changing custom palette and TV effects adjustables in 1% steps again. Updated documentation for changes in ROM properties key names. The codebase now compiles under gcc6 again. Future versions will require gcc7, though. The download links are in the original post (and as always, donations are welcome). The Retron77 port is still being built, so the links currently point to the 6.1.2 release. It will be updated when the build is ready.
  6. It's possibly related to vsync issues, where one monitor is vsynced and the other one isn't. I'm going to be absolutely honest here; this one may be hard to trace. Not only would we have to have duplicate monitors on a system, but they'd probably have to be on a Mac. I do have multi-monitor setup at work, but I can't get back to my office yet And even then, it's not a Mac system. Is any other SDL-based app having the same issues? Does it happen only with the latest version of Stella, or did it start with some previous version? If so, which one??
  7. OK, no problem. Feel free to report it here, or to create an issue on Github: https://github.com/stella-emu/stella/issues. We want to have Stella act like real hardware at all times, to make it easier on developers (because as you're now seeing, doing development strictly on hardware is very time consuming).
  8. Please describe what the problem was in your code, and how you fixed it. Then we can look into why Stella isn't detecting it, and perhaps fix it so it does.
  9. I'll think about it some more. Nothing will happen for 6.2.1, which will be released in a day or so. But perhaps for 6.3.
  10. So again, I'm not sure what you're asking for. There is a 1x mode there already for generating snapshots with all the extra stuff turned off. There was a bug whereby it was applying TV effects when it shouldn't have (mentioned above). I've fixed that, so now in 6.2.1 you can get clean snapshots.
  11. Fixed the 1x snapshot issue. The first pic is from Stella 6.2 (TV effects are incorrectly applied). The second pic is from the latest code (will be included in Stella 6.2.1). The result is obvious.
  12. Well then, the current '1x' option is what you need. Currently there's a bug that applies TV effects to that mode, and it shouldn't. I can have that part fixed for 6.2.1. But to be clear to everyone; it would be in 1x zoom mode, 320 pixels wide by h pixels high (where h depends on whether the ROM is NTSC or PAL). And no phosphor (which means no blending of frames in 30Hz mode), no scanlines, no interpolation, no TV effects. It's easy to turn everything off and offer a mode to save in that format. The problem comes when someone says "I want everything turned off except this". And the 'this' is different for everyone. 😈
  13. Also, I'm not entirely sure that pixel-exact images are what people are looking for either. Because a pixel-exact image is one that comes from the TIA in one frame, and that means no phosphor effect and no zoom. So we have some people requesting pixel-exact images, but they want zoom. And others are requesting pixel-exact, but they don't want flicker 😖 So I'm not sure in the end what it actually is that people want with this functionality.
  14. From all the feedback I see, it seems that what most people want is a way to generate pixel-exact snapshots. So it's not so much that what's rendered onscreen is pixel-exact, but that the eventual snapshots will be. It's easy enough to extend the snapshot settings to offer an option to do a pixel-exact image, with only integral zoom (so again, no interpolation). However, we won't be changing what is output to the screen. A lot of work has been done to make this as realistic as possible. NTSC and PAL TV sets don't suddenly change dimensions, and neither should Stella. It is a fact that PAL scanlines are thinner than NTSC ones, so generating video output that doesn't do that same thing is in effect quite inaccurate. Even if Stella worked that way in the past. It was wrong then, and we're attempting to correct that going forward. So the best we can do is offer a snapshot mode that just gives you raw pixels without any interpolation. It's already there, mostly. We need to fix a few bugs and add to it a little, but the infrastructure is there to do it.
×
×
  • Create New...