Previously you had to use /dev/sdx or /dev/sdx1 for the device in /etc/fstab,
but the order in which these are assigned is non-deterministic on modern
kernels. Now, if you want a specific card, you can use /dev/disk/by-uuid,
or if you want a specific port, you can use /dev/disk/by-path.
types and let the user try to use whatever they might have. Even if it can't be
mapped properly to something that will work it's still worth trying and
shouldn't cause any major problems (other than just not being able to play with
some weird devices, like lightguns for example).
that should fix a lot more pads that were being reported as not being detected.
Also added some debug log messages that output each device's type and name
so in the future if other devices fail to be detected we can easily see what it
is in the info log.
A movie larger than the max texture size would be rendered - at its original
size - onto a smaller texture, causing an access violation. This just ignores
the max texture size for movies.
Two better solutions:
1. Resize the movie to the texture size. Ideal, but slow in my experiments.
2. Don't load the movie texture at all in this case. A possibility in the
future, but will require some refactoring first.
5f7001e: "Added a new branch"
01456ed: "Fixed a lot of memory leaks"
dac4493: "Fixed all remaining memory leaks that I could figure out"
0792db7: "Removed the smnew macro and the call to _CrtSetDbgFlag()"
Some of these caused destructor-time problems due to static initialization
order fiasco and related issues. Notably, the program would no longer exit on
OSX and had to be killed.
There were probably legitimate fixes in here, but since these are monolithic
commits it's too much work to extract them now. Let's reapply them
individually and in the forward direction.
the debug output for the Debug and FastDebug project configurations. This
requires replacing all instances of new with a macro, smnew, that defines a
special form of new which outputs file and line number information along with
the memory leak details. This makes finding memory leaks much easier since you
can just double-click the leak in the output window and it will take you to the
line that caused it.
Original message is as follows:
[Xcode4.4] wrong code: NSBitsPerPixelFromDepth seems to like to return 0.
instead, use a reimplementation of CGGetDisplayBitsPerPixel
Basically includes hi def image stuff and headers.
Note: Mac OS X build is broken. LowLevelWindow_MacOSX.mm refers to the removed RageDisplay_Legacy_Helpers files. The replacement is not immediately obvious.
Ben "root" Anderson