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
so that sound works better under Windows NT/2000/XP systems.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@165 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
bankswitching as suggested by Adam Wozniak. This allows most of
the demos/homebrew games being created using this method to work
without a stella.pro file entry.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@164 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
game state is stored in a 'state' sub-directory of the current working
directory or in a 'state' sub-directory of the directory specified by
the 'STELLA_HOME' environment variable if it is set.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@163 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
2002 regarding the difficulty switches being reversed. It looks like
this bug was introduced in the 1.0 release of Stella (only took 4 years
to find and fix it :-)
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@162 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
which are 10,495 or 10,240 bytes in length are considered to be DPC
based games. This should allow hacks of Pitfall II to work.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@161 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Looks like this works better for games when the stella.pro file is missing.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@160 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
the issue with the robots in Berzerk always appearing in the same pattern
when the game starts.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@159 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
console is created. If properties are not found for the ROM then the
MD5 value will be set to the MD5 value of the ROM. This allows the
"-showinfo" command line option to display the MD5 checksum of unknown
games...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@158 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
call to resize the window needed to be after the call which tells the
window manager the maximum size of the window.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@157 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
shown, and cannot be turned off.
Barring any errors encountered in memory allocation (etc.), using
-showinfo 0 will not output ANYTHING to the console.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@153 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
all of the Pitfall II music is played now that the TIA sound routines can
handle it.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@146 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
compiling (or running) Stella with no sound support whatsoever.
Added ability to compile multiple sound backends into the X11 and SDL
versions, and to dynamically select from among them at run-time. For
now, the X11 version can't use the SDL sound core. This is in
preparation for the ALSA sound backend, which may or may not make it
into Stella 1.3.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@144 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
a little more room for error. Also added a call to SDL_Delay in the
blocking section of the updateSound method so that it doesn't hog the CPU.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@143 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
switched to a new set of low-level Sound Blaster routines which appear
to provide better Sound Blaster support and the ability to auto-detect
sound card settings.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@142 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
stephena