Cyanogen3DS seems broken with the new GPU changes

[joel16]

First of all my program heavily relies on sf2d and sflib for loading it's textures. I haven't changed anything with the source but after updating with the most recent versions of libctru, citro3d and libsf2d, libsfil, libsftd it appears to run very slowly on both Citra and hardware. What's even weird is that none of the controls actually work, except for the analog stick. A/B/Y doesn't seem to work. The only that may possibly be causing the lags is this https://github.com/joel16/Cyanogen3DS/blob/master/source/utils.c#L126 I can't think of anything else that may affect performance. Do you have any idea what's the problem?

[xerpi]

Hmm can you try commenting functions such as drawing a texture to see if the speed improves and find the function that is slow?

[kitlith]

So... I appear to be having similar issues with my project (this isn't limited to Cyanogen3DS). Iirc, I was getting roughly 120 FPS before I updated, and now I'm getting ~58-59. This is now causing issues with my sound, though it's probably fixable. And I don't even have real collision detection yet... >_<

I will attempt commenting stuff tomorrow, I need to take a break from this.

[fincs]

https://github.com/joel16/Cyanogen3DS/blob/master/source/boot.c#L66

Why is there a sleep? sf2dlib is supposed to already take care of synching with the screen refresh rate (which is 60FPS, rendering at anything higher than that is pointless)

[joel16]

@fincs the sleep function is there to prevent the boot animation from going way too fast. That was the reason why I had to place the sleep function there. Besides that function isn't activated if bootanimation is off (in my case it is), so it wouldn't even go to the sleep function in the first place. But as you suggested, I tried commenting it out but it didn't make any change.

@xerpi I tried commenting out some drawing functions, and also my setBilienarFilter function to see if it improves performance in any way but sadly it didn't. It's weird because I haven't messed with the source since the most recent changes to the GPU. I only made a few changes in the makefile to adapt to the changes in the way shaders are handled. I'm out of ideas here.

[joel16]

The issue still persists and basically leaves my program unusable, has anyone found anything regarding this?

[TricksterGuy]

Any update on this? This is also happening in my homebrew application which also heavily relies on sf2dlib.

I don't know if this would help debug, but... After loading this up in citra-qt with a gdb instance attached I'm seeing it hang or something else strange is happening. I placed a breakpoint at the start of the main game loop stepping through it, it works file but allowing it to run for several seconds it eventually starts doing the following

(gdb) bt

0 svcWaitSynchronization ()

at /devkitPro/ctrulib/libctru/source/svc.s:210

1 0x0017a368 in gspEventThreadMain (arg=)

at /devkitPro/ctrulib/libctru/source/services/gspgpu.c:151

2 0x0017cc30 in _thread_begin (arg=)

at /devkitPro/ctrulib/libctru/source/thread.c:36

3 0x00000000 in ?? ()

I will also note that commenting out the drawing functions the input appears to be working fine except nothing is drawn of course!

So I suspect its a case of deadlock...

[kitlith]

Blast, I completely forgot about this! >_> sf2dlib, when using citro3d, essentially has VSync. After calling sf2d_swapbuffers(), it waits until the current frame actually gets displayed, if I understand correctly. (someone please feel free to correct me on this)

What I did was move my sound loading stuff into another thread, leaving graphics and collision (which could probably also be in another thread... shrugs) in the main thread. Now I get a steady framerate and steady sound.

[joel16]

Cyanogen3DS doesn't even use sound (yet), and the framerate issues still occur. There are also many graphical glitches. I have certain 'overlays' on my project. For example if the cursor (which is controlled by the d-pad/c-pad/analog) goes over a certain x and y axis, another asset will be displayed over the current to make it sort of 'highlight'. These things are causing glitches on both screens, which never used to happen with the old GPU code. It's funny how everything was working fine and progress was going smooth, then this just completely transformed my project into an unusable state. I literally changed nothing, except adopting to the new citro3d changes (include -citro3d in the libs, and minor makefile stuff). Didn't mess with the source in any other way, so I really don't know what's going on. I might as well just give on my project.

[TricksterGuy]

@kitling that sounds plausible and I'm inclined to believe you since commenting out the swap_buffers call does make my app respond to input but doesn't show anything (as expected).

If this is definitely the case then I'm miffed that the documentation wasn't updated with this new unexpected behavior or mentioned in the commit that switched this to using citro3d some warning would have been appreciated.

So you are suggesting shoving off the rendering to a different thread since sf2d_swap_buffers will now block until the screen is actually showing the contents of what was drawn correct? If this is the case then the question is why doesn't the library just spawn threads to do itself so that the behavior is left unchanged?

and joel16 don't give up! There's probably one/two pieces missing out of the puzzle here.

Anyway I am thankful, for the support in keeping this maintained I like the simplicity of this library.

[xerpi]

@joel16 I'd recommend you to use citro3d directly. Wrap some of the code here in a thin layer and you'll be fine: https://github.com/devkitPro/3ds-examples/blob/master/graphics/gpu/gpusprites/source/main.c

[joel16]

Didn't even think about using citro3d directly, but I'll give it a shot. Thanks for your suggestion.