3 ms·
No problem, we are cool. I see your point. I believe there is still a lot of room for improvement in terms of accuracy, clarity and code size. Note that this r
by andreaorru 10y ago
No problem, we are cool. I see your point.
I believe there is still a lot of room for improvement in terms of accuracy, clarity and code size. Note that this repository was more than 3 years old. Maybe this will motivate me to improve it even further.
- rounce 10y agoI think that'd be pretty cool to see. I'd be especially be interested how quickly the returns in size diminish given your starting point. Likewise, how much it'd would have to change architecturally as it gets smaller. Sounds like a slightly more extreme form of the game Shenzen-I/O. While reading through the repo one thing I kept thinking was it would be nice IMO would be decoupling the everything from the GUI so that it was a little 'flatter'. So `main` would call `NES::run()` (or something), and `NES` would leverage GUI. GUI would be just drawing stuff. (In my head at least,) it feels like that way it might be easier to mentally partition things, for those using it as a learning project. As `NES` would be responsible for ownership and interop that GUI is doing now. I'll add it to my todo list and perhaps in god-knows-when I'll fork it and do this if you haven't gotten round to it :) Having said that it's inspired me to finish my first Go project which was a GameBoy emulator. Was started mainly to deep-dive the language, but I think it could be useful in a similar way if cleaned up and documented for folks.