41 replies to this topic

[stephena]

spacedueler, on Thu Jan 5, 2012 12:52 PM, said:

Breakout - 2nd player doesn't seem to work on separate axis

Breakout uses paddle 0 / paddle 2 combination, but you've probably set it to 0/1 (for Street Race to work). For this to work the way you want, the current 'mouse-to-paddle' setting will have to be stored per-game, and not be a global setting.

Quote

Indy 500 - 2nd player doesn't seem to work on separate axis - I know the driving control is a whole other animal - but that would be bad a** to get that game working 2 players. My arcade spinner controls this game just like a driving controller (360 degrees rotation). It's a bit too sensitive, but I can play with the settings

The current 'mouse-to-paddle' mapping is just that: mouse to paddle. More code would be needed for separate axes on the mouse to map to driving controllers (or any other controllers for that matter). Now that I think about it, having the mouse-axis mapping stored per-ROM would have been a better idea. That way, the mouse could emulate any device you want on any axis, and also be different for every ROM. I'll consider this for the 3.6 release.

[PFL]

I've been playing around with 3.5 for a few days now and it's great that the 'ROM list' loading delay bug is gone.

I have a question regarding the future implementation of the graphic filters. Is it remotely possible to make them compatible with earlier versions of OGL, at all? The reason I ask is that I love to use my netbook while traveling to play old console emulators but it only has support for OGL 1.4. It would be really nice if in future builds I could use the filters on my netbook as well as my home computer. Thanks for any info.

[stephena]

PFL, on Tue Jan 17, 2012 6:48 PM, said:

I have a question regarding the future implementation of the graphic filters. Is it remotely possible to make them compatible with earlier versions of OGL, at all? The reason I ask is that I love to use my netbook while traveling to play old console emulators but it only has support for OGL 1.4. It would be really nice if in future builds I could use the filters on my netbook as well as my home computer. Thanks for any info.

The new effects will be Blargg filtering, just like in Atari800. And yes, they will work with lower versions of OpenGL. I can't say which right now, since I haven't looked at it thoroughly yet, but I suspect v/1.4 will do. Perhaps even 1.3 will be the minimum. But my point is to exclude as few people as possible (since using OpenGL itself is already excluding some people).

What I do with OpenGL is actually very basic. I just use it for free image stretching and (possibly when scanlines are added), alpha-blending. No other advanced features of OpenGL will be required, so the minimum version can drop back.

[Keatah]

That's great news. I can run Atari 800 Emulator v2.2.1 with openGL v1.3 on just about the worst hardware imaginable, iNTEL ExtremeGraphics2 82855-GM integrated graphics from 2004.

So if artifacting in Stella will use the Blargg Filtering kit - then we should be in good shape as far as lesser and older systems are concerned.

What is the name of the filtering currently in use in Stella?

[stephena]

Keatah, on Wed Jan 18, 2012 9:52 AM, said:

That's great news. I can run Atari 800 Emulator v2.2.1 with openGL v1.3 on just about the worst hardware imaginable, iNTEL ExtremeGraphics2 82855-GM integrated graphics from 2004.

So if artifacting in Stella will use the Blargg Filtering kit - then we should be in good shape as far as lesser and older systems are concerned.

Then that will probably be the requirement here too. I won't be doing anything other than what Atari800 is doing.

In fact, once SDL 2.0 is released (the graphics library that Stella uses), then we probably won't even be using OpenGL in Windows at all. On that platform, SDL will use Direct3D, which is much better supported than OpenGL. Linux and OSX will still use OpenGL, since it works fine there. The only reason I added explicit support for OpenGL in the first place was to get acceptable speed. Once the new SDL comes out, I can remove the OpenGL code completely and let SDL take care of everything behind the scenes. This is also why I'm hesitant to add new OpenGL features, because in probably 6-8 months time all that code will be ripped out anyway.

Quote

What is the name of the filtering currently in use in Stella?

No name, it is a home-grown scheme developed by Ian Bogost and students at MIT. However, they later sent me updated code that did Blargg filtering, with the intent of replacing the old code. I'm only now getting around to working on it.

