Thanks, great feedback so far.
Although many games have large tiles composed of smaller tiles, this has nothing to do with the graphics hardware, unless you count the NES where palette selection applies to four tiles at once, making 16x16 tiles made of 8x8 tiles a natural design choice.
Figure 16 is wrong, as it lists SNES and Saturn with indexed color depths of 11 and 15. It should be 9 and 11. The so-called 11 bit format on SNES and 15 bit format on Saturn are direct color formats. It probably shouldn't be called "Nintendo SNES" either, since the N stands for Nintendo.
SNES can't rotate or scale sprites.
The 8 FM algorithms supported by the YM2612 aren't supposed to mimic specific instruments, but some are better suited for certain sounds than others. A sound designer typically determines the best algorithm to use by looking at a spectrogram of the instrument he is trying to mimic and through trial and error.
Thanks, will modify accordingly.
The main thing that is wrong with this "thesis" is that most of it isn't about emulation. There are many details about systems for which there are emulators, but apart from the chapter on CPU emulation, there is little about how to actually emulate them.
Since you haven't written an emulator yourself, it might be difficult to write about emulation.
Real thesis or no, most people do boring stuff for their master's thesis (at least around here), such as Django apps for managing cooking recipes. Since I already have to write a long paper on something, might as well be an introduction to emulation.
I've written "toy" emulators before, obviously nothing I have released. My paper/article is supposed to be an article introducing someone to emulation, not necessarily a manual on how to write an emulator. Perhaps I should have mentioned beforehand that it's supposed to be light on details.
There are also many sentences that are awkward or that don't mean anything. Remember, you're not trying to explain to someone over the phone what an emulator is. Every word should mean something, and every sentence should mean what it say
True. The draft is rough and I mean to polish it. The problem with writing stuff is that you develop blind-spots and don't see some things, which is why I decided to post here. Chapter 3 is an example.
- Maintaining sprite, background and texture caches
- Emulating mid-frame effects efficiently
- Save states, movies, determinism and sources of indeterminism
- High resolution graphics, filtering, other graphical enhancements, and the problems they may present
- Things that are hard to emulate
- Avoiding undesirable sound artifacts when the emulator is running fast or slow
- Emulating network interfaces
- Debugger code and data breakpoints
This a great list, thanks again.
Figure 15 is a picture you did not make (I have seen it on Wikipedia before), you should cite the source. Figure 22 should be cited.
I put some public domain pics as placeholders before I can substitute my own. I fully plan to cite sources of things I end up using in the final version.
Figure 20, "sprite size" perhaps should be "max sprite size"?
That's what it was supposed to mean; awkward wording I agree.
Perhaps figure 24 too if that is taken from somewhere.
That's mine.
Once again, thanks for the wonderful feedback so far and taking the time to reply.
