before a certain state was entered. For example, launching a game
and bypassing the ROM launcher would attempt to draw elements from
the debugger, with coordinates that were usually larger than the
current screen.
Made system-wide location of stella.pro/stellarc files configurable
at build-time. They're now stored in DATADIR/stella, where DATADIR
can be changed with "--datadir=..." during configure. This is only
enabled for UNIX for now.
Added missing 'cheat' and 'break' to commandline description.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@964 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
the problem with the GP2X port.
Removed SDL_FillRect() calls in OpenGL GUI drawing, since the extra
function calls are only slowing things down when we can access the
pixels directly.
Made return/enter key activate the currently selected button in the
ROM launcher instead of always starting a ROM. This was confusing
when the 'Quit' button was highlighted and pressing enter started a
ROM. Now pressing enter in such a case will actually do 'quit'.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@963 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
the OSX port, and if it goes fine then dynamic OpenGL support will be done.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@960 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
longer be linked to the binary, but is opened at runtime. This makes
automatic builds easier, so the nightly builds for Linux and Win32
should now support OpenGL.
Added 'gl_lib' commandline argument to change the OpenGL library to
use, but the defaults should work fine.
Everything works great in Linux; still TODO is test in Windows and OSX.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@957 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
still TODO for 24 bit mode.
I've benchmarked the CPU usage in Linux under 16/32 bit modes, and they're
within 1% of those for z26. Not bad for C++ vs. assembly code :) I still
need to test in Windows, which (ironically enough) tends to be slower than
Linux in graphics performance.
Note that CPU usage ranges from 6% (Linux/1x/software/phosphor/16bit) to
85% (Linux/3x/software/phosphor/32bit). Using OpenGL, the usage is always
12%, whatever the zoom/color depth/phosphor. I just love OpenGL ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@955 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
completely broken right now. I *really* hate software buffers. Why
can't everyone have hardware support for zoom and color depth (aka OpenGL)?
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@954 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
Cleaned up stella.pro wrt to 'Keypad' vs. 'Keyboard'. The manual says
Keyboard, so that's what we use.
Added 'Display.Phosphor' property for many ROMs which require it (thanks
to the z26 database). This means it will be automatically used for those
ROMs.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@950 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
commandline. Two new CL arguments have been added (but these might change):
1) -pp <yes|no>: sets the new 'Display.Phoshor' property
2) -ppblend <0-100>: sets the amount to blend in phosphor mode
Note that if 'pp' isn't set, then it won't matter what 'ppblend' is set to,
since phosphor won't be used at all. Some performance tweaks are still
required, and software mode isn't yet supported.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@949 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
ROMs to eliminate flicker. Right now is disabled by default, and when
enabled only works in OpenGL mode. It's not yet configurable either,
so it's either on or off. It looks like crap on ROMs that don't need it,
but is really nice for those that do.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@947 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
emulation mode, but it's somewhat sensitive in GUI navigation (could
be my cheap gamepad).
Remapping is mostly complete, except for assignment of hats to analog
events. Some more thought is required for this one.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@946 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
joystick detection type speeds up the Windows port again. It seems it's
the strangest things that slow down the code ...
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@944 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
don't care what type they are (this is good, since the detection code
was crap anyway). Events are now designated as being digital or analog.
If an event is analog and the stick also happens to be analog, then it
will get analog values; otherwise it won't. Hopefully this will speed
up analog processing in Win32 (which I swear is the bane of my existence,
since every time I boot into Windows I feel my blood pressure rising :( )
Fixed typo which caused the joymap to be saved incorrectly.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@943 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
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
stephena