Homebrew Ntrviewer with o3ds?

[TheGreek Boy]

It's possible one day ntrviewer to work with o3ds?

 

[Seriel]

Maybe at like 1fps.
The o3ds has a shit processor, it won't be able to handle it.

 

[TheGreek Boy]

Maybe at like 1fps.
The o3ds has a shit processor, it won't be able to handle it.

So you say it's imposible to work 'normal'?

 

[Seriel]

So you say it's imposible to work 'normal'?

It certainly won't work to the same standard as the n3ds one.

 

[ih8ih8sn0w]

You have less than 1/8 the processing power of a n3ds on an o3ds, there is no possible way you will be able to use ntrviewer on an o3ds without your ds crashing, or lagging to an unplayable framerate...

 

[Ryccardo]

Maybe if the NTR core was open source.

Fix'd, your original message explains a correct limitation but doesn't matter until this point is solved

 

[Seriel]

Fix'd, your original message explains a correct limitation but doesn't matter until this point is solved

Okay, but don't touch my post mkay?

 

[ChaosRipple]

Fix'd, your original message explains a correct limitation but doesn't matter until this point is solved

If someone can code the arm9 to take screenshots and send them over a socket, I'll gladly have the client end coded in c#. I have some slight experience coding in C but none with the 3DS arm processors, making it very time consuming for me if I would want to make something like NtrViewer. Really, all you need to do is copy the buffer from addresses 0x1E6000-0x22C500 using memcpy and send them to the client (Compression could be applied as well for better performance). The client will handle all the byte to image conversion which I've already done. It would be nice to have this feature installed into one of the existing CFWs (run a thread in the background waiting for a socket connection from the client) so not all of us would be required to install Ntr.

Couple Notes:
- 0x1E6000-0x22C500 is the address for the top screen's left framebuffer 0, meaning the bottom screen has its own address.
- Certain applications actually move the framebuffer elsewhere so we'd probably need some sort of hook to detect the address change and send those bytes over instead.