corrects the problems with spurious axis events in the GUI. Now,
we only generate an emulated axis event when necessary, just as
if it was implemented in the SDL core.
If this code ends up being too slow, then optimization will have to
be made elsewhere. Everything that this code does is necessary,
and it can't be shortened any further.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@998 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
actually works. This time we try axis events, similar to the code
from gp2xmess project.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@997 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
stella.pro in the current directory instead of the system dir.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@994 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
gamepad, implementing 'case 2' configuration. This hasn't been tested
yet, since I don't have the hardware.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@992 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
This is needed particularly for the GP2X joystick direction handling,
where directions are (incorrectly) implemented as button events
instead of more intuitive HAT events. When this is complete, it will
also remove the EventHandler 'kJDirXXX' enums, which I always thought
was dirty code anyway.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@991 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
where the extra code was causing a slowdown at startup. Also removed
some dead JS code.
Disable phosphor effect by default for GP2X, since the FrameBuffer isn't
optimized enough yet to handle it.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@981 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
to test this, so I'm sure that it's probably slow and doesn't render
correctly. For anyone using this mode; switch to 16-bit software mode,
use OpenGL, or get a better video card :)
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@976 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
at some point, since this type of work bores me to tears :(
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@975 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
supported input type is joystick axes. It doesn't really make sense to
assign analog events to hats/buttons/keys, since they're not analog in
nature.
Reworked the MediaFactory/FrameBuffer classes so that we always get a
valid FrameBuffer object. So no more crashes because of NULL
FrameBuffer pointers.
git-svn-id: svn://svn.code.sf.net/p/stella/code/trunk@971 8b62c5a3-ac7e-4cc8-8f21-d9a121418aba
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
stephena