mirror of https://github.com/bsnes-emu/bsnes.git
a15d15047c
Okay, I posted a new WIP. This one's source only again,
since the Windows port is still unchanged.
I went through and used std::min + std::max, rather than my own
#define, for the sole benefit of getting Nach's JMA code to compile
again (JMA includes a C++ standard header that doesn't like you
#defining min/max, apparently). I was kind of cheap with it though,
max(0, min(10, value)) -> max(0U, min(10U, value)), etc.
Geez, std::min/max can't even cast between uint16 and uint32. What a
joke, I'll have to write my own that takes advantage of type traits.
I also started killing off the "bheader.h" files. Since 90% of them
are just template classes, I figure I may as well stick them all in a
namespace and make something akin to boost / Loki. I'm calling this
one nall (I love making up all these names, lately). I also use gcc -I
to point to it, so you get #include <nall/array.hpp> instead of
#include "../../../lib/barray.h", much nicer.
Taking advantage of the new template library, I added any.hpp
(generic object container), traits.hpp (type traits) and static.hpp
(static assert, if), and with that, I made stdint.hpp, which is a C++
implementation of stdint.h. Since stdint.h is part of C99, it isn't
included with all compilers (eg Visual C++). By using sizeof() and
static_if, I was able to make my own compiler-independent version of
this file. Thus, the dependency on stdint.h was removed.
I'd be very interested in feedback on anything in nall/
(it's located in src/lib).
Specifically, could someone with a big-endian machine test any.hpp?
I'm worried that downcasting will reverse the order of data read back.
Example test app:
#include <stdio.h>
#include <nall/any.hpp>
int main() {
nall::any t = 0x01020304;
printf("0x%x\n",nall::any_cast<short>(t));
//should print 0x0304
return 0;
}
> Please byuu, can you extend the API, would you be so kind?
Of course, I want vai to be used for more than just SNES emulation.
Though I've yet to get anyone using any of my libraries before, so it
may be a fairly pointless endeavor.
It'll take me some time, though. I'm working on a lot
of other stuff first.
> Anyways, byuu, here's what I wrote of the OpenGL renderer so far, to
> prove its very much being worked on.
Really cool! My only concern is the use of Win32-specific code
(header, GetForegroundWindow(), HDC stuff, setting up the pixel format
stuff) ... no idea how this is going to compile on Linux :(
I don't know the Linux equivalents to all of the
Win32-specific stuff being done.
Nonetheless, please take your time. I'll check it out when you have
the Win version finished. Thanks a million for making this :D
> What about guys like me who just stick to Intel HDA.
Hah, I do the same. I'm not going to spend more on my
sound card than on my mainboard that comes _with_ onboard sound. HDA
sounds just fine to me :/
[No archive available]
|
||
|---|---|---|
| src | ||
| license.txt | ||
| readme.txt | ||
readme.txt
bsnes Version 0.027 Author: byuu -------- General: -------- bsnes is a Super Nintendo / Super Famicom emulator that began on October 14th, 2004. The latest version can be downloaded from: http://byuu.org/ Please see license.txt for important licensing information. -------------- Shortcut Keys: -------------- Esc - Toggle menubar visibility F11 - Toggle fullscreen mode ------------------ Known Limitations: ------------------ S-CPU - Invalid DMA / HDMA transfers not fully emulated - Multiply / Divide register delays not implemented S-PPU - Uses scanline-based renderer. This is very inaccurate, but few (if any) games rely on mid-scanline writes to function correctly - Does not support FirstSprite+Y priority - OAM / CGRAM accesses during active display not supported correctly - RTO flags are not calculated on frames that are skipped when frameskipping is enabled. This provides a major speedup, however it will cause in issues in games that test these flags, eg the SNES Test Program Electronics Test. Turning frameskipping off will allow RTO flag calculation on every frame Hardware Bugs - S-CPU.r1 HDMA crashing bug not emulated - S-CPU<>S-SMP communication bus conflicts not emulated --------------------- Unsupported Hardware: --------------------- SA-1 Coprocessor used in many popular games, including: - Dragon Ball Z Hyper Dimension - Kirby Super Star - Kirby's Dreamland 3 - Marvelous - SD Gundam G-NEXT - Super Mario RPG Super FX Coprocessor used in many popular games, including: - Doom - Star Fox - Star Fox 2 (unreleased beta) - Super Mario World 2: Yoshi's Island SPC7110 Coprocessor used only by the following games: - Far East of Eden Zero - Far East of Eden Zero: Shounen Jump no Shou - Momotarou Densetsu Happy - Super Power League 4 ST-011 SETA DSP used only by Quick-move Shogi Match with Nidan Rank-holder Morita ST-018 SETA RISC CPU used only by Quick-move Shogi Match with Nidan Rank-holder Morita 2 Super Gameboy Cartridge passthrough used for playing Gameboy games ------------------------ Unsupported Controllers: ------------------------ Mouse Super Scope Justifier Multitap (4-port and 5-port)