citra-emu / citra Goto Github PK

I've recently made myself more familiar with the boost libraries and figured being able to use them would be helpful in a number of places. In particular, these three boost libraries seem beneficial for Citra:

• Ranges (http://www.boost.org/doc/libs/1_56_0/libs/range/doc/html/index.html) in place of <algorithm>: Allows accessing standard library containers via ranges rather than iterators. This has a number of conceptional advantages, and most importantly it allows for more compact code: a simple find operation would be boost::find(some_vector, some_element) rather than std::find(some_vector.begin(), some_vector.end(), some_element). Additionally it provides fancy features like range zipping (cf. http://pastie.org/private/xne0jrgive77aothj8cw)
• Format (http://www.boost.org/doc/libs/1_56_0/libs/format/index.html) in place of Dolphin's StringFromFormat: Provides a type safe replacement for conveniently generating std::string objects with a printf-like syntax
• Filesystem (http://www.boost.org/doc/libs/1_56_0/libs/filesystem/doc/reference.html): Provides generic file access functions (file_size, exists, etc) as well as path string handling. This would allow us to throw away a lot of Dolphin code from our code base.

A full list is shown at http://www.boost.org/doc/libs/1_56_0/ . You can tell I'm being conservative about the number of libraries I'm proposing to use :) Luckily, a lot functionality of the boost libraries has been standardized in C++11, otherwise the list would probably have been bigger.

The general idea behind this is a) to give Citra developers more powerful tools to work with b) to throw out code forked from Dolphin (which requires us to synchronize with updates etc). However, there also is a number of disadvantages to using boost:

• Bad documentation: Well, it varies. Basic functionality can usually be grasped quickly, however more advanced things or very special corner features may be hard to understand without writing a small test application.
• Long compile times: This one is indeed annoying, and there's not much we can do about it.
• Horrible compile error messages: some libraries don't have this issue at all, while the more template-heavy ones will spam pages full of error messages.

For now, I'd say let's just give it a shot - each of the above shortcomings needs to be seen in a case-by-case basis. If some library turns out to suffer from one of them heavily, we can just decide not to use that one without dropping boost usage altogether.

If this change gets accepted, we should

• include the relevant Boost headers in externals.
• add an explicit list of allowed dependencies to the coding style guide.
• as a first phase, migrate over relevant common/ interfaces to boost.
• as a second phase, replace common/ usage with direct boost usage.

Error on build SLN

3dbrew: OpenFile flags

Debugging screenshot: http://i.imgur.com/ixDXTIc.png
Note in the log that mode=2, and in the debugger note create_flag's BitField.

I'm beginning to think that our implementation decision to separate "archives" (e.g. RomFS, SDMC, etc.) from "files" is incorrect. As evidence of this, the archive interface (https://github.com/citra-emu/citra/blob/master/src/core/hle/kernel/archive.cpp#L43) to applications is just a copy-paste of the file interface (https://github.com/citra-emu/citra/blob/master/src/core/hle/kernel/archive.cpp#L129). Furthermore, we need to basically hack the OpenFileFromArchive call to return an archive handle in place of a file handle as needed (e.g. https://github.com/bunnei/citra/blob/fs-fix-paths/src/core/hle/kernel/archive.cpp#L374). Lastly, with our backend design, both archives and files have essentially the same interface, and the differences between each are largely ambiguous (e.g. https://github.com/bunnei/citra/blob/master/src/core/file_sys/file_romfs.cpp has no purpose because the same interface is defined in https://github.com/bunnei/citra/blob/master/src/core/file_sys/archive_romfs.cpp).

On the actual system, I would guess that "archives" are indeed some abstract thing, however in software they are probably just accessed from a normal file handle. While this needs to be tested, I still propose to change the implementation to reflect this (based on my reasons cited above), getting rid of all the file_sys/archive_* implementations (as well as the Kernel::Archive object) and move it to their respective file_sys/file_* files.

...Which brings us to the next question: Do we create these files at boot, and then keep them persistent? Or do we implement some "pseudo" file handle that points to the archives that can be deleted/duplicated/recreated? (probably the latter... but again, needs hardware verification)

@yuriks @linkmauve Please comment.

svcOutputDebugString is used for exactly what its name says - print a debug string. AFAIK it's implemented via a NOP on retail consoles, but it would be useful for debugging homebrew since it's the only efficient way to get debug information from within the emulated application. Additionally, maybe there are leftover calls to this function in commercial games which are useful to see.

Currently, this function is implemented in Citra, but for some reason the parameters it takes do not match the ones mentioned on 3dbrew (which specifies an additional integer to be passed as an argument).

Tentative "patch" for src/core/hle/svc.cpp here:

void OutputDebugString(const char* string, int i) {
    NOTICE_LOG(SVC, "(%x): \"%s\"", i, string);
}

This should be fixed for the sake of completeness.

To reproduce: double-click on any data in the disassembly view.

When running Citra using my Intel HD Graphics 4600, every loaded program will just display a black screen on top, and white screen at the bottom, even programs that are just supposed to show a pixel, they however work fine in every other aspect, they just don't show anything. This behavior doesn't happen when running Citra with my NVIDIA GTX 860m graphics card, and applications show graphics when using it.

I tested it with hwtests and several other homebrews of mine (https://github.com/Subv/3ds-homebrew) they all exhibit this behavior.

I ran glIntercept using both the HD 4600 and the GTX 860m in full debug mode, apparently the images are being correctly placed in the textures (the Images folder contains the images, and they appear to be fine), however they are never shown to the user in the frontend.

This happens with both the GFWL and Qt frontens.

Here are the glIntercept results of each card:

HD 4600: https://gist.github.com/Subv/24e737464a2507cc1783
GTX 860m: https://gist.github.com/Subv/bfdc9c7ae39d28f8dc0a

I noticed however that smealum's hbmenu somewhat works when using the HD 4600, the would-be bottom screen (the homebrew list) is displayed in the top screen of the Qt frontend, and the bottom screen remains white.

Image of hbmenu on HD 4600 http://i.imgur.com/QO3OJWD.png
Image of hbmenu on GTX 860m: http://i.imgur.com/1knEZHJ.png

Operating System: Windows 8.1 x64
Graphics Card:

• Intel HD Graphics 4600 integrated into cpu Intel Core i7 4710MQ using Intel driver v10.18.10.3960
• Nvidia GTX 860m using driver GeForce Game Ready Driver v344.75

Fixing this would require to rework the log facilities, since they currently work like printf and will cut on null byte.

It's pretty hard to explain, look on the left

When running Citra on i686, I consistently get a stack corruption on every homebrew I’ve tested. This issue doesn’t happen on amd64. Here is the backtrace:

Program received signal SIGSEGV, Segmentation fault.
0xf7fd7da0 in ?? ()
(gdb) bt
#0  0xf7fd7da0 in ?? ()
Backtrace stopped: Cannot access memory at address 0xc504

It should be possible to render emulation output in a full screen window. This should probably be designed careful to allow for the following things:

• exclusive full screen mode (proven to yield a superior user experience in certain ways in recent Dolphin developments, cf. https://dolphin-emu.org/blog/2014/06/30/dolphin-progress-report-june-2014/ .. in particular this may make things appear more "smoothly")
• non-exclusive full screen mode
• overlay of Qt widgets for ingame configuration (not being able to configure the emulator in fullscreen mode is a major usability issue, so we should at least have the option of blending in the configuration dialog)
• possibly other stuff I forgot.

A crypto library will be needed for AES support, I propose PolarSSL because it is modular and somewhat lightweight, we could only import the Cipher-AES module.

Requesting suggestions. Please keep in mind that the AES library needs to support 128-bit keys, along with CBC mode and CTR mode. Other key sizes and modes might be needed in the future but for now these are the requirements.

I had some trouble building Citra. I've tried to fix it, it now compiles, but I'm not able to get any homebrew running. (Segfaults, nothing drawn in emulation window, etc)

Here's what I have installed:
System: Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3
libqt4-dev: 4.8.6
glfw: 3.0.4
xorg-dev: 7.7
libglu1-mesa-dev: 8.0.5
gcc: 4.7.2
cmake: 2.8.11.1

Here's the build error log:

In file included 
    from /home/daniel/tmp/citra-master/src/./video_core/command_processor.h:10:0,
    from /home/daniel/tmp/citra-master/src/./video_core/gpu_debugger.h:15,
    from /home/daniel/tmp/citra-master/src/core/hle/service/gsp.cpp:15:
/home/daniel/tmp/citra-master/src/./video_core/pica.h: 
In member function 'const std::array<Pica::Regs::TevStageConfig, 6ul> Pica::Regs::GetTevStages() const':
/home/daniel/tmp/citra-master/src/./video_core/pica.h:227:41: 
error: could not convert 
    '{((const Pica::Regs*)this)->Pica::Regs::tev_stage0, 
    ((const Pica::Regs*)this)->Pica::Regs::tev_stage1, 
    ((const Pica::Regs*)this)->Pica::Regs::tev_stage2, 
    ((const Pica::Regs*)this)->Pica::Regs::tev_stage3, 
    ((const Pica::Regs*)this)->Pica::Regs::tev_stage4, 
    ((const Pica::Regs*)this)->Pica::Regs::tev_stage5}' 
from '<brace-enclosed initializer list>' to 'const std::array<Pica::Regs::TevStageConfig, 6ul>'
make[2]: *** [src/core/CMakeFiles/core.dir/hle/service/gsp.cpp.o] Error 1
make[1]: *** [src/core/CMakeFiles/core.dir/all] Error 2
make: *** [all] Error 2

Fixed by curly brackets added to expression at pica.h:224

    const std::array<Regs::TevStageConfig,6> GetTevStages() const {{
        return { tev_stage0, tev_stage1,
                 tev_stage2, tev_stage3,
                 tev_stage4, tev_stage5 }};
    };

But more headaches:

/home/daniel/tmp/citra-master/src/video_core/debug_utils/debug_utils.cpp: In member function 'void Pica::DebugUtils::GeometryDumper::AddTriangle(Pica::DebugUtils::GeometryDumper::Vertex&, Pica::DebugUtils::GeometryDumper::Vertex&, Pica::DebugUtils::GeometryDumper::Vertex&)':
/home/daniel/tmp/citra-master/src/video_core/debug_utils/debug_utils.cpp:31:71: error: no matching function for call to 'std::vector<Pica::DebugUtils::GeometryDumper::Face>::push_back(<brace-enclosed initializer list>)'
/home/daniel/tmp/citra-master/src/video_core/debug_utils/debug_utils.cpp:31:71: note: candidates are:
In file included from /usr/include/c++/4.7/vector:65:0,
                 from /usr/include/c++/4.7/bits/random.h:34,
                 from /usr/include/c++/4.7/random:50,
                 from /usr/include/c++/4.7/bits/stl_algo.h:67,
                 from /usr/include/c++/4.7/algorithm:63,
                 from /home/daniel/tmp/citra-master/src/video_core/debug_utils/debug_utils.cpp:5:
/usr/include/c++/4.7/bits/stl_vector.h:881:7: note: void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = Pica::DebugUtils::GeometryDumper::Face; _Alloc = std::allocator<Pica::DebugUtils::GeometryDumper::Face>; std::vector<_Tp, _Alloc>::value_type = Pica::DebugUtils::GeometryDumper::Face]
/usr/include/c++/4.7/bits/stl_vector.h:881:7: note:   no known conversion for argument 1 from '<brace-enclosed initializer list>' to 'const value_type& {aka const Pica::DebugUtils::GeometryDumper::Face&}'
/usr/include/c++/4.7/bits/stl_vector.h:899:7: note: void std::vector<_Tp, _Alloc>::push_back(std::vector<_Tp, _Alloc>::value_type&&) [with _Tp = Pica::DebugUtils::GeometryDumper::Face; _Alloc = std::allocator<Pica::DebugUtils::GeometryDumper::Face>; std::vector<_Tp, _Alloc>::value_type = Pica::DebugUtils::GeometryDumper::Face]
/usr/include/c++/4.7/bits/stl_vector.h:899:7: note:   no known conversion for argument 1 from '<brace-enclosed initializer list>' to 'std::vector<Pica::DebugUtils::GeometryDumper::Face>::value_type&& {aka Pica::DebugUtils::GeometryDumper::Face&&}'
make[2]: *** [src/video_core/CMakeFiles/video_core.dir/debug_utils/debug_utils.cpp.o] Error 1
make[1]: *** [src/video_core/CMakeFiles/video_core.dir/all] Error 2
make: *** [all] Error 2

Fixed by curly brackets added to function at debug_utils.cpp:15

void GeometryDumper::AddTriangle(Vertex& v0, Vertex& v1, Vertex& v2) {
    vertices.push_back(v0);
    vertices.push_back(v1);
    vertices.push_back(v2);

    int num_vertices = vertices.size();
    faces.push_back({{ num_vertices-3, num_vertices-2, num_vertices-1 }});
}

Hi,

I tried to compile citra in mac. However, cmake complains that the two variables, GLEW_INCLUDE_PATH and GLEW_LIBRARY, are not set. Where should I point them to?

Thanks,
Daniel

Really, sticking with GPLv2 is just going to cause us more trouble than it's worth. Fwiw, most of the Dolphin contributors that have copyright over code in Dolphin's "Common" library have agreed to relicensing their code to GPLv2+, so I don't think we have any dependencies which are truly GPLv2-only anymore.

Obviously should ask the people who contributed to citra so far about their opinion on this and their green light on relicensing the existing Citra code.

Revision: master b4d766f
OS: Windows 8.1 x64
Compiler: VS 2013 Pro

When I enable the dyncom interpreter in the configuration settings, Citra either crashes in unrelated places when I start emulation (built as x64) or otherwise (built as x86) executes a bit of code seemingly correctly and then starts spamming writes to random places in emulated memory. I can't debug the arm code because the Qt debugger doesn't work when dyncom is enabled.

The behavior/crashes changed depending on the optimization settings, so this is probably a memory corruption issue.

To reproduce: double-click on any piece of data in the call stack.

I'm guessing this is probably because of citra using the CPU too much.

Citra needs an eager developer to champion the effort to improve our use of assertions. Currently, we use assert (the standard library one), _assert_dbg_ (defined in our logger, this breaks our style guide and also doesn't really do anything), and ERROR_LOG (just logs an error and can easily be ignored/missed) somewhat interchangeably, without any consistency. ERROR_LOG should only be used for errors that are like "this is an error, but it's OK and won't generally break the emulator" (e.g. for something not implemented that's not a big deal). Assertions should be used for things like "this should NEVER happen and if it does, emulation should abort". This is not currently the case. With this task, you should:

• Identify the best way to do assertions, and get buy-in from the team (e.g. should we use exceptions? should we crash the emulator in debug mode? should we prompt the user and stop emulation in release mode? etc.)
• Implement the new assertion system, gut out _assert_dbg_
• Clean up inconsistencies/update our code to do the right thing (this will generally involve replacing a lot of ERROR_LOG calls with assertions). If something is correctly changed to an assertion but breaks the emulator, we should figure out why/fix it.

This makes it difficult to use, as you would need to keep scrolling down as more output appears. It'd be ideal if the newest output appeared at the top instead.

Call stack:

#0  0x000000010000f84a in DisassemblerWidget::OnPause() at /Users/gandrade-air/Documents/Dev/citra/src/citra_qt/debugger/disassembler.cpp:223
#1  0x000000010000431c in DisassemblerWidget::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) at /Users/gandrade-air/Documents/Dev/citra/build/src/citra_qt/moc_disassembler.cpp:189
#2  0x00000001090f0b6f in QMetaObject::activate(QObject*, int, int, void**) ()
#3  0x00000001085eb0a0 in QAbstractButton::clicked(bool) ()
#4  0x00000001083799ef in QAbstractButtonPrivate::emitClicked() ()
#5  0x0000000108379857 in QAbstractButtonPrivate::click() ()
#6  0x000000010837a870 in QAbstractButton::mouseReleaseEvent(QMouseEvent*) ()
#7  0x00000001082e01fe in QWidget::event(QEvent*) ()
#8  0x000000010837a5d3 in QAbstractButton::event(QEvent*) ()
#9  0x000000010840b678 in QPushButton::event(QEvent*) ()
#10 0x00000001082a7ffc in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
#11 0x00000001082ab447 in QApplication::notify(QObject*, QEvent*) ()
#12 0x00000001090bc932 in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
#13 0x00000001082a88e8 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) ()
#14 0x00000001082fe56c in QWidgetWindow::handleMouseEvent(QMouseEvent*) ()
#15 0x00000001082fd84f in QWidgetWindow::event(QEvent*) ()
#16 0x00000001082a7ffc in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
#17 0x00000001082aaabb in QApplication::notify(QObject*, QEvent*) ()
#18 0x00000001090bc932 in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
#19 0x000000010897b5fc in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) ()
#20 0x000000010897a565 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) ()
#21 0x00000001089691cb in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
#22 0x000000010b5a8f0d in QCocoaEventDispatcherPrivate::processPostedEvents() ()
#23 0x000000010b5a98a8 in QCocoaEventDispatcherPrivate::postedEventsSourceCallback(void*) ()
#24 0x00007fff94078661 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ ()
#25 0x00007fff9406a7ed in __CFRunLoopDoSources0 ()
#26 0x00007fff94069e1f in __CFRunLoopRun ()
#27 0x00007fff94069838 in CFRunLoopRunSpecific ()
#28 0x00007fff9298443f in RunCurrentEventLoopInMode ()
#29 0x00007fff929840be in ReceiveNextEventCommon ()
#30 0x00007fff92983ffb in _BlockUntilNextEventMatchingListInModeWithFilter ()
#31 0x00007fff8d2dc821 in _DPSNextEvent ()
#32 0x00007fff8d2dbfd0 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#33 0x00007fff8d2cff73 in -[NSApplication run] ()
#34 0x000000010b5a85e4 in QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
#35 0x00000001090b99ad in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
#36 0x00000001090bcee7 in QCoreApplication::exec() ()
#37 0x000000010003dba8 in main at /Users/gandrade-air/Documents/Dev/citra/src/citra_qt/main.cpp:254
#38 0x00007fff98c505c9 in start ()

The input on the Qt front-end only works when using the pop-out window mode. With the emulation window integrated into the debugger, there's no way to focus on the widget or send input to it.

Note that this also applies to the Write function as well.

Consider:

template <typename T>
inline void Read(T &var, const VAddr vaddr) {
    // TODO: Figure out the fastest order of tests for both read and write (they are probably different).
    // TODO: Make sure this represents the mirrors in a correct way.
    // Could just do a base-relative read, too.... TODO

    // Kernel memory command buffer
    if (vaddr >= KERNEL_MEMORY_VADDR && vaddr < KERNEL_MEMORY_VADDR_END) {
        var = *((const T*)&g_kernel_mem[vaddr & KERNEL_MEMORY_MASK]);

    // Hardware I/O register reads
    // 0x10XXXXXX- is physical address space, 0x1EXXXXXX is virtual address space
    } else if ((vaddr >= HARDWARE_IO_VADDR) && (vaddr < HARDWARE_IO_VADDR_END)) {
        HW::Read<T>(var, vaddr);

    // ExeFS:/.code is loaded here
    } else if ((vaddr >= EXEFS_CODE_VADDR)  && (vaddr < EXEFS_CODE_VADDR_END)) {
        var = *((const T*)&g_exefs_code[vaddr & EXEFS_CODE_MASK]);

    // FCRAM - GSP heap
    } else if ((vaddr >= HEAP_GSP_VADDR) && (vaddr < HEAP_GSP_VADDR_END)) {
        var = *((const T*)&g_heap_gsp[vaddr & HEAP_GSP_MASK]);

    // FCRAM - application heap
    } else if ((vaddr >= HEAP_VADDR)  && (vaddr < HEAP_VADDR_END)) {
        var = *((const T*)&g_heap[vaddr & HEAP_MASK]);

    // Shared memory
    } else if ((vaddr >= SHARED_MEMORY_VADDR)  && (vaddr < SHARED_MEMORY_VADDR_END)) {
        var = *((const T*)&g_shared_mem[vaddr & SHARED_MEMORY_MASK]);

    // System memory
    } else if ((vaddr >= SYSTEM_MEMORY_VADDR)  && (vaddr < SYSTEM_MEMORY_VADDR_END)) {
        var = *((const T*)&g_system_mem[vaddr & SYSTEM_MEMORY_MASK]);

    // Config memory
    } else if ((vaddr >= CONFIG_MEMORY_VADDR)  && (vaddr < CONFIG_MEMORY_VADDR_END)) {
        ConfigMem::Read<T>(var, vaddr);

    // VRAM
    } else if ((vaddr >= VRAM_VADDR)  && (vaddr < VRAM_VADDR_END)) {
        var = *((const T*)&g_vram[vaddr & VRAM_MASK]);

    } else {
        ERROR_LOG(MEMMAP, "unknown Read%lu @ 0x%08X", sizeof(var) * 8, vaddr);
    }
}

the equivalent with the enum constants added in:

template <typename T>
inline void Read(T &var, const VAddr vaddr) {
    // TODO: Figure out the fastest order of tests for both read and write (they are probably different).
    // TODO: Make sure this represents the mirrors in a correct way.
    // Could just do a base-relative read, too.... TODO

    // Kernel memory command buffer
    if (vaddr >= 0xFFFF0000 && vaddr < 0xFFFF1000) {
        var = *((const T*)&g_kernel_mem[vaddr & KERNEL_MEMORY_MASK]);

    // Hardware I/O register reads
    // 0x10XXXXXX- is physical address space, 0x1EXXXXXX is virtual address space
    } else if ((vaddr >= 0x1EC00000) && (vaddr < 0x1FC00000)) {
        HW::Read<T>(var, vaddr);

    // ExeFS:/.code is loaded here
    } else if ((vaddr >= 0x00100000)  && (vaddr < 0x4000000)) {
        var = *((const T*)&g_exefs_code[vaddr & EXEFS_CODE_MASK]);

    // FCRAM - GSP heap
    } else if ((vaddr >= 0x14000000) && (vaddr < 0x16000000)) {
        var = *((const T*)&g_heap_gsp[vaddr & HEAP_GSP_MASK]);

    // FCRAM - application heap
    } else if ((vaddr >= 0x08000000)  && (vaddr < 0x10000000)) {
        var = *((const T*)&g_heap[vaddr & HEAP_MASK]);

    // Shared memory
    } else if ((vaddr >= 0x10000000)  && (vaddr < 0x14000000)) {
        var = *((const T*)&g_shared_mem[vaddr & SHARED_MEMORY_MASK]);

    // System memory
    } else if ((vaddr >= 0x04000000)  && (vaddr < 0x06C00000)) {
        var = *((const T*)&g_system_mem[vaddr & SYSTEM_MEMORY_MASK]);

    // Config memory
    } else if ((vaddr >= 0x1FF80000)  && (vaddr < 0x1FF81000)) {
        ConfigMem::Read<T>(var, vaddr);

    // VRAM
    } else if ((vaddr >= 0x1F000000)  && (vaddr < 0x1F600000)) {
        var = *((const T*)&g_vram[vaddr & VRAM_MASK]);

    } else {
        ERROR_LOG(MEMMAP, "unknown Read%lu @ 0x%08X", sizeof(var) * 8, vaddr);
    }
}

And now the condensed one with the problem lines

template <typename T>
inline void Read(T &var, const VAddr vaddr) {
...
    // Hardware I/O register reads
    // 0x10XXXXXX- is physical address space, 0x1EXXXXXX is virtual address space
    } else if ((vaddr >= 0x1EC00000) && (vaddr < 0x1FC00000)) {
        HW::Read<T>(var, vaddr);

    // VRAM
    } else if ((vaddr >= 0x1F000000)  && (vaddr < 0x1F600000)) {
        var = *((const T*)&g_vram[vaddr & VRAM_MASK]);
...
}

it's possible for intended VRAM read/writes to accidentally be considered Hardware I/O read/writes.

Some usecases would be top-bottom dual-screen setups, middle gap emulation…

The emulator will fail to read a file from the SD card if the cases do not match. This probably only applies on case-sensitive OSes.

That is, all the output on that terminal will have the same font color as the last line of citra's log output unless some program (like ls --color) change it back.

• start citra-qt
• load an application
• make sure single-window mode is disabled
• press any key (e.g. tab)
• watch citra-qt crash.

Apparently this is because the HID service accesses some nullptr. Should be fairly easy to fix.

The Common code (taken from Dolphin) contains several modules for implementing commonly-used utility objects across multiple platforms. Due to Citra using newer compilers [than Dolphin did when this code was originally written], some of these modules are now deprecated. These modules should be removed and replaced with their standard C++ alternatives. The ones I know of right now:

• https://github.com/citra-emu/citra/blob/master/src/common/std_condition_variable.h can be replaced with std::condition_variable
• https://github.com/citra-emu/citra/blob/master/src/common/std_mutex.h can be replaced with std::mutex
• https://github.com/citra-emu/citra/blob/master/src/common/std_thread.h can be replaced with std::thread
  Please comment if there are more.

This is mostly for my personal convenience, but it's also allows for 3DS applications to be started via drag'n drop onto a citra executable.

Example: ./citra-qt path/to/3ds/application.elf => auto-runs application.elf

Visual studio throws out an ambiguous symbol error (c2593) here:

https://github.com/citra-emu/citra/blob/master/src/video_core/vertex_shader.cpp#L163
https://github.com/citra-emu/citra/blob/master/src/video_core/vertex_shader.cpp#L164
https://github.com/citra-emu/citra/blob/master/src/video_core/vertex_shader.cpp#L388
https://github.com/citra-emu/citra/blob/master/src/video_core/vertex_shader.cpp#L389

Currently This is used by all homebrew software that runs on the 3ds. So this should be should be done at a higher priority right now in order to remove some of the errors we currently get from running homebrew software on citra.

A common argument for showing this information in a central place like the title bar is that when people submit bad bug reports we would at least still be able to see the version number from a screenshot they provide (if they provide one). While I personally find that argument ridiculous, there probably is a small point to it for nightly releases, however stable releases should be sufficiently different to each other that such a version number is not crucial for anything.

The reason for this change is that it just "feels wrong" to print the version number/git hash (which, might I add, is just a random string of gibberish to the average user anyway) in the title bar. Another argument is that virtually all other applications get along just fine without having to uglify their title bar like this (some of which definitely have a less advanced average user base than us).

Finally, both Microsoft's and Apple's human interface guidelines suggest against printing version information in title bars:

• http://msdn.microsoft.com/en-us/library/windows/desktop/bb246387%28v=vs.85%29.aspx implicitly by not including the version number in the window title to use for application main windows.
• https://developer.apple.com/library/mac/documentation/userexperience/conceptual/applehiguidelines/Menus/Menus.html very explicitly by saying "Don’t include the app version number in the name. Version information belongs in the About window."

Note that we currently have no way of marking "stable releases" in the source code, so this is mostly a TODO for the future.

19:14 <@neobrain> arm_dyncom_interpreter.cpp:(.text+0xc293): undefined reference to `VMOVR'
19:14 <@neobrain> arm_dyncom_interpreter.cpp:(.text+0xc2fa): undefined reference to `VMOVI'
19:14 <@neobrain> arm_dyncom_interpreter.cpp:(.text+0xc71c): undefined reference to `VMOVBRRD'
19:14 <@neobrain> arm_dyncom_interpreter.cpp:(.text+0xc90b): undefined reference to `VMSR'
19:14 <@neobrain> arm_dyncom_interpreter.cpp:(.text+0xf3ec): undefined reference to `VMOVBRS'

CC @bunnei .

Fwiw, removing the "inline" keyword from the function declarations in vfp.h fixes the build, but I don't know if that's in any way a proper fix or not.

A monospace font (such as Source Code Pro) would provide for better alignment and better readability with the debugger tools.

Depends on #108, but citra should provide an option to rebind keys, so the user doesn't have to dig through SDL's code to find out what key maps to which number.

How it should work:

hostname:~ user$ citra --help
...
-l  --bind-list List the current keybindings
-r  --rebind    Rebind key-to-button mappings:
                A, B, X, Y, LB, RB, Select, Start, 
                Up, Down, Left, Right, 
                Stick-Up, Stick-Down, Stick-Left, Stick-Right
hostname:~ user$ citra --rebind=A
Press the key you would like to rebind to...
hostname:~ user$ citra --rebind=Stick-Up
Press the key you would like to rebind to...
hostname:~ user$ citra -l
A       S    | Up           T
B       A    | Down         G
X       Z    | Left         F
Y       X    | Right        H
LB      Q    | Stick-Up     Up Arrow
RB      W    | Stick-Down   Down Arrow
Select  M    | Stick-Left   Left Arrow
Start   N    | Stick-Right  Right Arrow
hostname:~ user$

This should not occur as per hardware, and can lead to some strange, unexpected errors if software assumes that the directory is writeable.

Yo, this topic has come up with yuriks's error codes branch. The backgrund is that we should strive towards having important functions, classes and class methods documented well (with a proper explanation of its behavior and with explicit @return, @param, etc Doxygen tags).

A question that popped up in this context was which commenting style to use, i.e.

/**
 * Some function which does stuff
 * @param stuff You know, stuff
 */
void SomeFunction(int stuff);

or

/// Some function which does stuff
/// @param stuff You know, stuff
void SomeFunction(int stuff);

My very personal preference is the former, because it stands out well in the source code, while the other one just hurts my eyes. Either way, would be cool to have some sort of consensus which one should be used.

Handle OpenArchive(FileSys::Archive::IdCode id_code) {
    auto itr = g_archive_map.find(id_code);
    if (itr == g_archive_map.end()) {
        return 0;
    }
    return itr->second;
}

Result CloseArchive(FileSys::Archive::IdCode id_code) {
    if (1 != g_archive_map.erase(id_code)) {
        ERROR_LOG(KERNEL, "Cannot close archive %d", (int) id_code);
        return -1;
    }

    INFO_LOG(KERNEL, "Closed archive %d", (int) id_code);
    return 0;
}

As you can see, OpenArchive simply accesses the archive from the kernel's archive map. It doesn't create an archive, or modify the map in any way.

On the other hand, CloseArchive completely erases the archive from the archive map.

This makes it impossible to close an archive and then re-open it, something which is actually done by retail software.

In the log, when closing Citra:

QMainWindow::saveState(): 'objectName' not set for QDockWidget 0x1096a3070 'Graphics Debugger;
QMainWindow::saveState(): 'objectName' not set for QDockWidget 0x1096a7070 'Pica Command List;

hi, i have opensuse 13.2 32bit with QT5 and i have that compilation error:

[  8%] Building CXX object src/common/CMakeFiles/common.dir/break_points.cpp.o
In file included from /home/common/citra/src/./common/common_types.h:29:0,
                 from /home/common/citra/src/./common/common.h:36,
                 from /home/common/citra/src/common/break_points.cpp:5:
/usr/lib/gcc/i586-suse-linux/4.8/include/xmmintrin.h:31:3: error: #error "SSE instruction set not enabled"
 # error "SSE instruction set not enabled"
   ^
In file included from /home/common/citra/src/./common/common.h:36:0,
                 from /home/common/citra/src/common/break_points.cpp:5:
/home/common/citra/src/./common/common_types.h:79:5: error: ‘__m128’ does not name a type
     __m128  a;              ///< 128-bit floating point (__m128 maps to the XMM[0-7] registers)
     ^
src/common/CMakeFiles/common.dir/build.make:54: set di istruzioni per l'obiettivo "src/common/CMakeFiles/common.dir/break_points.cpp.o" non riuscito
make[2]: *** [src/common/CMakeFiles/common.dir/break_points.cpp.o] Errore 1
CMakeFiles/Makefile2:234: set di istruzioni per l'obiettivo "src/common/CMakeFiles/common.dir/all" non riuscito
make[1]: *** [src/common/CMakeFiles/common.dir/all] Errore 2
Makefile:76: set di istruzioni per l'obiettivo "all" non riuscito
make: *** [all] Errore 2

there is something i can do ?

Emulator doesn't render Gateway's special features properly. Bottom screen color wrong and color bleeding out the sides of bottom screen.

Launcher can be found at:
http://filetrip.net/3ds-downloads/homebrew/download-homebrew-b-1-1-f32608.html

The content is a bit blurred, with a white pixel on the right side, which is definitely not 1:1 with the emulated screen.

Good evening!

I managed to run all command lines oriented at github.

git clone https://github.com/glfw/glfw.git
cd GLFW
mkdir build && cd build
cmake -DBUILD_SHARED_LIBS = ON ..
make
sudo make install

[root@localhost build]# make install
[ 24%] Built target glfw
[ 25%] Built target boing
[ 27%] Built target gears
[ 33%] Built target heightmap
[ 38%] Built target particles
[ 40%] Built target simple
[ 42%] Built target splitview
[ 44%] Built target wave
[ 46%] Built target accuracy
[ 50%] Built target clipboard
[ 51%] Built target cursor
[ 53%] Built target cursoranim
[ 55%] Built target defaults
[ 59%] Built target empty
[ 62%] Built target events
[ 66%] Built target fsaa
[ 70%] Built target gamma
[ 74%] Built target glfwinfo
[ 77%] Built target iconify
[ 79%] Built target joysticks
[ 83%] Built target modes
[ 85%] Built target peter
[ 87%] Built target reopen
[ 88%] Built target sharing
[ 90%] Built target tearing
[ 94%] Built target threads
[ 96%] Built target title
[ 98%] Built target windows
[100%] Generating HTML documentation
[100%] Built target docs
Install the project...
-- Install configuration: ""
-- Installing: /usr/local/include/GLFW
-- Up-to-date: /usr/local/include/GLFW/glfw3native.h
-- Up-to-date: /usr/local/include/GLFW/glfw3.h
-- Up-to-date: /usr/local/lib/cmake/glfw/glfwConfig.cmake
-- Up-to-date: /usr/local/lib/cmake/glfw/glfwConfigVersion.cmake
-- Up-to-date: /usr/local/lib/cmake/glfw/glfwTargets.cmake
-- Up-to-date: /usr/local/lib/cmake/glfw/glfwTargets-noconfig.cmake
-- Up-to-date: /usr/local/lib/pkgconfig/glfw3.pc
-- Up-to-date: /usr/local/lib/libglfw.so.3.1
-- Up-to-date: /usr/local/lib/libglfw.so.3
-- Up-to-date: /usr/local/lib/libglfw.so
[root@localhost build]#

But do not know how to run ...
Could anyone help me?

This is mainly because the Stop button in the menu bar does not actually stop emulation, it simply pauses it.

Furthermore, Citra starts Core upon opening the Qt window (rectified by #169).

Excuse me, I'm having an issue compiling citra on ubuntu 14.04. I have all the required dependencies.

> $ make
> [ 2%] Built target inih
> [ 3%] Automoc for target qhexedit
> [ 3%] Built target qhexedit_automoc
> [ 7%] Built target qhexedit
> [ 23%] Built target common
> [ 73%] Built target core
> [ 82%] Built target video_core
> Linking CXX executable citra
> /usr/local/lib/libglfw3.a(x11_init.c.o): In function `initExtensions':
> x11_init.c:(.text+0x1b03): undefined reference to `XineramaQueryExtension'
> x11_init.c:(.text+0x1b1d): undefined reference to `XineramaIsActive'
> /usr/local/lib/libglfw3.a(x11_monitor.c.o): In function `_glfwPlatformGetMonitors':
> x11_monitor.c:(.text+0x6e9): undefined reference to `XineramaQueryScreens'
> collect2: error: ld returned 1 exit status
> make[2]: *** [src/citra/citra] Error 1
> make[1]: *** [src/citra/CMakeFiles/citra.dir/all] Error 2
> make: *** [all] Error 2 

-Wall and -Wpedantic are gcc compiler options that specify the amount of warnings to spam during compilation. I think it's beneficial for code quality to catch as many warnings as possible (warnings which turn out to be useless can be disabled explicitly later on).

Additionally, we should make an effort to get the build warning-free. This allows us to enable -Werror (warnings are treated as errors) on the travis build bot, so that new code is guaranteed not to introduce new warnings to the code base.

Good afternoon.

Congratulations on the project.
I wonder if being able to run a .3ds file?
I noticed that has several extensions in the program has more .3ds

Thanks for listening!

It provides virtually no advantage over checking for the platform-specific preprocessor definitions, maybe other than being consistent, which is kind of useless because it trades that consistency for being de facto standardized.

I like having few project-specific oddities, so I suggest dropping and replacing it with the corresponding preprocessor definitions.