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
of mouse events to MainWin32.
Removed the DI_Event type structures. While it made the code
look nicer, we really didn't need the performance hit (however
small it may have been) of serializing and deserializing the
events.
Removed the rest of the framebuffer code from MainWin32.
Made sure the exit event (Escape) was sent to the core,
so that current settings could be saved.
Next I'll look at the joystick code (should be quite easy).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@208 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
really didn't compile :)
And now for the changes.
1) I've updated the DirectInput class to DirectInput 8, and moved
to an event-based system, somewhat similar to SDL. Only the
keyboard is supported for now, but adding joystick and mouse should
be quite easy.
2) I've (almost completely) moved the FrameBuffer stuff out of
MainWin32 and into FrameBufferWin32, where it actually belongs.
Next, I'll work on more code cleanups, and then I'll attempt
to switch to the experimental DirectDraw code (so we have
windowed *and* fullscreen modes dynamically).
All things considered, its coming together faster than I thought ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@205 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
FrameBuffer class is paused, and *it* notifies the child class of
this event. Previously, the code for pausing the parent class
had to be provided by the child, meaning that if the derived
classes of FrameBuffer didn't provide it, then the emulation
core would not pause. This is exactly what happened to me
in the Windows version, and I spent 10 minutes trying to figure
out why pause wasn't working :)
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@204 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
characters were stored in one texture, and pieces of that were carved
out when a particular character was needed. That approach left visual
artifacts in GL_LINEAR mode because of the way OpenGL divides up
textures (clamped to [0,1]).
The new approach is to use 256 8x8 textures, and draw them separately.
It actually makes the drawText() and drawChar() methods much shorter.
This may be slightly slower than before, but since large numbers of
characters are only ever drawn when needed (versus at the current
framerate), I don't think the speed difference will be noticed.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@203 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
It now partially compiles again, but many features are still
missing.
Added a FrameBufferWin32 class. This will eventually contain
DirectDraw windowed and fullscreen code, but for now it does
nothing.
Upgraded the project to Visual Studio .NET. It will no longer
compile with VC++ 6.
Now for the parts that will definitely change:
1) Right now, the MainWin32 class is also acting as the FrameBuffer.
The relevant code will be moved to FrameBufferWin32.
2) The DirectInput class will be completely rewritten to use
DirectInput8. Also, I'll be moving to event-based input where
the state is taken into account. The rewrite will also allow
multiple joysticks, and selecting which joystick input device
is mapped to which internal Atari joystick.
3) The SettingsWin32 class does nothing ATM. It will be expanded,
and will replace using the registry (the associated registry class
will be removed).
4) I haven't even looked at the sound yet. I want to get all
other stuff working before I even attempt it. It *did* make
some noise the last time I tried it, but something wasn't quite
right.
So, bottom line is that this compiles without sound, mouse,
joystick, windowed modes, and any of the 1.4 core enhancements.
But at least it compiles :) I expect the extras to be worked
out quite soon (except for sound), since I've already done
most of the same thing in Linux.
And to potential porters; its still not ready, and you should
probably be looking at the SDL port anyway ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@202 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
You can now select the video backend with '-video soft' or
'-video gl'.
Cleaned up the menu text lines that were longer than the
current display width. These lines are now truncated and
have a '...' appended to them. The menu modes are now more
tolerant of display sizes. So (for example), if some port
uses a 640 pixel wide framebuffer, the menu will now resize
and fully take advantage of all available space.
I've looked at the Windows code, but I still haven't mustered
the strength to work on it. It will basically be a complete
rewrite of sound, video, and input classes. And I'm not
looking forward to it ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@201 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
There is now an SDL OpenGL port with filtering and alpha-blending.
It's a work in progress right now, but is already quite stable.
It's not as optimized as the software version yet, but this will
change as well. For now, you have to compile the SDL version in
either normal software mode or OpenGL mode. This will change
before the 1.4 release.
When entering menu mode, the emulation is now suspended. And when
pause is pressed, you can't enter menu mode. Because of these changes,
CPU use has dropped dramatically when viewing menus. This will benefit
all ports, since menus are now redrawn only when necessary, instead of
at the current framerate.
For a reference, on a Pentium-IV 2.4GHz, the software SDL version
maxes CPU usage at 9%, and the SDL OpenGL version at 13.5%. This is
at 60 fps and a zoomlevel of 4. While some small improvements can
(possibly) be made to the OpenGL version, I think we'll soon be hitting
the glass ceiling.
Work on the Porting.txt document is progressing, and I estimate it to
be 45% complete.
The Windows version still doesn't compile, and I still haven't looked
at it. Rest assured that it will be done before 1.4. There will be
a simultaneous release, even if the Linux versions are finished.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@200 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
The major changes are a stabilization of the core code. There should
be much fewer major core changes from now on.
Updated the SDL port to the latest core changes. Next I'll start on the
Windows port.
There are still many optimizations left to do. Specifically, when using
the SDL port on a Pentium4 2.4GHz, normal mode results in 4% CPU usage,
while menu mode makes it jump to 46%. This must be improved.
The porters guide is a work-in-progress, and not yet available.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@199 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
heavily broken pending a rewrite of the Framebuffer class.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@198 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Added arrows for user feedback in the key remapping section of the
UserInterface class. Still have to indicate which key is being
remapped, though.
Added another menu to the main menu (of the GUI) called
'Character Set', showing the font being used. I found it useful
for determining what particular character to use when coding
the GUI, but I don't know if it will remain in the final release.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@197 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
8 joysticks with 20 buttons (and 2 axis) each. That should be more than
enough for now (famous last words).
Of course, this doesn't mean that whatever system you run Stella under
can have 8 joysticks with 20 buttons. It means that *IF* your system
does have a 20-button joystick, then Stella can handle it without
a recompile.
This was mainly included for those people that have gamepads with
hats, throttles, etc. There shouldn't be more than 20 of those
per gamepad, so each would be mapped to a button.
For now, the event handling core only knows about buttons and
left/right, up/down axis events (which can be considered a button
as well). It will be up to the frontends to map whatever your
gamepad has (hat, wheel, etc.) to something that Stella can
understand (a button).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@196 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
events can now be remapped from the GUI.
Added joystick support for remapping.
Updated EventHandler with defaults for every remappable event
in Stella.
Updated the manual with changes to the key mappings.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@195 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Updated the SDL port to bind to those keys.
Cleaned up the SDL port event handling method a bit. By the time I'm
finished, I hope that almost all event mapping/lookups will be constant
time by using simple array lookup.
Next thing to do is to add all possible remappings to the UserInterface,
get the joystick remapping working, and then get to the Windows port.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@194 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
stephena