In my last game, I used parallax scrolling as some little visual detail that is rarely used in other games.
For my next game, which is a screen-by-screen-scrolling, top-down game, what visual details could you suggest that I might include?
One thing that I already have in mind is to use the intensify bits:
In three parts of the game, the screen will be overlaid with red, green and blue respectively which will have a plot- or location-based justification.
But I'm thinking of also using other visual tricks that you don't see very often in games.
Do you have any suggestions which techniques I could use?
One of the big points made by Miau=morphcat is: make sure to add sparkly bits. Little extra bits of motion (sparks, coins bouncing, &c) all over the place really help the game feel more alive.
In his specific applications, he means that it's sometimes worth dancing around the sprite overdraw limit.
lidnariq wrote:
Little extra bits of motion (sparks, coins bouncing, &c) all over the place really help the game feel more alive.
That's more artistic stuff.
Extra bits of motion is about loading new tiles and changing the x and y position, i.e. the stuff that you do anyway, only that your graphics and animations look nicer.
But I was talking about technical things.
Like putting the sprite 0 in the middle of the screen and changing the scrolling position mid-frame to do parallax scrolling on a console that only has one background layer.
Or using the rarely-used color bits to overlay the whole screen in blue as some kind of simulated transparency layer.
I assume some Mode 7-like zooming cannot be simulated on the NES. That's why I'm looking for different stuff.
How about sprites that go BEHIND the background. Very few games makes use of this possibility.
Yeah, that might be a possibility.
My other game does this as well when a character jumps into a window.
Is there anything else that's visually a bit impressive (no matter if you actually need to push the hardware limits or if it's a simple implementation like setting a bit of a certain value)?
Background scaling can't be done easily on the NES, with the arguable exception of
Cosmic Epsilon, which uses a separate 1K bank of CHR ROM to store each row of floor texture scaled to each width. But
real-time sprite shrinking to CHR RAM could be doable depending on how many sprites you have, how big they are, and how fast they animate.
Lots of pattern animations.
Quote:
I assume some Mode 7-like zooming cannot be simulated on the NES. That's why I'm looking for different stuff.
Quote:
Background scaling can't be done easily on the NES,
Technically it can be easily done, but only if you're wishing to wait at least one second to have your frame rendered
Maybe you'll find some inspiration in
this thread.
Reserve an area in memory for 2-dimensional parallax animation of a "deeper" background pattern. It's been used in a few shoot 'em ups, but i haven't seen it in a top-down adventure for example.
You could use a similar technique to get more colors out of the graphics:
http://www.aaronbell.com/secret-colours ... modore-64/You'd have to swap tiles and palettes pretty fast though. Don't know enough to know if it's feasible.
Just palette swapping could perhaps be fast enough? And half the toggle rate could perhaps be good enough, if the hue and luminosity gap isn't too wide. Ideally, you'd swap between neighboring colours. EDIT: or between a colour and a gray roughly of the same luminosity to achieve a few washed out colours. A dynamic range in colour saturation is not something you readily see on the nes.
FrankenGraphics wrote:
Just palette swapping could perhaps be fast enough? And half the toggle rate could perhaps be good enough, if the hue and luminosity gap isn't too wide. Ideally, you'd swap between neighboring colours. EDIT: or between a colour and a gray roughly of the same luminosity to achieve a few washed out colours. A dynamic range in colour saturation is not something you readily see on the nes.
I guess I was also hoping to fake more colors per tile by switching tiles rapidly. But, yeah. You are right.
slobu wrote:
You could use a similar technique to get more colors out of the graphics:
http://www.aaronbell.com/secret-colours ... modore-64/You'd have to swap tiles and palettes pretty fast though. Don't know enough to know if it's feasible.
With an authentic NES and an authentic CRT TV, it'll always look like it's flickering. This'd fall under the "only works in emulators" cathegory. The only way to make the flicker close to non-noticeable is to have two close colours (for example on NES just one hue or one luminosity unit apart), but then they're so close and you can just use one of them and don't need to flicker. (Or if you really need something in between use dithering).
Bregalad wrote:
slobu wrote:
You could use a similar technique to get more colors out of the graphics:
http://www.aaronbell.com/secret-colours ... modore-64/You'd have to swap tiles and palettes pretty fast though. Don't know enough to know if it's feasible.
With an authentic NES and an authentic CRT TV, it'll always look like it's flickering. This'd fall under the "only works in emulators" cathegory. The only way to make the flicker close to non-noticeable is to have two close colours (for example on NES just one hue or one luminosity unit apart), but then they're so close and you can just use one of them and don't need to flicker. (Or if you really need something in between use dithering).
Yeah, I made an Atari 2600 game that relied on colors that paired well when switched. You'd definitely have to make a test program and manually eyeball which colors worked on CRT and LCD.
Actually, swapping between neighboring hues in certain parts of the palette should yield better results than others. Swapping between the blues wouldn't matter much (there's plenty and some of them are close enough in hue), but there's interesting shades of yellow and red to be had, as long as the illusion is working at least a little bit.
Flickering between neighboring luminosities for a few miliseconds between fade states could mean smoother(ish) transitions during fadeouts and -ins. Think of it as pulse width modulating duty cycles. 100% (stable colour), 80%, 60%... 0% (next stable colour)
Blargg & Neil Baldwin made
Litewall, which does use flickering between adjacent shades.
Thanks! Didn't know about that project.
All references were down in that topic, here's a
working one. (Litewall 9).
And here's a
youtube video filming a
screen projection.
Flickering looks awful on a real CRT TV, don't bother with it.
Dwedit wrote:
Flickering looks awful on a real CRT TV, don't bother with it.
Seconded.
Screen shake can look pretty good, but not many games ever used it.
FrankenGraphics wrote:
Flickering between neighboring luminosities for a few miliseconds between fade states could mean smoother(ish) transitions during fadeouts and -ins.
Reminds me of
Formula One - Built To Win (U), which flickers between shades of gray to fade its intro text in and out slowly.
tepples wrote:
But
real-time sprite shrinking to CHR RAM could be doable depending on how many sprites you have, how big they are, and how fast they animate.
Thanks. I'll have a look at it.
tokumaru wrote:
Maybe you'll find some inspiration in
this thread.
That link with the 100 gifs never completely works for me. Only a few gifs are shown, the other stuff remains black, even after a long while.
FrankenGraphics wrote:
Reserve an area in memory for 2-dimensional parallax animation of a "deeper" background pattern.
Parallax scrolling was already done in "City Trouble". I don't think it's particularly fitting for my adventure.
DRW wrote:
That link with the 100 gifs never completely works for me. Only a few gifs are shown, the other stuff remains black, even after a long while.
Sounds like what happens when enforcing noscript against imgur.
I don't have noscript installed in Firefox. Also, some of them are visible, but most are not.