For .3dsx builds I usually run them through homebrew launcher. You might have to replace the .3dsx in the cores folder under retroarch.
@justinweiss Your latest build pushes Tony Hawk Pro Skater 2 to a nearly stable 60fps. The menu is slightly less clear than before though. Also, I said nearly stable because there are occasional drops when new sounds are played for the first time in a run (smashing glass, knocking over barrels). Those drops are all the more maddening given how close you have pushed this to stable.
What version is your retroarch install?
I would try to replace both the .3dsx in retroarch folder and the cores folder.
Still doesn't make sense that it crashes. Maybe you need to delete your config files. I'd back them up first.
Nice! The menu being less clear is probably the difference between rendering too many pixels and bilinear scaling it down, vs skipping pixel rendering (and "integer scaling" it down). That's what I meant by losing a few rows and columns. I kept it as an option in case you preferred one way or the other.
I would guess those drops are caused by trying to load from the SD card. Besides the async CD access tweak, I haven't had any ideas around how this could be solved. It also happens in RPGs the first time a character makes an attack. The 3DS doesn't have enough memory to preload the entire CD (and you wouldn't want to wait for that anyway), and there's not really a predictable way to figure out what it's going to load next to preload it earlier on.
You might see a little improvement, but its mostly the 3ds hardware thats going to get you.
@justinweiss Just wanted to say thank you for continuing to update this. I got the 3dsx file to work, and the difference in Chrono Cross is amazing. Thank you!
That new DuckStation core is supposed to be fast and it has hardware rendering support (via OpenGL). Would compiling that for 3DS and adding support for CitraGL (OpenGL library for 3DS) run any better?
I don’t know how it compares otherwise, but I think OpenGL would help in general — most of the major recent optimizations in PCSX on 3DS have been in the software renderer, and it still seems to be the slow part. At least, apart from disc access.
I think it’s unlikely we’d see a benefit through RetroArch soon, since I think there is a lot of work required to get OpenGL core acceleration on the 3DS/Vita. There’s still an open bounty if I remember correctly. But it could be worth trying to either build it standalone or bypass the RetroArch video driver and render directly, the way I think the Vita crew is doing with the Dreamcast emulator. All options are a lot more work than a straight port, unfortunately, but I’m hopeful someone with experience porting new cores to 3DS takes it on!
Last edited by justinweiss,
As a POC, i've been able to get GL rendering working using picaGL. It's very basic at the moment and is missing quite a few features.
@justinweiss already mentioned, it’s unlikely we’d see a benefit through RetroArch soon. I do like to add at-least some progress is being made.
It will take a while for me to clean up the mess i left behind, and figure out how to make a proper, preferably, additional driver.
Source will follow once clean enough.
It's a start towards having a GL enabled frontend. Maybe, just maybe, eventually exposing the GL driver to the cores will allow us to gain a few additional fps and additional cores. Currently, the default 'ctr_gfx driver' is completely disabled.
I do like to thank @justinweiss for his inital libretro ctr_opengl branch,
@MasterFeizz for his picaGL library (you're a GOD, and i hate to see you losing interest),
@Rinnegatamante for his vitaGL, gl1 retroarch implementation ( PR ).
For anyone interested enough, here's a stella2014 build with picaGL as graphics driver enabled. Who doesn't want to play GL rendered atari2600 games on their 3ds. Well I do..
To use this, from any other core, make sure to set 'RGUI' as menu driver and launch a game from there.
Starting the core directly, makes it launch with the wrong pixelformat, and you'll be greeted by a distorted menu. (yes, i suck)
This is purely a POC build, so expect issues.
@justinweiss already mentioned, it’s unlikely we’d see a benefit through RetroArch soon. I do like to add at-least some progress is being made.
It will take a while for me to clean up the mess i left behind, and figure out how to make a proper, preferably, additional driver.
Source will follow once clean enough.
It's a start towards having a GL enabled frontend. Maybe, just maybe, eventually exposing the GL driver to the cores will allow us to gain a few additional fps and additional cores. Currently, the default 'ctr_gfx driver' is completely disabled.
I do like to thank @justinweiss for his inital libretro ctr_opengl branch,
@MasterFeizz for his picaGL library (you're a GOD, and i hate to see you losing interest),
@Rinnegatamante for his vitaGL, gl1 retroarch implementation ( PR ).
For anyone interested enough, here's a stella2014 build with picaGL as graphics driver enabled. Who doesn't want to play GL rendered atari2600 games on their 3ds. Well I do..
To use this, from any other core, make sure to set 'RGUI' as menu driver and launch a game from there.
Starting the core directly, makes it launch with the wrong pixelformat, and you'll be greeted by a distorted menu. (yes, i suck)
This is purely a POC build, so expect issues.
Wow, NICE! I was never able to get anything other than a total system hang during menu display. I'd love to know what I missed.
Besides the benefits of using a display driver that is used (and updated) by more people, I was also wondering whether the gl_gfx driver would be faster than the ctr_gfx driver. The ctr_gfx driver seems to do a lot of work (which, to be fair, the libraries were in a _much_ earlier state when it was written), and I wondered if, even being wrapped in a translation layer, using newer rendering patterns would add a bit of speed.
For example, standalone mGBA does run ~10% faster than the same exact core in RetroArch, and I still don't know why. But the renderer in standalone is much simpler, so that was my first guess.
Last edited by justinweiss,
The vita implementation utilizes glDrawArrays, instead of glBegin, glEnd. Which requires the render buffers to be allocated.
The vitaGL library takes care of this, but picaGL does not. (?) At-least, that's what i learned from looking at the rendering done with DaedalusX64. The buffers are allocated in the context daedalus provides.
So, for now, i've reverted back from glDrawArrays to the glBegin, glEnd functions. Until the right context is provided.
I'm also using 1.6 libctru and the latest picaGL. Haven't tried compiling with the v1.1 libctru used on the official builds yet.
The updated library requires, next to pglSwapBuffers(), also gfxSwapBuffersGpu() to be called.
I've used a simple GL rendering example, called multiple times, from as early on in the boot process to verify GL is functional while retroarch is initializing. To verify which pixelformat is set, and hack my way to rendering something (anything).
For now it forces everything to be rendered at 400x240 with similar viewport, rotated 90deg, hence why none of the scaling, rotating or other graphical functions work.
But to be honest, it's mostly trial and error. and error and error. Without any prior knowledge on GL, and a severe lack of tutorials on GL v1.1 it very hard for me to pinpoint the exact issue which you also encountered. The system hanging on pglSwapBuffers(), but my guess is that glDrawArrays(), without pointers to the appropriate buffers may cause an issue.
Once i've cleaned all my debug comments and non related code, a diff with your branch should clear things up a bit.
@MrHuu Thank you so much for taking this forward. You and @justinweiss have done so much to move Retroarch forward on this platform. Your work here is so exciting because the N3DS is soooooooo infuriatingly close to full speed PSX on some marquee titles. If we could squeeze out even modest performance improvements it might push things over the line.
It's actually the other way around, picaGL is closer to actual openGL than vitaGL. You can just use glDrawArrays like regular, the only catch is that if the arrays are not on linear memory it will have to be copied every time you need to draw them.
I've pushed a change that will fix the need for gfxSwapBuffersGpu after pglSwapBuffers.
Anyways if you need any help, feel free to ask.
FYI, this change was merged, so it should be in current nightlies and the next stable. Thanks to everyone who tried it out!
Edit: welp, maybe not. Sounds like it may be a while until the build bot is repaired :-(
Last edited by justinweiss,
https://www.libretro.com/index.php/hacker-vandalised-our-buildbot-and-github-organization/
^ this sucks badly.. hopefully it can be worked out soon without much loss. Let's hope Github is able to help out and restore things.
Thanks! Forgive me for any stupid questions.. but as i understand it would be preferred to have the arrays in linear memory. So we don't have to copy them each frame? To me it seems like the most optimal way to go. I just have to figure out how, as this exceeds my current knowledge on the matter. (might be useful for my mutilated residualvm build too, eventually)
Once i've uploaded the current source, without glDrawArrays for the moment, hopefully someone can help out on this part. Or point me in the right direction.
I've also tried building the latest picaGL, but it forces me to compile with the latest 2.0.0 ctrulib.
Unfortunatly, RetroArch is far from being able to be build with the latest libraries.
That's bad.. very bad.. hopefully we'll be able to enjoy your latest commits soon!
On an other note. What are your thoughts on trying to have the development environment updated to be compatible with the latest libctru?
It does require to drop *hax1 support and the 'ctr_gfx' driver needs to be overhauled. It also uses customized memory management, as opposed to libctru. I'm not really sure if this can be reverted to have the libctru supplied one.
As you already mentioned, this is based on a very early implementation, which will prove more difficult to maintain as other libraries are being updated.
Just asking your opinion on the matter.
^ this sucks badly.. hopefully it can be worked out soon without much loss. Let's hope Github is able to help out and restore things.
Thanks! Forgive me for any stupid questions.. but as i understand it would be preferred to have the arrays in linear memory. So we don't have to copy them each frame? To me it seems like the most optimal way to go. I just have to figure out how, as this exceeds my current knowledge on the matter. (might be useful for my mutilated residualvm build too, eventually)
Once i've uploaded the current source, without glDrawArrays for the moment, hopefully someone can help out on this part. Or point me in the right direction.
I've also tried building the latest picaGL, but it forces me to compile with the latest 2.0.0 ctrulib.
Unfortunatly, RetroArch is far from being able to be build with the latest libraries.
That's bad.. very bad.. hopefully we'll be able to enjoy your latest commits soon!
On an other note. What are your thoughts on trying to have the development environment updated to be compatible with the latest libctru?
It does require to drop *hax1 support and the 'ctr_gfx' driver needs to be overhauled. It also uses customized memory management, as opposed to libctru. I'm not really sure if this can be reverted to have the libctru supplied one.
As you already mentioned, this is based on a very early implementation, which will prove more difficult to maintain as other libraries are being updated.
Just asking your opinion on the matter.
Yeah :-( It seems like more of an annoyance than anything, at least the PRs and issues weren't deleted. Nice thing about Git is that here are probably hundreds of full mirrors of the source repos floating around on people's machines.
I originally did all my RA improvements on the newest libctru. Most cores I tried only required minor changes. I think I still have an open PR on the main RA repo for it.
A bigger problem is all the testing and maintenance work that would need to be done -- someone would need to own:
* Updating all the cores to use newest libctru
* Updating the buildbot to use newest libctru (maybe now is a good time!)
* Doing heavy testing of all cores to make sure there aren't regressions
That last one is tough, I actually broke pcsx for a stable release because I built under the newest libctru but didn't test under the older libctru. Learned my lesson and now I have a build environment that matches the buildbot's.
I still think it would be worth it to upgrade, though. There's a lot that could be cleaned up using newer APIs and patterns, and it would be much easier for someone new to get started when they don't need to dig up a specific older version of devkitpro to get it working. I'm sure there are people who would be interested in contributing to RetroArch 3DS who give up when the builds don't work under their setup.
So, worthwhile, probably not too hard, but still time-consuming and the team doesn't have the resources to take it on. Someone interested would probably need to push it through.
If someone was to do it, it would probably be best to handle both the old and the newest version at the same time (through ifdefs or whatever). That way it could be tested, merged, and reviewed incrementally.
Last edited by justinweiss,
Such a bummer to see the buildbot being decimated, I was gonna download the latest nightly right at the moment when I first saw this post, only to find out that the site had been hack only a couple of hours ago. Do you by any chance still have that nightly?
On another note, I've tried out the latest .3dsx build you'd attached on page 19. I've been playing mainly with the cia installed official 1.9.0 version though, so if I Ieft Enable Hi-Res Downscaling on in the .3dsx version and let the config file record that change, there naturally was no way to turn it of in the 1.9.0. But I've also noticed on some occasions even after I turned it off the screen still wouldn't fully go back to normal (as in, for example, 2D images will display correctly with all the pixels, but black columns still persist in 3D in-game sections), so I'd have to delete that config file and use a new one. Is this glitch to be expected somehow with this .3dsx build? I was playing Spider-Man btw.
Last edited by wanderindirk,
-
-
-
@
SylverReZ:
One of the sites that weren't blocked on the school's network was some file uploading sites. I would upload some games, write down the URL and take it to school one day. -
-
@
SylverReZ:
I did it when the teachers werent looking ofc. I even managed to take in a USB stick that wasn't allowed.
-
@
Bunjolio:
my school has a chrome extension called light speed filter agent and it legit blocks YouTube pfps since the file cdn(I think aka yt3.ggpht.com) is classed as mature -
-
-
-
-
-
-
@
SylverReZ:
It was easy to bypass some of the restrictions, as one of the admins left a registry key in the administrative shares drive, which allowed me to get around the blocking of some sites.
-
-
-
-
-
-
-
-
-
-
-
-