Homebrew [RELEASE]Nitro Screen - Facilitating screen capture with NTR CFW

[jlangford]

HI all, I posted a quick hack of NTR debugger ages ago here and it motivated me to do something a bit more ambitious.

Big thanks to Cell99 for NTRDebugger.
Thanks @NekoMichi for the awesome tutorial on setting this all up!

New 3DS Only.
For the windows version go here.
For the Very Alpha cross platform version go here.

 

[N7Kopper]

Requests, huh? Would an option to automatically save the streamed videos be feasable? Bonus ducks if you can make the Top and Touch screens save to different files.

 

[jlangford]

Requests, huh? Would an option to automatically save the streamed videos be feasable? Bonus ducks if you can make the Top and Touch screens save to different files.

I would say OBS is best for actually saving the catpure, but once I am hosting NTRViewer within Nitro Stream it's definitely possible. It's just the efficiency, I don't think I have the knowledge to compete with a project like OBS. I'll certainly put it on the list though.

 

[Deleted-394630]

That's all you got on your homescreen? You must be joking!

 

[Nabix]

Requests, huh? Would an option to automatically save the streamed videos be feasable? Bonus ducks if you can make the Top and Touch screens save to different files.

I would definitely love this. I don't feel like downloading a bunch of screen recorders just to record my gameplay.

 

[jlangford]

I would definitely love this. I don't feel like downloading a bunch of screen recorders just to record my gameplay.

Well, as I said, I'll see what I can do

 

[TR_mahmutpek]

This program can incerase stream fps? Also thank you for your efford

 

[jlangford]

This program can incerase stream fps? Also thank you for your efford

It doesn't do anything that can't be done manually with some command line work and the NTR Debugger. This just ties it all together into one package. The short answer is yes, it can be used to increase fps if you want to play with the stream quality and the advanced settings.

 

[Joom]

*sigh* I don't mean any sort of offense by saying this because you did a good job, but I wish developers would move away from .NET languages. None of my computers run Windows, and WINE is really not a viable solution. There's quite a few 3DS tools I'd like to use but can't, and I'd rather not use a VM.

 

[Sliter]

oh well I'm taking so much to try this taht everything is getting easier XD
Thansk a lot!

 

[jlangford]

*sigh* I don't mean any sort of offense by saying this because you did a good job, but I wish developers would move away from .NET languages. None of my computers run Windows, and WINE is really not a viable solution.

.Net is what I know and love so I'm afraid I'll continue to develop for it, however it is also the future of cross platform development with recent advances in .Net Core & Mono.
Mono & Wine are very viable options for most .Net applications, however this one still wouldn't work as I'm using WPF which hasn't had the love it deserves.

NTRDebugger just uses TCP connections to talk to NTR on the 3DS so you could write a cross platform version of this in any language you wanted (Java is probably best?) based on the source code I've provided & NTRDebugger's source code. I haven't actually peeked into NTRViewer on the otherhand so I don't know what that's written in, but it uses sdl, so it's also possible to recreate it. It would take some documentation from Cell9 or someone who knows how to sniff and read what packets mean to figure that out though. (Or maybe it would just take someone to decompile NTRViewer)

 

[Joom]

The future of cross-platform development? C++ is gonna be hard to beat. The only .NET application I know of that works well on multiple platforms is Banshee, and even then the Windows version is a mess. Also, Java is never the best. It's worse than .NET.

 

[jlangford]

The future of cross-platform development? C++ is gonna be hard to beat. The only .NET application I know of that works well on multiple platforms is Banshee, and even then the Windows version is a mess. Also, Java is never the best. It's worse than .NET.

