2010-08-09 13:28:56 +00:00
|
|
|
/* Global Headers */
|
|
|
|
|
|
Update to v094r08 release.
byuu says:
Lots of changes this time around. FreeBSD stability and compilation is
still a work in progress.
FreeBSD 10 + Clang 3.3 = 108fps
FreeBSD 10 + GCC 4.7 = 130fps
Errata 1: I've been fighting that god-damned endian.h header for the
past nine WIPs now. The above WIP isn't building now because FreeBSD
isn't including headers before using certain types, and you end up with
a trillion error messages. So just delete all the endian.h includes from
nall/intrinsics.hpp to build.
Errata 2: I was trying to match g++ and g++47, so I used $(findstring
g++,$(compiler)), which ends up also matching clang++. Oops. Easy fix,
put Clang first and then else if g++ next. Not ideal, but oh well. All
it's doing for now is declaring -fwrapv twice, so you don't have to fix
it just yet. Probably just going to alias g++="g++47" and do exact
matching instead.
Errata 3: both OpenGL::term and VideoGLX::term are causing a core dump
on BSD. No idea why. The resources are initialized and valid, but
releasing them crashes the application.
Changelog:
- nall/Makefile is more flexible with overriding $(compiler), so you can
build with GCC or Clang on BSD (defaults to GCC now)
- PLATFORM_X was renamed to PLATFORM_XORG, and it's also declared with
PLATFORM_LINUX or PLATFORM_BSD
- PLATFORM_XORG probably isn't the best name ... still thinking about
what best to call LINUX|BSD|SOLARIS or ^(WINDOWS|MACOSX)
- fixed a few legitimate Clang warning messages in nall
- Compiler::VisualCPP is ugly as hell, renamed to Compiler::CL
- nall/platform includes nall/intrinsics first. Trying to move away from
testing for _WIN32, etc directly in all files. Work in progress.
- nall turns off Clang warnings that I won't "fix", because they aren't
broken. It's much less noisy to compile with warnings on now.
- phoenix gains the ability to set background and foreground colors on
various text container widgets (GTK only for now.)
- rewrote a lot of the MSU1 code to try and simplify it. Really hope
I didn't break anything ... I don't have any MSU1 test ROMs handy
- SNES coprocessor audio is now mixed as sclamp<16>(system_sample
+ coprocessor_sample) instead of sclamp<16>((sys + cop) / 2)
- allows for greater chance of aliasing (still low, SNES audio is
quiet), but doesn't cut base system volume in half anymore
- fixed Super Scope and Justifier cursor colors
- use input.xlib instead of input.x ... allows Xlib input driver to be
visible on Linux and BSD once again
- make install and make uninstall must be run as root again; no longer
using install but cp instead for BSD compatibility
- killed $(DESTDIR) ... use make prefix=$DESTDIR$prefix instead
- you can now set text/background colors for the loki console via (eg):
- settings.terminal.background-color 0x000000
- settings.terminal.foreground-color 0xffffff
2014-02-24 09:39:09 +00:00
|
|
|
#if defined(PLATFORM_XORG)
|
2010-08-09 13:28:56 +00:00
|
|
|
#include <X11/Xlib.h>
|
|
|
|
|
#include <X11/Xutil.h>
|
|
|
|
|
#include <X11/Xatom.h>
|
2013-11-28 10:29:01 +00:00
|
|
|
#elif defined(PLATFORM_MACOSX)
|
2013-04-14 08:52:47 +00:00
|
|
|
#define decimal CocoaDecimal
|
2013-03-19 08:48:50 +00:00
|
|
|
#include <Cocoa/Cocoa.h>
|
2010-08-09 13:28:56 +00:00
|
|
|
#include <Carbon/Carbon.h>
|
2013-04-14 08:52:47 +00:00
|
|
|
#undef decimal
|
2011-09-29 12:08:22 +00:00
|
|
|
#elif defined(PLATFORM_WINDOWS)
|
2010-08-09 13:28:56 +00:00
|
|
|
#include <windows.h>
|
|
|
|
|
#endif
|
|
|
|
|
|
2011-02-28 23:45:31 +00:00
|
|
|
using namespace nall;
|
|
|
|
|
|
2010-08-09 13:28:56 +00:00
|
|
|
/* Video */
|
|
|
|
|
|
|
|
|
|
#define DeclareVideo(Name) \
|
Update to v093r12 release.
byuu says:
I've completely redone the ethos InputManager and ruby to work on
HID::Device objects instead of one giant scancode pool.
Currently only the udev driver supports the changes to ruby, so only
Linux users will be able to compile and run this WIP build.
The nice thing about the new system is that it's now possible to
uniquely identify controllers, so if you swap out gamepads, you won't
end up with it working but with all the mappings all screwed up. Since
higan lets you map multiple physical inputs to one emulated input, you
can now configure your keyboard and multiple gamepads to the same
emulated input, and then just use whatever controller you want.
Because USB gamepad makers failed to provide unique serial#s with each
controller, we have to limit the mapping to specific USB ports.
Otherwise, we couldn't distinguish two otherwise identical gamepads. So
basically your computer USB ports act like real game console input port
numbers. Which is kind of neat, I guess.
And the really nice thing about the new system is that we now have the
capability to support hotplugging input devices. I haven't yet added
this to any drivers, but I'm definitely going to add it to udev for v094
official.
Finally, with the device ID (vendor ID + product ID) exposed, we gain
one last really cool feature that we may be able to develop more in the
future. Say we created a joypad.bml file to include with higan. In it,
we'd store the Xbox 360 controller, and pre-defined button mappings for
each emulated system. So if higan detects you have an Xbox 360
controller, you can just plug it in and use it. Even better, we can
clearly specify the difference between triggers and analog axes, and
name each individual input. So you'd see "Xbox 360 Gamepad #1: Left
Trigger" instead of higan v093's "JP0::Axis2.Hi"
Note: for right now, ethos' input manager isn't filtering the device IDs
to look pretty. So you're going to see a 64-bit hex value for a device
ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
|
|
|
struct Video##Name : Video { \
|
2010-08-09 13:28:56 +00:00
|
|
|
bool cap(const string& name) { return p.cap(name); } \
|
|
|
|
|
any get(const string& name) { return p.get(name); } \
|
|
|
|
|
bool set(const string& name, const any& value) { return p.set(name, value); } \
|
|
|
|
|
\
|
2013-05-02 11:25:45 +00:00
|
|
|
bool lock(uint32_t*& data, unsigned& pitch, unsigned width, unsigned height) { return p.lock(data, pitch, width, height); } \
|
2010-08-09 13:28:56 +00:00
|
|
|
void unlock() { p.unlock(); } \
|
|
|
|
|
\
|
|
|
|
|
void clear() { p.clear(); } \
|
|
|
|
|
void refresh() { p.refresh(); } \
|
|
|
|
|
bool init() { return p.init(); } \
|
|
|
|
|
void term() { p.term(); } \
|
|
|
|
|
\
|
|
|
|
|
Video##Name() : p(*new pVideo##Name) {} \
|
|
|
|
|
~Video##Name() { delete &p; } \
|
|
|
|
|
\
|
|
|
|
|
private: \
|
2013-05-02 11:25:45 +00:00
|
|
|
pVideo##Name& p; \
|
2010-08-09 13:28:56 +00:00
|
|
|
};
|
|
|
|
|
|
2013-03-19 08:48:50 +00:00
|
|
|
#ifdef VIDEO_CGL
|
|
|
|
|
#include <ruby/video/cgl.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
2010-08-09 13:28:56 +00:00
|
|
|
#ifdef VIDEO_DIRECT3D
|
|
|
|
|
#include <ruby/video/direct3d.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef VIDEO_DIRECTDRAW
|
|
|
|
|
#include <ruby/video/directdraw.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef VIDEO_GDI
|
|
|
|
|
#include <ruby/video/gdi.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef VIDEO_GLX
|
|
|
|
|
#include <ruby/video/glx.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef VIDEO_SDL
|
|
|
|
|
#include <ruby/video/sdl.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef VIDEO_WGL
|
|
|
|
|
#include <ruby/video/wgl.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
Update to v084r03 release.
(r02 was not posted to the WIP thread)
byuu says:
Internally, all color is processed with 30-bit precision. The filters
also operate at 30-bit depth.
There's a new config file setting, video.depth, which defaults to 24.
This causes the final output to downsample to 24-bit, as most will
require.
If you set it to 30-bit, the downsampling will not occur, and bsnes will
ask ruby for a 30-bit surface. If you don't have one available, you're
going to get bad colors. Or maybe even a crash with OpenGL.
I don't yet have detection code to make sure you have an appropriate
visual in place.
30-bit mode will really only work if you are running Linux, running Xorg
at Depth 30, use the OpenGL or XShm driver, have an nVidia Quadro or AMD
FireGL card with the official drivers, and have a 30-bit capable
monitor.
Lots of planning and work for very little gain here, but it's nice that
it's finally finished.
Oh, I had to change the contrast/brightness formulas a tiny bit, but
they still work and look nice.
2011-12-03 03:22:54 +00:00
|
|
|
#ifdef VIDEO_XSHM
|
|
|
|
|
#include <ruby/video/xshm.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
2010-08-09 13:28:56 +00:00
|
|
|
#ifdef VIDEO_XV
|
|
|
|
|
#include <ruby/video/xv.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* Audio */
|
|
|
|
|
|
|
|
|
|
#define DeclareAudio(Name) \
|
Update to v093r12 release.
byuu says:
I've completely redone the ethos InputManager and ruby to work on
HID::Device objects instead of one giant scancode pool.
Currently only the udev driver supports the changes to ruby, so only
Linux users will be able to compile and run this WIP build.
The nice thing about the new system is that it's now possible to
uniquely identify controllers, so if you swap out gamepads, you won't
end up with it working but with all the mappings all screwed up. Since
higan lets you map multiple physical inputs to one emulated input, you
can now configure your keyboard and multiple gamepads to the same
emulated input, and then just use whatever controller you want.
Because USB gamepad makers failed to provide unique serial#s with each
controller, we have to limit the mapping to specific USB ports.
Otherwise, we couldn't distinguish two otherwise identical gamepads. So
basically your computer USB ports act like real game console input port
numbers. Which is kind of neat, I guess.
And the really nice thing about the new system is that we now have the
capability to support hotplugging input devices. I haven't yet added
this to any drivers, but I'm definitely going to add it to udev for v094
official.
Finally, with the device ID (vendor ID + product ID) exposed, we gain
one last really cool feature that we may be able to develop more in the
future. Say we created a joypad.bml file to include with higan. In it,
we'd store the Xbox 360 controller, and pre-defined button mappings for
each emulated system. So if higan detects you have an Xbox 360
controller, you can just plug it in and use it. Even better, we can
clearly specify the difference between triggers and analog axes, and
name each individual input. So you'd see "Xbox 360 Gamepad #1: Left
Trigger" instead of higan v093's "JP0::Axis2.Hi"
Note: for right now, ethos' input manager isn't filtering the device IDs
to look pretty. So you're going to see a 64-bit hex value for a device
ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
|
|
|
struct Audio##Name : Audio { \
|
2010-08-09 13:28:56 +00:00
|
|
|
bool cap(const string& name) { return p.cap(name); } \
|
|
|
|
|
any get(const string& name) { return p.get(name); } \
|
|
|
|
|
bool set(const string& name, const any& value) { return p.set(name, value); } \
|
|
|
|
|
\
|
|
|
|
|
void sample(uint16_t left, uint16_t right) { p.sample(left, right); } \
|
|
|
|
|
void clear() { p.clear(); } \
|
|
|
|
|
bool init() { return p.init(); } \
|
|
|
|
|
void term() { p.term(); } \
|
|
|
|
|
\
|
|
|
|
|
Audio##Name() : p(*new pAudio##Name) {} \
|
|
|
|
|
~Audio##Name() { delete &p; } \
|
|
|
|
|
\
|
|
|
|
|
private: \
|
2013-05-02 11:25:45 +00:00
|
|
|
pAudio##Name& p; \
|
2010-08-09 13:28:56 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#ifdef AUDIO_ALSA
|
|
|
|
|
#include <ruby/audio/alsa.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef AUDIO_AO
|
|
|
|
|
#include <ruby/audio/ao.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef AUDIO_DIRECTSOUND
|
|
|
|
|
#include <ruby/audio/directsound.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef AUDIO_OPENAL
|
|
|
|
|
#include <ruby/audio/openal.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef AUDIO_OSS
|
|
|
|
|
#include <ruby/audio/oss.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef AUDIO_PULSEAUDIO
|
|
|
|
|
#include <ruby/audio/pulseaudio.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef AUDIO_PULSEAUDIOSIMPLE
|
|
|
|
|
#include <ruby/audio/pulseaudiosimple.cpp>
|
|
|
|
|
#endif
|
2010-08-16 04:10:50 +00:00
|
|
|
|
|
|
|
|
#ifdef AUDIO_XAUDIO2
|
|
|
|
|
#include <ruby/audio/xaudio2.cpp>
|
|
|
|
|
#endif
|
2010-08-09 13:28:56 +00:00
|
|
|
|
|
|
|
|
/* Input */
|
|
|
|
|
|
|
|
|
|
#define DeclareInput(Name) \
|
Update to v093r12 release.
byuu says:
I've completely redone the ethos InputManager and ruby to work on
HID::Device objects instead of one giant scancode pool.
Currently only the udev driver supports the changes to ruby, so only
Linux users will be able to compile and run this WIP build.
The nice thing about the new system is that it's now possible to
uniquely identify controllers, so if you swap out gamepads, you won't
end up with it working but with all the mappings all screwed up. Since
higan lets you map multiple physical inputs to one emulated input, you
can now configure your keyboard and multiple gamepads to the same
emulated input, and then just use whatever controller you want.
Because USB gamepad makers failed to provide unique serial#s with each
controller, we have to limit the mapping to specific USB ports.
Otherwise, we couldn't distinguish two otherwise identical gamepads. So
basically your computer USB ports act like real game console input port
numbers. Which is kind of neat, I guess.
And the really nice thing about the new system is that we now have the
capability to support hotplugging input devices. I haven't yet added
this to any drivers, but I'm definitely going to add it to udev for v094
official.
Finally, with the device ID (vendor ID + product ID) exposed, we gain
one last really cool feature that we may be able to develop more in the
future. Say we created a joypad.bml file to include with higan. In it,
we'd store the Xbox 360 controller, and pre-defined button mappings for
each emulated system. So if higan detects you have an Xbox 360
controller, you can just plug it in and use it. Even better, we can
clearly specify the difference between triggers and analog axes, and
name each individual input. So you'd see "Xbox 360 Gamepad #1: Left
Trigger" instead of higan v093's "JP0::Axis2.Hi"
Note: for right now, ethos' input manager isn't filtering the device IDs
to look pretty. So you're going to see a 64-bit hex value for a device
ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
|
|
|
struct Input##Name : Input { \
|
2010-08-09 13:28:56 +00:00
|
|
|
bool cap(const string& name) { return p.cap(name); } \
|
|
|
|
|
any get(const string& name) { return p.get(name); } \
|
|
|
|
|
bool set(const string& name, const any& value) { return p.set(name, value); } \
|
|
|
|
|
\
|
|
|
|
|
bool acquire() { return p.acquire(); } \
|
|
|
|
|
bool unacquire() { return p.unacquire(); } \
|
|
|
|
|
bool acquired() { return p.acquired(); } \
|
|
|
|
|
\
|
Update to v093r12 release.
byuu says:
I've completely redone the ethos InputManager and ruby to work on
HID::Device objects instead of one giant scancode pool.
Currently only the udev driver supports the changes to ruby, so only
Linux users will be able to compile and run this WIP build.
The nice thing about the new system is that it's now possible to
uniquely identify controllers, so if you swap out gamepads, you won't
end up with it working but with all the mappings all screwed up. Since
higan lets you map multiple physical inputs to one emulated input, you
can now configure your keyboard and multiple gamepads to the same
emulated input, and then just use whatever controller you want.
Because USB gamepad makers failed to provide unique serial#s with each
controller, we have to limit the mapping to specific USB ports.
Otherwise, we couldn't distinguish two otherwise identical gamepads. So
basically your computer USB ports act like real game console input port
numbers. Which is kind of neat, I guess.
And the really nice thing about the new system is that we now have the
capability to support hotplugging input devices. I haven't yet added
this to any drivers, but I'm definitely going to add it to udev for v094
official.
Finally, with the device ID (vendor ID + product ID) exposed, we gain
one last really cool feature that we may be able to develop more in the
future. Say we created a joypad.bml file to include with higan. In it,
we'd store the Xbox 360 controller, and pre-defined button mappings for
each emulated system. So if higan detects you have an Xbox 360
controller, you can just plug it in and use it. Even better, we can
clearly specify the difference between triggers and analog axes, and
name each individual input. So you'd see "Xbox 360 Gamepad #1: Left
Trigger" instead of higan v093's "JP0::Axis2.Hi"
Note: for right now, ethos' input manager isn't filtering the device IDs
to look pretty. So you're going to see a 64-bit hex value for a device
ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
|
|
|
vector<HID::Device*> poll() { return p.poll(); } \
|
2014-01-05 09:59:17 +00:00
|
|
|
bool rumble(uint64_t id, bool enable) { return p.rumble(id, enable); } \
|
2010-08-09 13:28:56 +00:00
|
|
|
bool init() { return p.init(); } \
|
|
|
|
|
void term() { p.term(); } \
|
|
|
|
|
\
|
|
|
|
|
Input##Name() : p(*new pInput##Name) {} \
|
|
|
|
|
~Input##Name() { delete &p; } \
|
|
|
|
|
\
|
|
|
|
|
private: \
|
2013-05-02 11:25:45 +00:00
|
|
|
pInput##Name& p; \
|
2010-08-09 13:28:56 +00:00
|
|
|
};
|
|
|
|
|
|
2013-12-21 10:45:58 +00:00
|
|
|
#ifdef INPUT_CARBON
|
|
|
|
|
#include <ruby/input/carbon.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
2010-08-09 13:28:56 +00:00
|
|
|
#ifdef INPUT_SDL
|
|
|
|
|
#include <ruby/input/sdl.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
2013-12-21 10:45:58 +00:00
|
|
|
#ifdef INPUT_UDEV
|
|
|
|
|
#include <ruby/input/udev.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
2014-01-05 09:59:17 +00:00
|
|
|
#ifdef INPUT_WINDOWS
|
|
|
|
|
#include <ruby/input/windows.cpp>
|
|
|
|
|
#endif
|
|
|
|
|
|
Update to v093r12 release.
byuu says:
I've completely redone the ethos InputManager and ruby to work on
HID::Device objects instead of one giant scancode pool.
Currently only the udev driver supports the changes to ruby, so only
Linux users will be able to compile and run this WIP build.
The nice thing about the new system is that it's now possible to
uniquely identify controllers, so if you swap out gamepads, you won't
end up with it working but with all the mappings all screwed up. Since
higan lets you map multiple physical inputs to one emulated input, you
can now configure your keyboard and multiple gamepads to the same
emulated input, and then just use whatever controller you want.
Because USB gamepad makers failed to provide unique serial#s with each
controller, we have to limit the mapping to specific USB ports.
Otherwise, we couldn't distinguish two otherwise identical gamepads. So
basically your computer USB ports act like real game console input port
numbers. Which is kind of neat, I guess.
And the really nice thing about the new system is that we now have the
capability to support hotplugging input devices. I haven't yet added
this to any drivers, but I'm definitely going to add it to udev for v094
official.
Finally, with the device ID (vendor ID + product ID) exposed, we gain
one last really cool feature that we may be able to develop more in the
future. Say we created a joypad.bml file to include with higan. In it,
we'd store the Xbox 360 controller, and pre-defined button mappings for
each emulated system. So if higan detects you have an Xbox 360
controller, you can just plug it in and use it. Even better, we can
clearly specify the difference between triggers and analog axes, and
name each individual input. So you'd see "Xbox 360 Gamepad #1: Left
Trigger" instead of higan v093's "JP0::Axis2.Hi"
Note: for right now, ethos' input manager isn't filtering the device IDs
to look pretty. So you're going to see a 64-bit hex value for a device
ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
|
|
|
#ifdef INPUT_XLIB
|
|
|
|
|
#include <ruby/input/xlib.cpp>
|
2010-08-09 13:28:56 +00:00
|
|
|
#endif
|