[Thomas Jentzsch]

stephena, on Wed Jan 18, 2012 2:20 PM, said:

The only reason I added explicit support for OpenGL in the first place was to get acceptable speed. Once the new SDL comes out, I can remove the OpenGL code completely and let SDL take care of everything behind the scenes.

So will SDL become faster than OpenGL or will you give up speed for better maintenance?

Maybe it is about time to abandon my old Athlon 2000+

[PFL]

Cool! I knew you were intent on using Blargg in the future but I was unsure just why OGL 2 was used in the first place. I'm pretty ignorant with regards to OGL/SDL/DirectX but it's good to know that at least you know what you're talking about!

It'll be good having Stella looking pretty on my wee netbook.

[stephena]

OK, a little history on the graphics in Stella:

• Originally there were separate ports; Linux used X11, WIndows used Direct2D (now obsolete), and an OSX port didn't exist at all. All ports used software rendering (aka, no acceleration).
  
• One of my first jobs when starting with Stella is unifying the codebase and porting to SDL, so that Linux and Windows use the same code, and an OSX port was possible. Rendering is still in software (aka, slow).
  
• Eventually, I added an OpenGL renderer to Stella, which speeds things up considerably. The minimum version is 1.2 or so (very basic usage).
  
• I have to maintain OpenGL and software mode, and take care that one doesn't break the other. And it gets hard, because some things that are very fast and easy to code in OpenGL are very slow in software, and vice-versa.
  
• At some point, the OSX port moves to OpenGL exclusively, since all OSX machines from 10.2 or so have guaranteed OpenGL support.
  
• The original TV filtering is developed by the people mentioned above. They want to use OpenGL shaders, so the minimum version is bumped to 2.0.
  
• Deficiencies are noticed in OpenGL in Windows. I could start an entire thread on this, but long story short, OpenGL isn't as well supported in Windows as Direct3D.
  
• I don't want to write Direct3D-specific code and then have to maintain yet another rendering class. Doing this is bringing Stella back to the way it used to be (separate graphics code for each platform).
  
• MIT guys send me new code based on Blargg filtering, which doesn't need OpenGL shaders. So the minimum version can drop back to 1.3 again.

