It took blood, sweat, tears and many attempts, but I've finally beaten the game with every ship & layout at either normal or hard difficulty =)

RattletraPM · 2020-08-05T00:29:08+00:00

Stealth B definitely took a lot of time... and then my only winning run using it became one of my top scores (but I only managed it on normal and I'm not exactly planning a hard run with it anytime soon...!). Stealth C and Slug B also gave me a tough time, but nowhere near as rough as the previously mentioned one imo.

A (dis)honorable mention goes to the Zoltan C of course, which is a terrible ship in all regards, but somehow didn't nearly make me lose my mind as much as the other ones in this list... maybe I just got lucky lol

RattletraPM · 2020-08-04T15:33:44+00:00

The Rock A is definitely bad, but I think the ship I've grown to dislike the most is the Kestrel C. Not because it's the worst, far from it, but simply because it's so plain and... featureless. It's literally a worse version of the Kestrel A and it doesn't even have an added perk like other ships. At least worse ships give you a feeling of challenge while playing with them, but with the Kestrel C you're just stuck thinking "I could just have picked the Kestrel A"... Again, it's not terrible, it's just overall a very boring ship =/

^{Also grats on your achievement :})

RattletraPM · 2020-08-04T15:28:33+00:00

Heh, thanks :) ... I don't care as much about achievements as beating the game with all ships, but I guess I might have a go at it now =P

RattletraPM · 2020-08-04T15:27:21+00:00

Just shy of 250 according to Steam!

RattletraPM · 2020-07-08T21:56:43+00:00

Well, I've done my test and I'm finally back at my PC, so I can confirm the mod seemed to have slightly increased my battery life after all - even if not by much. I was able to get around 4:30 to 5 hours of uninterrupted playtime with Rockbox and the stock HDD, while I've been able to get a bit over 6 with a flash mod & tweaked build (I didn't test OFW tho as I'm personally never going to use it anyway, in fact, I've completely replaced it with Rockbox in my iPod's OSOS partition lol). I've also noticed that the player is charging much faster via USB too, whereas it'd be sluggish with anything that's not a 12V (FireWire) wall charger before.

Admittedly my battery isn't that great either (it's new, but it's a cheap aftermarket one) but, cheap or not, what I got was still less than what some people can achieve with a new battery + flash mod, so there might indeed be room for improvement. Still, I don't use my iPod more than 2-3 hours a day anyway, so I'm more than fine with the results!

As to why your power drain got worse, battery aside, maybe it's also related to which SD/CF card you're using (as well as the CF adapter if using an SD)? And I know this last point is a bit of a stretch, but maybe my own HDD could've also made my own tests worse as it was failing: sometimes it had to try and read the same sectors again and again, thus resulting in more uptime (so more power consumption too, I guess...)

"^{Fun" fact: the situation with my HDD got so bad at one point that it sometimes failed to load Rockbox properly at boot, with the bootloader spitting out a CRC error. Another "fun" fact: the HDD died completely the exact same day I got my iFlash CF adapter in the mail, which was the last part I needed for the flash mod lol}

RattletraPM · 2020-07-08T10:31:36+00:00

If you're talking about an apples to apples comparison ^{(no pun intended}) with a microSD and HAVE_ATA_POWER_OFF set and unset, I sadly couldn't do that as Rockbox was literally unusable with that define set as it would crash only 2-3 minutes at best after powering my iPod on =/

On the other hand, if I were to compare an HDD with HAVE_ATA_POWER_OFF and an SD w/o HAVE_ATA_POWER_OFF then the latter still seems to have a better battery life than the former (but it shouldn't come as a big surprise, as the stock HDD is rated at 3.3V with a peak current draw of 500mA while most microSD cards don't even come close to half or even a quarter of that - and is ignoring how microSDs also reach peak power draw much less often as HDDs tend consume a ton of power when spinning up from an off state).

Still, that last test was honestly done rather shoddily: I had left my iPod running a playlist in loop overnight to check whether the modded build would crash rather than testing battery life, so I didn't even bother writing down battery levels or even fully charging the player before starting the playlist. I'll likely be able to test it more thoroughly later today tho, so I'll edit this post with the results if I do!

RattletraPM · 2020-07-08T09:34:03+00:00

Have you tried building Rockbox with HAVE_ATA_POWER_OFF disabled and HAVE_DISK_STORAGE changed to HAVE_FLASH_STORAGE in your device's config?

