nesdev.com
http://forums.nesdev.com/

Tiles pixels 2x, 4x (or more) - HD remaking of NES games
http://forums.nesdev.com/viewtopic.php?f=21&t=9029
Page 1 of 5

Author:  joabfarias [ Wed Jun 20, 2012 10:49 am ]
Post subject:  Tiles pixels 2x, 4x (or more) - HD remaking of NES games

Hello everyone.
First of all, sorry for my english. This is my first post here, so please be patient with me.
I had an idea recently, and searched the internet for a forum like this one to discuss it.
It is quite simple:
Take a NES rom file, and reproduce it taking every 4 bits (a pixel in NES) making that same nibble (a nibble is a set of 4 bits) appear 16 times intead of just one time. Each pixel now would be a matrix of 4 x 4 pixels.
After this, take an open source emulator and change the code in a way to make it have a screen of 1024 X 960 (four times the original 256 x 240).
Additionally, in every graphic instruction, make the emulator take the tiles from the new rom file (the one with 16x nibbles).
Of course, initially the graphics would look the same. But after some tile editing, we could have graphics like this one, for example:
Image
Instead of looking like this:
Image
Obviouly, there are people out there that could make it look far better, but it is just an example. Using black pixels (or darker colors) to make shades would be beautiful.
The idea is to have fan made HD remakes of old classics, with the help of everyone.
If there are NES limitations that would make it impossible to achieve, please tell me.
I am not a programmer (at least, not an emulator programmer), so if anyone wish to help, it would be awesome.[/img]

Author:  Dwedit [ Wed Jun 20, 2012 11:19 am ]
Post subject: 

This comes up again every once in a while.
Enhancing graphics in a NES emulator wouldn't be all that hard to do, but I don't know of any emulators that actually support it yet.

But one way to accomplish this is to use replacement graphics. Look up the original tile's graphics, and overlay a replacement tile instead. The replacement graphic would not necessarily be constrained to the size of the original tile, it could be a few pixels larger in all directions. And it would not be restricted to the original palette, it could use a larger palette chosen based on which original NES palette it is using. I'd recommend 16 color or 256 color replacement graphics, so you can still do palette-swaps.

Games that do pixel effects on the game's graphics would be a problem, since the tiles wouldn't match anymore, but those are rare.

For background tiles, replacement graphics that are bigger than the original tile would be more of a problem, since you would need to define an order for tiles to be drawn. Maybe make some tiles higher priority than others, and if there's a tie, tiles to the right and tiles below win.

Extra frames of animation? Not likely. For that you need to modify the programming of the original game.

Some masking effects would still need to be done. Super Mario 3 puts low-priority sprites behind tiles so that later sprites get masked off. This would still need to be simulated even with replacement graphics.

Then there's the sprite limit. Normally a nuisance that just gets in the way, makes ugly blinky sprites everywhere. But some games do use the sprite limit for masking effects to hide other sprites in the area, such as Zelda 1 or Gremlins 2. Those can be detected.

Author:  tepples [ Wed Jun 20, 2012 11:25 am ]
Post subject: 

Games that use CHR ROM could do this, but games that use CHR RAM would need to identify each tile through some sort of hash table on 16-byte regions of the pattern table. It would not work for games that dynamically update background tiles, such as Videomation (drawing program), Qix (drawing program with enemies), Hatris (objects in background not aligned to 8x8 grid), 3D Block (likewise unaligned), Shanghai 2 (same), and text boxes in Super Bat Puncher and the Action 53 menu.

But if anyone wants to work on implementing hi-res texture packs, let me know, and I'll whip up a hi-res copy of Thwaite 0.03's CHR ROM for testing.

Author:  joabfarias [ Wed Jun 20, 2012 11:36 am ]
Post subject: 

Do you guys know an open source emulator that would be the easiest to use for this?
I have some knowledge in Visual Basic, Basic, Pascal, C and Java.
If we could get it to work, it would be good to have a modified version of Tilificator to edit the graphics.

Author:  cpow [ Wed Jun 20, 2012 11:52 am ]
Post subject: 

joabfarias wrote:
Do you guys know an open source emulator that would be the easiest to use for this?
I have some knowledge in Visual Basic, Basic, Pascal, C and Java.
If we could get it to work, it would be good to have a modified version of Tilificator to edit the graphics.

Sounds more like you're wanting an emulator with a built in hq2x magnification filter.

Author:  joabfarias [ Wed Jun 20, 2012 11:56 am ]
Post subject: 

cpow wrote:
Sounds more like you're wanting an emulator with a built in hq2x magnification filter.

No, it is not.
The human brain/eye can reconstruct a picture far better than any filter, 2xSAI or HQ3x are just workarounds.
If you can make a filtered image look as good as what I did above, I will shut my mouth.

