greatest achievement on limited machines (?)
category: general [glöplog]
Quote:
An Amiga scener might feel that Glenz Vectors are the greatest thing ever, meanwhile, a Speccy scener may suggest that the effect isn't even worthy of the term 'effect.'
I wonder who he could possibly mean :-) (Holy crap, did we really all miss an opportunity to crack a "sup dawg, I put glenz inside your glenz" gag on that thread?)
Leaving aside how you can possibly compare accomplishments on different platforms, from a Speccy perspective it's a bit tricky to pick things out as groundbreaking, because Spectrum hardware behaviour is relatively well-defined and deterministic (no custom chips that go berzerk when you crank up their parameters), so most stuff is really just an evolution of tricks that were known in 1986. The full screen rasters in Shock are probably an all time "classic" effect on the Speccy, but as a hardware hack it's not really doing anything different from the not-full-screen ones that came before it.
I can think of one exception: recently an emulator author worked out how to tame the 'ULA snow' with carefully chosen sequences of instructions, to produce something like hardware scrolling. If that ever makes it into a demo, that would be a definite candidate...
I guess we're more interested in hardware-specific hacks than clever algorithms here, so my personal choices from the Speccy scene would be DigiSID, and the fullscreen border rotator at the end of Rage...
...both of which are brain-melting coding accomplishments in my book, since they have to count instruction timings for the entire time, rather than the usual thing of doing cycle-accurate effects for a while and then stopping to do something else until the next interrupt comes along.
Also, pokemon mini.
Thanks for the big explanation evil. It seems to be more hard and annoying that I thought it would be. Wicked that someone has to change the refresh rate so many times to achieve that.
Actually Evl forgot something, there are two different types of STF machines, the number of added lines when opening the top border differs on these machines, so you actually need to open the bottom border at two different locations.
The fullscreen tech now is quite standardized, but in the good old time one discovered that the tolerance between various machines was very very large, so the trick was to try the routine on a large number of machines to find the "nice spot" that worked well on the various models of ST.
Actually if you take two STF, measure the positions where the fullscreen opening and closing are starting and finishing... then you open them, and exchange some of the components (like the GLUE and the MMU), and you will find out that the tolerances have changed :)
Fun :D
The fullscreen tech now is quite standardized, but in the good old time one discovered that the tolerance between various machines was very very large, so the trick was to try the routine on a large number of machines to find the "nice spot" that worked well on the various models of ST.
Actually if you take two STF, measure the positions where the fullscreen opening and closing are starting and finishing... then you open them, and exchange some of the components (like the GLUE and the MMU), and you will find out that the tolerances have changed :)
Fun :D
i'd like to take 15 seconds of your time to recommend that you all check out vicious sid on the c64. sound through your video chip is pretty much one big achievement.
dunno if this is relevant, but one could mention flat real mode and X mode.
on the pc.
flat real mode and X mode.
I'm voting for Soundemon's 8bit sample playback routine on C64 (as seen here). That one is an astounding engineering feat and it was NEW. In fucking 2008.
(I'm not talking about the sound-coming-out-of-the VIC thing, that one is more like "oh gosh, someone was really stupid enough to try" ;)
(I'm not talking about the sound-coming-out-of-the VIC thing, that one is more like "oh gosh, someone was really stupid enough to try" ;)
hehe, exactly my thought :)
(nufli was also quite an achievement..!)
In most 8 bits, muls, divs etc are not hardcoded in the cpu, but they do 3d or effects with intensive use of such routs. Basically we can consider every 'maths' effect (sqrt, sin if (pre)calculated in the demo) as a hack...
But of course, overscan, hardware zooms, gorgeous pics (yeah, Crest!) or sound are more groundbreaking...
One thing more that is a real nice thing on the ST: Spectrum 512.
This one changes the palette lookup table during a scanline, giving a maximum of 48 different colours per scanline (on a machine that is limited to 16 by hardware). It is raster-beam synchronized and uses up all CPU of the scanlines where the graphics is displayed.
But MAN was this a killer thing when it arrived already back in 1987. Then, to code a paint program around this display tech is to me pure madness. But that russian guy made that as well.
This one changes the palette lookup table during a scanline, giving a maximum of 48 different colours per scanline (on a machine that is limited to 16 by hardware). It is raster-beam synchronized and uses up all CPU of the scanlines where the graphics is displayed.
But MAN was this a killer thing when it arrived already back in 1987. Then, to code a paint program around this display tech is to me pure madness. But that russian guy made that as well.
I agree with anyone who points out that it's not *as much* of an achivement to make an "emulator only" demo.
However it IS an achivement to code a demo which RUNS BETTER with and emulator while STILL being functional on a base machine.
(= Even if you do only get .05 FPS on 020 =)
It is of no detriment to the coders abilities if a demo DOES NOT run on an emulator though.
...but I should not need to tell you all that AGAIN! heh.
However it IS an achivement to code a demo which RUNS BETTER with and emulator while STILL being functional on a base machine.
(= Even if you do only get .05 FPS on 020 =)
It is of no detriment to the coders abilities if a demo DOES NOT run on an emulator though.
Quote:
Emulation = Masturbation to imagination
The Real Thing = Masturbation to fully sick pr0n
Party Setup = Pure SEX!
...but I should not need to tell you all that AGAIN! heh.
evil:
for sure the ST/F overscan, syncscroll stuff was one of the sickest code hacks on limited machines.
also the 4 pixel plasma was a fun idea http://www.pouet.net/prod.php?which=29074 on ST.
or this monochrome overscan http://www.pouet.net/prod.php?which=29701 on ST.
But it was even more funny when AURA documented the FALCON 030 hardware registers by themself. "unofficial Falcon 030 docs" "screenspain" This was the base of nearly all Falcondemos later. :)
for sure the ST/F overscan, syncscroll stuff was one of the sickest code hacks on limited machines.
also the 4 pixel plasma was a fun idea http://www.pouet.net/prod.php?which=29074 on ST.
or this monochrome overscan http://www.pouet.net/prod.php?which=29701 on ST.
But it was even more funny when AURA documented the FALCON 030 hardware registers by themself. "unofficial Falcon 030 docs" "screenspain" This was the base of nearly all Falcondemos later. :)
or that eor fillrout scroller by chaos.
http://www.pouet.net/prod.php?which=750 also is this was platform independent.
http://www.pouet.net/prod.php?which=750 also is this was platform independent.
Oh.. This is a subject close to my heart, I think that stretching limited hardware is THE core concept of what the demoscene is all about!
For me, the C64 is THE place to look for great achievements on limited hardware, i mean still today we have things like 8-bit sample playing and nufli being invented.
I also have to specially mention Crossbow/Crest, I mean the guy has continued to exploit the machine with new tricks for more than two decades. Amazing!
Btw. thanks to evil for that explanation on ST overscan etc. interesting stuff (I need to get me an ST some day)! Sideborder stuff on the C64 is similar, having to have cycle exact code going the entire screen where you want the sideborder open. When you start doing FLI and having moving sprites etc. at the same time, it borders on insanity.
OK, onto other platforms.
An example worth mentioning (probably obscure for many) is Rezurrection/Calodox. When talking about limited hardware, the ZX81 without expansion mem is just about as limited as it gets, and I honestly doubt that someone can do anything better on that hardware (that's why I quickly abandoned that config and went for the 16kb expanded stuff instead! :D)
Well, maybe I have rambled on enough for now!
For me, the C64 is THE place to look for great achievements on limited hardware, i mean still today we have things like 8-bit sample playing and nufli being invented.
I also have to specially mention Crossbow/Crest, I mean the guy has continued to exploit the machine with new tricks for more than two decades. Amazing!
Btw. thanks to evil for that explanation on ST overscan etc. interesting stuff (I need to get me an ST some day)! Sideborder stuff on the C64 is similar, having to have cycle exact code going the entire screen where you want the sideborder open. When you start doing FLI and having moving sprites etc. at the same time, it borders on insanity.
OK, onto other platforms.
An example worth mentioning (probably obscure for many) is Rezurrection/Calodox. When talking about limited hardware, the ZX81 without expansion mem is just about as limited as it gets, and I honestly doubt that someone can do anything better on that hardware (that's why I quickly abandoned that config and went for the 16kb expanded stuff instead! :D)
Well, maybe I have rambled on enough for now!
sdw: bah, 2k is the proper size, not 16k (:
(From what I understand, there aren't any NTSC related issues, though I _seriously_ doubt this. I haven't my machine here to test tho, so I can't prove/disprove.)
(And I'm referring to my first machine, the Timex-Sinclair 1000, which was slightly different from the ZX81 in that it had 2k and ran on NTSC frequencies.)
(From what I understand, there aren't any NTSC related issues, though I _seriously_ doubt this. I haven't my machine here to test tho, so I can't prove/disprove.)
(And I'm referring to my first machine, the Timex-Sinclair 1000, which was slightly different from the ZX81 in that it had 2k and ran on NTSC frequencies.)
Sdw: if you're interested, those 2 demos were amazing technical milestones concerning (among others) fullscreen and syncscroll on ST
http://www.pouet.net/prod.php?which=3242
http://www.pouet.net/prod.php?which=11060
Also these ones:
http://www.pouet.net/prod.php?which=29414
http://www.pouet.net/prod.php?which=11350
http://www.pouet.net/prod.php?which=3242
http://www.pouet.net/prod.php?which=11060
Also these ones:
http://www.pouet.net/prod.php?which=29414
http://www.pouet.net/prod.php?which=11350
New ideas and fx are great (and hard enough to invent) on any platform, especially after all these years the scene has existed. (That's an excuse you can use anyway, hehehe...)
Coding demos without MIPS, MFLOPS and GPUs adds an extra challenge, especially for those not used to talking to the hardware directly. The lack of APIs and layers means you have to spend quite some time developing your own functions or libs. Unless you prefer to use code written by others, that is, if the functions you want exist for that platform.
If on top of that the platform is fixed, you have to find out and work around the limitations by spending further time on experiments and benching. You don't have to, ofc, but other sceners who know its limits can judge the code performance quite accurately... it's a greater danger of being a lame coder (c) 1989 on fixed platforms... hehe
So there's a lot to be said for not coding for limited or fixed platforms ;) and all the more respect to those who still love them and do amazing stuff on them!
And coding just for fun is great, but there's a special magic with demos with a new idea or impressive effect, and on limited platforms you have a greater chance to blow some brainfuses if you have a new idea - on PC and other fast 3D platforms you have to be 'more impressive than modern games' to "impress with code" - unless you have a good idea.
Coding demos without MIPS, MFLOPS and GPUs adds an extra challenge, especially for those not used to talking to the hardware directly. The lack of APIs and layers means you have to spend quite some time developing your own functions or libs. Unless you prefer to use code written by others, that is, if the functions you want exist for that platform.
If on top of that the platform is fixed, you have to find out and work around the limitations by spending further time on experiments and benching. You don't have to, ofc, but other sceners who know its limits can judge the code performance quite accurately... it's a greater danger of being a lame coder (c) 1989 on fixed platforms... hehe
So there's a lot to be said for not coding for limited or fixed platforms ;) and all the more respect to those who still love them and do amazing stuff on them!
And coding just for fun is great, but there's a special magic with demos with a new idea or impressive effect, and on limited platforms you have a greater chance to blow some brainfuses if you have a new idea - on PC and other fast 3D platforms you have to be 'more impressive than modern games' to "impress with code" - unless you have a good idea.
As I suspected noone is talking Amiga.. it seems the machine was not land for big achievement. I wonder why noone tries to strecth the A500.
Ehm, the unexpanded ZX81 has 1K, not 2K of RAM. Lambda 8300, a ZX81 clone, has 2K.