volume to be controlled. There's some code for the Mac which will
need to be updated for this to work in that environment.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@259 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
passed when a TIA register is modified. Also added code to stop a frame
once it reaches the maximum number of scanlines for the current TV
mode (i.e., PAL or NTSC).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@257 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
That means I was able to ditch the ugly INI file code, and use the Settings
classes directly. It also means I don't have to pass many options to Stella
commandline program through commandline arguments, since they'll already
be in the config file.
This is the beginning of fully integrating the Stella commandline program
with the StellaX GUI. It won't happen for this release, but in later
releases these may become one program again.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@254 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
sense for the Settings class to have to depend on Console, especially
since I plan to use the Settings class in the Windows frontend.
Removed the snapshot filename code from the individual SettingsXXX classes,
since it was redundant. Instead, added a ::fileExists() method, which
is the only thing that was really platform-specific about the code
anyway.
Linux and Windows ports have been updated. The Mac port will have to be
updated to work with this.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@253 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
instead of joystick events.
This bug has been present in the codebase for over 3 years (at least).
Thanks to Mark Grebe for pointing it out.
This means that you will no longer be able to use a gamepad/joystick
for both joystick *and* driving controller events at the same time;
you'll have to map a particular device to either an internal Atari
joystick *or* an internal Atari Driving Controller.
This also means that the Driving Controller remapping now actually
works. Previously, it didn't do anything.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@252 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
port, since Mac users are accustomed to using Control-Q instead.
To any Mac users who are testing the code at this point; you'll have to
delete your Stella config file for this change to take effect.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@251 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Stella program. Right now it doesn't do anything, but at least it
compiles :)
Since most options can be toggled at run-time in the Stella binary,
and most of those changes are saved by Stella itself, I'm probably
not going to add many options to StellaX (only the ones that can't
be changed through Stella itself). The next version will hopefully
have more configurable options.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@249 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
In the future, you should use the '-P' option to CVS update
or checkout to prune all the old directories which no longer contain
any files.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@247 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
It's still in the main CVS repository if you want it ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@245 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
(second paddle on first Stelladaptor) actually generated a PaddleTwoFire
event.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@244 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
yet have a driving controller, I can't add support for it (donations would
be welcome :)
- The buttons/axis events seem to work, but I really have to push
hard on the sticks for an event to register. It's probably because of
the crappy controllers I have. I'll test on a real 2600 when I get a
chance.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@243 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Stelladaptor will act as the left joystick/paddles 0 and 1/left driving
controller. The second detected Stelladaptor will act as the right
joystick/paddles 2 and 3/right driving controller. Any other Stelladaptor
will be ignored.
- Of course, since I don't actually have my Stelladaptor yet, only the
detection of Stelladaptors is present; the actual functioning is not done
yet (but I expect it will be quite easy to add it).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@242 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
really worked right anyway.
- Stella now tries to open all joysticks you have (up to 4), and
they can then be remapped any way you want.
- As of the previous cvs commit, all old state files are now
invalid. Sorry, but it had to happen sometime (and it may happen
again).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@241 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
would have liked in the 1.3 release, and it still doesn't. The background
music in Pitfall2 is there, but it's scratchy. And in Quadrun, you only
hear one 'quadrun' instead of 'quadrun, quadrun, quadrun'.
- For now, you can disable/enable it by (un)-commenting the line
'#define DIGITAL_SOUND' near the top of the SoundSDL.cxx file.
- For those of you that care, here's the problem:
Previously, the correct number of sound samples were created and
the audio system had delays inserted to account for it. Problem was,
the delays were causing 'jumps' in the video rendering, since the
sound code was delaying every frame.
Now, the audio system only takes as many samples as is needed. This
eliminates the audio/video sync problems, since there are no delays
at all. But the problem now is that if more samples are generated
than the audio system requires, some are lost and/or overwritten.
I do place them in a queue, but the samples are being generated faster
than they're being removed. So things don't sound quite right.
- At least that's what I think. We need some way to combine both approaches,
so that the audio system only gets as many samples as it needs, but in *those*
samples, all the sound information up to that point must be present. I guess
the samples will have to be mixed, or something.
- If anyone has ANY suggestions at all, they would be greatly appreciated.
- And for anyone who doesn't have a clue what I'm talking about, let me
say I really &&%*(&* hate sound programming.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@240 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
the cursor. It should now work correctly.
Thanks to Mark Grebe for the suggestions.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@239 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
an OSX port on the way.
- Added z26 palette support. Use Control-P to switch between the three
available color palettes.
- Special thanks go to Mark Grebe for all the above changes.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@238 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
seem to add any more overhead, and it's theoretically supposed to sound better
(jury's still out on that one).
- Added a patch that fixes compiling under OS X with Fink (thanks to Julian
Squires).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@237 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
the annoying flashing that was happening in Linux. Hopefully it will fix
the Windows GL code as well ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@234 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
resolutions. Fixes the problem in Linux of getting weird refresh rates,
and will hopefully fix the fullscreen OpenGL Windows problems as well.
- Removed the option of automatically pausing when toggling fullscreen/
windowed mode since it was getting on my nerves :)
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@233 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
has basically been reverted to 1.2 functionality. The good news is that
the video and audio are always in sync, even in Windows. The bad news
is that we've lost advanced sound in Pitfall2. I know what's required to
fix it, but I'm seriously considering doing a new release and waiting
until the release after that to fix it. Right now (with release 1.3),
most games have laggy sound, even under Linux, but the background music
in Pitfall2 is there. I'd rather do a new release with Pitfall2 not
completely working, but having everything else working great, than wait
another month or two. I'm sure most people will agree ...
- The Windows port has some slight popping every now and then. Damn, I
really hate Windows sound programming. It just can't handle low-latency
sound generation as well as Linux (shameless plug).
- Added options '-fragsize' and '-bufsize', which set the sound fragment
and buffer sizes, respectively. They're currently set to 512 and 1536,
and this seems to work best.
- Fixed an error in calling 'putenv' in mainSDL. Now the Windows port
actually starts with the game window centered.
- Finally, IMHO (baring Pitfall2) Stella now works better wrt A/V sync
on Linux than z26 does on Windows (a bit of friendly competition :)
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@232 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
with 'make -jN' when compiling on SMP or distcc-based machines. Defaults
to 1 CPU, and most people won't need to touch it.
- Cleaned up some sound related build options in the makefile. Now
there is only one sound option (SDL, since the codebase is standardizing
on SDL), and the OSS and ALSA drivers are being discontinued.
- Moved the settings that were specific to Linux SDL port to the emucore
Settings class, since they are now relevant to all SDL ports (including
Windows).
- Reworked the sound selection code in mainSDL. Now the '-sound'
commandline and ini-file argument is a boolean, representing whether
sound is enabled or disabled.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@231 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Many changes to the makefile representing the 'SDL-ification' of the
Stella codebase. Now there are 4 make options which should be
self-explanatory: "linux, linux-gl, win32, win32-gl".
The codebase now compiles under Linux (with gcc) and Windows (with MinGW)
from the same makefile without any editing or modifications. So there
is finally full cross-platform support.
Next step is to fix the small OpenGL regressions in Windows, and finally
move to the dreaded sound code. Then a new release ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@230 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Made emulator pause when toggling between windowed and fullscreen
modes.
Added code for the TEXTURES_ARE_LOST definition. In Windows, when
changing the window size or toggling fullscreen/windowed modes, the
OpenGL textures are lost and must be reloaded. This now works.
Fixed a long-standing bug in snapshot files. I made sure they were
opened in binary mode. That wasn't required in Linux. Sometimes
developing multi-platform code can really work the bugs out.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@228 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Linux and Windows.
Reworked the Makefile (again). Now you have to edit it and select
which system you are using for the SDL port (linux or windows),
then start compilation with 'make sdl'.
The makefile is starting to get harder to manage, and with the
explosion of features, I'm looking into moving to a configure
script (autoconf and automake) for a future release.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@227 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
compilation in Windows. There's still some work to do in the
SettingsWin32 class, and tweaking of the sound, but it's pretty
close. I think its the best that Stella has ever sounded on
Windows ...
I use the MingW32 environment with the Ming SDL libs from libsdl,org.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@226 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
uses to the SDL port. Currently, the three choices are the current
Stella palette (standard), the palette from version 1.1 (original),
and the one from the z26 emulator (z26).
The '-palette <standard|original|z26>' option can be used from the
commandline, and Control-P can be used while within the emulator.
I haven't actually added the z26 palette yet, so when you switch to
that one, you get a blank screen.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@225 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Added the Cyberstella icon to the SDL port. No more ugly looking
'X' icon for Stella in Linux.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@224 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
SDL FrameBuffer classes. This is in preparation for the port of the SDL
version to Windows (which already runs quite well).
This may eventually be a replacement for Cyberstella ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@222 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
modes in the OpenGL SDL port.
Updated the documentation with the changes to the SDL commandline
arguments. Rewrote the Linux requirements and installation
procedures.
Merged all todo stuff into the Todo.txt file, and removed the
redundant CyberstellaTodo.txt.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@221 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
All Settings should now be saved in the stellarc file.
Activated all former settings in StellaConfig. You can now select
different options from the config dialog box and actually have
them work in the emulation core.
Cleaned up the main file lister user interface a little. Specifically,
when you resize the window, the internal file lister should resize
as well. This one was bugging me for a long time. There's still
some work to do when making the outer window smaller than the inner
one though.
Made first pass at the SoundWin32 code. It now sounds *much* better
than it did before, but there's still some work left to do. I've been
looking at other Windows Atari 2600 emulators (PCAE and Z26), and
I've noticed that while their sound generation is clear and doesn't
have pops, the pitch and latency is still off a bit. The only time
I've ever heard it work correctly is in the Linux version of Stella,
and I'm trying hard to make Cyberstella work the same way.
Note, this isn't a slam again PCAE or Z26, or saying that Linux
is superior to Windows (I'll leave that to another discussion ;).
It's just that Stella and the sound code were originally
developed under Linux, and that's where it seems to work best
(and I'm hoping this will change).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@220 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Moved the refresh() method to FrameBuffer::refresh(), since
all ports may need it.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@219 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
references to SettingsWin32.
Made many changes to FrameBufferWin32, cleaned up the code
and renamed variables. I may only release fullscreen mode
for version 1.4, so I decided to clean it up a bit.
Enabled SettingsWin32 code. Now you can save/load state
files.
Reorganized the base Settings class a bit. It had a
dependency on a Console being created when it shouldn't
have. As a result, any changes made to event remappings
won't be saved. I'll fix it tomorrow; time for sleep ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@218 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
OpenGL port.
Added a FrameBufferSDL::refresh() method that's triggered when
the window needs to be redrawn (SDL_VIDEOEXPOSE event).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@217 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
CPU usage from 14% to approx. 10%. While that may not seem like much,
it's actually a 28% improvement.
The only way for it to get much better is to switch to paletted OpenGL
textures, but since they aren't supported in all versions of OpenGL,
I may not even bother.
For reference, the software SDL port uses a maximum of 5% CPU. I don't
see the OpenGL port ever getting that low.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@216 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
changes.
Added code to draw menus to FrameBufferWin32. This will be
changed around soon, when I get to implementing the windowed
modes. I added it now to make sure that remapping works from
the in-game GUI (it does!).
Most of the core features are now working. I need to add
windowed mode (as mentioned above), then start cleaning up
the settings and getting rid of the registry crap ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@215 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
wrt to the MediaSource.
Previously, in the main run loop for a port, you had to call
FrameBuffer::update and then
Sound::updateSound(FrameBuffer::MediaSource). Now, you can call
FrameBuffer::update() and then Sound::update(). But since the
ordering here is important, I've introduced a Console::update()
that does it all. So the main run loop for each port just
got a bit simpler.
Also changed around the Snapshot class a bit. All this is to
reinforce the fact that the MediaSource is owned by the core,
and the FrameBuffer, Sound, and Snapshot classes make use of
it. Previously, it seemed as if the FrameBuffer owned the
MediaSource.
I'm finding all these little inconsistencies because of
writing the Porting.txt document, and trying to explain
why something is being done a certain way (and if I
can't explain it, I rewrite it). So if for no other
reason, the Porting.txt document has already been
valuable.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@214 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
for a minor reorganization of Sound code (the update
performed in the main loop will eventually be done by
Console::update() only, instead of updating the display
and sound separately).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@213 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
I'm on a Celeron 766 with a crappy ATI card. Under normal usage,
CPU usage has dropped from 60% to 8.5%. But there is still a
slowdown when showing alpha-blended rectangles at the current
framerate. I'm about to mark this up as being caused by the
crappy card and OpenGL implementation I'm using, so performance
may not get much better than this. On my development system
(even before this latest patch), CPU usage never goes above 14%
(granted, that system is a P4-2.4 with GeForce4MX card).
I'll try to run on a similar system to this Celeron, but with
an NVidia card, and see if the ATI card drivers are actually
at fault.
But I really do think its the OpenGL drivers, since software
mode never uses more that 4% of the CPU, and that is at 1280x1024.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@212 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
OpenGL port. Normally, the window is double the native TIA frame
width, so we always get a ratio of 2.0 (2:1).
Now, if you're using OpenGL mode, the '-gl_aspect' commandline argument
can take a decimal number representing the ratio you want to use.
For example, normal TV mode would be 1.3333 (4:3).
Depending on the resolution you use, you can make the window look much
more like the original Atari. I find that in 1600x1200 mode, an
aspect of 1.6 looks quite authentic.
This is only supported in the SDL OpenGL port for now, since changing
the aspect took only 1 line of code (I love 3D graphics :) It may
never be supported in software SDL, since it is quite a bit harder
to do it in software.
Ditto for the Cyberstella DirectDraw7 code (it will probably never be
implemented, unless hardware scaling is available). If/when I get
around to the Direct3D port, it will be trivial to do there as well.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@211 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
joysticks are used (the limit in the Stella core). I only
have a single joystick on my development system so I
haven't yet actually checked if it works with multiple sticks.
I see no reason why it wouldn't.
Since remapping is now in the Stella core, we automatically
get joystick remapping. The core GUI for changing events
hasn't been done yet (quite simple, but I'm waiting for the
FrameBuffer rewrite), but I've been successful in changing
the remapping directly in the stellarc file.
So one huge feature request has been completed (multiple
joysticks and event remapping), Next I'll work on the
remaining oft-requested feature (windowed and fullscreen
mode in the same program, without a recompile).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@210 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
bwmott