So along comes SDL 1.3/2.0 (which hasn't been released yet). It will allow me to write code with SDL function calls that, behind the scenes, are hardware accelerated. On Windows it will automatically use Direct3D, and on Linux/OSX it will use OpenGL. In fact it's even better, because it will also support OpenGLES/OpenGLES2, which most smartphone/tablets are supporting right now.

I don't give up any speed, since Stella still uses OpenGL/Direct3D behind the scenes. What I gain is that I don't have to worry about it. I simply create a framebuffer, scale it, and draw it. I don't have to care how it's done, just that it's done quickly. This eases my burden immensely, makes the codebase smaller, and performs better on Windows.

Basically, I've added stuff to Stella over the years because of missing features and deficiencies in SDL. Now SDL will include that functionality, and my code can be greatly simplified.

EDIT: It may sound strange, but I'm actually excited to be removing code from Stella! Anything that makes my job easier makes me want to continue working on it (and conversely, anything that makes things harder makes me want to throw it against the wall). Stella is currently around 75000 lines of code with over 170 classes. It's well structured, but anytime your codebase starts getting that large (and you're the only person working on it), management starts to get much more difficult. And anything you can do to simplify the complexity is that much more of a win.

[Keatah]

Fantastic!

[stephena]

OK, just a quick update on my progress so far (related to topics mentioned previously in this thread):

• The 'fixed debug colors' bug has been fixed
  
• The extra register info has been added to the I/O tab, in addition to controller-specific input
  
• Barring any major problems, the mouse is axis functionality will be upgraded to (a) work per-ROM, and (b) include driving controllers as well as paddles

Once I get the last one finished, I'll be ready for a new point release. Then I can start concentrating on Blarrg filtering for 3.6.

On another note, response to my donation request has actually been very good. Thanks to several people, I've been able to obtain a Commodore 128D! Have a look at my other thread concerning expansion options for the 128D.

Finally, I've received the mouse spinners mentioned above, and also a Blissbox adapter. I'll be using these in testing for the next release.

[spacedueler]

stephena, on Wed Jan 25, 2012 11:03 AM, said:

Finally, I've received the mouse spinners mentioned above

Stephen - I'm glad they made it and you are putting them to use
You described the new mouse functionality in more detail over at the SpinnerMouse pictorial thread:
http://www.atariage....__fromsearch__1
These are great additions to the program!

[PFL]

Thanks for the history lesson. It makes a lot more sense to me now.

It'll be good when the new SDL is out and about - I think quite a few projects reliant on SDL will gain a lot in code streamlining and refinement.

...So, when is Stella 3.6 due out then? (j/k!)

[stephena]

SDL version 2.0 was just tagged yesterday. I suspect the first official release will be sometime in the next 3-4 months. I aim to have Stella compatible with SDL 2.0 soon after it's released, probably sometime this summer. This will mean a major version bump to 4.0.

As for 3.6, I'm aiming for sometime in March.

[Keatah]

..great stuff! What are the requirements for the new SDL library. While Stella's workload would go down, like you say, but what of the newer SDL?

[PFL]

That's good news. I was only joking about 3.6 but it was a nice surprise to see that you gave an ETA. Thank you.

[stephena]

Keatah, on Sat Jan 28, 2012 2:59 PM, said:

..great stuff! What are the requirements for the new SDL library. While Stella's workload would go down, like you say, but what of the newer SDL?

This is still up in the air a little, but according to what they're saying on the mailing list, WinXP will be the minimum supported. For OSX, probably 10.4 (Tiger), and right now Intel-only. This last one is a concern, because if they don't support PPC, then effectively as of Stella 4.0, PPC support will be dropped as well. I'm still looking into that. It might be possible for me to create PPC-compatible libraries. But at some point I think PPC support is going to disappear. I can only go back so far ...

As for general requirements, an accelerated video card will be assumed. There will be a backup software-renderer built in, but I'm not sure if I'm going to use it in Stella. I want to move away from that sort of thing. That means a Direct3D compatible card for Windows, and an OpenGL compatible card for Linux/OSX.

Now before anyone worries, most cards and drivers released in the past 6-7 years are actually compatible. The main issue with the current SDL is that it was written for systems in the 90's, when software rendering was all the rage, and Direct3D/OpenGL 3D rendering was very new on PC hardware. The industry is moving on, and now SDL is as well, making its default rendering modes take advantage of 3D hardware (which as I said, has actually been available for at least 5+ years).

As for performance improvements, I give an example for my development system (Intel Corei7, Nvidia 9600GT video card). Using 4-5X zoom in software mode pegs one core at 100%. Running at 2560x1440 OpenGL mode (effectively over 7X zoom) takes 4% CPU of one core! For those interested, the main problem in that in 2560x1440 software mode, Stella itself has to maintain a framebuffer of that size, effectively updating 13MB/frame @ 60 frames/sec (or 780MB/sec). For OpenGL mode, it only has to maintain a framebuffer of size 160x240 or so (or 9MB/sec). Think about having a very flexible sheet of rubber, and making a drawing on it. Then, stretch this sheet several times over both horizontally and vertically. That's what Stella does in hardware rendering mode. It draws a little picture, and lets the video card 'stretch' it. And it typically saves over 80 times the work. It's actually ridiculous that software is still using non-accelerated rendering in 2012. But that's the case currently ...

EDIT: I forgot to mention that all current phone/tablet-like devices support hardware-accelerated rendering at this point (usually OpenGL ES), and since SDL (and Stella) will now support this natively as well, it actually makes porting to these devices even easier than it is now. Really, apart from the fact that SDL 2.0 is new and there will probably be some initial teething problems, there is zero drawback in moving to it.

[stephena]

Stella 3.5.5 has just been released. Quite a few of the issues mentioned in this thread have been addressed. Please move all new discussion to the 3.5.5 release thread.