Homebrew Official Citra - New 3DS Emulator

  • Thread starter Thread starter bunnei
  • Start date Start date
  • Views Views 3,856,546
  • Replies Replies 7,211
  • Likes Likes 175
Citra's FB Page said:
As expected with our last announcement, two more game are known to boot in Citra. Cubic Ninja has reached its loading screens before eventually hanging, and Gunman Clive is showing background textures. Cubic Ninja and Ocarina of Time 3D seem to hang while trying to save data. Once that is figured out, it may be possible that the games go even further!
2gqQfEQ.png

fQuQTYO.png





Cya~
 
  • Like
Reactions: Twee
I'm getting
Code:
[ 84%] Building CXX object src/citra/CMakeFiles/citra.dir/config.cpp.o
Linking CXX executable citra
/usr/local/lib/libglfw3.a(x11_init.c.o): In function `initExtensions':
x11_init.c:(.text+0x1b35): undefined reference to `XineramaQueryExtension'
x11_init.c:(.text+0x1b4f): undefined reference to `XineramaIsActive'
/usr/local/lib/libglfw3.a(x11_monitor.c.o): In function `_glfwPlatformGetMonitors':
x11_monitor.c:(.text+0x6ee): 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
when I try to compile citra..
 
Essentially pulled an all-nighter today to get stuff working; guess I succeeded, so I'm just gonna throw this out here:

(disclaimer: of course, this was a team effort, not solely mine :) )


So, I saw this and decided to fork your multitexturing branch to compile and try it out. I was wondering about it before I compiled, and I wasn't surprised when I got "Failed to load ROM (Error 2)!" when trying to load my decrypted Ocarina of Time 3D rom in .3ds format. Have you implemented .3ds rom support in a separate branch or haven't uploaded to GitHub yet? Or is there a way to dump roms in another format that I don't now about?
 
Okay, so I'm using the pica_progress branch, along with the 2 patches needed to make OoT 3D render something and also a small fix to get it to compile on OS X, which I noticed archshift posted the same change plus more on the PR. I've been messing around for a little while now, but the best I can get is short log spam and then a crash. I don't have the other two games that have been shown to boot, so I can't test them. I've used the normal and qt builds, tested them both using both interpreters, but this is the best I can get:
Code:
[  10.428862] HW.Memory <Error> core/mem_map_funcs.cpp:Read:95: unknown Read32 @ 0x00000F66
[  10.428873] HW.Memory <Error> core/mem_map_funcs.cpp:Write:144: unknown Write32 0x00000000 @ 0xFFFFFF7C
[  10.428876] HW.Memory <Error> core/mem_map_funcs.cpp:Write:144: unknown Write32 0x00000000 @ 0xFFFFFF80
[  10.428883] HW.Memory <Error> core/mem_map_funcs.cpp:Write:144: unknown Write32 0x00000000 @ 0xFFFFFF84
[  10.428886] HW.Memory <Error> core/mem_map_funcs.cpp:Write:144: unknown Write32 0x00000000 @ 0xFFFFFF88
[  10.428888] HW.Memory <Error> core/mem_map_funcs.cpp:Write:144: unknown Write32 0x00000000 @ 0xFFFFFF8C
[  10.428891] HW.Memory <Error> core/mem_map_funcs.cpp:Write:144: unknown Write32 0x00000000 @ 0xFFFFFF90
[  10.428893] HW.Memory <Error> core/mem_map_funcs.cpp:Write:144: unknown Write32 0x00000000 @ 0xFFFFFF94
[  10.428896] HW.Memory <Error> core/mem_map_funcs.cpp:Write:144: unknown Write32 0x00000000 @ 0xFFFFFF98
[  10.428898] HW.Memory <Error> core/mem_map_funcs.cpp:Write:144: unknown Write32 0x00000000 @ 0xFFFFFF9C
[  10.428900] HW.Memory <Error> core/mem_map_funcs.cpp:Write:144: unknown Write32 0x00000000 @ 0xFFFFFFA0
[  10.428903] HW.Memory <Error> core/mem_map_funcs.cpp:Write:144: unknown Write32 0x00000000 @ 0xFFFFFFA4
[  10.428905] HW.Memory <Error> core/mem_map_funcs.cpp:Write:144: unknown Write32 0x00000000 @ 0xFFFFFFA8
[  10.428907] HW.Memory <Error> core/mem_map_funcs.cpp:Write:144: unknown Write32 0x00000000 @ 0xFFFFFFAC
[  10.428910] HW.Memory <Error> core/mem_map_funcs.cpp:Write:144: unknown Write32 0x00000000 @ 0xFFFFFFB0
[  10.428912] HW.Memory <Error> core/mem_map_funcs.cpp:Write:144: unknown Write32 0x00000000 @ 0xFFFFFFB4
[  10.428915] HW.Memory <Error> core/mem_map_funcs.cpp:Write:144: unknown Write32 0x00000000 @ 0xFFFFFFB8
[  10.428917] HW.Memory <Error> core/mem_map_funcs.cpp:Write:144: unknown Write32 0x00000000 @ 0xFFFFFFBC
Segmentation fault: 11
logout
Maybe I'm doing the whole loading a .3ds rom file wrong, I dunno. I simply renamed it to a .bin so Citra would accept it. I didn't think I'd get anything out of doing that, but I got this short log spam. Or maybe the branch doesn't fully work yet on OS X? I don't think that's it, GameYob and BlargSNES displayed fine. I might try a Linux build later.
 