You could take that further and say that C++ will never beat C and that C will never beat Assembly. C++ is great and it's amazing at what it's designed for, but creating cross platform desktop applications (Read: Not command line/serverside/etc.) is not one of those things. Out of high level languages I really believe .Net is the way forward. I also think that currently java is one of the few ways to deploy consistent cross platform desktop applications. (Let's not get into QT and GTK)

 

[Joom]

Uh, C++ is the successor to C, and you really can't compare either to ASM. That's like saying JavaScript will never beat Python.

 

[jlangford]

Uh, C++ is the successor to C, and you really can't compare either to ASM. That's like saying JavaScript will never beat Python.

I wouldn't consider it a successor, but let's not get off topic.

Note: I should say; I have tried to stick to the MVVM pattern (It needs a butt load of reworking) in Nitro Stream so you could actually reuse a lot of my code if you wanted to use Monodevelop to strap a gtk.net front end onto the app for use with Linux et al.

 

[Joom]

That wouldn't work on OS X, though.

 

[jlangford]

That wouldn't work on OS X, though.

I'm pretty sure MonoDevelop will compile a .Net solution (Mostly) on OSX.

 

[W007]

You could take that further and say that C++ will never beat C and that C will never beat Assembly. C++ is great and it's amazing at what it's designed for, but creating cross platform desktop applications (Read: Not command line/serverside/etc.) is not one of those things. Out of high level languages I really believe .Net is the way forward. I also think that currently java is one of the few ways to deploy consistent cross platform desktop applications. (Let's not get into QT and GTK)

You are really not well informed about these issues. Assembly has a place especially in some embedded systems applications, in OS development, in optimization of C or C++ programs (yes, knowledge of assembly is useful there), and in compiler code generation. C has a place but really only when there's no C++ compiler.

C++ is designed to be cross platform if you want it to be, but there are ways for it to not be cross-platform such as platform-specific libraries. Sometimes there are good reasons to use platform-specific libraries, especially in embedded systems and backends to cross platform libraries.

C++ and Qt or GTK are GREAT ways to write cross platform GUI programs. I personally prefer Qt because it's super easy to use. GTK might be easy to use too but I haven't tried in years. If you think these aren't valid ways to write cross platform C++ GUI programs, you're super mistaken.

My personal opinion is that .Net as a whole wouldn't be that bad if it wasn't so Microsoft-centric. It is not a good way to write cross-platform programs and it likely never will be because Microsoft really does not care about non-Microsoft-OS users. You might cite the Windows 10 Bash thing, but that's really just a scheme to try to get people to migrate away from non-Windows OSes. It's also not a way to write GUI programs for Windows.

 

[chaoskagami]

however it is also the future of cross platform development with recent advances in .Net Core & Mono.

Oh boy, you have no idea. Just the very fact that C#/VB/CIL is by Microsoft is a CoI to being cross platform. If you think otherwise, just wait. Bash is also just a ploy/scam to try and get the dwindling power users back (which is futile.)

(Or maybe it would just take someone to decompile NTRViewer)

Yeah, sure. Pigs will also fly. "Decompilation" is reserved for languages that make no effort at hiding their code since they aren't native, e.g. CIL, JVM, Dalvik, etc. Otherwise, prepare for hell and a half.

I'm pretty sure MonoDevelop will compile a .Net solution (Mostly) on OSX.

Um, no. What you fail to realize is that mono supports less than 1/2 of .NET's "standard", whatever that means, since it's entirely Windows-specific and literally can't be implemented cross-platform. If you code in mono you need to tailor for mono, not windows.

Anyways, jlangford. You are not well informed here. You may want to read up and actually understand what "cross-platform" means, because targeting Windows is not.

I could also complain about how MonoDevelop != Mono, but eh.

 

[jlangford]

You are really not well informed about these issues. Assembly has a place especially in some embedded systems applications, in OS development, in optimization of C or C++ programs (yes, knowledge of assembly is useful there), and in compiler code generation. C has a place but really only when there's no C++ compiler.

I think you missed my point - I know that each and everyone one of them have their uses and excel at them. My point was that each one could be seen as 'more cross platform' than the last simply down to how each one is 'lower level' than the last and will run pretty much anywhere you want it to. C++ Doesn't provide anything on it's own to enable cross platform desktop applications. You can strap on GTK, Qt or even .Net to it, but they're all their own entities.

I don't at all consider them invalid ways of writing Cross Platform desktop applications, in fact all of them, Qt, Gtk, Java, hell even projects like electron are currently more viable ways to develop cross platform desktop apps than .Net. What my point was, is that with the way .Net has been open sourced with .Net Core and how compatible Mono has become in the last few years, I can see .Net becoming a viable and very popular platform.