DO IT PLEASE I HAVE A NEW 2DS ALL I WANNA PLAY IS MARIO MAKER!
Are you talking about a app or a .exe?
Are you talking about a app or a .exe?
Last edited by Deleted member 445482,
Homebrew Record 3DS Gameplay to SD Card?
- Thread starter CyberTails
- Start date
- Views 8,298
- Replies 36
I'm sorry, but Mario Maker is a bit of a heavy game, so HzRec will have a very very bad performance when stuff is going to be loaded (NAND and SD share the same stuff, so reading the NAND could bottleneck writin the recording to the SD, which in turn will decrease the FPS throughput).
But anyways, here is the cia: https://puu.sh/B14xg/aa5e052045.cia
I don't give support related to HzRec because it's supposed to be a secret and abandoned project due to its bad performance. Take the file as-is. Who knows, it could damage your SDCard, idk. I'm just making very unlikely things up to try to emphasize how dev-only the state of this program is.
The above cia WILL overwrite the streaming HzMod on purpose, so don't get surprised.
The behavior is similar to HzMod's, except this recods to SD instead of via internet. Most of the code is the exact same, except I removed the networking code. I could probably optimize this more due to the space freed up due to the lack of networking code but eh. Unless I hear positive feedback I won't ever touch this thing again because on old3DS this thing is totally unusable.
I have set a bit weird keycombo which might be a bit hard to press on some 3DS models. It's Y + START + SELECT. Not START + SELECT + Y. You MUST press and hold Y first, then you press START *and* SELECT in any order.
The LED should turn from light blue to green. That means you're recording. If it turns back to light blue that means that a write error has occurred (most likely a full SDCard). If that happens, you're screwed
You can press the same keys to stop the recording.
The recorded files go onto your SDCard at /HzRec_<CPU ticks>.hzr along with a /HzLog.log (which I'd love to have for debugging and analysis reasons). You either need a special program to convert them to videos, or write your own video encoder. I'll provide technical details about this file format at the end of this post.
You can download this tool I wrote to encode the hzr files as video: https://puu.sh/B14YU/8896669f71.zip
Please note however that this tool is only provided for convenience, as-is, without support. This tool unpacks the entire hzr file into your Temp folder, so make sure you have 2x as much free space as the hrz file's size you want to convert. Also watch out if your system drive is an SSD because this tool will write a LOT of data on your system drive, regardless of the hzr file's location.
The provided tool is a commandline tool, so you will need to know how to open a command prompt (hint-hint: it's SHIFT-RIGHTCLICK in an empty space, then "open command prompt here"... don't see it? fuck Windows 10). If you don't want to use the commandline then you can just drag the hzr file onto the exe, but you won't be able to finetune the output video's properties, including quality.
Also, as a sidenote: I noticed that my tool allows to encode in a different file format other than avi by specifying a different extension. You must specify the extension WITHOUT a dot. Also, the extension is optional, it's detected by checking if the first character is a minus sign or not.
Another thing I noticed just before posting is that because these files are not meant to see the public outside of me or the betatesters, the outputted video's first frame has a high chance of containing obscene text, so you might have to cut it off using a video editor.
There is no file magic, just a stream of data, hence if the recording gets interrupted, the most that will happen is that the last frame might be corrupted.
There is not a predefined struct or packet system. I tried my best to make the file format as compact and performance-effective as possible.
Everything starts with the CPU tick counter, which is an unsigned 64bit number. Due to how the CPU tick counter in the Horizon kernel (or the hardware, I don't really know) works, the first bit is always clear, so I packed my own data into that first bit: the control flag.
If the control flag is clear (most of the data will have this clear) then the rest of the "packet" is a data "packet".
You will read an unsigned 32bit number which tells the rotated X position of the image chunk. Then comes the filesize.
If the highest bit is set in the image offset fileld, then it's a proprietary Targa image (there are images with 17bits and 18bits set while compressing, each of them correspond to a 16bit color format of the 3DS (which I can't check now, so bruteforce it somehow)), otherwise it's a JPEG image.
It's recommended to draw w/ overwrite on a canvas framebuffer while decoding the frames due to old3DS not being able to hold a whole frame in RAM.
If the control flag is set, it is a "mode select" event. There are 4 unsigned 32bit integers in this event: top screen LCD mode, top screen framebuffer stride, bottom screen LCD mode (unused), bottom screen framebuffer stride.
LCD modes can be used to fix any compression errors, framebuffer stride can be used to crop the image to proper size.
There is not a predefined struct or packet system. I tried my best to make the file format as compact and performance-effective as possible.
Everything starts with the CPU tick counter, which is an unsigned 64bit number. Due to how the CPU tick counter in the Horizon kernel (or the hardware, I don't really know) works, the first bit is always clear, so I packed my own data into that first bit: the control flag.
If the control flag is clear (most of the data will have this clear) then the rest of the "packet" is a data "packet".
You will read an unsigned 32bit number which tells the rotated X position of the image chunk. Then comes the filesize.
If the highest bit is set in the image offset fileld, then it's a proprietary Targa image (there are images with 17bits and 18bits set while compressing, each of them correspond to a 16bit color format of the 3DS (which I can't check now, so bruteforce it somehow)), otherwise it's a JPEG image.
It's recommended to draw w/ overwrite on a canvas framebuffer while decoding the frames due to old3DS not being able to hold a whole frame in RAM.
If the control flag is set, it is a "mode select" event. There are 4 unsigned 32bit integers in this event: top screen LCD mode, top screen framebuffer stride, bottom screen LCD mode (unused), bottom screen framebuffer stride.
LCD modes can be used to fix any compression errors, framebuffer stride can be used to crop the image to proper size.
If you have ffmpeg and mono then you could run the exe... or at the worst case, wine... or write a Python script to unpack the hzr and then ffmpeg to encode a video from the frames
It mostly depends on your SDCard and what other programs are open and what they are doing. Just... never completely fill up your 3DS's SDCard otherwise bad things will happen.
well its good i have 20 gigs of space left.
--------------------- MERGED ---------------------------
I Installed the cia but nothing happened.
--------------------- MERGED ---------------------------
I Installed the cia but nothing happened.
Good! So yeah I think your system is just a bit slow for recording high quality. Especially if Try looking up guides for better FPS in OBS.
Edit: wrote this yesterday and never posted..
Relax dude. Look into Wine for Mac. You need to remember that the people who are making homebrew are just average joes. Dont get upset that someone hasnt made the perfect solution for you... It may never happen and thats something you need to come to terms with.
Also I just saw you are on a Chromebook. Depending on the model you should try to install Linux on it. You have already voiced that "dont suggest linux it does not work" Can i ask you why you say that?
Last edited by darkloud89,
I don't have the greatest understanding of what's going on here, but I might have a few suggestions:
1. when I set the quality of my obs recording on my old crappy PC to 240p that fixed lag. It didnt make the biggest difference quality wise since the 3ds runs at roughly 240p already. Maybe you haven't tried turning down the quality?
2. I could personally help you install Linux on your Chromebook since I installed it on mine recently, and I have the cheapest Chromebook money can buy.
3. if you want an outrageous and crazy solution that could theoretically work, try letting somebody else remote desktop your computer with a program such as TeamViewer or chrome remote desktop or even Skype or discord. Stream your 3ds to your PC, and have the person on the other end record the stream. It's worth a try.
4. If you have a camcorder or a decent phone, if you play around with the settings, it's almost impossible to tell you recorded it with a camera. Here's a tutorial of a person doing just that:
If you think it would be too hard to play it on a table, you could possibly use input redirection to use a controller, but not sure if that works on a Chromebook.
1. when I set the quality of my obs recording on my old crappy PC to 240p that fixed lag. It didnt make the biggest difference quality wise since the 3ds runs at roughly 240p already. Maybe you haven't tried turning down the quality?
2. I could personally help you install Linux on your Chromebook since I installed it on mine recently, and I have the cheapest Chromebook money can buy.
3. if you want an outrageous and crazy solution that could theoretically work, try letting somebody else remote desktop your computer with a program such as TeamViewer or chrome remote desktop or even Skype or discord. Stream your 3ds to your PC, and have the person on the other end record the stream. It's worth a try.
4. If you have a camcorder or a decent phone, if you play around with the settings, it's almost impossible to tell you recorded it with a camera. Here's a tutorial of a person doing just that:
If you think it would be too hard to play it on a table, you could possibly use input redirection to use a controller, but not sure if that works on a Chromebook.
Last edited by Giodude,
I'm sorry, but Mario Maker is a bit of a heavy game, so HzRec will have a very very bad performance when stuff is going to be loaded (NAND and SD share the same stuff, so reading the NAND could bottleneck writin the recording to the SD, which in turn will decrease the FPS throughput).
But anyways, here is the cia: Link broken
I don't give support related to HzRec because it's supposed to be a secret and abandoned project due to its bad performance. Take the file as-is. Who knows, it could damage your SDCard, idk. I'm just making very unlikely things up to try to emphasize how dev-only the state of this program is.
The above cia WILL overwrite the streaming HzMod on purpose, so don't get surprised.
The behavior is similar to HzMod's, except this recods to SD instead of via internet. Most of the code is the exact same, except I removed the networking code. I could probably optimize this more due to the space freed up due to the lack of networking code but eh. Unless I hear positive feedback I won't ever touch this thing again because on old3DS this thing is totally unusable.
I have set a bit weird keycombo which might be a bit hard to press on some 3DS models. It's Y + START + SELECT. Not START + SELECT + Y. You MUST press and hold Y first, then you press START *and* SELECT in any order.
The LED should turn from light blue to green. That means you're recording. If it turns back to light blue that means that a write error has occurred (most likely a full SDCard). If that happens, you're screwed
You can press the same keys to stop the recording.
The recorded files go onto your SDCard at /HzRec_<CPU ticks>.hzr along with a /HzLog.log (which I'd love to have for debugging and analysis reasons). You either need a special program to convert them to videos, or write your own video encoder. I'll provide technical details about this file format at the end of this post.
You can download this tool I wrote to encode the hzr files as video: Link broken
Please note however that this tool is only provided for convenience, as-is, without support. This tool unpacks the entire hzr file into your Temp folder, so make sure you have 2x as much free space as the hrz file's size you want to convert. Also watch out if your system drive is an SSD because this tool will write a LOT of data on your system drive, regardless of the hzr file's location.
The provided tool is a commandline tool, so you will need to know how to open a command prompt (hint-hint: it's SHIFT-RIGHTCLICK in an empty space, then "open command prompt here"... don't see it? fuck Windows 10). If you don't want to use the commandline then you can just drag the hzr file onto the exe, but you won't be able to finetune the output video's properties, including quality.
Also, as a sidenote: I noticed that my tool allows to encode in a different file format other than avi by specifying a different extension. You must specify the extension WITHOUT a dot. Also, the extension is optional, it's detected by checking if the first character is a minus sign or not.
Another thing I noticed just before posting is that because these files are not meant to see the public outside of me or the betatesters, the outputted video's first frame has a high chance of containing obscene text, so you might have to cut it off using a video editor.
There is no file magic, just a stream of data, hence if the recording gets interrupted, the most that will happen is that the last frame might be corrupted.
There is not a predefined struct or packet system. I tried my best to make the file format as compact and performance-effective as possible.
Everything starts with the CPU tick counter, which is an unsigned 64bit number. Due to how the CPU tick counter in the Horizon kernel (or the hardware, I don't really know) works, the first bit is always clear, so I packed my own data into that first bit: the control flag.
If the control flag is clear (most of the data will have this clear) then the rest of the "packet" is a data "packet".
You will read an unsigned 32bit number which tells the rotated X position of the image chunk. Then comes the filesize.
If the highest bit is set in the image offset fileld, then it's a proprietary Targa image (there are images with 17bits and 18bits set while compressing, each of them correspond to a 16bit color format of the 3DS (which I can't check now, so bruteforce it somehow)), otherwise it's a JPEG image.
It's recommended to draw w/ overwrite on a canvas framebuffer while decoding the frames due to old3DS not being able to hold a whole frame in RAM.
If the control flag is set, it is a "mode select" event. There are 4 unsigned 32bit integers in this event: top screen LCD mode, top screen framebuffer stride, bottom screen LCD mode (unused), bottom screen framebuffer stride.
LCD modes can be used to fix any compression errors, framebuffer stride can be used to crop the image to proper size.
I know you said you won't provide any support for these files: But can you please reupload them because the links you provided are broken by now and I'd really like to try this out
I know you said you won't provide any support for these files: But can you please reupload them because the links you provided are broken by now and I'd really like to try this out
Damn, I forgot I actually did this. I'll have to find and test a build of this.
What are you using? Depending on old3DS/new3DS I might be able to include some optimizations present in some newer but unreleased versions.
In my opinion it's one of the most interesting 3ds Mod projects out there.
I'm using a New 3DS XL
you are very talented to make a program like this. i will be using it on a new 3ds xl once its fixed!
Sorry,
I don't want to annoy you, but did you find a working build after all these years?
Similar threads
- No one is chatting at the moment.
-
-
@
Sonic Angel Knight:
Or, I also heard that if you use flash memory, it can act as more "RAM" at least windows tell me when I stick a flash drive into it. -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
K3Nv2:
I can think of the design teams process another joystick and no audio or a joystick and mono audio -
-
-
-
-
-
-
-
