Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RBoy: A Gameboy Emulator in Rust

github.com

Post reply on HN
Print view View original

41–50 of 63 posts

Re: RBoy: A Gameboy Emulator in Rust

#41

Post by krageon »

josephg wrote: post #29
Aissen wrote: post #13

I had a quick look at the big match expressions, and this does not look like this project has been through cargo fmt (it would add +2000 lines of code for the whole project). Which is probably a good choice, but as someone who's been looking at this, I wonder if the tradeoffs made in rustfmt are the right ones (note: I have no idea how I would make this better for the general case).

I can’t speak for the author, but personally I hate tools like go fmt, es-prettify and cargo fmt. I’d never use this stuff by choice because they delete the work I do to make my code easier for me to read. For example, I use extra blank lines to separate different parts of a function, or separate groups of functions visually. These sort of tools like to delete vertical white space, which hurts readability. In javascr…

> for what reason?

Perhaps you do not remember reading through 10k lines of PHP source that has been formatted by someone who has entirely different ideas about what good formatting is than almost everyone else on earth (or perhaps you never have!), but if you did remember the advantage of a single formatting standard that is ubiquitous would be very clear.

Re: RBoy: A Gameboy Emulator in Rust

#42

Post by krageon »

childintime wrote: post #36
rhooke wrote: post #30

Earlier quoted context omitted.

I enforce formatters wherever possible after working on codebases with 20+ years of people imposing their own unique opinion on where spaces and braces should go. Worse, arguing about what the spacing should be, and making noisy diffs because people change previous peoples styling. The formatter has no opinion. It follows rules. It doesn't work perfectly everywhere. It works enough. I would argue caring about exact b…

There is no reason why each of us can't have the formatted according to one's taste (=what works best), instead of this "communism". It's just a matter of IDE support that is lacking. The IDE should apply user formatting preferences upon reading in the file, and apply the std formatting while writing it (with the aim of having diffs work well). That would make good use of auto-formatters.

> communism

It's in precisely zero ways like communism and that really doesn't help the clarity of the rest of your post.

Re: RBoy: A Gameboy Emulator in Rust

#43

Post by mywittyname »

ajsnigrutin wrote: post #31
Shish2k wrote: post #12

Earlier quoted context omitted.

A couple of years ago every new Go project was being reported here; before that every new Elixir project was being reported; I don’t know if HN was around in the mid-2000’s but I’m pretty sure if it was, it would be full of every new Ruby on Rails project… these phases have been coming and going for as many years as I’ve been signed up here at least ¯\_(ツ)_/¯

Yep, and everyone still uses all the stoftware written in C/++, and the stuff written in ruby/(and soon go/rust/...) doesn't even run anymore.

Getting old, forgotten C/C++ code running can be a job. It's really a matter of how well written the make files were and if one still has the original tool chain sitting around. C/++ code written for a paid, closed-source compiler can require a lot of changes to get running under something like GCC.

Not sure how Ruby's backwards compatibility is, since I don't use it, but I have to imagine it's like most other scripting languages in that getting the correct major version is all you need.

Re: RBoy: A Gameboy Emulator in Rust

#45

Post by FemmeAndroid »

Aissen wrote: post #13

I had a quick look at the big match expressions, and this does not look like this project has been through cargo fmt (it would add +2000 lines of code for the whole project). Which is probably a good choice, but as someone who's been looking at this, I wonder if the tradeoffs made in rustfmt are the right ones (note: I have no idea how I would make this better for the general case).

For those looking to see an example of the match expressions:

https://github.com/mvdnes/rboy/blob/9f6b3bc47311ba687326bfff...

This process of matching on opcode and doing a marginally different version of the same basic few operations on one of a set of registers is something that is _much_ easier to do when you're able to see all the opcodes and activities in a densely packed set of lines like this.

