into FrameBufferSDL2 only. This will make conversion to actual SDL2 code much
easier, since it won't be touching any of the core emulation code in src/emucore.
Next TODO is something similar for EventHandler (which uses SDL heavily and is
too tied to a core class).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2846 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
break. First thing to do is update the year. Happy new year to anyone
reading these commit logs.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2833 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
have been changed to 'SDL2'. From this point on, the OpenGL-specific
code will be removed, and replaced by SDL2-specific hardware-accelerated
code.
Cleaned up (mostly) the API of FrameBuffer vs FrameBufferSDL2. Since the
FrameBuffer class is an emucore object, it should have no knowledge of SDL,
or any particular rendering toolkit for that matter (just in case we want
to move to SDL3 eventually :) ).
At this point, all checks for OpenGL have been removed, so if you don't
have it on your system, Stella will fail to compile and/or run.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2832 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
centering has been removed (SDL2 provides this natively).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2831 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
in line with the other ports. Besides, the code now also supports
64-bit Windows, so the name was incorrect anyway.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2830 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
software rendering support. I've been wanting to do this for years,
and finally the time has come. So for now, you need OpenGL for Stella
to build and run.
Expect major breakage over the next few months, as I port to SDL2.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2829 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
ever want to see the TIA, not the entire debugger area too.
This will be fixed for Stella 4.0, once I remove the @#*%$-ing software
rendering support. That part of the code keeps coming back to haunt me
for years. It will be *SO MUCH EASIER* to deal with these things when
everything is a FBSurface that can be stretched/scaled as necessary.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2828 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
of bold and normal fonts within the debugger UI. Because of the # of changes
this requires, this is as far as I'll willing to go with UI configurability.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2820 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
I wasn't completely sure how the file was structured, but it's starting to
make a lot more sense now. I think in the end, it will be better to use this
file as much as possible.
Bumped version #, and starting all over again.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2815 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
number.name convention (which seem to be pass #'s for DASM). Initially
having this info in Stella was simply visually inconsistent, but now
it also interferes with recompiling when saving the disassembly (IOW,
the data put into the symbol file by DASM can't be fed back into DASM
again in these cases).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2803 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
tab area and RAM area now take advantage of extra space.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2798 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
to the screen (inactive pixels are 'transparent' in the UI). In the
case where there is only one possible object below the register, a
'blank' uses the underlying colour (ie, in normal priority, a blank
PF is 'coloured' using COLUBK).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2797 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
COLUBK instead of always using colour 0 (black). This is more
informative, as it displays how the registers actually work when
being drawn to the screen. Thanks to Tjoppen of AtariAge for this.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2796 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
symbol names in the DASM symbol file). This partly fixes a deficiency in
symbol files, whereby two names could have the same address (one has an
address, the other as a constant), and Stella would use whichever one
occurred in the file last.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2795 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
values, which messed up code running from RAM (ie, address $80 became $8000!).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@2790 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
stephena