Levels & Items Art

I would, however, like to say that I'm not opposed to finding a way to massively expand the palette. As someone pointed out, 2560 colors might not be enough.

This is all kinda beside the point since I'm not even working on my engine at the moment - it's finals time and I'm under a lot of stress. in 2 weeks I'll be done and I'll be fully prepared to change what needs to be changed about my palette.

An interesting note is that originally, I had the tile sets store the palette in them internally, with the ability to draw from an unlimited number of colors. The problem came when I was drawing too many colors.

Like I said, I'm not working right now so I don't feel like going into detail, but remember that what I have thus far is unoptimized. The working copy of my project is mainly used as a testing ground, with tons of sloppy code (hence why I'm pretty embarassed to show it off) so my first planned step was to sit down and completely rewrite everything, cleanly (and partially because I've started using ubuntu instead of windows). So, during this rewrite period, I'll be very open for comments and new ideas.

 

Heh, I had never seen that topic you posted until now (I think), and I will also add that the download link is down.

 

Heh, well the download link was posted in 2006. I don't even have that specific revision anymore - the project has changed drastically since then.

 

I have done some work actually. I will render some stuff out but I have to clean out my computer first, as it over heats then shuts down when max is thinking away! DOH!

 

Something I guess a bunch of people don't realize - my sprite editor will already automatically downscale an image's palette to match what's been set up, and try to match colors as accurately as possible to preserve the image.

An example (remember, these images are from an old version of NMImage, backwhen it was called Hedgehog Image... it's going to be rewritten from scratch)

Lets load Sonic's animation and extract it's palette



Now lets load Sonic 3's title screen, but tell it only to use the palette that's been extracted:



Original Sonic 3 title screen for comparison:



Here's what the last build of Hedgehog Image looked like:



and a development screenshot:



As you can see, the box on the lower right is supposed to be a magnified view of whatever the mouse is over.

I promise I'm a fairly competent programmer, and contrary to certain beliefs, my graphics library already works and 2 years worth of work has already been poured into it. Unlike most of this project, the graphics engine is very, very far along :D

 

Have you thought about putting in the main HD sonic sprite for comparasion? Might be an idea.

 

I actually don't have a windows machine anymore. I used to do development on my laptop, but it's in pieces right now. Luckily, I routinely backed up all my work, so I still have my source code and all my assets. But all I have left in way of development is my linux box, and my old source won't compile on this machine. Hence the total rewrite.

It's for the best, anyways. As I said earlier in this topic, my old source code was a mess. In several, several ways it was inefficient, unoptimized, and very sloppy. I'd intended to rewrite it once I had it working exactly as I envisioned anyways. My image editor was actually built using the graphics engine - I developed them concurrently.

Off the top of my head, an example of how it was sloppy and unoptimized:

The screen in SDL can be directly accessed as an array of characters, with each character representing a pixel. The palette was stored as a vector of 3 integers, representing R,G, and B values. To draw to the screen, I'd check what color I was supposed to draw, copy the 3 colors to a temporarily created variable, convert them into the pixel format that SDL recognizes, then memcopy to the right spot on the screen array. This is extremely sloppy. What I'm going to do instead is store the palette as a linked list of SDL_Colors already formatted to the pixel format, and rather than copying it to a temporary variable, I'll simply memcopy it's address into the screen.

There's a bunch of examples like that in my source. So... going back to your question - I can't do that just yet because my development machine is dead. My engine works, and is up and running, but it needs to be completely rewritten, which won't take nearly as much time as conceptualizing did.

 

From what I understand, and that's very little when it comes to making graphics, for a community to work together and make a common game they have to use a common color pallet. So we don't have a sonic state (for example, running at full speed) with one base blue color, and then another sonic state (such has him standing still) with another base color for blue. It just looks funny when the colors jump, and you will notice it.

That brings me to my next topic, how are we going to, or how do you, standardize the colors you use? Are you going to use pallets? Could we not just sample the color from the game it self?

 

The original genesis displayed resolutions of 320 x 240. For the S2HD project, we are working at four times that resolution. So, 1280 x 960.

 

Er, that was just a sprite sheet I had grabbed. My engine absolutely can handle sprite flipping, so you're correct - we won't need states for every possible direction.

 

I still don't believe we need the resolution that high—three times the resolution would suffice just fine and look better on most monitors.

Doing the material at 4x is a nice idea, though.

 

Really! That big of a change in resolution? That's pretty insane. In that case, I am going to have to revise the size of upscale.

Original: 320px X 240px
Updated: 1920px X 1080px

1920 / 320 = 6
1080 / 240 = 4.5

So everything should be like, 4 and a half times the resolution of the originals . . .

Ok, sweet, thanks for clearing that up!

For those of you who don't know what Sprite Flipping means (Like me, 5 minutes ago Google found me this.) I found this:

Source: NES January 21 Notes


[quote post='192020' date='Apr 30 2008, 08:54 AM']

I still don't believe we need the resolution that high—three times the resolution would suffice just fine and look better on most monitors.

Doing the material at 4x is a nice idea, though.[/quote]

We should be doing material at 4.5 times the resolution of the original, and this should be a set standard across all graphic arts.

Not that I am telling you how to bake your cake, it's just a good idea over all. There would be no issues with why one character is now taller then the other when they were smaller in the original due to one artist interpretation vs another artists interpretation of size. With math there are set rules, and ones that should be adopted by the community at large so that we can better work as a unit. Quality standards should be set not only in size, but also for colors. I know people who work at 4 times the resolution only to down size it when the final work is submitted, this is fine and should be encouraged (as it allows for a higher quality of work), but there final output needs to be of a certain size.

 

I believe we've already discussed resolutions earlier Dygear. It was stated that HD can actually refer to a many number of resolutions, so 4x ought to be more than sufficient. As I understand it, 4x is what everyone has been submitting as their artwork so far.

 

Is this set in stone as a standard or it is simply a defacto standard?
I don't want to start making art, only to have it rejected or needed to be redone due to an issue with it's size. (Not that it would matter as I work with Vectors.)

 

Anyone know where I can get Illustrator? College just ended for the summer, I've got nothing to do, and my cracked version of Illustrator doesn't work. And I'd love to help you guys.

I do have Flash though. Can you do the same shit in Flash? I know it uses vectors over pixels like Illustrator does.

 

Well, I know that vector art is set in stone but I'll have confirmation on the 4x issue for you soon.

 

I await with (a)bated, keystrokes.

 

While I don't know if 4x is officially the final decision yet, but we will not be running it larger than that and scaling downward is easy in principle. Go ahead and do 4x.

Also, we're not aiming to match a specific existing HD resolution. 1280x960 is not an HDTV or VGA standard, but it is the proper aspect ratio of the Genesis so it may be the default res. We may also support other lower resolutions, which likely will change the aspect ratio, but not in a prohibitive way I expect.