The VG Resource

What I mean is, in SMBX, the sprite sheets themselves are scaled up (along with having the stupidest layout I've ever seen in a sprite sheet) instead of having the program scale them up during rendering. Are you using enlarged sheets or scaling at render time?

From poking around with the idea I got, I can say that I probably won't have to have the sprite sheets scaled up. But the tilesets and panorama would need to be, since there's no way to dynamically change tileset settings (such as the width and height of each tile on the tileset) during runtime, without having to loop through every single tile to change it for each individual instance. Not that big a deal though; the tilesets and panorama would likely be smaller than the spritesheets anyway, in terms of dimensions.

(07-20-2014, 09:52 AM)Midi Wrote: [ -> ]What I mean is, in SMBX, the sprite sheets themselves are scaled up (along with having the stupidest layout I've ever seen in a sprite sheet) instead of having the program scale them up during rendering. Are you using enlarged sheets or scaling at render time?

There are reasons SMBX stores the sprites scaled up, and that's because it supports custom graphics. By storing the sprites at 2x resolution, it allows custom graphics to be at 1x resolution.

Still, it's totally pointless to do this unless that is a factor.

Technically you could make custom graphics, and even music for our games. The sheets and music are all external. Now, I don't intend to SUPPORT custom graphics or music (like having a section on the site that will probably be made down the line, for example), but people would be free to do what they wish to the graphics and music files.

The collision masks and such are stored internally, so if people who do edit the graphics files do something ridiculous, like make a knife super large to take up the whole allotted space in the bounding box given to it in the sprite sheet, it wouldn't make a difference to where collision actually happens. Those who do silly things like that will only hurt theirself in that regard, since the visuals wouldn't match up with the collisions.

So I found a really old backup of World of Chaos DX: Extended (so old, elemental charging wasn't even added!), and began to derp around in it, updating the graphics with my refined hue-shifting technique. Behold, how much control the power of color can REALLY have on your works.

i dunno man, all i see is PURPLE. try desaturating your colors a bit and dont stick to purple too often

also, is it me, or did your new stuff get worse? the older mugshot and star had better aa and the character/enemy sprites has more contrast.

It only seems that way, for the colors, because the old sprites had pillow shading and like 4 shades jumbled into one scene, whereas the new sprites only have a highlight and a single shade. The star tip, I derped on myself.

I've worked out a system as I refined my process, that I noticed helped, as I practiced more in my toonwork. I do the hue-shifting more aggressively on the characters, so that they stand out much more from the background, and give them black outlines (but not 0, 0, 0 black; no color ever gets below 8, 8, 8 ). For the BG, I do it less aggressively, but still enough to be noticeable, so that the BG isn't dull looking, but also not as vibrant as the characters.

Shifting to blue or purple is actually for the 3rd or 4th shades (for colors that allow it to be) of colors that otherwise wouldn't get there right away. For example, yellow. First, yellow shifts to red. From there, it starts to get more bluish-purple with the 3rd and 4th shades. For grays, reds and blues, Purple is pretty much the straight forward path, since green already has so little bearing over what the color result is.

For highlights, it also depends on the color. Nothing ever goes to yellow straight away, unless it's already within that vicinity, like reds and oranges. Grays and purples go towards blue, and then towards green, and then towards yellow, for the respective shade levels.

Now, if there was a palette system in the development tool, I could have the sprite palettes directly updated to have the shades reflect what type of light they're in (like if there's a blue moon, all the colors would change slightly to reflect that). Since there isn't, instead what I'd use is an overlay for the area (basically whatever the flat color of the blue moon is, for instance, drawn over the screen (but under the GUI) at an alpha, so that everything has that effect). Because of this, I keep all the shading in the general shifting rules as mentioned in the first two sections above, so that I can use an overlay, and not have to make a billion sprite sheets for each specific lighting scenario.

I could experiment with shifting to the respective colors for BGs even less aggressively than I already do compared to sprites, but I'm not sure if it'll actually look better, rather than making the BG look duller and less colorful.

EDIT

So I tried the less aggressive shifting on the tiles, but did my usual go-to shifts.

Old vs New

(08-15-2014, 07:04 AM)Koh Wrote: [ -> ]For grays, reds and blues, Purple is pretty much the straight forward path, since green already has so little bearing over what the color result is.

for red, i understand. for blue, i suppose it needs a tint of it. but for gray, you usually stick to blue. a desaturated blue to be exact.

(08-15-2014, 07:04 AM)Koh Wrote: [ -> ]I could experiment with shifting to the respective colors for BGs even less aggressively than I already do compared to sprites, but I'm not sure if it'll actually look better, rather than making the BG look duller and less colorful.

i also get that you want to make backgrounds look good and all, but since this is a cave, i think you should stick to the dark/dull setting for it.

also while it was an improvement, your edit is still pretty purple. i took the liberty to edit the colors myself



the darkest blue on the tiles probably isnt that good, but i think you get the point

Oh, I didn't post the iteration I did after that, to give your suggestions a shot...I was too lost in adding more mechanics to this thing, lol. Don't know why, since the new engine needs to be continued, but I guess I was just testing some concepts I want to implement in that one...like Rare Monsters. Discolored, stronger, faster, more resilient, but 3x the exp and a much higher chance of rare rewards.

Old vs New

Wanted to try something out.

->

Finally redid Koh's midres sprite.


Now I've more space to show things like the bent knees. So I can try doing the better walking animation from this new version. Also, the animations aren't simply flipped, so his battle stance will look different facing left.

the outside AA hurts the lowres sprites making it blocky instead of smooth

Those corner 24,24,24 pixels are actually to be the outline color 8, 8, 8 at 50% alpha transparency. GIFs don't support partially translucent pixels, but it'd essentially look like this:

Since the pixels are transparent instead of a specific shade of gray like Mario and Luigi, they can go over any kind of background, and still give the sprite a bolder outline effect, which is what I want. I may make it 75% transparency; I haven't played with intensity yet, but I know the end-result is what I'm going for.

Why don't people do translucent AA all the time? It seems like it'd always be better option than the traditional way (other than when the artist isn't using it for game-related things.)

To quote DragonDePlatino from PureZC...

Quote:Yup. Anti-aliasing sprites with alpha transparency works just fine on all kinds of backgrounds. If I plop Koh's sprite into an upper layer and shove a checkerboard in the lower layer like so...

It looks nice on any brightness. Really, anti-aliasing like this is encouraged because a lot of modern games use it. The only reason it isn't as widespread is because a lot of game engines can't handle partial alpha-transparency, ZQuest to name one.

Yup, that's exactly what I was going for. Most dev tools allow for this though. Really, all that happens is the pixels are like that in the PNG spritesheet files.

In other news...