(The start of the opcodes that I linked are not the best example of this, but they get more regular the further down the file you go. See https://github.com/mvdnes/rboy/blob/9f6b3bc47311ba687326bfff... )

Beyond knowing that they exist, I haven't explored macros in rust, but I'm curious if they could be of help here. But using cargo fmt, and spreading each of those lines into 3-10 lines would be awful, and would definitely lead to me making mistakes and not noticing typos.

Re: RBoy: A Gameboy Emulator in Rust

#46

Post by noobermin »

josephg wrote: post #29
Aissen wrote: post #13

I had a quick look at the big match expressions, and this does not look like this project has been through cargo fmt (it would add +2000 lines of code for the whole project). Which is probably a good choice, but as someone who's been looking at this, I wonder if the tradeoffs made in rustfmt are the right ones (note: I have no idea how I would make this better for the general case).

I can’t speak for the author, but personally I hate tools like go fmt, es-prettify and cargo fmt. I’d never use this stuff by choice because they delete the work I do to make my code easier for me to read. For example, I use extra blank lines to separate different parts of a function, or separate groups of functions visually. These sort of tools like to delete vertical white space, which hurts readability. In javascr…

Disappointed by the downvotes here. While formatters help in most instances, sometimes you should break convention for the sake of emphasis or readability. Anyone here can come up with a good example for themselves. Consistency is the hobgoblin of little minds. Patterns and rules help but no rule should be absolute, judging people's quality of code is like judging people for their dress or their vocabulary. While they are important they are certainly not sufficient for a judge of one's character.

Re: RBoy: A Gameboy Emulator in Rust

#47

Post by stefs »

josephg wrote: post #29
Aissen wrote: post #13

I had a quick look at the big match expressions, and this does not look like this project has been through cargo fmt (it would add +2000 lines of code for the whole project). Which is probably a good choice, but as someone who's been looking at this, I wonder if the tradeoffs made in rustfmt are the right ones (note: I have no idea how I would make this better for the general case).

I can’t speak for the author, but personally I hate tools like go fmt, es-prettify and cargo fmt. I’d never use this stuff by choice because they delete the work I do to make my code easier for me to read. For example, I use extra blank lines to separate different parts of a function, or separate groups of functions visually. These sort of tools like to delete vertical white space, which hurts readability. In javascr…

while i agree with you on some parts (ternary operators for example), i love the autoformatters for two reasons:

1. it makes it just plain easier to read others code. it's hard enough to have to grasp the logic behind everything, if they have wildly different formatting on top of that it gets substantially worse (incidentally, this was given as one of the reasons why go was such a success in the open source world).

2. i've been able to get a couple of archaic linter rules dropped, i.e. the brackets around single statement conditionals.

    // for this reason brackets were mandatory
    if (a == b)
        doSomething();
        doSomethingElse();
now with an auto formatters indentation fixes, this mistake becomes instantly obvious and thus a non-issue.

Re: RBoy: A Gameboy Emulator in Rust

#48

Post by [deleted] »

zozbot234 wrote: post #39
mlang23 wrote: post #3

A rust port for the gameboy, that would have been impressive...

There's some ongoing work on a LLVM whole-program backend for the MOS 6502, which can already compile some Rust code (discussed https://news.ycombinator.com/item?id=28581812 ). If that's successful (it does require lots of new optimization passes to match the effectiveness of hand-written code), it would be quite easy to have a backend for the Z80 as well.

[deleted]

Re: RBoy: A Gameboy Emulator in Rust

#49

Post by paoda »

FemmeAndroid wrote: post #45
Aissen wrote: post #13

I had a quick look at the big match expressions, and this does not look like this project has been through cargo fmt (it would add +2000 lines of code for the whole project). Which is probably a good choice, but as someone who's been looking at this, I wonder if the tradeoffs made in rustfmt are the right ones (note: I have no idea how I would make this better for the general case).

For those looking to see an example of the match expressions: https://github.com/mvdnes/rboy/blob/9f6b3bc47311ba687326bfff... This process of matching on opcode and doing a marginally different version of the same basic few operations on one of a set of registers is something that is _much_ easier to do when you're able to see all the opcodes and activities in a densely packed set of lines like this. (The start of th…

I can't say much about the use of macros, however there are some SM83-specific patterns you can take advantage of if you decode instructions using octals like what I do in my own gameboy emulator here [1]

[1] https://git.musuka.dev/paoda/gb/src/branch/main/src/instruct...

Re: RBoy: A Gameboy Emulator in Rust

#50

Post by jawline »

Aissen wrote: post #13

I had a quick look at the big match expressions, and this does not look like this project has been through cargo fmt (it would add +2000 lines of code for the whole project). Which is probably a good choice, but as someone who's been looking at this, I wonder if the tradeoffs made in rustfmt are the right ones (note: I have no idea how I would make this better for the general case).

I think the core issue here is mainly that a giant match isn't the best way to express opcode tables, and jump tables are just a bit more idiomatic here as in other languages. I've also been working on an emulator for the gameboy in Rust (https://github.com/jawline/Mimic, I wanted to be able to draw gameboy games to the command line) and I think the use of a jump table made it a bunch simpler / easier to refactor (https://github.com/jawline/Mimic/blob/9463b658ebf006b2369d2b...).
Post reply on HN