so I may have broken something.
Improved 'joystick is mouse' code in the GUI. Also account for devices
where the D-pad sends button events instead of the normal axis events.
Treat joystick events as other types of controllers based on the
virtual port entry in stella.pro. This means that mappings for a
joystick will emulate other devices when necessary, and should
help on 'small' devices with few inputs.
Added 'sp' developer commandline argument, which sets the
"Console.SwapPorts" property and swaps the arrangement of the
virtual ports. Useful for games like "Raiders of the Lost Ark",
where the joysticks are normally swapped. Updated stella.pro
for Raiders to use this property.
Moved ugly #ifdef code for screen dimensions out of FrameBuffer and
directly into the respective OSystemXXX classes.
Added 'freq', 'tiafreq' and 'clipvol' commandline arguments, which
affect the sound subsystem. Note that none of these add new
functionality; they merely expose what were previously constants
in the code:
- freq: sets sound sample output frequency
- tiafreq: sets sound sample generation frequency
- clipvol: clips volume to eliminate huge cracks when pausing sound
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@940 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
can also be set in the Settings class):
-freq : sets the sound sample output frequency, defaults to 31400
-tiafreq : sets the sound sample generation frequency, defaults to 31400
-clipvol : boolean which toggles volume clipping, defaults to true
Some fixes to the 'joystick button is an axis' code, so that it actually
works in GUI mode.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@938 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
by the system-specific OSystemXXX class. This is accomplished by overriding
certain methods in OSystem, and removes the need for numerous #ifdef's in
EventHandler. In simpler terms, pressing 'Defaults' in the EventMapper
now uses defaults which are custom-defined to the specific port.
Added ability for joystick buttons to emulate axis events (and therefore
act as mouse events) for the internal GUI. Some devices such as PSP and
GP2X don't have a directional pad, and send directions as button events
instead of axis events. By overriding a method in OSystem, one can now
specify which buttons (if any) to treat as directional.
Added ability to remap the 'increase/decrease volume' events.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@936 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
for those dialogs that don't emulate the mouse (currently the Launcher
and Command dialogs). Moving a joystick axis in such dialogs now repeats
the event until the axis is released (similar to key repeat). Also,
the number of events is based on how long the axis is held. So the
longer the axis is pressed, the faster events will be generated.
The LauncherDialog now handles its own joystick axis events, which
are described as follows:
- Axis up/down (on any stick) move up and down through the game list.
- Axis left/right moves between the 4 buttons on the bottom (play,
options, reload, quit).
- The buttons are now highlighted to indicate that they're focusable.
So the cursor keys can also be used to move between them.
Still TODO is deal with analog joystick axis events. The analog nature
of these types of joysticks should really be ignored by the GUI.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@935 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
be much more robust.
Updated VC.net project with latest files.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@934 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
currently buggy, in that it doesn't seem to play back what was actually
recorded :) But it seems that each time I play back the state file, the
same things happen, so at least I know it's deterministic that way. I just
need to figure out which is being done incorrectly, the save or the load.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@932 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
with all related event recording/loading stuff, since it really didn't
belong in either the EventHandler or Event classes. Loading a previously
saved eventstream now loads the ROM state as well. All that's left to
do (for basic functionality) is for the EventHandler to poll the
EventStreamer for events, and then pass them directly to the Event class.
Still TODO is decide on a GUI for all this, and what it means to 'interrupt'
an eventstream (should we just stop the load, delay processing of it,
lock out all user input until the stream is finished, etc).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@931 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
the first event seen is now used. So that means once 'Map' is pressed
in the EventMapper, you can no longer move the cursor using the joystick
axis; that axis event will be remapped to whatever action your remapping.
Disabled double-clicking in EventMapper activating remap mode, since it
causes problems when using joystick buttons as mouse clicks.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@925 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
(where it really belongs). So the GUI is fully navigable using the joystick.
Joystick axes emulate mouse movement, and joystick buttons emulate a left
mouse click.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@924 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
will now either exit gracefully (when launching a ROM from the commandline),
or continue running (when in ROM launcher mode) when attempting to use an
undefined cartridge type.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@923 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
TabWidget. The fix is not as clean as I'd like, since it basically
checks for a certain case only (a hack). The TabWidget really does
cause a lot of problems, but for now I just work around it.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@921 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
erase that axis from the analog assignment (if it was also assigned to
an analog event).
Started work on intelligent focusing in the InputTextDialog, but it
requires some more work on the focusing the Dialog class (which is really
sort of a mess).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@919 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
in GUI menu mode. The code was too troublesome to fix, and navigating
a GUI with a joystick simulating a mouse is a broken concept anyway.
In place of joy-is-mouse navigation, added the ability to use the cursor
keys or joysticks axes to 'tab' between different focused objects in
GUI mode. This is much more intuitive, and is how navigation works in
a mouse-less, game console based system. Also, any joystick button (or
enter/space keys) activate the currently focused item.
For now, only the CommandDialog can be accessed this way. It really
only makes sense here anyway, since many GUI objects in the other menus
really need access to a keyboard and mouse, and if you have those, one
can already navigate the menu.
Overall, this should make arcade cabinet style access much easier. One
can map the CommandDialog to a joystick button, navigate with the joystick
axes, and select an item with any joystick button. So Stella can be
started, play a game, and then exit, all by just using the joystick. It
also solves quite a few usability problems for the WinCE and PSP ports.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@918 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
are stripped, since they have special meaning in the cheat file.
Added support for one-shot cheats. Basically these work exactly the same
way as normal cheats, but they are only evaluated once, and are never
saved.
Cleaned up the IFDEF mess for FrameBuffer and Sound objects in OSystem class
by creating a MediaFactory class that deals with it. This might seem like
just moving the problem elsewhere, but it does help remove the clutter in
OSystem, and make compiling slightly faster whenever the FrameBuffer classes
are changed. No porter should ever have to touch the emulation core classes.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@915 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
we can also remove RTTI support. This may result in a slightly smaller
binary.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@912 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
After this, hopefully state (and eventstream) files will be portable
between different platforms, even those differing in endian-ness and
bit length. Ints are now stored and retrieved in little endian format
and are 4 bytes long. So state files should still work on 32-bit x86 Linux,
but old state files will no longer be valid for 64-bit or non-x86 systems.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@911 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
emulating paddles with the keyboard or joystick. These slider widgets go
from 0 to 100 percent, and represent minimum (0) to maximum (100) speed.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@910 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
TODO is add a scale factor (for each paddle) to the GUI, so one can
adjust the speed/amount of movement.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@909 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Pressing 'Ctrl e' now starts/stops event recording (key is temporary and
will probably change). An state file is then generated containing the
state when recording started, and the eventstream up to the point when
recording stopped.
Next I'll work on loading the event state file and replaying the events.
This one is a little harder, since it has to override EventHandler::poll()
and use events from the eventstream. Hopefully rudimentary support will
be there by the end of the weekend.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@906 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
many places other than the GUI code.
As a diversion from the joystick stuff, I'm experimenting with event
recording. Eventually, this will allow one to record a state + events,
and then load that INP file again. When loaded, Stella will replay the
events, and you'll be able to see exactly what happened before. Since
this is based on frames, the replaying can speed up and slow
down by changing the emulation framerate. And it can be exited at any
point, and normal emulation can continue. Or at least that's how I
want it to work.
A preliminary spec for the event stream is -X A B A B ... -X ...,
where X represents how many frames to wait, and 'A B' are event/value
pairs representing an event in Stella. I think this is very similar
to the scheme that Thomas J. recently added to z26, so converting to
a Stella eventstream should be easy.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@905 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
simulated paddles for now. I got it working, but I'm not sure how
useful it will be. Maybe it's better to just add joystick emulation
for paddle events, and not care whether the axis are digital or analog
(it would certainly be easier code-wise), using something like JoyMouse??
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@904 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
an axis is analog or digital (but this may prove to be insufficient).
This will be useful for the paddle emulation code. If a paddle event
is detected *and* the axis is analog, then the eventhandler will generate
true analog values, which are more accurate than digital. Otherwise,
paddle events associated with a digital axis will have the analog values
emulated by use of a JoyMouse-type structure.
Eventually, this code can be extended to deal with other analog-type events
(lightgun, etc) or other analog axis (trackballs).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@903 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
complete, since I can play a two player game of River Raid with one
gamepad (P1 using D-pad and button 0, P2 using analog stick and
button 1). Still TODO is add support for remapping paddles, but
this will be quite easy. After that, maybe the ability to use
keys for paddle movement. This one is a bit harder, so I may leave
it for a future release.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@902 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
infrastructure is now ready, but I can't test that yet since I don't
have a joystick at work :)
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@901 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
in the emulator, including paddle events. Analog and digital sticks will
be supported. Currently, axis handling is completely broken.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@900 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
cheats. There's still some error checking to do, to make sure that
cheats don't contain characters that are reserved for the cheat file
(comma, colon, quote, etc).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@897 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
works correctly, and inserts the cheats for whatever ROM happens to be
loaded.
The CheatCodeDialog now communicates with CheatManager, meaning that
cheats can be seen in the dialog, and enabled/disabled with their
respective checkboxes. Still TODO is add support for adding/removing/
deleting cheats, and for one-shot cheats.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@896 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
'stella.cht' file, where each line/record consists of a ROM md5sum
and a comma-separated list of cheats. Each cheat is specified as a
colon-separated string, defined as "NAME:CODE:ENABLE".
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@895 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
where each cheat can be toggled on or off. Of course, it doesn't
actually do anything yet, since it isn't connected to the
CheatManager. For now, input of cheats from the GUI is completely
disabled. Commandline should still work, though.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@894 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
instead of being possibly 'massaged' by EventHandler::handleEvent().
This should result in slightly faster operation, and also allow
more accurate emulation of the Stelladaptor joysticks (ie, pressing down
hard on a joystick and activating all four directions will do exactly
what a real 2600 would do).
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@892 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
stephena