|
Grade My Waterbear by Scoopex [web]
[nfo]
|
||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|||||||||||||
|
popularity : 65% |
|||||||||||||
alltime top: #2012 |
|
|||||||||||||
added on the 2016-02-21 03:12:19 by Photon  |
||||||||||||||
popularity helper
comments
Cool roto!
Nice little prod!
Enjoyed it. And my brother got greeted.
what ham said. nice music!
like!
Fine intro
great - keep it up!
Nice stuff
Okish
Good job
Nice one.
Nice and stylish little demo
yes
Music wasn't my cup of chip, but I overall, nice.
Great routine and tune!
Had absolutely nothing to do with this so can safely thumb it up. Nice tune and neat effect, enjoyed it!
Oldskool. No content.
Love the music Notorious!
Technical & nice!
Best demo featuring tardigrades I've ever seen.
I like it photon. Great!
Good tune and nice little intro!
Nice rotozoomer!
Great effect code. noby you can't judge everything against some personal ideal of what demos are. What are you going to do next? Thumb down all the 1989 releases because design hadn't become a concept in demoscene history yet?
4mat: I disagree. I don't have a personal idea of what demos are or should be, but I do have a taste of what kind of demos I like, and I think such personal concerns completely valid to form an opinion on. It's expressed in comments on pouet all the time, such as people voting down say noise demos across the board because it's not their taste. And I think that's fine. The solution is either to possibly compromise and transform the style into something more accessible, or just accept that not everyone is going to like it. I think this one opted for the second option, and that's fine too, but it doesn't mean I have to like it.
To be fair though, I don't hate everything "oldskool". I don't feel like writing elaborate comments all the time, so excuse my bluntness. My concern with this demo mainly is that it's aesthetically barren and poor, and that it lacks content, having only one (and a half?) standard effect (that is of course not entirely trivial to implement on an amiga). I do appreciate the coding effort, but to me that's rarely enough alone.
I have honestly thought about just mass voting down on a bunch of late 80s early 90s demos, just to make a point. However like you said they're from a different era and I agree they should be judged to a different standard, so the only point that would make would be to showcase my pretentiousness. I don't think that applies here though, since this is a current release and I'm not going to use a different standard to judge it.
I hope that clears it and doesn't make me look like a douche.
To be fair though, I don't hate everything "oldskool". I don't feel like writing elaborate comments all the time, so excuse my bluntness. My concern with this demo mainly is that it's aesthetically barren and poor, and that it lacks content, having only one (and a half?) standard effect (that is of course not entirely trivial to implement on an amiga). I do appreciate the coding effort, but to me that's rarely enough alone.
I have honestly thought about just mass voting down on a bunch of late 80s early 90s demos, just to make a point. However like you said they're from a different era and I agree they should be judged to a different standard, so the only point that would make would be to showcase my pretentiousness. I don't think that applies here though, since this is a current release and I'm not going to use a different standard to judge it.
I hope that clears it and doesn't make me look like a douche.
nice
The content here is of technical nature. Full framerate colourful rotozoomer on OCS Amiga.
great stuff photon and notorious!!
Nice little prod :) thumb up for the music especially :)
I somehow fail to see how this is "generations ahead". Sorry folks... doesn't look nice. Sound is okay.
Amazing roto
Can't understand why Amiga productions like that got so many likes (again and again). I think it is real problem for Amiga demoscene.
Highest grade for your spinning tardigrade!
thumb up for supporting TDF with amiga release!
Full of OCS win.
Nice little prod and thanks for the explanation in the nfo.
ha, i recognize that pic!
great rotozoomer! nice little prod :)
Great rotozoomer and great little Swedish Amiga prod for Japan
utter crap.
It's cool if you don't like it, but you're getting predictable, Kimi. How many is it now? (Psst - you missed Blu Sky.)
Why not try to find time to contribute to your first ever prod? Just something. In all these years.
Why not try to find time to contribute to your first ever prod? Just something. In all these years.
Nice small prod is big in Japan.
Nice roto, but I just ... expect more from Photon/ Scoopex.
thumb up for code
another bonny SCX prod
grade! ;)
Decent. :)
Always quality (and a bit of humour) from Photon! I love that choon, too.
ok
like! :)
may be a technical feat. the delivery is rather mundane.
Good, is there any difference with this one from BriteLite : HSDV2 by Damones ?
Yours is a little wider (210 VS 200 hidden by the logo), same height and same chunky size, both in Ham ?
Yours is a little wider (210 VS 200 hidden by the logo), same height and same chunky size, both in Ham ?
Cyg: this one is higher and is copperchunky, whereas mine zooms much closer and is in HAM
Dunno what to say. This is the first and only maximum size, minimum bandwidth truecolor 4x4 OCS chunky mode. No-one will beat those specs, so.
The mode works with any effect, I had a high-precision rotozoomer laying around, so...
I don't use tables. Everything is dynamic including pan, rotation speed, zoom speed, etc. Texture size is limited only by available memory. Zoom method is a choice, enlarged texels didn't occur to me and so it's not made for that.
27x zoom is max on OCS 1MB, full texture resolution. A silly idea :) made it two 320x320 textures instead.
The mode works with any effect, I had a high-precision rotozoomer laying around, so...
I don't use tables. Everything is dynamic including pan, rotation speed, zoom speed, etc. Texture size is limited only by available memory. Zoom method is a choice, enlarged texels didn't occur to me and so it's not made for that.
27x zoom is max on OCS 1MB, full texture resolution. A silly idea :) made it two 320x320 textures instead.
Photon: only maximum size with copperchunky, with HAM you of course get a larger screen if needed ;)
Britelite: HAM eats 50% bandwidth before plotting pixel one, we both know that's why your wider screen looks different.
All I can say is, you've made a dozen chunky modes for OCS alone. Mine is optimal, and you could have coded it.
Of course, I welcome future attempts to prove me wrong, beat me and send fuckings in scrolltext etc :)
All I can say is, you've made a dozen chunky modes for OCS alone. Mine is optimal, and you could have coded it.
Of course, I welcome future attempts to prove me wrong, beat me and send fuckings in scrolltext etc :)
A single effect war breaking out just before revision? Awww yeah!
Photon: fortunately the HAM mode I use only takes the DMA bandwidth of four bitplanes ;)
Which is still respectable, but not near optimal. Mine is. And overhead per chunky pixel decreases with increased vertical resolution, instead of the other way around. I expected you to recognize some of the advantages, but yeah. You don’t have to like my rotozoomer.
Photon: there are advantages and disadvantages in both approaches. and exactly where did I criticize your rotozoomer?
:) name one disadvantage with mine.
here's one: no chance of making it wider using copperchunky :D
Yes, 4xn Copperchunky is now maximized on OCS. But how is that a disadvantage for the rotozoomer that is wider than yours?
Ahh, yes, I was mainly referring to copperchunky vs HAM in general.
Do I really have to release a 208 pixel wide version now? :D
Do I really have to release a 208 pixel wide version now? :D
Quote:
I welcome future attempts to prove me wrong, beat me and send fuckings in scrolltext etc :)
I have a fetish for the fierce competition of the good old days - that guy brags about a great effect, along comes someone who beats him and calls him names and he's suddenly God Almighty etc, I'm very fond of that kind of thing. :)
nice little prod.
overcute chip.
overcute chip.
and noby and kimi_kandler are some stupid assholes
I like the music, but maybe u should use more time on the actual demo. I know its good to release something but this is not very good.
Nice proof of concept. Makes me want to beat it some day. ;)
Nice. The choice of texture made me smile =). And that photon thought britelite criticize him was just lol =D.
Watch it all the way through!
No entertainment to me.
Very weak OK only because of the tech, all the rest could have been much better.
Very weak OK only because of the tech, all the rest could have been much better.
meh... kids in primary school can rotate objects and throw up something on the screen. I'd expect something more from scoopex or let photon retire.
I demand a new Scoopex megademo!
Not much to it, unispiring
Downthumbers apparently didn‘t get the point.. funny
assumption: 4 bpls, texel width 4px
I just grabbed a piece of paper and a pen and sketched down an idea ...counting...counting...counting...oops, the width would be 200px like for "Grade My Waterbear". Could it be that four adjacent sprites in the middle of each line play a key role?
During the night I did some more thinking and figured out a slightly modified variant having a width of 208 or maybe even 216px.
Just some more loose thoughts:
Lets assume a rotozoomer with a texel width of 2px, 4 or 5 bpls and a height of maybe 100px.
Would it be feasible to code a horizontal (= in x direction) copper interlace in order to double the width? That is, the first frame displays the odd texel columns with bitplane information that are separated / interspersed with empty spacer texels at the even positions. And the following frame is then displaying the even texel columns with bitplane information whereas the odd texels are now empty. I guess it stands to reason that this will cause a flickering like for the usual interlace mode. But could this be mitigated and prevented by switching to the next frame and its copperlist and by setting the beam position (writing to $dff02a / $dff02c) to the first line of the next frame as soon as the last rotozoomer-line of the previous frame was displayed? Or is this, like my former boss liked to say, pure bullshit?
I just grabbed a piece of paper and a pen and sketched down an idea ...counting...counting...counting...oops, the width would be 200px like for "Grade My Waterbear". Could it be that four adjacent sprites in the middle of each line play a key role?
During the night I did some more thinking and figured out a slightly modified variant having a width of 208 or maybe even 216px.
Just some more loose thoughts:
Lets assume a rotozoomer with a texel width of 2px, 4 or 5 bpls and a height of maybe 100px.
Would it be feasible to code a horizontal (= in x direction) copper interlace in order to double the width? That is, the first frame displays the odd texel columns with bitplane information that are separated / interspersed with empty spacer texels at the even positions. And the following frame is then displaying the even texel columns with bitplane information whereas the odd texels are now empty. I guess it stands to reason that this will cause a flickering like for the usual interlace mode. But could this be mitigated and prevented by switching to the next frame and its copperlist and by setting the beam position (writing to $dff02a / $dff02c) to the first line of the next frame as soon as the last rotozoomer-line of the previous frame was displayed? Or is this, like my former boss liked to say, pure bullshit?
submit changes
if this prod is a fake, some info is false or the download link is broken,
do not post about it in the comments, it will get lost.
instead, click here !
Here is the Youtube link.