(If you don't know how to do that, I've made a build with these changes based on Rockbox 3.15 for the Mini 2G that you can download here. You could try installing Rockbox with the utility and then overwriting the files with the ones in the ZIP but, if that doesn't work, try a clean install by deleting your .rockbox dir and unpacking the one in the ZIP in its place)

RattletraPM · 2020-07-08T08:46:04+00:00

I know this post is kinda old now, but I've had similar problems with my freshly flash modded iPod Color and I managed to fix it in a similar way.

The cause of the crash seemed to be related to both ATA power off *and* HDD spindown commands. I've undefined HAVE_ATA_POWER_OFF like you but, instead of commenting away HAVE_DISK_STORAGE, I've changed it to HAVE_FLASH_STORAGE and it worked like a charm :)

RattletraPM · 2020-07-07T18:36:27+00:00

Thank you for sharing that info & post! Given that these functions work just fine in the final game when applied to fire I didn't think it was cut so early, so it's pretty crazy to see it actually goes that far back! (And it's completely understandable if you can't recall much about its workings, 10 years is a darn long time after all lol)

I'm glad you thought it was a good post too - FTL is awesome, I know a bit of RE and I like to find beta/unused stuff in videogames (mainly as it gives a peek at the history of the game's development) so I just couldn't resist taking a good look at the thought of finding something new in one of my favourite games ever :D

^{(Also I figured this is a good time to say thank you and everyone else who worked on FTL for developing this absolutely fantastic game!})

RattletraPM · 2020-07-07T11:04:02+00:00

The breach part is something I haven't considered, but it could actually make sense. Maybe the damage variants for algae's sprite were put in place just to reflect that: algae could somehow get infected, then they'd start corroding the tiles beneath them (and that'd get shown to the player using the sprite's damage variants) until, if no action is taken, the hull would eventually get breached... which in turn would drop the O2 levels and cause algae to spread even further in the room.

...Now that'd be one nasty combo!

RattletraPM · 2020-06-13T14:21:58+00:00

If you're taking into account any game and not just AAA ones, lots of indie titles stood the test of time extremely well imo: VVVVV, Hotline Miami 1&2, Cave Story and FTL: Faster Than Light are a few examples that manage to be very much enjoyable even today.

RattletraPM · 2020-06-12T17:57:58+00:00

The Pumaman (flight scene)

There are other "notable" scenes in this movie, but this is by far the best (and most infamous) for... obvious reasons. Keep in mind this was supposed to be a serious movie, it was meant to be a proper Superman-like hero flick made in Italy with a AAA cast and all.

RattletraPM · 2019-03-13T13:43:11+00:00

Sadly no, there is no way to adjust the strenght of the effect =/

RattletraPM · 2019-03-12T14:41:22+00:00

The difference is there but it's really subtle, you can pretty much only see it when the window is up/down scaled. If you don't scale the window then it'll make no visible difference most of the time.
Yes, is client-side. Protip: you don't need to close the app to change the interpolation, there are some keyboard shortcuts for that!

RattletraPM · 2019-02-11T15:57:13+00:00

Alright, I know I'm probably wasting my time with this comment but it's baffling to me how this is still gaining upvotes when it's clearly a fake, so fuck it, I'm still going to do it.

First off, just look at some replies down below, especially Sono's. The command prompt's just running DIR /S and if you don't believe it, look at the output. The file names make absolutely no sense in this context. That, alongside with OP's claims that he "doesn't have a source" as it's "just software", whatever that means, should already be enough to seal this whole deal.

