Homebrew [Homebrew] 3DS Remote Desktop

  • Thread starter Thread starter retrozelda
  • Start date Start date
  • Views Views 223,375
  • Replies Replies 297
  • Likes Likes 46
I know the topic has already gotten underway, but I'd like to say that this idea is awesome. The thought of just being able to use the 3ds as a remote PC would just make me happy. Especially if you could just link the two over a network and still have the same functionality hundreds of miles away.


Technically, you could download and try the android dolphin emulator. You'd be living the dream, albeit at at about -2 fps :)

Any idea on how fast that would work on the OnePlus One? Don´t have one but was planning on getting one, and this would be a real nice iceing on the cake
 
Since you use the same method as the guy who developed 3DsController (http://wiki.gbatemp.net/wiki/3DS_Controller) I tried to use his hb app and it works so I guess the problem is somewhere else :(

Edit:
Also what is that flickering thing in the upper left corner on the top screen?

i didnt even know that existed haha. must be something with non blocking sockets maybe? i can look into it when I get some time.

Tuto required please !!! :wacko:

Homebrew + ? to work

Homebrew only => [ERR -1]

what? you need to run the .exe server and the homebrew on the 3DS.
 
Any idea on how fast that would work on the OnePlus One? Don´t have one but was planning on getting one, and this would be a real nice iceing on the cake

Since it's still in the early development stages, it won't run well on any piece of phone hardware. I have a htc M8 w/ a 4 core 2.3Ghz processor and it lags even that. I think it'll be years before there's even a phone or tablet that can handle it and play at 30+ fps. We'll see...
 
i didnt even know that existed haha. must be something with non blocking sockets maybe? i can look into it when I get some time.



what? you need to run the .exe server and the homebrew on the 3DS.


Thant you for you reply !

But what .exe for the server program please ?
It's not mentioned on the first post ... :cry: (Or don't see it !)
 
Great app, good luck with further development. I hope you don't mind me doing some silly experiments in the mean time :)
I have no idea whether DX9 has something built-in to capture separate windows or not, but getting Front Buffer only seems to work from full desktop. As a very stupid solution I've tried to crop the area to send only a certain window and basically hardcoded it for VBA. I don't think it runs any faster, but at least the image is clearer. Also, I removed stretching since I just hate how it looks.
And a simple test video

P.S. The sound is coming from my PC's speakers, not 3DS's
 
Thant you for you reply !

But what .exe for the server program please ?
It's not mentioned on the first post ... :cry: (Or don't see it !)

On my website here, or on the first post theres an attachment. Extract that(i recommend using 7zip). The server exe and the homebrew client exist within that.


client gets the wrong ip...
can't connect ....
Firewall and anything else what could block the program is turned off :/

Can you be a bit more specific? But if you have the same confusion a few other people elsewhere had, The IP that shows up in the client can be changed wit the DPad and the L and R shoulder buttons. You enter the IP of the pc running the server. :hateit:

Great app, good luck with further development. I hope you don't mind me doing some silly experiments in the mean time :)
I have no idea whether DX9 has something built-in to capture separate windows or not, but getting Front Buffer only seems to work from full desktop. As a very stupid solution I've tried to crop the area to send only a certain window and basically hardcoded it for VBA. I don't think it runs any faster, but at least the image is clearer. Also, I removed stretching since I just hate how it looks.

DX9 can grab a handle to and specific windows front buffer. Im at work, so I cant give you specific line numbers, but somewhere in main.c, I am using hte console handle to get the desktop window handle. Instead of passing the capture class that handle, it can theoretically be any window handle. Then, i cant remember if i am building the off screen surface based on the default monitor, or through the size of the handle, but! That can easily be changed to be more dynamic. A simple way you could test something could be using the GetTopWindow() function and bind it to a hotkey or something. If you do anything sexy like that before I get around to it, you could contribute to the project :D
 
The stuttering is caused by packet size and my poor network setup(this was running through 2 different routers where my pc and the 3DS are on different subnets, and one of the routers is old and crappy).

Not to mention how the 3DS AND new 3DS only have a B/G radio available. I'm sure this is causing some bottleneck as well.
 
DX9 can grab a handle to and specific windows front buffer. Im at work, so I cant give you specific line numbers, but somewhere in main.c, I am using hte console handle to get the desktop window handle. Instead of passing the capture class that handle, it can theoretically be any window handle. Then, i cant remember if i am building the off screen surface based on the default monitor, or through the size of the handle, but! That can easily be changed to be more dynamic. A simple way you could test something could be using the GetTopWindow() function and bind it to a hotkey or something. If you do anything sexy like that before I get around to it, you could contribute to the project :D

