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
Now for the things that aren't finished yet:
- Only the most basic functions can be remapped. If you
erase the mapping for those that can't yet be remapped,
you'll have to delete the 'keymap' line from stellarc and
start over.
- Core events can only be remapped to other keys on the keyboard.
I haven't got the joystick remapping working yet (but it should
be easy to do).
- The TIA needs to be modified to show 320 pixels horizontally.
Right now, I'm using 8 pixel-width fonts on a framebuffer of
160 pixels, so there's not a lot of horizontal real estate.
So text will probably overwrite other stuff. This is cosmetic,
and WILL be fixed.
- Modification of the TIA will break every frontends rendering
code. It had to be done sometime ...
- I haven't yet added any user feedback mechanism for the user. So when
you go into remap mode and are about to remap a key, you won't
know it :) I'll be adding arrows (like in XMAME) ...
I've added a "Game Information" menu, which shows things like Game name,
manufacturer, rarity, type, etc. Basically stuff from the stella.pro file.
It has no purpose other than for coolness :)
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@193 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
didn't compile. This one does.
Removed reference to TIA::showMessage, and added
UserInterface::showMessage, since it was always meant to be a
GUI element. Having it in the TIA class was a temporary hack.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@192 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
is basically there. All I need to do now is create methods that
actually draws text, boxes, cursors, etc.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@190 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
changes that are being made to key remapping. I think that
the key remapping will work, but we won't know for sure
until the GUI is done and we can actually test it :)
The eventhandler depends on getting *KEYPRESS* events.
Specifically, a key press is not the same thing as a pressed
key :) For example, the Windows and DOS ports scan the
keyboard and send the state 60 times per second. So if a key
was pressed and held for 1 second, the Windows and DOS ports
will send 60 keypresses, when it should send only one.
Having a key pressed for 60 seconds IS NOT equivalent
to 60 keypresses.
This will have to be fixed in the frontend, most likely
by having 2 keyboard state arrays and only sending the
changes per update.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@189 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
specified in the program will be saved to the rcfile. Previously,
*any* text in the rcfile was saved on exit, even bogus settings.
Also, any settings given from the commandline which are not meant
to be ever saved in the rcfile are now actually not saved.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@187 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
properties of the <key, value> type.
This is a much cleaner approach, and it eliminates the problems of
object slicing experienced before (passing SettingsUNIX through a
Settings pointer, and then needing the stuff specific to SettingsUNIX,
requiring a cast).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@186 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
someone had to look at the code and do something with it.
As of now, joysticks and mouse aren't working. Settings aren't saved.
And sound support is patchy. Definitely a work-in-progress.
It looks like I'll be the maintainer for this as well, at least until
we can find someone who is willing to take over full time.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@185 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
They both referred to each other, so it made more sense to only have
one file.
Porters will now only need to define their own SettingsXXX, derived from
Settings.hxx, for platform specific stuff.
Updated the X11 and SDL ports wrt to the previously mentioned stuff.
The next task will be to update the DOS port, which should be
incredibly easy (assuming I can get a stable DOS dev environment) ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@183 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
EventHandler class. All thats left to do there is integrate the
Snapshot code into the core, but that will have to wait until I
rewrite the PNG handler to not need the PNG library ...
Changed the Settings class to a virtual abstract class, and created
a SettingsUNIX class to derive from it and work with the X11 and SDL
versions.
Some notes on updating the DOS and Windows ports (which I will probably
do eventually), and on porting to other toolkits:
A port needs the following:
- a main function which takes native events and converts to the core
format, and generally acts as the dispatcher (mainXXX.cxx)
- a specific frontend, derived from Frontend.hxx, which sets up port
specific filename and locations (FrontendXXX.hxx)
- a specific settings class, derived from Settings.hxx, which deals
with settings/commandline arguments specific to that port (SettingsXXX.hxx)
- probably some other stuff that I've forgotten
The next step is get the DOS port working with the new EventHandler (easy)
and attempt to bring the Windows port into the year 2003 (it hasn't been
touched for almost a year, quite hard).
I also have to write a GUI class that will draw menus, etc. and actually let
you remap keys from the emulator itself. And that may have to wait until
the fabled graphics rewrite that Brad and I will be working on. It never ends ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@181 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
1) It exists in the core, but only the SDL port is updated to use
it. And the other ports don't even compile yet ...
2) The mappings for keyboard and joystick are saved in the rcfile, but
for reasons of efficiency and ease of programming, the format is somewhat
cryptic. But the plan is to never have to edit the maps directly anyway.
3) There is no GUI in Stella to set the remapping. This is the next
major thing to do, after I get the other ports to at least compile.
4) I haven't documented the format of the maps in the rcfile. Its not
difficult to modify, just tedious. If anyone is reading this and really
wants to know (or even cares), email me directly for instructions.
Enjoy :)
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@178 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
now uses the EventHandler class and doesn't directly handle events itself.
All thats left for key remapping is to create load/save methods for the
event arrays. Of course, to actually change events from within the
emulator will require a GUI, which I haven't even started yet :) The GUI
will have to wait until the graphics rewrite, where we go to a full
320x200 framebuffer (versus the 160x200 one we have now).
In the meantime, remapping will be configurable from the rcfile only.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@177 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
lose the ability for Shift-F10 to cycle downwards through the
available states.
One other thing; the current CVS source won't compile for X11 or DOS,
and not everything works in SDL. This can't be helped, as I'm fixing
the frontends one at a time.
Windows hasn't been able to compile for quite some time, and unless
someone looks at it soon, its going to get a serious case of bit-rot ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@175 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
easier to manage, and to enable key-remapping.
After these changes are complete, the EventHandler and Settings
classes will be merged into the core and no longer optional.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@174 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
SDL version has been changed (not fully), and it doesn't actually do
any remapping yet :)
The new class 'EventHandler' will receive all events and will dispatch
them to the core. The frontends will no longer deal with events
directly, but will convert them from native format (SDL, X, DOS, etc.)
to core events. The actual remapping will be taken care of in the core,
and each frontend will never know about it.
For those frontends that don't wish to take advantage of core remapping,
they can still use the 'Event' class directly.
Eventually, this will be extended to the joystick code as well, but I
don't think it would be wise to remap the mouse.
One thing that has changed is that it will no longer be possible for
one key event to activate more than one core event. It doesn't make
sense to do it, and I'm not sure the original code actually worked
anyway. One core event can be mapped to more that one key event,
however (Joystick fire 0 could be activated by Joy button 0, Space,
Left Ctrl, etc).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@173 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
default behaviour of the volume settings. Now, if no volume settings
have been specified, this means that changing the volume is disabled,
and the volume won't be changed on program start or exit. Specifying '-1'
for the volume will have the same effect.
This is the new default behaviour. If you want a different volume, you
now have to specify it.
Updated the documentation concerning using '-volume -1'.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@172 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
* Variables and functions accessed during interrupt service routines
are properly locked to ensure they are in physical memory.
* The emulation can be synchronized with the VSYNC of the video
card instead of using the system timer. The is the default
behavior when running under Windows NT/2000/XP since the DJGPP
system timer functions do not operate correctly under these
operating systems.
* New routines have been added to setup the graphics modes. The
new modes should run at 60Hz instead of the standard 70Hz for
the 320x200 mode.
* The stella profile is search for in the current working directory
as well as the $STELLA_HOME directory.
* When loading a ROM it is looked for in the current working directory,
$STELLA_HOME/ROMS, and finally $STELLA_HOME.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@166 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
stephena