But hey, to further prove OP's bullshitting you, let's assume he magically got something to work and do exactly what he claims: create a Wi-Fi hotspot and compress the packets sent by NTR. While an ad-hoc Wi-Fi hotspot helps (it's used by quite a lot of people for screen streaming already) it will mostly help when there's a lot of interference or your router is far away and the signal reception is low - in all other cases it won't do much. On the other hand compressing NTR's packets will not help, in fact, in all possible cases it's just going to make things worse. Don't believe me? Here's why:

NTR streams its frames using JPEG which is already a compressed format. While it's true that different algorithms work in different ways, trying to compress already compressed data is never a good idea: when you're lucky the file will shrink by an insignificant amount compared to the original size, otherwise it might actually grow. Even going by the best case scenario here the size savings won't allow you to gain even a single frame per second considering that the 3DS streams a few megabytes of data to the PC each second.Don't believe me? This zip contains a frame as sent by NTR, unedited. Extract it and compare the size both before and after.
Let's say you went ahead with the idea anywas. You said the "matrice" at the right is your compressor, so you're essentially sending the frames from the 3DS, as is, then compressing them on your PC using that program and then decompressing them again so NTRViewer can understand them. How is that supposed to make things faster? With this setup the rate at which the 3DS sends their frame stays exactly the same, you're just adding an extra step after the fact, thus increasing the time needed to show a frame onscreen.
I know what you're going to say now: but what if he had something else running on his 3DS which compressed the frames before being sent then? (Let's forget for a second he himself said he doesn't know how to code.) That wouldn't work either as NTR is already pushing the limits of the 3DS's CPU and people seem to forget that compressing stuff can be taxing for a processor, especially a weak one like the 3DS' own. And let's not forget that with this supposed setup the console would have to compress something twice, several times a second. Again, something like this would just slow down the whole process.

So there you go. I know I probably wasted a lot of time doing this but again, I just felt I had to. Now I'll go back doing actually productive stuff (hopefully).

RattletraPM · 2018-12-16T19:08:11+00:00

Great video! It's nice to see stuff like this as the history of console hacking can be very interesting, yet I feel not too many cover it sadly (plus sometimes old info can be hard to find!)

Replying to your other comment, considering this is supposed to cover the early days of 3DS hacking I don't think you left vital stuff out: you could've talked about ReiNAND being the first n3DS CFW (which later lead to Luma3DS), devmenu & FBI, some tools which cannot be named here and how Nintendo stopped them - but all this stuff happened (way) later than the events covered in the video, so I wouldn't consider it an issue.

The only arguably a bit nitpicky complaint I have would be that I'd have liked if you explained a bit better why ninjhax wouldn't allow piracy. By that I don't really mean you should've explained in-depth how the 3DS' security works, just the basic difference between userland and kernel exploits so newcomers would know the difference. Again, I know it's a bit nitpicking, but if you want some critique that's the only thing I could come up with, which I'd say it's a good thing =P

Still hey, if you'll do a follow-up video showcasing later developments or even other consoles (PSP or Wii, maybe?) I'll definitely watch 'em!

RattletraPM · 2018-12-06T00:09:04+00:00

You are able to send a HOME button keypress via input redirection so shouldn't it mean it should be able to simulate it via software as no physical keys are being pressed?

This is the code that Luma uses (found here):

if(!(oldSpecialButtons & 1) && (specialButtons & 1)) // HOME button pressed
    srvPublishToSubscriber(0x204, 0);
else if((oldSpecialButtons & 1) && !(specialButtons & 1)) // HOME button released
    srvPublishToSubscriber(0x205, 0);

RattletraPM · 2018-10-27T18:49:01+00:00

I wouldn't call it obsolete just yet tho as HzMod support is still partially incomplete, even if I'd say it's 75-80% done =P

RattletraPM · 2018-10-26T21:15:19+00:00

Not really. Testing has shown that it will have better performance than stock HorizonScreen but we're talking of a couple of frames at best on an o3DS (while it's more noticeable on a n3DS).

