This is enabled in the UI or through the 'tv.phosphor' commandline
argument. Note that what was previously 'tv.phosphor' (for setting
the blend level) is now 'tv.phosblend'.
Updated documentation in various places.
This is allowed, since after analyzing the code, we see the pixel format
will always be ARGB8888 mode, so we can hard-code the logic to do the
conversion.
This leads to a measurable performance improvement, since we eliminate
3 function calls per RGB colour lookup. And the calls themselves involved
IF statements and various other shifts that weren't needed. Assuming
normal phosphor mode with 160x210 pixels, this saves 100,800 function calls
per frame!
For now, Blargg phosphor mode simply shows the same image as without phosphor.
This is a WIP, and if we can't get it finished for 5.0, it will be released as-is.
Phosphor blend now defaults to 0 in the base properties, and is converted to
50 before being passed to higher levels. This needs to change when we
get to issue #144.
- converted many pointers to references
- merged code from several files into one class
- broke up some methods into more managable chunks
This will allow it to be easy to add the phosphor code during
NTSC TV emulation.
- Updated default phosphor blend to '30'.
- Added shortcut keys Alt-i and Alt-o to decrease/increase phosphor
blend mode dynamically, while a ROM is running.
- Made range of blending 0 - 100.
std:: functions into BSPF namespace at all. So I removed them, and have the
calls map directly to the std:: versions.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@3304 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
To anyone reading this, Merry (belated) Christmas and Happy New Year!
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@3239 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
I realized that they didn't need to be stored in a map, since the integer
ID was never actually being used. This must have been part of a proposed
API that I've since deleted??
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@3062 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
implementation, and using virtual d'tor only when absolutely necessary.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@3000 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
any-sized PNG can be loaded and then scaled to the available space.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2979 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
on top of the dialog surface. This is useful when the surfaces are using
different resolutions, and we don't want to draw the exact overlaying surface
pixels directly into the the dialog surface.
For now, this is most useful for rendering snapshots in the ROM launcher, and
eventually it will allow arbitrarily-sized images to be scaled (in hardware)
to the picture area of the launcher.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2978 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
having to know about TIA, Properties, etc. Basically, it now saves
a snapshot of either the FrameBuffer or an FBSurface, and adds
text comments passed into it. The contents of the surface and comments
are no longer calculated (or known) by the PNG code.
This is in preparation for saving FBSurface from anywhere, which will
help in the debugger for taking snapshots.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2928 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Changed pointers to references in c'tor calls, making things a little safer.
Removed FBSurfaceTIA, since it was tied too closely to SDL itself. Added a
class called TIASurface that is functionally very similar, but is more generic
and accessible by the FrameBuffer directly. Eventually, this class will take
responsibility for all things related to rendering the TIA image (Blargg TV
effects, phosphor mode, etc).
TIA rendering is currently borked; fixes will follow ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2889 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Stephen Anthony