Sorry, can't really help you - but if you have to rename the file to a .bin, chances are it's not something that Citra supports and/or the file format will be misrecognized. Can you maybe tell me the magic header word at offset 0x100 from a hex editor?

For now I'm tempted to say your dump is not working properly.
 
Well, I got my rom situation solved. I think. I ended up getting a .cci file and got a lot more results when booting, but still nothing rendered. I have an extremely long log here. The biggest thing that pops out to me is the extremely large amount of "Unknown source framebuffer format 4" and "Unknown destination framebuffer format 4" spam. Of course, theres a lot more things that were spammed, but this looks most related.
 
I might be dumb for saying this, but what else can I get from the log? I posted the entire thing that was outputted to my terminal. GitHub cuts it off a ways down, but viewing it as a raw file will show it all.
 
Well I don't know, you said "Of course, theres a lot more things that were spammed, but this looks most related. " so I figured you might have removed important parts of the logs.
 
  • Like
Reactions: Hydr8gon
is Citra (and 3Dmoo, even if not the correct thread) only for 64bit compatible computers?
I'm on Win XP x86, and the x86 build on emucr still gives me error "not a valid 32bit application".
It's maybe an issue of emuCR's build? maybe they compile both versions on a 64bit OS. I didn't find a faq or active forum on their website.

I didn't try to compile it myself yet, I never used visual studio.


Edit:
I want the emulator to test my homebrew, I understand that you don't like auto or random build provided to end user, but don't worry I won't cry if last released game is not working as it's not what I will use it for.
So if someone has a built for XP 32bit, I would gladly accept it.
Thank you.
 
I don't know about emucr builds, I have no control over whatever they do (and well, I think I stated before that I don't particularly like that people go to that site to begin with).

Citra *is* written to be 32 bit compatible though. However, chances are there's no XP support.
 
is Citra (and 3Dmoo, even if not the correct thread) only for 64bit compatible computers?
I'm on Win XP x86, and the x86 build on emucr still gives me error "not a valid 32bit application".
It's maybe an issue of emuCR's build? maybe they compile both versions on a 64bit OS. I didn't find a faq or active forum on their website.

I didn't try to compile it myself yet, I never used visual studio.
no they work on both old 3dmoo don't work on x64 the newer do but you are run win XP --> you need to compile 3dmoo with the Platform Toolset win XP
 
  • Like
Reactions: Cyan
Hi there,

You might have seen our little announcement of Facebook, but for those who didn't I'll post here, too.

A number of people have asked whether they could support the project via donations. We've been a bit hesitant with setting up something like this, but ultimately realized that it would indeed make a lot of things easier. So if you're interested in helping us out, here's the paypal to go to:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=K899FANUJ2ZXW
Donations accumulate easily, so don't worry if you can only donate a small amount :)

To give you an idea of things we'll spend the donations on:
* 3DS consoles: This is the most expensive, but also most helpful point. Developers can use access to actual consoles to figure out how the hardware works. Some of us have bought consoles out of their own pocket solely for reverse-engineering the hardware and never played any games with them. We would like this to be the exception, and instead give skilled developers something to work with without requiring them to pay for working on an open-source project.
* Additional 3DS equipment: Games, NDS flashcards, etc. All that kind of stuff which is required for testing and/or getting homebrew code execution.
* In the future, we will likely need some income to cover for server costs (website, buildbots, etc), too.
* More generally, we would like to be able to buy things helping Citra development directly or indirectly without having to worry about our personal finances.

Some people stated concerns that they would be willing to pay only if they received a binary build to tinker around with. Please understand that we will not provide those builds in the near future. We simply see little point in it currently, and it would just mean that we have to set up some buildbot infrastructure now and deal with user support. It's just not worth currently given that this is time that we lose for coding. That said, I believe we have thrown out more than enough evidence (here and on our Facebook page) that our project is legit and is making steady (if not even accelerating) progress. Rest assured, builds will be provided once we think the general public should have access to them, and meanwhile anyone can set up a development environment and build it from the source code on GitHub.

That said, I'm looking forward to seeing what people think about this announcement and/or if I should be more specific in any relevant points, so feel free to leave a comment to this thread.

Regards,
neobrain
Citra developer
 
Well I don't know, you said "Of course, theres a lot more things that were spammed, but this looks most related. " so I figured you might have removed important parts of the logs.

Nah, I know to post the full logs. ;) While I do know a lot less about all this stuff than I would like, I know that the full log is always more useful. For all I know, it could still be my game dump! I'd love to dive into the code and maybe see what's going on in there myself, however with my current knowledge all I can really do with ARM code is look at it and vaguely understand what it does. I really hope sometime to be doing some meaningful work for this emulator!
 
I'm currently trying to build Citra on OSX. I'm following the steps that don't use the homebrew thing:
Code:
it clone https://github.com/glfw/glfw.git cd glfw mkdir build && cd build cmake .. make sudo make install

When I do the line "cmake .." it's not doing anything. IT's saying that the cmake command isn't found. Anyone have any idea why?
 
I'm currently trying to build Citra on OSX. I'm following the steps that don't use the homebrew thing:
Code:
it clone https://github.com/glfw/glfw.git cd glfw mkdir build && cd build cmake .. make sudo make install

When I do the line "cmake .." it's not doing anything. IT's saying that the cmake command isn't found. Anyone have any idea why?
Well then, obviously cmake is not installed or its not in your PATH.
 

Site & Scene News

Popular threads in this forum