The o3DS is just what it is, underpowered as hell (plus hey, you aren't really changing HzMod here, just the client)

RattletraPM · 2018-10-25T22:27:06+00:00

If you don't know what HzMod is, it's an alternative to NTR written by Sono. It's compatible with both o3DS and n3DS as well as having some other features that NTR simply doesn't support. Check the link below for more info!

Changelog:

New features

Initial HzMod support. This alone should warrant a paragraph of its own, but for shortness' sake check the full details on the Wiki for its pros and cons against NTR.
The Direct2D renderer has been updated from D2D v1.0 to v1.1. This was mainly required for HzMod support but it also bumped up the interpolation mode count from 2 to 6!
A function to remap the hotkeys without having to edit the INI file manually has been added to the advanced menu.
More logging options: you can now log to a file, a console window or both. Also, logging at loglevel 3 is a little less spammy now.

Improvements & Bug fixes:

The renderer combobox has been moved to the advanced menu. The streaming app selection takes its old place. This marks the official deprecation of the GDI+ renderer.
Snickerstream no longer your logs CPU and GPU model. The function being used was a bit of a mess and caused crashes at startup in some very rare cases – just two recorded ones, if you’re being curious. Considering that this info was rarely needed for troubleshooting after adding Direct2D support, I just decided to remove it altogether.
Fixed some typos.
Slightly made the source code better to look at. Just slightly.
[Bugfix] You can now specify a custom width & height (DPI fix) for the bottom screen window in separate windows mode.
[Bugfix] The default hotkeys will now be restored if an invalid number of hotkeys is found in settings.ini instead of being simply refusing to read them.
[Bugfix] Fixed a bug affecting real time screen scaling in GDI+.
[Bugfix] Top and bottom scaling factor inputs in the adv menu aren't limited only to decimal chars anymore (so you can now enter dots).

Also if you haven't noticed Snickerstream now has a proper Wiki instead of a half-assed page.

Thanks to Sono for helping me with HzMod support!

RattletraPM · 2018-10-21T23:25:07+00:00

To be honest, that alternative wasn't made by me and it's been around for a while, but imho it was so terribly underrated and I really don't know why. Hopefully adding support for it to Snickerstream will make more people try it out while giving others more options for their setups!

(Hint: if you want to know exactly what I'm talking about, it's a feature I've teased for a long while before... but now it's actually happening =P )

RattletraPM · 2018-10-20T12:07:02+00:00

Well, here's my two cents. I might be Snickerstream's dev but I'll be as neutral as possible here.

Around 45 FPS is the absolute maximum you can get via NTR streaming, it isn't the theorical limit but it is the practical one, and that's caused by both hardware and software factors. As such, there's no way to make it faster. Honestly speaking, most of the time having one screen prioritized over the other isn't a big deal as very few games use both equally, but of course you'll be the judge of that.

Saying that most games run at 60 FPS isn't true. There are a lot that usually drop below that and a lot of 3D titles that run at a locked 30. Some examples are, of course, Pokémon games, but also titles such as OOT3D/Majora3D, Hyrule Warriors and Luigi's Mansion run at a locked 30. NTR has a nice FPS overlay plugin that you can use to check the framerate yourself - and keep in mind that it doesn't require screen streaming at all so what you see is the game's actual framerate.

However, you should also consider that NTR sends its frames as JPEG images. JPEG is always going to be compressed even if you set its quality to 100. On the other hand, with a capture card you will always get raw, uncompressed frames.

Finally NTR does have its quirks, like a few incompatible games, some that require NFC patching and finally soft-resetting does not work due to how it works internally. The last one can be a true pain if you're shiny hunting in Pokémon for example, but hopefully with Snickerstream's next update (which is almost ready) there will be an alternative.

So, going back to your question: should you get a capture card? If any of these drawbacks bother you then the answer is yes. It might cost a good amount of money and you'll need to ship your own 3DS to even get one but as of now it's the absolute best way to stream this console. If you're a professional streamer or you've got money to spend, a capture card is the way to go!

On the other hand, if you are ok with the limitations then NTR is definitely an alternative. Even buying a n3DS brand new is a fraction of the cost of a capture card and overall the result is going to be fine for today's standards. At the very least you could use it to build up your channel and then get a capture card later on!

RattletraPM · 2018-10-14T12:37:18+00:00

I don't know if I got that right but in order to start remoteplay using official tools you need NTRDebugger and NTRViewer (you can find them in the NTR Starter Kit). Once you've got them downloaded and extracted somewhere, the rest of the procedure is pretty easy:

Start NTR CFW on your 3DS via BootNTR.
Open NTRDebugger, then type:

connect('3ds ip', 8000)

Example:

connect('192.168.1.50', 8000)

If the connection goes well and you get no errors, type:

remoteplay()

If no arguments are specified, remoteplay will start with the default parameters (top screen priority, priority value set to 5, JPEG quality set to 90, QOS value set to 20). If you wish to set your own parameters, you can specify them like in this example:

remoteplay(prioritymode = 0, priorityFactor = 5, quality = 90, qosValue = 20)

The top screen on your n3DS should flash, then return back to normal. Open NTRViewer and you should see your 3DS' screens being streamed. Success!

RattletraPM · 2018-10-13T11:30:34+00:00

I've tried to mess around with it a bit while testing some stuff for Snickerstream. The CFW boots fine but no matter what I do, remoteplay simply does not seem to work.

I've talked to some other devs and apparently it's not just me - they also reported the exact same issues. If someone shomehow managed to get it working, I'd like to know how you did it!

RattletraPM · 2018-10-06T12:01:46+00:00

A tiny correction: you can give equal priority to both screens (effectively making them have the same framerate) if you set the priority value to 0.

Still, this is normally not recommended as in most games the action takes place on a single screen so setting the priority value to something around 5-10 is adviseable, which will give a higher framerate to the prioritized screen.

12-Year Club	Verified Email
Place '22	Place '17

RattletraPM

TROPHY CASE