Author:  cpow [ Wed Jun 20, 2012 12:11 pm ]
Post subject: 

joabfarias wrote:
cpow wrote:
Sounds more like you're wanting an emulator with a built in hq2x magnification filter.

No, it is not.
The human brain/eye can reconstruct a picture far better than any filter, 2xSAI or HQ3x are just workarounds.
If you can make a filtered image look as good as what I did above, I will shut my mouth.

That was kind of my point. I couldn't distinguish the result you're looking for from the h2qx results I linked to. Maybe I'm blind. I'll shut my mouth. :oops:

Author:  joabfarias [ Wed Jun 20, 2012 12:17 pm ]
Post subject: 

cpow wrote:
I'll shut my mouth. :oops:


Sorry if I was uneducated, cpow. It was not my intention.
I believe that better pixel artistis could make the example I made look superb, using shading and other tecniques, even with the NES color limitations.

I will see if I can adjust the code of HalfNes (a java opensource NES emulator) to make what I want.
If any of you believe there are easier ways of doing it, please tell me.

Author:  rainwarrior [ Wed Jun 20, 2012 12:30 pm ]
Post subject: 

Sounds pretty doable for CHR-ROM games. CHR-RAM probably not. Extra colours would be hard to reconcile with palettes, probably best to stick with the original 4-colour versions.

You could probably include the HD CHR file alongside the ROM, like subtitle files for movies. The regular CHR inside the ROM would be used internally, and at render time replace the operation that renders a pixel with an operation that renders 4 pixels. Should hopefully be pretty straightforward.

Why has nobody done this? I suspect most people who want to emulate Megaman are pretty cool with how many pixels he has. Probably some people would be interested in this, but the majority I think just wants it to look like an NES.

Author:  joabfarias [ Wed Jun 20, 2012 12:40 pm ]
Post subject: 

rainwarrior, you are right when you say that some people want it to look like the original NES.
But when the community begins to remake the graphics with REALLY GOOD work (not like the example I made), I am sure that it will be something worth of attention.
Besides, I think that the graphics replacement will take much less CPU power than magnification filters. If this is true, we can start to make the original pixels 6x6 or 8x8 large, and it will bring much more artistic possibilities.

Author:  tepples [ Wed Jun 20, 2012 12:56 pm ]
Post subject: 

rainwarrior wrote:
Sounds pretty doable for CHR-ROM games. CHR-RAM probably not.

Unless you map each distinct 8x8 pixel tile in CHR RAM to a tile in the replacement texture pack. That's what I meant by a hash table. For anything that doesn't generate CHR data at runtime, the hash table method should be nearly as reliable as CHR ROM.

Quote:
Extra colours would be hard to reconcile with palettes, probably best to stick with the original 4-colour versions.

I can think of two ways to work around this. One involves storing a 15-color palette for each possible 3-color palette. Another involves generating a palette like so:

0-3: Old colors
4-7: Black and colors 1-3 mixed 50:50 with black
8-11: White and colors 1-3 mixed 50:50 with white
13-15: Colors 1 and 2, 1 and 3, and 2 and 3 mixed 50:50 (for internal antialiasing)

Should I draw a picture of what such a palette might look like?

Author:  Dwedit [ Wed Jun 20, 2012 1:35 pm ]
Post subject: 

So we'll need a tool which matches original tiles to a sprite sheet image, then a tool to help the user select which image in a sprite sheet corresponds to another image in an enhanced sprite sheet.

Because palettes will not exactly match between CHR data and sprite sheets, do matching by unique colors. You may need to edit a sprite sheet if the author added unnecessary stuff such as outlines.



Or just work with tile dumps. You have the original tile dump, then another enlarged or enhanced version of the tile dump. Correspondence is done entirely by position.
For games that use CHR RAM, savestates can help you get tile data.

Author:  joabfarias [ Wed Jun 20, 2012 1:40 pm ]
Post subject: 

This is starting to get big.
A moment will come when somebody will want to replace Princess Daisy with a bikini babe.

Author:  jayminer [ Wed Jun 20, 2012 2:21 pm ]
Post subject: 

I think this is a really cool idea.

It reminds me of Spec256 - an emulator that together with hacked games could render old ZX Spectrum games in 256 colors. A video of it in action can be seen here: http://www.youtube.com/watch?v=xGN59bA1n3M

Author:  tokumaru [ Wed Jun 20, 2012 3:14 pm ]
Post subject: 

jayminer wrote:
Spec256

I wonder how they managed to tell the game objects apart, since AFAIK the Spectrum only has a single graphics plane (i.e. no hardware sprites).

On the NES, it would be better if the same tiles could be mapped to different upscaled bitmaps depending on their palette, otherwise it would be hard to make good looking high-resolution bushes and clouds in SMB, for example. Enemies that are just palette swaps could benefit from this too, and receive extra details.

Page 1 of 5 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/