offbyone

What's the point of downloading a game if not to experience it?

"Nobody deserves to get paid for creating the games I enjoy".

I haven't used Zig myself but I think it could have its place. IMO Rust has moved too far away from C to be something many existing users will move to (and using both in the same project is messy), but Zig seems to integrate well enough that it might.

I haven't personally written a NES emulator but I have a friend who did and it seemed like a comparable level of difficulty to the GB. It did sound like emulating the cartridge hardware was harder because games didn't tell you what they used (compared to GB where a cart tells your that info in the header), but I'm guessing you can cover most games by only implementing a small subset of the options anyway.

Lol the funny thing is that this isn't even close to my longest project :P I have one with a first commit close to 10 years ago (and I of course started it a while before the first commit). It's my favorite just for how fun the result is. IMO the best projects tend to be ones you actually like to use when you're done.

That said I also wouldn't put too much stock in that 1 year, I think I worked on it a lot for about a month and then moved onto other things after having trouble with it. I came back about a year later and managed to more or less finish it. It's definitely a long time to devote to a project, but if you stayed focused on it you could do it in a couple months I think.

If you're on Linux then I'm pretty sure the confusing behavior you're seeing is due to the line buffering the kernel does by default. Ctrl+D does not actually mean "send EOF", and it's not the "EOF character", rather it means "complete the current or next stdin read() request immediately". That's a very different thing, and sometimes it means EOF and other times it does not.

In practice what this means is that, if there is no data waiting to be sent on stdin then read() returns zero, and read() returning zero is how getchar() knows an EOF happened. The flow looks like this:

1. Your program calls getchar().
2. getchar() calls read() on stdin and your program blocks waiting for input.
3. The user presses Ctrl+D on the tty, having not typed anything else.
4. The kernel immediately ends the blocked read() call and returns zero bytes read.
5. getchar() sees that it got no bytes from read() and returns EOF.
6. Your program sees that and exits the loop.

However, in practice it doesn't work that cleanly because the tty is normally operating in "cooked" mode, where the kernel sends input to your program line by line, allowing the user to edit a single line before sending it. The way this works is by buffering the stdin contents and sending it when the user hits enter. Going back to Ctrl-D, you can see how this screws things up, leading to the behavior you see:

1. Your program calls getchar().
2. getchar() calls read() on stdin and your program blocks waiting for input.
3. The user types some input, but does not hit enter. This data sits in the kernel's stdin buffer and is not send to your program yet.
4. The user presses Ctrl+D on the tty.
5. The kernel immediately ends the blocked read() call and starts returning the currently buffered stdin input, without waiting for an enter press.
6. getchar() sees that it got a byte from read() and thus returns it.
7. Your program starts getting all the previously buffered bytes and keeps running until getchar() has seen all of them.
8. getchar() calls read() on stdin. There's now no bytes in the buffer so you block waiting for input, the same as before. The previous Ctrl+D was already "used up" to end the previous read() call so it doesn't matter any more.
9. The user types Ctrl+D.
10. Because there is currently no input in the line buffer, read() returns zero. getchar() sees this and returns EOF.

In the above case Ctrl+D doesn't work as expected because of the line buffering. The read() call ended early without waiting as expected, but your program just starts receiving all the buffered input so it doesn't have any idea you pressed Ctrl+D and never gets the read() == 0 EOF condition. Additionally the Ctrl+D is a one-time deal, it ends one read() call early and sends the buffered input. When you call read() again with nothing to send it just blocks and you have to do another Ctrl+D to actually get read() to return zero.

You can see the line buffering behavior if you add a putchar() inside your loop. The putchar() doesn't actually print while you type the characters, it only prints after you hit either enter or Ctrl+D, showing that your program did not receive any of the characters until one of those two actions happened.

Starting with Gameboy might be a bit daunting but if you're reasonably comfortable with C then I don't think it's too bad. If you're not too familiar with the hardware side of it then that might be a challenge, but the advantage with the Gameboy is that there's tons of documentation and tutorials out there which can probably help you work though the details. Really the big thing is to just be ready to do lots of reading XD You need to get a base-level of understanding of the system before you start coding. git says it took me around a year to get it functional and playing most ROMs, but that was with some big breaks in-between.

Also, that's a very good question. For performance, it was never an issue. I started it with a focus on keeping the code clean vs. worry about performance and it turned out fine, I've run it on a cheap 1.6GHz machine and it didn't even reach 25% CPU usage, so IMO I wouldn't worry about it. This also doesn't vary that much ROM to ROM.

For the ROMs I tested, for the most part every ROM tended to uncover something new, but the Gameboy has a pretty nice progression of "easy" to "hard" ROMs if you just sort by the MBC type, and also the BIOS is a pretty good test of basic functionality. Additionally there are a few different test suite ROMs out there that are fantastic, they'll run through every instruction or piece of functionality and check for the correct results, they saved me tons of time.

I totally agree with you that a typical CEO would not put up with this at all, but then I don't think this is a very typical situation :D I would assume she knew what she was getting into. He named himself CTO so it's not like he's no longer involved in the company, and the CEO can't really 'overrule' him on any product decisions or anything else since he's technically also her boss.

Now, if he's smart he will hopefully at least take her opinions/guidance into consideration, but 🤷

He still owns the company so it doesn't matter who the CEO is, he is their boss. If he wants to continue making big business decisions then he still can, and if the CEO doesn't agree he can either fire them or just go over their head.

I few years back I wrote a Gameboy emulator in C, it was definitely one of the most fun projects I've done. The Gameboy is simple enough that you can make an emulator for it without crazy amounts is effort, and the result is very satisfying. A lot of the simpler systems people recommend writing emulators for aren't that interesting IMO simply because after you write it the games you can run aren't that great.

Are we sure on that? I've seen conflicting reports on whether they actually started paying or not (Ex. Engadget article from a week ago says they are). It's not public information so it's hard to verify.

Does Twitter Blue show ads? I guess I assumed if you're paying you don't have to see those, but that would make too much sense 🤦‍♂️