In case this link becomes dead, it's "Scroll Back: The Theory and Practice of Cameras in Side-Scrollers" by Itay Keren on Gamasutra.
I found the article interesting. But it appears to recommend moving pixel art by less than a pixel:
In the Gamasutra article, Itay Keren wrote:
Nowadays, we can design beautiful pixel art, and then move it across the actual pixels that are much finer than the pixel-art. And if you choose to avoid going pixel-perfect, you can even make use of the sub-pixel space as most modern engines offer.
I think subpixel movement of pixel art looks a little inauthentic. Does anyone else?
tepples wrote:
I think subpixel movement of pixel art looks a little inauthentic. Does anyone else?
Like I said before, this happened even during the days of the Atari 2600. Sprites on that system could be scaled, by hardware, to 2x or 4x their width, but they could still be moved by the basic pixel unit. This means that since the dawn of video games, the visual representation of game entities didn't necessarilly have as much resolution as the display. So no, I don't think subpixel movement is unauthentic, unless you're specifically simulating a platform that wouldn't allow it.
tokumaru wrote:
Like I said before, this happened even during the days of the Atari 2600. Sprites on that system could be scaled, by hardware, to 2x or 4x their width, but they could still be moved by the basic pixel unit. This means that since the dawn of video games, the visual representation of game entities didn't necessarilly have as much resolution as the display. So no, I don't think subpixel movement is unauthentic, unless you're specifically simulating a platform that wouldn't allow it.
Most third- and fourth-generation consoles don't support that sort of sprite enlarging. It's glitchy on the Master System and not present at all on NES, TurboGrafx-16, Genesis, or Super NES. Neo Geo has only shrinking, not enlarging. Super NES has the mode 7 background, but even its scrolling is quantized to texels, as can be seen when driving at a slight angle in
Super Mario Kart.
tepples wrote:
Most third- and fourth-generation consoles don't support that sort of sprite enlarging.
But you can still scale in software or deliberately draw using pixels that are larger than a hardware pixel (can't think of any exemples right now, but I'm absolutely sure there are some).,
My point is that the amount of blockiness in the characters and backgrounds isn't necessarily tied to the basic display unit, and could very well be the result of a graphical limitation/feature (as is the case of the Atari 2600, Master System and anything using a TMS9918) or a deliberate artistic decision.
In the end, it depends on the look and feel you're going for. If you want to look authentically retro, subpixel scrolling/movement will feel out of place, but if you just like chunky pixels and didn't make any commitment to any constraints in particular, I don't see why not go for the subpixels if the result feels nice.
tepples wrote:
Super NES has the mode 7 background, but even its scrolling is quantized to texels, as can be seen when driving at a slight angle in Super Mario Kart.
Wait, really? (also are you sure that's the hardware and not Mario Kart's engine?) I was under the impression that it had some subpixel accuracy, much like the Sega CD does (amusingly the Sega CD has different precision for start pixel and delta values).
I first learned how to make a mode 7 effect using software rendering in C, and it used subpixel coordinates. The equivalent to mode 7 on the Game Boy Advance also allows subpixel coordinates. So I thought it was SMK's engine until I read that the mode 7 scroll position (horizontal position in $210D, vertical position in $210E) has no subpixel bits.
I guess some of this has something to do with
a rant by Blake Reynolds of Dinofarm Games. There are plenty of cases where pixel art is used out of laziness, and pixels aren't even a consistent size, and sprites are rotated to put blocks of pixels at an angle.
blakereynolds wrote:
Many developers who try to achieve the retro aesthetic overlook how much magnification is going on, resulting in not one, but several different resolutions at once.
To me, sprite magnification is an effect associated with the second generation (Atari 2600, Coleco/MSX, C64). The only examples of sprite magnification I'm aware of using third- or fourth-generation hardware are 1. status bars on Game Gear and PAL or PAL/M SMS games (which
had the magnification bug fixed), 2. 3D-style texture mapping performed on the CPU or GSU, and 3. back images of Red and his monsters in first-generation
Pokémon games on Game Boy Color, which are also scaled on the CPU but not moved much anyway.
The sprites in Virtua Fighter Mini too (since it was a Game Gear only game so the MAG bug was guaranteed to have been fixed).
I thought Mode 7 only had texel-level scrolling too (the runway in Pilotwings seems like an obvious example), until I tried scrolling a 2x-zoomed layer by 3 pixels and it ended up offset by 3 dots. One and a half texels.
I need to look into this more.
rainwarrior wrote:
Following up on the question of why bit reversal.
Wrong thread?
WTF this is really annoying. Why was the collision thread split into a new thread with a name that's so similar to the other topic?
Because the new topic wasn't about collision anymore, and I'm imperfect at creating new titles.
Sik wrote:
The sprites in Virtua Fighter Mini too (since it was a Game Gear only game so the MAG bug was guaranteed to have been fixed).
An SMS version was released in Brazil though, and so was Earthworm Jim. Maybe all PAL-M consoles had the bug fixed too, but that still made it possible for owners of early consoles to import the carts and experience the bug.
tepples wrote:
I guess some of this has something to do with
a rant by Blake Reynolds of Dinofarm Games. There are plenty of cases where pixel art is used out of laziness, and pixels aren't even a consistent size, and sprites are rotated to put blocks of pixels at an angle.
Yeah, that's ridiculous, but every case of that I can think of isn't from serious, well designed games, but joke games put together in a few days without any effort being put into the graphics. Honestly, I believe a game could do this (different pixel sizes, smooth scaling and rotation) and still look good, as long as actual effort was put into the graphics and they were consistent with the atmosphere of the game. It would be its own thing though, not a simulation of graphics from a particular era.
Quote:
To me, sprite magnification is an effect associated with the second generation (Atari 2600, Coleco/MSX, C64).
I had forgotten about the Commodore 64, which made extensive use of half-resolution sprites that could still move in full resolution. There are surely way more examples on that platform than on the Atari 2600, which already has quite a few.
There are several systems (Wonder Boy in the arcade, etc.) that have a resolution 256 pixels across, but seem to allow scrolling in increments of half a pixel.
It bugs me, as it appears to be a cut corner. Someone will have to make(show) a work where it is used thusly that does not suffer for it, I suspect.
Myask wrote:
It bugs me, as it appears to be a cut corner. Someone will have to make(show) a work where it is used thusly that does not suffer for it, I suspect.
Do the Touhou fighting games do that? The pixels in the character sprites are considerably larger than the ones in the backgrounds, and I don't imagine they snap to the coarser grid, but it's hard to get motion (as distinct from animation) slow enough to tell...
Pixel art and "retro" game design are really two separate things. And if you're not trying to be retro, I don't see that pixel art needs to adhere to any particular set of artificial rules as long as the result looks good.
...
But if you
are trying to be retro, that sort of thing seems lazy. EDIT: deleted perfectionist rant.
Myask wrote:
It bugs me, as it appears to be a cut corner. Someone will have to make(show) a work where it is used thusly that does not suffer for it, I suspect.
Both
Hotline Miami games feature both subpixel movement and gratuitous rotation, but the games are also so heavily stylized (in completely separate ways from the pixelated look) that it doesn't really seem out of place when you're in the middle of it.
Or maybe that's just my inner fanboy talking, but I can't think of any other games that have such well-done aesthetics in spite of violating the rules of "authentic" pixel art.
Relevant to this thread
https://www.youtube.com/watch?feature=p ... 0wxo#t=155Nice way to use scaling =P
Also this reminds me of how the C64 can mix both low resolution 4×8 tiles (with 4 colors) and high resolution 8×8 tiles (with 2 colors). Sprites are similar (you can have both types simultaneously too).
Revenant wrote:
Both Hotline Miami games feature both subpixel movement and gratuitous rotation
The pixels are also quite a lot larger than the display pixels.
Hotline Miami does look good.
C64-notions, well, you've still got the underlying half-size display grid, so it doesn't look too out of place (the seagulls look a little odd, I'll admit, but it doesn't seem to clash. Also, they were on CRTs...)
A few seconds of watching Hotline Miami on YouTube gives me the impression that while the pixel art is there to help provide a "retro" feel, it does so in the sense of evoking associations with a certain time period (as do other design elements such as the phone graphic) rather than in the sense of trying to emulate the limitations of older hardware at a whole-game level. Accordingly I think modern elements such as subpixel motion are perfectly legitimate artistic choices.
If you're attempting to make a game that looks like it was made on older hardware, though, I tend to think you should stick as closely as you can to the limitations of a specific machine, ideally developing on actual hardware. I realize others don't take quite as hard a line on this as I do, but in the case of pixel-by-pixel motion (or half-pixel if you're imitating a platform that can do it) it never looked all that bad unless the developer screwed up somewhere, so not bothering with it really does come across as needlessly inauthentic IMO.
...yes, I realize this is mostly just a slightly wordier version of my previous post in this thread. I'll shut up now, until such time as further posting is warranted.
Being a huge fan of Sega's "super scaler" tech (and similar) since it was invented, I've always been fond of games/hardware that defy the pixel grid and go crazy with its sprites and backgrounds. Hotline Miami was a perfect psychedelic loveletter to that aesthetic for me.
But I agree that modern pixel games that just go half-way – like, 3x/4x zoomed pixel assets, no particular zoom/rotation effects but 1x scrolling – make an unintellectual impression and often just looks fake and sloppy.
Superscaler games never defied the pixel grid though =/ Also the appeal of them was making objects out of sprites and have them look 3D-ish (usually this meant multiple sprites for stuff like buildings or walls so perspective worked on them), while that faded out with proper 3D rendering it's definitely something that could be done with modern hardware without even having to resort to pixelart (high resolution sprites with texture filtering, anyone?)
One question: if the thread is about modern platforms, what the hell is it doing in the SNES forum?
I was thinking about asking the same question.
Because it was split from another topic in SNESdev forum. Moved.
Optiroc wrote:
Being a huge fan of Sega's "super scaler" tech (and similar) since it was invented, I've always been fond of games/hardware that defy the pixel grid and go crazy with its sprites and backgrounds.
Ah! Yeah, that's actually a pretty good analogue. Stuff like
Blaster,
Afterburner, or
Space Harrier were full of pixel-size mismatch and sometimes rotation in a way that a lot of modern "pixel" games do. Of course, they probably saw it as a defect of not having enough memory for higher resolution sprites, though, not an aesthetically valid solution. ;P Sik makes a good point that it was purely in the service of 3D rendering.
I think not respecting the pixel grid, either through half-pixel movement or pixels not lining up, looks not just like lazy art, but lazy design sense in general. The only reason I can think of someone being okay with that situation is that they don't know a lot about pixel art and don't have the ability to look at their game and see that something looks screwy. It makes shitty looking pixel art, and contributes to the pile of games that just take low-res graphics and shit all over them that way. Flappy Bird is a particularly popular game that (in my opinion) makes poor use of pixel art.
I am skipping pedantic examples like scaling up sprites, as those produce uneven pixels, but the (admittedly ugly) result still respects the platform's constraints. Pixel art doesn't have to look like a specific platform, but the style is about restrictions of some sort and the pixel grid is probably the only one that is universal across all pixel art.
I would like to congratulate Towerfall: Ascension for having almost all of its in-game graphics respect the pixel grid, yet not feel like the player's movements are restricted as a result.
mikejmoffitt wrote:
Flappy Bird is a particularly popular game that (in my opinion) makes poor use of pixel art.
I think you mean to say
was.
It's still out there on *cough* certain APK archives. Besides,
Splashy Fish has the same problem. The
unofficial NES port of Flappy Bird corrected this.
I'm a bit torn on this issue.
After playing Shovel Knight on 3DS, I was surprised to hear that it doesn't respect the pixel grid (sprites don't line up to the background pixel grid). I really couldn't tell on the small screen. Looking at a video it's quite obvious from how smoothly the sprites move. I can say that generally I prefer authenticity (whatever it means in this case), but don't know how critical I can be about it if I can't even notice that something's off... It's certainly a fair decision to prioritize the smooth movement, and not to apply artificial restrictions to specifically prevent it.
(OT: I was also slightly surprised in Shovel Knight's ending credits to see that they used an actual physics engine (Box2D) for the game. Clarification: I'm not saying that it's somehow more manly to not use one, but my experiences with using "real" physics engines for platforming engines haven't been so great.)
I believe the 3DS version
does account for the pixel grid, but I'm not sure (there was some change regarding this though). The PC version definitely doesn't though.
rainwarrior wrote:
Blaster isn't even rendering sprites, it's just objects made out of multiple flat rectangles =P
Sik wrote:
rainwarrior wrote:
Blaster isn't even rendering sprites, it's just objects made out of multiple flat rectangles =P
Depends which phase of gameplay you're talking about. The asteroid field is clearly sprites, but even the rainbow-road-robots-and-tron-gates things have a very clear grid to them. A row of large pixels and a flat rectangle are the same thing, in practice, and the "flat rectangles" do fit on a grid that's being scaled. (i.e. they really are pixels, the sprite resolution for the enemies in that phase is just REALLY low; the later phases have higher resolution sprites)
OK yeah looking more later there are proper sprites in the second wave. They're prescaled though, so it isn't a good example either =/
I believe you, but how do you know that they are prescaled? I guess it's that they never zoom in very far, because if it is prescaled, it looks pretty smooth.
It doesn't look very smooth to me.
EDIT: OK, looking at it again. OK yeah it's reasonably smooth, but still the steps are very obvious, so it's either prescaled or there's some really low granurality in the scaling.
Sik wrote:
It doesn't look very smooth to me.
EDIT: OK, looking at it again. OK yeah it's reasonably smooth, but still the steps are very obvious, so it's either prescaled or there's some really low granurality in the scaling.
It's probably because I'm watching it on the lowest resolution on a tiny window.
I have considered making a minimal game development framework, where the focus isn't on providing an engine but rather providing a more authentic display. Really my only goal is to make it extremely easy for someone to set up a low internal resolution (like 288x224 or 256x240, etc) and have the framework manage pre-scaling by some integer, then doing aspect ratio-respecting filtered scaling up to the target window or monitor resolution. Images blitted to the internal resolution framebuffer would not use filtering and have their coordinates floored to the nearest integer to prevent pixel transition blur. That way, a developer wishing to make a pixel game may utilize the framework, and doesn't have to think about these things that many developers do not even know to think about.
Filtered scaling? I hope it's not the gaussian blur crap that everybody abuses nowadays.
psycopathicteen wrote:
Filtered scaling? I hope it's not the gaussian blur crap that everybody abuses nowadays.
No, it's prescaled with nearest-neighbor first, then the blurrier linear filtering is used. This preserves pixel edges to an extent while making uneven pixel sizes less of an issue when the target resolution is not a multiple of the original.
Here's a mockup comparison. 256 x 240 --> 800 x 600.
First using linear filtering directly (ugly):
Now with an integer pre-scale value of 2 done first with nearest, then linear scaled to 800x600 (better!):
Sort of reminds me of
fractional bilinear interpolation (FBI), a pixel shader whose output is identical to this technique.
The pixels in your scaled version are a bit too wide. On a 4:3 TV adjusted to spec, an NTSC NES produces pixels that are 8/7 of a scanline's height wide. To preserve shapes, you should pad on the left and right with 12 pixels of the background color, producing a 280x240 pixel picture, before blowing it up to a 4:3 rectangle. For example, you'd blow up 280x240 to 560x480 before blowing it up to fit the screen. (3x, or 840x720, is too big both ways for 800x600.) Then you FBI that up to the 800x600 screen.
Anybody thought of doing RGB subpixel rendering?
Ugh, ugh, ugh, NO, don't even.
1- Subpixel doesn't work well for colored input.
2- Subpixel requires an inordinate number of assumptions about the display you're rendering on.
3- Subpixel makes screenshots useless, because those assumptions from #2 are basically guaranteed to be broken on other viewing outputs.
tepples wrote:
Sort of reminds me of
fractional bilinear interpolation (FBI), a pixel shader whose output is identical to this technique.
The pixels in your scaled version are a bit too wide. On a 4:3 TV adjusted to spec, an NTSC NES produces pixels that are 8/7 of a scanline's height wide. To preserve shapes, you should pad on the left and right with 12 pixels of the background color, producing a 280x240 pixel picture, before blowing it up to a 4:3 rectangle. For example, you'd blow up 280x240 to 560x480 before blowing it up to fit the screen. (3x, or 840x720, is too big both ways for 800x600.) Then you FBI that up to the 800x600 screen.
It was just a lazy approximation where I punched in 800x600. That shader does look like exactly what I'm interested in.
lidnariq wrote:
Ugh, ugh, ugh, NO, don't even.
1- Subpixel doesn't work well for colored input.
2- Subpixel requires an inordinate number of assumptions about the display you're rendering on.
3- Subpixel makes screenshots useless, because those assumptions from #2 are basically guaranteed to be broken on other viewing outputs.
In other words: this is why ClearType sucks (I mean, that's exactly the very thing ClearType attempts so we have an existing example of how it works in practice =P).
And yeah forget about #2. These days each display has a completely different arrangement of the lights, mostly in order to account for the differences in perception between green and red/blue (as well as for reducing the discoloration at different angles in the case of LCD screens).
I just ran across this game for Genesis,
Marko's Magic Football.
Take a look at the layers behind or in front of the action. The tiles have half the normal resolution, it looks like. I think they did this to hint at a depth-of-field out of focus effect. Kind of a neat reason to mix resolutions, (Is it a hardware feature or did they just draw the tiles that way?)
Just drawn like that.
GS Mikami does it as well, using mosaic this time. Scrolling is done as usual which means it looks like "wobble" as you move around. Honestly it's more likely done like that to hide the fact they used the same pattern for the background and the foreground though...
Sik wrote:
GS Mikami does it as well, using mosaic this time. Scrolling is done as usual which means it looks like "wobble" as you move around. Honestly it's more likely done like that to hide the fact they used the same pattern for the background and the foreground though...
Oh, that's interesting! Given that it only does it in the part of the level with the waterfall, and those tiles are used without mosaic elsewhere, I would actually guess that the attempt was to use the shimmering effect of the mosaic aliasing to represent mist from the waterfall. Very odd!
rainwarrior wrote:
I just ran across this game for Genesis,
Marko's Magic Football.
Take a look at the layers behind or in front of the action. The tiles have half the normal resolution, it looks like. I think they did this to hint at a depth-of-field out of focus effect. Kind of a neat reason to mix resolutions, (Is it a hardware feature or did they just draw the tiles that way?)
It's not a direct hardware feature - either the tiles were stored that way (weird choice) or were made that way in software (also weird choice).
can we get a thread where we discuss the sound effect samples in that game
Well, with VRAM, tiles at half resolution like that could take up 1/4 the space if you have a little time to decompress them before the upload to VRAM, so there's a practical benefit on top of the fake "depth of field" idea it might be doing.
I think it looks fine for closer foregrounds and it kind of gives of the "superscaller" vibe, but It looks odd in the background. It's like some weird games where the background actually scrolls faster than the foreground. It freaks me out.