Well my renderer logic outputs to a 32-bit pixel buffer. The engine itself is free of any true input or output logic, so anything can be put ontop of it. I already considered filtered output. All that would need to be done is, at render time, instead of simply memcpying the buffer into surface, you instead read the pixels and do some sort of processing on them.

I've already begun thinking about a way to properly emulate a CRT TV screen. Several things that make CRT TVs "special" from our modern displays:
* Trails - Bright dots bleed into following frames
* Pixel Size - Bright dots tend to be physically larger than smaller dots
* Distortion - most CRTs of the day weren't perfectly sized, and had a slight fisheye effect to them.

I'll deal with this area after the emulator itself is completely done. But as I said, all sound and video output, as well as controller input is generic and can be used by other logic to produce or create the final output.

Quote: I've already begun thinking about a way to properly emulate a CRT TV screen. Several things that make CRT TVs "special" from our modern displays:
* Trails - Bright dots bleed into following frames
* Pixel Size - Bright dots tend to be physically larger than smaller dots
* Distortion - most CRTs of the day weren't perfectly sized, and had a slight fisheye effect to them.

Those CRT effects are relatively minor in comparison to the degradation of the picture quality when the console is connected to an NTSC TV (it's not called Never Twice the Same Colour for nothing [wink]). Here's a NES NTSC video filter that may be of interest.

Amazing link! I have bookmarked this, thanks a million!

I recall that for some or most tile based nes games, a character/wall sprite actually corresponds to multiple smaller sprite tiles.

Would it be easy or hard for the emulator to hide this detail so potential developers only see code that manipulates the fully assembled tile rather than parts, and a correspondingly 'merged/simplified' level map in memory?

I don't recall many nes games with multiple scrolling layers. Is it possible to extract the supposed background tiles from the foreground. I.e., can collision info be supplied? And perhaps provide info if a given tile is player, enemy, collision object, background, text, and etc.?

Could palette look up be hidden? In essence, if the code for your or other emulator can hide these details and present itself as a modern, simple, and straightforward 2D tile engine, many enhancement and cool effects can be considered.

Quote: Original post by essial
Well my renderer logic outputs to a 32-bit pixel buffer. The engine itself is free of any true input or output logic, so anything can be put ontop of it. I already considered filtered output. All that would need to be done is, at render time, instead of simply memcpying the buffer into surface, you instead read the pixels and do some sort of processing on them.

Quote: Original post by rumble
I recall that for some or most tile based nes games, a character/wall sprite actually corresponds to multiple smaller sprite tiles.

Correct, sprites are 8x8 in size. Mario (original) was comprised of a grid of 2 tiles by 4 tiles. Even the backgrounds are 8x8 in size. This is due to the fact that each tile has two 8-byte chunks describing it's value (not counting other influences on color). Each bit of each byte was either the first, or second bit of the color index.

Quote: Original post by rumble
Would it be easy or hard for the emulator to hide this detail so potential developers only see code that manipulates the fully assembled tile rather than parts, and a correspondingly 'merged/simplified' level map in memory?

I'm not quite sure what you are asking here. Each sprite is independent, and there is no true way to say what sprites "go" with each other. And as for the background, it's simply a grid of 8x8 tiles -- again, no way to "know" what goes with what.

Quote: Original post by rumble
I don't recall many nes games with multiple scrolling layers. Is it possible to extract the supposed background tiles from the foreground. I.e., can collision info be supplied? And perhaps provide info if a given tile is player, enemy, collision object, background, text, and etc.?

There is no real foreground and background; nor are there any layers. Quite simply, you have the "Background" (one layer of 8x8 pixel tiles), and you have "sprites". Each sprite has a flag to determines if it is to be drawn over, or under the background. Not sure what you mean by collision info unless you are referring to the sprite #0 hit, which I doubt you are :)

Quote: Original post by rumble
Could palette look up be hidden? In essence, if the code for your or other emulator can hide these details and present itself as a modern, simple, and straightforward 2D tile engine, many enhancement and cool effects can be considered.

Again, not sure where you are going with this. 8-bit processors simply aren't capable of doing very many "cool" things. The neatest effect I can even think of being done would be to mess around with the scroll registers during hblanks to produce wave effects across the screen. Emulators don't hide or show code. They emulate their target hardware as close to how the real hardware does it as possible.

If anyone is interested, I just posted the full source to my 2A03 processor emulator as it stands for now at my blog. If you have anything else to add just reply to comments on the blog, it's time to let this post die and make room for new ones :)