Redkey

This is amazing. I've been on a bit of a J2ME jag lately, and it can be difficult to find working copies of games, and then guess the requirements for running them. There are archives of dozens of copies of the same game, all with nearly identical file names, but each one has been tweaked for a different series of phones. Which file targets which phones? Who knows?!

I loaded your .jar into my emulator and it worked first time. I had also seen this specific game and wanted to play it, but it seemed only to be available in Russian and Chinese.

Thanks for all your hard work. It's really appreciated!

For anyone who's interested in J2ME horror, I also recommend the Silent Hill Orphan series. There are three games that I know of; point-and-click first-person adventures with simple combat. I bought and played them on an actual phone back in the day, but I think they're still good in emulation.

Yes, and you've got to remember to download it as soon as you buy it. I've been stung a couple of times by companies going out of business or inventing rationales for removing "old" things.

I presume that the code was tested for various cases where there was at least one previous password on record, but everyone forgot about new users with no previous passwords. However I'm having trouble imagining what the code could actually be doing.

I can only imagine a dynamically typed language, and a "checkedPasswords" variable being declared but uninitialized, then a loop incrementing that variable for each non-similar password pulled from the records, and finally a check to see if checkedPasswords equals the number of stored previous passwords.

The execution environment could type and initialize the variable by default after the first increment, but in the case of the user having no previous passwords on record that wouldn't happen, and the final equivalency check would be comparing an integer to some internal "NaN" state, thus failing.

I've had a copy for a long time, and I dust it off to try playing it every year or so. My Japanese reading skill is improving very slowly, so each time I make a little more progress before giving up.

It feels super interesting in a surreal, David Lynch/Haruki Murakami/Garage way.

I fixed it, but that is weird. I originally thought it had a double "r", but I looked it up to check and I'd swear that the results spelled it with only one. Now I check again and it's a double "r".

Must be arrabbiata, 'cause it's got quite a burn.

I know it's a really picky take, but I resent the implication that I should want to keep my personal files mixed in at the same level of the file hierarchy as all my applications' random settings, cached data, and temporary garbage. Documents, Music, Videos, Projects, .config, .cache, SelfishAppName, OtherSelfishAppName...

It bothered me when Microsoft started doing it in Win95, and it still bothers me in Linux. Especially when software acts surprised (or occasionally indignant) that I don't keep all my files in those directories. I have lost small bits of my own work over the years by forgetting to back up things that recalcitrant software refused to store anywhere else.

But I am amused that this is the same name that I use at the top of my own storage hierarchy for self-made things.

I used one of the i5 CPUs with HD2500 integrated graphics in my main gaming PC for several years, up until only about 3-4 years ago. The performance was OK for me, but I paired it with a much newer, discrete GPU. Those integrated graphics are really going to hold you back. In games from 2012-2014 (around when those CPUs came out), they average 20-40 fps on lowest settings.

You don't have to use Steam, but it is a very painless way to play games that you own on Steam. I use Lutris for my non-Steam Windows games. It works well on my main gaming PC, but I often have issues with it on my laptops which have older integrated graphics, due to lack of Vulkan support, which Lutris seems to insist upon even when the software can use OpenGL.

Your comment seems to be trying to disagree with me, but I think you wrote almost the same things that I wrote in the comment that you're replying to:

• The Rust book is about much more than just what's in its title (my point being that this also goes for the cited C++ book).
• C++ is a baroque and sometimes unwieldy language.

Initialization in C++ is so simple that somebody wrote a nearly 300-page book on the subject

There's a book about 101 ways to cut potatoes. Perhaps that could be a real mike-drop bit of evidence that we shouldn't be cooking potatoes.

Here's a 249-page book "just" about atomics and locks in Rust. Does a book this large about only one aspect of Rust prove that it's a terrible language? No, because as with the C++ book, if we look at the summary of contents we can see that it actually covers a great deal more, simply with a focus on those topics.

Luckily we don't have to be compete masters of every aspect of a language in order to use it.

Honestly, I think that modern C++ is a very piecemeal language with no clear direction, and it has many issues because of that. But the title and page count of a single book is not a convincing argument of anything.

I'm all for humourous roasts of things, but does anyone really find this funny? Was the author possibly being serious? I don't know. What I do know is that I stopped watching after the first four examples because they were all deliberately incorrect or misleading, but also didn't seem funny to me.

1. Crazy initialization
   That sure is a lot of ways to initialize a variable! Even though some of these variables are quite different and would be initialized differently from each other in many other languages, even only counting the initializations that are functionally equivalent, there are a bunch of abuses of syntax that I've never seen used in the wild.

At this point I had hope that this was meant to be amusing.

2. Printing to the console
   C++ has had a version of C's printf function from the very beginning. That weird stream syntax has some hardcore fans but many people ignore it. I did my CS degree close to 30 years ago, and the only time I used stream syntax was for one lab class exercise in which we had to show that we understood how to use stream syntax.

They still could be going for a comedy roast, I guess.

3. Getting a random number
   Much like the printf statement for number 2 above, C++ had its own version of C's rand function from the start. I've never even heard of the stuff that's being shown in this part of the video.

OK that was virtually the same fake point as the previous one, and still no punchlines in sight.

4. Having to type "static_cast" every time you recast a variable
   Nope, you don't. You're free to ask the compiler to automagically recast your variables to another type without giving any further detail just like you can in C. In fact, they're often called "C-style casts". There are even implicit casts, where you literally don't add anything, and just cross your fingers that the compiler does what you think it should do. It's like a little bit of the thrill of dynamic typing brought into C++! By using the static_cast keyword, you can tell the compiler that you understand that there's a potential issue with this recast, but that you expect that the standard way of handling it will be fine. There are other keywords for more unusual situations; it's not just a random bit of busywork added for no reason.

Many years ago I lived alone in a small apartment, and I used to leave most of my consoles connected and kept them in a big shelving unit with my TV. But now I live in a house with my family and that's not practical.

At the moment I'm in the process of moving the consoles I still use to wide, shallow boxes with fully removable lids. Up until recently I laboriously unpacked and repacked every console when I wanted to use it, carrying armfuls of cables and equipment to wherever in the house I wanted to set it up. But now, I'm buying these boxes and transferring each system across as I use them.

The idea is that I can leave everything attached to the console while it's in storage, and then when I want to use it I can just take the box to whichever room I want to use, remove the lid, connect power and AV, and pull out the controller and go. When I'm done, it's easy to disconnect the cables from the display and power socket, tuck everything back into the box, and put it away. This is almost as easy as leaving systems set up in place, plus it keeps dust and pet hair out of the equipment, which was a constant issue when I lived alone and left them all set up.

You just need to find boxes that are long and wide enough to hold the console with all its cables and peripherals attached without putting undue bending stress on the cables. For older systems you need to be careful of height as well, for joysticks and so you can leave any top-loading flash carts plugged in to save the connectors.