Super Turrican II
category: general [glöplog]
Does anybody know the game "Super Turrican II" for Super Nintendo Entertainment System? It features some cool effects at the beginning. Can anyone name these effects? And perhaps somebody even knows where to obtain more information on these effects (i.e. tutorials, source codes etc)?
Do you mean the warping Ocean, Factor5 logos? They use some simple tricks. The Ocean logo screen uses mode-7 to rotate the logo; the rest of the tricks are raster (line) scrolling tricks.
Almost all game systems can have their horizontal scroll values changed on each scanline, so that when a sine wave is applied, the graphics wave back and forth. Some systems (like the SNES, PC-Engine, Megadrive, etc) can have their vertical scrolling changed each scanline, just as easily as horizontal scrolling. This can create effects such as stretching/compressing of an image, or water-like wave patterns.
Put them all together and you get what you see in ST2.
Almost all game systems can have their horizontal scroll values changed on each scanline, so that when a sine wave is applied, the graphics wave back and forth. Some systems (like the SNES, PC-Engine, Megadrive, etc) can have their vertical scrolling changed each scanline, just as easily as horizontal scrolling. This can create effects such as stretching/compressing of an image, or water-like wave patterns.
Put them all together and you get what you see in ST2.
Yes, that's what I meant. Thank you for your explanation! On modern PCs using DirectX or OpenGL, this would probably be harder to implement?
BTW, nice site you have there. I like the idea of mixing reality with pictures from video games :)
No, Adok, waving pictures are not hard to implement on modern GPUs. Thanks for asking.
Adok's question was badly founded.
In most cases, it is not a question of how hard it is but a question of whether the parameter space you see immediately gives the effect out to you or not.
Maybe it'll become clearer if I make an analogy between computer/console architectures and musical instruments.
It takes quite some gusto to start playing on a guitar with your teeth. And if an old school platform is like a guitar, a pc platform is like a full-on orchestra.
In most cases, it is not a question of how hard it is but a question of whether the parameter space you see immediately gives the effect out to you or not.
Maybe it'll become clearer if I make an analogy between computer/console architectures and musical instruments.
It takes quite some gusto to start playing on a guitar with your teeth. And if an old school platform is like a guitar, a pc platform is like a full-on orchestra.
I guess Knos has understood me. I mean, I recall myself that colorcycling was a simple thing in a palette-based mode, but as nowadays palettes are not used any more, it is a bit more difficult to achieve the same effect (not much, but still). Nowadays you can't just manipulate some registers but have to implement certain effects the hard way, i.e. in case of colorcycling, change the colours of the pixels.
Adok, that's false: there is several screen modes and you can change the palette if you don't use a true color mode like a bitmap mode. The fact is computers have an history and for compatibility purpose we still have available the old technologies into the new ones, I mean all the old VGA stuff is still available and I'm also sure that new technologies bring old stuff upgraded. The issue today is choice: you've plenty of choice to make: which functions to call, how to explain the system doing this, ... This is more adminstrative work than democoding if you want my point, but however this is interesting and it's actually programmation but you deal less and less with hardware due to numbers of different implementation available (various graphics chipsets, motherboard chipset, ...). This is what make effects not as great as before: we have lost the VBL feeling and the synchro which comes with it. I've hardly seen any demos really well synced on the PC but I'm sure somebody will find a way to get constant fps from start to end resulting in no glitches and no slowdown while not killing the system in the background.
++
++
Hmm,.. depends.
For me it's still harder to do it the hardware way because I'll have to fiddle with hardware registers and stuff, too much to read and sometimes gets incomprehensible because tutors doesn't explain much and you have to figure out by yourself. In my own case I'd be doing (simulating) those raster effects in 5-10 minutes in pure software.
But if someone knows the hardware way well and is too lazy to actually programm software effects, he might stick into tweaking some registers and getting full screen effects without much hassle. I think that's one reason why most people in the CPC scene are doing demos with hardware effects instead of trying something diferrent. Well, on the CPC it's a bit harder than C64 still, you have to time with NOPs your raster effect, it is a hassle too, but when people got used to this kind of coding, maybe it seems to them easier (and more fun) than trying to code a top notch software effect on the CPC.
So, it's purely subjective. I am the pixel pusher and get a bit afraid when I see low level coding sources in a new system I don't know.
SDL has an 8bit mode. Does it use hardware pallete registers or simulates it, I don't know. Now, to fade out, we have to code a per pixel routine that interpolates from the R,G,B values to zero. That must be quite much slower and more code is needed. Well yes, sometimes hardware graphics coding makes life easier..
It's totally subjective.
For me it's still harder to do it the hardware way because I'll have to fiddle with hardware registers and stuff, too much to read and sometimes gets incomprehensible because tutors doesn't explain much and you have to figure out by yourself. In my own case I'd be doing (simulating) those raster effects in 5-10 minutes in pure software.
But if someone knows the hardware way well and is too lazy to actually programm software effects, he might stick into tweaking some registers and getting full screen effects without much hassle. I think that's one reason why most people in the CPC scene are doing demos with hardware effects instead of trying something diferrent. Well, on the CPC it's a bit harder than C64 still, you have to time with NOPs your raster effect, it is a hassle too, but when people got used to this kind of coding, maybe it seems to them easier (and more fun) than trying to code a top notch software effect on the CPC.
So, it's purely subjective. I am the pixel pusher and get a bit afraid when I see low level coding sources in a new system I don't know.
SDL has an 8bit mode. Does it use hardware pallete registers or simulates it, I don't know. Now, to fade out, we have to code a per pixel routine that interpolates from the R,G,B values to zero. That must be quite much slower and more code is needed. Well yes, sometimes hardware graphics coding makes life easier..
It's totally subjective.
Metroid Prime Hunters on Nintendo DS also uses that technique.
Just so you know.
Just so you know.
Quote:
On modern PCs using DirectX or OpenGL, this would probably be harder to implement?
Seeing as I currently have "wobble windows" enabled on my XGL session, I'd have to say no. Wheee! Look at pouet.net wobble! Wobble pouet.net, wobble! See pouet.net wobble!
(A pointless feature.)
I imagine if you got it to shake, all the September might fall down to the bottom, and you could apply a fire effect down there and all the bad threads would burn up. Alternately, they could provide enough heat and power to run the pc itself... thus making it... I need beer and sleep.
@thom: Did you know that they made a portable version of that feature which works with any operating system? They called it booze :-)
@sparcus: That's 2000 BC technology, right there!
Oh, along the lines of what Adok said, I seem to recall someone saying that coding a smooth scroller on a PC is difficult/impossible (probably because monitors are no longer guaranteed to run at 50 Hz or 60 Hz). I've also heard that it's impossible to put loading music into demos, but then again we've all probably seen .the .product.
Putting loading music into demos was possible since Win95 (or any other multitasking OS for that matter), so whoever told you so must have been old and/or retarded ;)
And concerning the smooth scroll stuff.. the 50/60hz dilemma can be solved by simply not caring for pixel-exact scrolling and letting the bilin/aniso filtering do its magic. It IS somewhat impossible tho to convince Windows to really let your mainloop run every frame without doing other "important" stuff. Writing animation code that compensates those small dropouts without making the situation even worse is quite hard, too.
Adok, btw: coding "rasterline-based" image effects with d3d or ogl is no problem at all, since GeForce1 days the GPUs are fast enough that you can simply split a rendertarget into its rasterlines and do weird stuff with every single one of them. We used that in fr-09:Goldrausch with this tv/noise effect. :)
And concerning the smooth scroll stuff.. the 50/60hz dilemma can be solved by simply not caring for pixel-exact scrolling and letting the bilin/aniso filtering do its magic. It IS somewhat impossible tho to convince Windows to really let your mainloop run every frame without doing other "important" stuff. Writing animation code that compensates those small dropouts without making the situation even worse is quite hard, too.
Adok, btw: coding "rasterline-based" image effects with d3d or ogl is no problem at all, since GeForce1 days the GPUs are fast enough that you can simply split a rendertarget into its rasterlines and do weird stuff with every single one of them. We used that in fr-09:Goldrausch with this tv/noise effect. :)
[quote="kb"]And concerning the smooth scroll stuff.. the 50/60hz dilemma can be solved by simply not caring for pixel-exact scrolling and letting the bilin/aniso filtering do its magic[/quote] Is it really that simple? First of all I can't see how aniso will help you. And I doubt that bilin is really powerfull enough to give good results, especially in lower res. When your text scrolls you will always get unsharp, sharp, unsharp, sharp,... as the texels hit and miss pixel centers. You will get a framerate-dependent lowpass filtering.
chock: It's not even a lowpass filter, it's just what it is: sampling. And yes, of course high frequencies aren't reproduced too correctly, and that's exactly why you tell the artist i nquestion to avoid them ;)
kb: A bilinear filter applies a weighting b*x(n)+(1-b)*x(n+1) (in two dimensions), which is a one-zero lowpass (in case 0<b<1) filter. So a bilinear FILTER is what the name suggests, a filter ;-)
The problem is that b changes depending on the distance between pixels and texels which results in different cutoff frequencies. Avoiding high frequencies solves the problem, but I don't know how blurry the text must be to get good results...
The problem is that b changes depending on the distance between pixels and texels which results in different cutoff frequencies. Avoiding high frequencies solves the problem, but I don't know how blurry the text must be to get good results...
chock: you're right about the interpolation being a filter, but you forgot to mention that it doesn't attenuate frequencies below the original nyqvist. All original frequencies remain intact.
What's causing the flickering is the fact that the filter is _not good enough_ and leaves many of the unwanted high frequency content so that after the texture sampler, which is, what the name suggests, a sampler :)) the usual phase errors lead to the cancellation of the original high frequency content.
That aside - where's the need for pixel exact scrolling anyway? What we're talking about is a fundamental limitation in earlier hardware - no subpixel accuracy. Of course everyone in the "good old times" was writing perfect scrolling routines, but that was only because we had no other choice. That's different today, and it's good that way.
What's causing the flickering is the fact that the filter is _not good enough_ and leaves many of the unwanted high frequency content so that after the texture sampler, which is, what the name suggests, a sampler :)) the usual phase errors lead to the cancellation of the original high frequency content.
That aside - where's the need for pixel exact scrolling anyway? What we're talking about is a fundamental limitation in earlier hardware - no subpixel accuracy. Of course everyone in the "good old times" was writing perfect scrolling routines, but that was only because we had no other choice. That's different today, and it's good that way.
Quote:
where's the need for pixel exact scrolling anyway?
I like how you implode here. It makes me feel mature and achieving in real life.
*compares self with smashed tv tube*
No, doesn't compute. Whatever. :)
No, doesn't compute. Whatever. :)
still, we like our high frequencies, sometimes.
Quote:
you're right about the interpolation being a filter, but you forgot to mention that it doesn't attenuate frequencies below the original nyqvist. All original frequencies remain intact
That is not true. Every frequency except 0 is attenuated (even though low frequencies aren't affected very much. Have a look here for a picture of the frequency response of a one-zero http://ccrma.stanford.edu/~jos/filters/img1112.png). And the thing about frequency cancellation is not relevant in the case of scrolling if the texture and the screen have the same resolution. The filter (and its phase shift) will stay constant over the whole frame, depending on subpixel distance. The phase of the filter is actually what you want, it moves the text with subpixel accuracy, but the lowpass filtering is the evil side effect of a bilinear interpolation. What you rather want is an all-pass filter.
Bilinear filtering may be sufficient for 3D subpixel accuracy, but for (text-)scrolling the one-zero is attenuating low frequencies too much (in my opinion). For a decent scroller you might need sinc interpolation or something close to that to look really good.
chock & kb: is there any other easier way (more comprehensible and practical way) to get something synced like it was on ST / Amiga / PC DOS? I mean without any slowdown / jerks / glitches and other Windows favors?
On OS X / Linux I'm sure this can be achieved and why it can't be under Windows?
Are you not enough experienced to disable Windows mess during a demo or is it simply impossible due to Windows' design? But impossible isn't a word demomakers know. And computers are programmable so, I'm sure a king of the system will succeed in getting total control over Windows and then bring back the old feeling of total hardware control we have in the past days. At least the illusion of.
On OS X / Linux I'm sure this can be achieved and why it can't be under Windows?
Are you not enough experienced to disable Windows mess during a demo or is it simply impossible due to Windows' design? But impossible isn't a word demomakers know. And computers are programmable so, I'm sure a king of the system will succeed in getting total control over Windows and then bring back the old feeling of total hardware control we have in the past days. At least the illusion of.