Tiles pixels 2x, 4x (or more) - HD remaking of NES games

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

ccovell
Posts: 1045
Joined: Sun Mar 19, 2006 9:44 pm
Location: Japan
Contact:

Post by ccovell »

tepples wrote:
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:...
A couple of months ago, I played around with a similar concept. Here are a couple examples:

For example, for BGs you have an additional 12 colours available to be used. You could fill them with a preset palette that you choose so all tiles can use the extra colours at any time. However, for re-used tiles (think SMB1 clouds are also bushes), re-touching tiles with preset colours doesn't work when they're used multiple times with different palettes.

Another option is to interpolate the extra 12 colours from each 4-entry NES palette.

ex:
Image

A routine to mix the extra colours from the base 4 shouldn't be too tough...
Also, when the game changes palettes, the relationships between all the colours stays logical:
Image

Just an idea... never mind the gaudy over-colouring of my sprite example.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Tiles pixels 2x, 4x (or more) - HD remaking of NES games

Post by koitsu »

joabfarias wrote:koitsu, I made that image in just a few minutes, and I don't have any experience in pixel art. I am very certain that people who know how to do this (and love the game) would make it look beautiful.
Sorry, I guess my intentions were misunderstood, and that's understandable. So let me explain them:

My point wasn't that your art sucked. My point was that you want to, in a bizarre way, "make existing classic games look different than how they were intended". You aren't talking about making a new game, or some spin-off (and like I said most of those I've seen in the past 20 years have been horrible), you're talking about trying to improve upon something that doesn't need improvement; and I'm intentionally ignoring the technical limitations as well.
joabfarias wrote:I did not understand why you are talking about money. Everything would be made purely by passion, by gamers and for gamers.
Which doesn't give it any more or any less merit.

My point, plain and simple: leave classic video games alone. They do not need to be improved, changed, enhanced, or modified. I don't want my NES games in HD. I want my NES games looking the way they were intended during their creation.

I'm glad people are talking about graphics and how to make things that look neat or better, yadda yadda, it's all interesting but again, leave the existing games alone. Old crotchety men like me have grown very tired of people trying to "enhance" nostalgia; it's no longer nostalgia when you fuck with it. All that happens is said nostalgia gets ruined.
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru »

koitsu, but if you don't want to play HD remake, you can just ignore it, correct? There are people with different opinions, who may enjoy it. It may even be not too bad, actually - check Monkey Island 2 HD remake (it allows to switch between the original and remake with a key at any point, by the way).

The idea to make an emulator that replaces graphics with hi-res and sound with MP3's is old and was proposed many times. I recall it from ~2004, I think. But still no one is really got up to the task, and I think that lack of artists would be a real showstopper. Also, to 'sell' the idea to people you certainly shouldn't use examples like in the first post, it only spoils the idea as it looks inferior to the original.
joabfarias
Posts: 24
Joined: Wed Jun 20, 2012 10:07 am

Post by joabfarias »

Well, koitsu, you made your point. Now, if you excuse us, we will continue our talk. Nothing personal, just a plain case of freedom of thought.

I am trying to make some changes in the source code of Nintendulator. If anyone knows a good C compiler that could correctly recompile the thing, suggestions will be welcome.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Post by thefox »

Shiru wrote:The idea to make an emulator that replaces graphics with hi-res and sound with MP3's is old and was proposed many times. I recall it from ~2004, I think. But still no one is really got up to the task, and I think that lack of artists would be a real showstopper. Also, to 'sell' the idea to people you certainly shouldn't use examples like in the first post, it only spoils the idea as it looks inferior to the original.
Yeah it's another catch-22. Programmers don't want to implement it in emulators until at least one hi-res pack is available, artists don't want to make the hi-res pack unless emulators support it. For this to happen eventually somebody is going to have to take the plunge.

As for what compiler to use to compile Nintendulator, Visual Studio is pretty much the only choice.
User avatar
Disch
Posts: 1848
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch »

I was never a fan of this idea.

It wouldn't look as good as people imagine it. It might work for backgrounds, but the sprites would look horribly out of place mainly because animation restrictions are still there.

Megaman, for example. Even with souped up graphics, his walking animation is only 3 frames. With NES graphics that looks natural. With "HD" graphics it would look absurd.

Link in the original Legend of Zelda has a 2 frame walking animation.
Link in Zelda 3 had what... 8 frames? Can you imagine how ridiculous Zelda 3 link would look if you cut that animation down to 2 frames?

Also a lot of games recycle tile graphics for multiple frames. Final Fantasy, for example, draws its character graphics with a 2x3 arrangement of sprites. However, when walking, only the bottom tiles animate.. the top 4 tiles are the same as the "standing" graphics. Megaman would be another example of this... when walking, not all of his tiles change each frame.

It also breaks effects. If you throw out the NES palette and use true color images, what do you do about palette animations? How do you tell the difference between red koopa shells and green ones?


It also changes the emulation aspect of things. For an emulator to be really accurate, it has to fetch and process chr data at very specific times. To handle "HD" data, you'd basically have to create an entirely separate PPU emulator. And couldn't that also change the behavior of potentially game altering effects like sprite-0 hit?
User avatar
Movax12
Posts: 541
Joined: Sun Jan 02, 2011 11:50 am

Post by Movax12 »

^I think a Lau script overtop of the nes emulation would be able to overcome most, if not all of those limitations, though it would need to be customized to each game. I think any solution would have to be customized to each game anyway though.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit »

Disch wrote:I was never a fan of this idea.

It wouldn't look as good as people imagine it. It might work for backgrounds, but the sprites would look horribly out of place mainly because animation restrictions are still there.

Megaman, for example. Even with souped up graphics, his walking animation is only 3 frames. With NES graphics that looks natural. With "HD" graphics it would look absurd.

Link in the original Legend of Zelda has a 2 frame walking animation.
Link in Zelda 3 had what... 8 frames? Can you imagine how ridiculous Zelda 3 link would look if you cut that animation down to 2 frames?

Also a lot of games recycle tile graphics for multiple frames. Final Fantasy, for example, draws its character graphics with a 2x3 arrangement of sprites. However, when walking, only the bottom tiles animate.. the top 4 tiles are the same as the "standing" graphics. Megaman would be another example of this... when walking, not all of his tiles change each frame.

It also breaks effects. If you throw out the NES palette and use true color images, what do you do about palette animations? How do you tell the difference between red koopa shells and green ones?


It also changes the emulation aspect of things. For an emulator to be really accurate, it has to fetch and process chr data at very specific times. To handle "HD" data, you'd basically have to create an entirely separate PPU emulator. And couldn't that also change the behavior of potentially game altering effects like sprite-0 hit?
You pretty much have to design your new graphics for many different palettes, since palette swaps are a reality. Think of it as replacing NES graphics with SNES-style graphics, then possibly increasing the resolution as well. SNES games used palette swaps too.
Using 16-bit or 24-bit truecolor graphics isn't a great idea at all. I was never suggesting anything like that. Maybe for title screens or something...
I hadn't even thought of different graphics depending on palettes until somebody brought up the clouds and bushes of SMB1. Maybe for specific palettes, they could use different images.

As for the question about sprites being only partially animated, there are two possible approaches to sprite replacement.
You could do a simple tile replacement, where the new tiles are constrained to the size of the old tiles. Then you would need to match the original art style, and work around how the original sprites were animated.
The other approach is to allow replacement "tiles" to be much bigger that the source tile, and can be drawn at an offset location. So you could blank out the parts that animate the wrong way, and make the other sprites bigger so the entire image is covered.
But if you are trying to make new graphics for a classic game, you probably have a lot of respect for the source material, so you are probably more likely to try to emulate how the original game chose to animate its graphics.

The Mega Man walk cycle is downright iconic. Even when it's actually Coach Z doing a hip-hop dance.

As for emulation, you don't have to change anything at all. You still do enough PPU simulation for accurate sprite 0 hits and Zapper emulation using the original character data. Then you have another engine draw the replacement graphics instead of the original graphics.

Oversized replacement background tiles might be a little tricky, since they can be bankswitched in and out of existence while the frame is rendering, and the tiles can also be scrolled around with wavy background effects. But I think there's a good enough way to handle them.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

joabfarias wrote:If the tool to redesign the sprites could be inside the emulator like in NESticle, with the results being show in real time, it would be really good.
No it wouldn't. The editing tools wouldn't be good, so the result would end up looking like your example (which everyone already made clear they didn't like). I'm all for the use of MSPaint for pixel art, but high-resolution sprites are a different thing. To make decent graphics you'll need decent software (Photoshop, Illustrator, etc.), there's no reason to waste time trying to implement drawing tools into an emulator.
Disch wrote:If you throw out the NES palette and use true color images, what do you do about palette animations? How do you tell the difference between red koopa shells and green ones?
Dwedit wrote:I hadn't even thought of different graphics depending on palettes until somebody brought up the clouds and bushes of SMB1. Maybe for specific palettes, they could use different images.
Yeah, I already mentioned that in this thread, but apparently people didn't pay much attention.
Disch wrote:It also changes the emulation aspect of things. For an emulator to be really accurate, it has to fetch and process chr data at very specific times. To handle "HD" data, you'd basically have to create an entirely separate PPU emulator. And couldn't that also change the behavior of potentially game altering effects like sprite-0 hit?
Like Dwedit said, the emulation will remain untouched. As I see it, the HD engine would peek at the emulation state and use palette, pattern, scroll, etc. information to render its image.
joabfarias
Posts: 24
Joined: Wed Jun 20, 2012 10:07 am

Post by joabfarias »

The idea is exactly like this, keep all instructions that are not graphics related untouched.
The games would look 512x480 (or more), but would "feel" like the old 256x240.
It would be impossible, for example, to scroll the screen in just one pixel to the left, since there are not really 512 columns but 256 "sets" of 2 columns.
User avatar
Movax12
Posts: 541
Joined: Sun Jan 02, 2011 11:50 am

Post by Movax12 »

Graphics resolution is not a problem. Many emulators can and usually do run at higher resolution than the NES. This allows some of the filters (ex. hq2x) to work.
joabfarias
Posts: 24
Joined: Wed Jun 20, 2012 10:07 am

Post by joabfarias »

Gilbert wrote:Similar things had been done in a really old arcade game emulator (for DOS) called EmuDX, in which you can replace the graphics and sound clips with new ones. There was also a certain SMS emulator that popped up a few years back in which you can replace its graphics by high resolution ones (read the tutorials; it's similar to what you want to do here).

So all this is possible (provided some people make the tools) but honestly unless the enhanced graphics are really good enough I'll stick to the original. Personally I think a much more worthwhile enhancement to Famicom graphics is to increase the colours (like from 4 colour to 16 colour for each tile; but then games with palette effects would need more attentions) than the resolution.
Just now I could see your links. HISMS is exactly what I had in mind. My point is: the NES community is far greater than the Sega Master System one, so it is more likely to have good pixel artists.
The graphics that are posted as example of Alex Kidd are really bad, but shows well the emulator capabilities.
Screenshots:
http://forums.ngemu.com/showthread.php?t=119198
http://hisms.orgfree.com/tutorial/index.html
LocalH
Posts: 186
Joined: Thu Mar 02, 2006 12:30 pm

Post by LocalH »

At this point, with the complexity, it would almost be "better" to make game-specific emulators that run the original game logic underneath (for 100% accurate gameplay) but use knowledge of the game's engine specifics to generate a display using higher-quality assets (if not well-done 3D models). I'm not talking making 2D games 3D but rather 2.5D.
joabfarias
Posts: 24
Joined: Wed Jun 20, 2012 10:07 am

Post by joabfarias »

LocalH wrote:At this point, with the complexity, it would almost be "better" to make game-specific emulators that run the original game logic underneath (for 100% accurate gameplay) but use knowledge of the game's engine specifics to generate a display using higher-quality assets (if not well-done 3D models). I'm not talking making 2D games 3D but rather 2.5D.
You mean like the graphics in "Operation Ragnagard" (Neo Geo)? That would be possible.

I will start to mess around with the source code of Nintendulator (finally I got a copy of Visual Studio). I plan to write the utility to convert the rom file turning every pixel in four pixels (I will focus on the colors issue later).
Do any of you guys know if it would do any damage if I "deinterlace" the graphics (usually, the first and the second bit come in different planes - http://wiki.nesdev.com/w/index.php/PPU_pattern_tables)? I think it would be easier to work this way.
User avatar
Hamtaro126
Posts: 818
Joined: Thu Jan 19, 2006 5:08 pm

Post by Hamtaro126 »

joabfarias, how about this:

--------------------

$0000-$1FFF = (Blank, Unused in enhanced games)
$2000-$2FFF = Nametables
$3000-$3EFF = Unknown

$3F00-$3F1F = Palette #0
$3F20-$3F3F = Palette #1
$3F40-$3F5F = Palette #2
$3F60-$3F7F = Palette #3

$4000-7FFF = Enhanced CHR

Palette Format:

16 for Backgrounds first, then 16 for Sprites = 32 * 4 = 128 colors, You can select out of 64 (or 256) colors depending on what implentation is used

Enhanced CHR only need two transparency areas: $x0, where x is an array of 0-7, the zero at the end of the value is the fixed value used in the transparency value!
AKA SmilyMZX/AtariHacker.
Post Reply