That was my first idea, to pass VBA window handle instead of screen handle. Unfortunately, as it says in GetFrontBufferData() reference, this function only works at full screen level. Passing a window handle instead of desktop handle causes a D3DERR_INVALIDCALL.
I know that most live-streaming programs, which used DX9, usually captured specific areas simply by cropping Desktop capture, so it seems there was some kind of limitation in DX9 in that regard. Whether it's worth switching to DX10 or not I don't know(I'm really new to all this :) ), probably not, but it could potentially add to performance.
 
Not to mention how the 3DS AND new 3DS only have a B/G radio available. I'm sure this is causing some bottleneck as well.

the 3ds' network card is shitty as well. the new 3ds has the capacity to download from the eshop faster, so I assume that it has a better network card inside although im just hypothesizing off of this video




That was my first idea, to pass VBA window handle instead of screen handle. Unfortunately, as it says in GetFrontBufferData() reference, this function only works at full screen level. Passing a window handle instead of desktop handle causes a D3DERR_INVALIDCALL.
I know that most live-streaming programs, which used DX9, usually captured specific areas simply by cropping Desktop capture, so it seems there was some kind of limitation in DX9 in that regard. Whether it's worth switching to DX10 or not I don't know(I'm really new to all this :) ), probably not, but it could potentially add to performance.

Ill try a few things and see what i can come up with. work closed due to incoming shitty weather conditions so I have an extended weekend :D
 
the 3ds' network card is shitty as well. the new 3ds has the capacity to download from the eshop faster, so I assume that it has a better network card inside although im just hypothesizing off of this video

It actually doesn't. I was surprised as well thinking the "faster downloads" would mean that they upgraded to an N capable wifi card, but tech specs everywhere show it as a B/G card. I think it operates faster by downloading the files at the same rate, but is able to install the CIA's faster due to processing.
 
It actually doesn't. I was surprised as well thinking the "faster downloads" would mean that they upgraded to an N capable wifi card, but tech specs everywhere show it as a B/G card. I think it operates faster by downloading the files at the same rate, but is able to install the CIA's faster due to processing.

Actually, just because the 3DS's Wifi card is classed as a B/G, doesn't mean it actually gets the full speeds that specification allows. The DS Lite for example had a B/G wifi card too, but it's known to be much slower then the 3DS. The n3DS may have a faster wifi card that might actually use the full transfer speeds available for that specification or comes close to it.

It would take someone with a modified router perhaps to peak at the actual transfer rates that the n3DS and 3DS get.
 
Actually, just because the 3DS's Wifi card is classed as a B/G, doesn't mean it actually gets the full speeds that specification allows. The DS Lite for example had a B/G wifi card too, but it's known to be much slower then the 3DS. The n3DS may have a faster wifi card that might actually use the full transfer speeds available for that specification or comes close to it.

It would take someone with a modified router perhaps to peak at the actual transfer rates that the n3DS and 3DS get.

The only problem is, would that even allow for fluid gameplay? There are several remote desktop applications for Android, and many of them only run correctly with 4G LTE connection.
 
Actually, just because the 3DS's Wifi card is classed as a B/G, doesn't mean it actually gets the full speeds that specification allows. The DS Lite for example had a B/G wifi card too, but it's known to be much slower then the 3DS. The n3DS may have a faster wifi card that might actually use the full transfer speeds available for that specification or comes close to it.

It would take someone with a modified router perhaps to peak at the actual transfer rates that the n3DS and 3DS get.


There have also been a lot of changes to wireless over the years, but not many improvements over the B/G spectrum. N and AC are where a lot of the focus is now in the 5Ghz spectrum. I think the improvement in speed is likely due to a lot of wireless routers and access points being capable of dual band which allows two streams of data transfer to take place at a time. Perhaps they added a second antenna to help which is one of the differences between the old and new 3DS.

I have a Meraki AP at home I could test with, it gives data input/output over time. Perhaps I can play with that over the weekend using youtube as a testing point on both units.
 
The main thing here is the DS capped transfer speeds to preserve battery. (one of the reasons battery life was so good with that console). I think the 3DS bumped things up with more power efficient hardware and the n3DS likely pushed things a bit faster too. But they are still below spec, because they are portable consoles with limited battery life.
 

Site & Scene News

Popular threads in this forum