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.

Reading current discussion, it seems more like “You say that it’s impossible to dirty your house, yet nothing’s stopping anyone from dumping out this bucket of mud on your floor, curious!”

Sorry for not being clear; when I said “keep track automatically” I meant dynamic typing. Of course you’re right that “keeping track of your variables” could also be interpreted to refer to static typing.

I started programming in a time when the idea that the computer could keep track of your variable types for you automatically was a fever dream, so it’s wild for me to see some programmers now throwing shade at particular langages for “not implementing proper variable typing functionality”.

It feels like someone saying that low-fat milk producers are too cheap or lazy to put enough fat in their milk.

Fashion really does go in cycles.

Years ago I used to have Lakka on a bootable USB drive to turn an old, low-powered laptop into a dedicated emulation machine.

The specs are hard to read, but I believe the main processor is an AMD A6-1450 APU, designed for tablets and released some time in or after 2013. Not a powerful chip by modern standards, but IMO still useable depending on your expectations. It’s definitely capable of emulating SNES without breaking a sweat. Even PS1 shouldn’t be a problem at native resolution. N64, Saturn, and Dreamcast are probably where you’ll start seeing slowdown in some games, and anything more, like PS2 or GCN, is unlikely to be playable.