|
Water My Grey Beard by Loonies [web] & Struts
[nfo]
|
||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|||||||||||||||
|
popularity : 67% |
|||||||||||||||
alltime top: #1662 |
|
|||||||||||||||
added on the 2023-01-22 21:25:40 by Blueberry  |
||||||||||||||||
popularity helper
comments
hehe
rulez added on the 2023-01-22 21:35:22 by SiR 
This made the compo for me. We've been thinking about this idea as well, but we didnt manage to achieve it yet. GMTA! Thanks!
More colours = Better intro
The funny title alone deserves a big thumbs up but the fact is this is a wonderful 40K in every aspect..
Incredible colorfull quality zoomer of an image looking exactly like Trap of Bonzai! :) (honoustly!) Smooth also! Love it!
Enjoy the live recording here:
https://youtu.be/33zLF7RG0Mk
Awaiting a great new release from Photon now :)
Cheers mates!
Enjoy the live recording here:
https://youtu.be/33zLF7RG0Mk
Awaiting a great new release from Photon now :)
Cheers mates!
Great improvement over the original demo. Sweet tune.
I highly enjoy the snarky scroller :D
Feels like in the old days. :) Competition is always nice. :D
Proper spirit from all involved: When optimal is not optimal enough, and to instigate more research with a bold claim - took 6 years to disprove!
I love everything about this one :D
Always great with some good old record-competition in the scene!
And I really like rotozoomers, and this one is smooth and colorful so thumbs up.
And I really like rotozoomers, and this one is smooth and colorful so thumbs up.
Colooors
Beardzoomer, what's not to like?
That's some hard tech right there!
And lovely zoomer graphics as well.
And lovely zoomer graphics as well.
Gotta love them rotozoomers!
woah!
I dig the attitude.
Roto perfection!
Spin around rapidly in a circle until you feel dizzy.
Good point
Loads of colours!
Loads of loads of colours.
Epic demosceneish "ZASCA!" XD
Congratulations on the world record. ;-) I don‘t like the rotozoom effect at all. But this one has shiny colors. The music breaks are perfect. And the live recording is very funny: „Ooohh, we have Blueberry…“
Non-live video please.
pretty colours!
A great achievement! And I loved the energy in the hall, seems like most people got the point regarding the waterbear comparison. If I had to pick any nits, I would say the second part doesn't fit well, I would rather have seen some variations on the first part.
But but... Photon said it was optimal.
Very cool! And the artwork really shows off 12bit color nicely.
The copper list looks like nothing special to me, just 54 color moves racing the beam perfectly and a skip/jump pair to loop.
Unless I'm missing something much trickier I am surprised no one managed this before, well maybe they did and it wasn't noticed?
If I'm missing something and it's actually super hard then sorry.
Could you get 56 colors by removing the loops and using the blitter to duplicate the lines or would that steal too many cycles from the cpu rotator code?
The copper list looks like nothing special to me, just 54 color moves racing the beam perfectly and a skip/jump pair to loop.
Unless I'm missing something much trickier I am surprised no one managed this before, well maybe they did and it wasn't noticed?
If I'm missing something and it's actually super hard then sorry.
Could you get 56 colors by removing the loops and using the blitter to duplicate the lines or would that steal too many cycles from the cpu rotator code?
succulent :)
Not really liking the music in this one, but the message is spot on.
Colorful and ultra-maximized!
It's cute to get an answer-tro like this every now and then, especially with the clever title (thumb for that alone). Pic shows off the colors very well, plasma was so-so but it was nice to get the bonus effect.
I like the colorfullness of the image. Not so sure about the text and the
attitude. But very nice and appealing rotozoomer!
@bifat / 2023-01-22 23:29:42
For aught I know, Photon's record was already beaten by roondar /
powerprograms some time ago (208px and 52 colors per line, though
w/o scroller and music).
attitude. But very nice and appealing rotozoomer!
@bifat / 2023-01-22 23:29:42
For aught I know, Photon's record was already beaten by roondar /
powerprograms some time ago (208px and 52 colors per line, though
w/o scroller and music).
Always great when things can be improved. What else to expect from this great crew?
world records are meant to be broken! :) great visuals and music pair well with the awesome code, lovely intro!
@ROG_VF: there was another attepmt by Britelite, similar fashion:
https://www.pouet.net/prod.php?which=67475
@ROG_VF: there was another attepmt by Britelite, similar fashion:
https://www.pouet.net/prod.php?which=67475
I get out of memory when trying to run it for some reason. I've always wondered what is the standard a500 512+512 setup in the emulator?
Chip RAM (512KB) is always required, but which one of the other options is the comon one to accurately mimic the 512KB expansion board for the a500 that your parents bought you?
Slow RAM?
Fast RAM?
Motherboard RAM?
Zorro III Fast Memory?
Accellerator RAM?
Graphics Card RAM?
I'll just put a rules here as I think they highest number of colors I've managed to change per scanline is 23 or 24.
Chip RAM (512KB) is always required, but which one of the other options is the comon one to accurately mimic the 512KB expansion board for the a500 that your parents bought you?
Slow RAM?
Fast RAM?
Motherboard RAM?
Zorro III Fast Memory?
Accellerator RAM?
Graphics Card RAM?
I'll just put a rules here as I think they highest number of colors I've managed to change per scanline is 23 or 24.
@loaderror The A500 half meg trapdoor expansion is ”slow RAM”. Do you have an emulated df1:? The readme says to unplug external drives (my guess is because they each eat a bit of chipmem).
Records are made to be broken!
@teo / 2023-01-24
Thanks for the info. Yeah, looks bearish-great despite the trickery with
the interspersed spacers.
Thanks for the info. Yeah, looks bearish-great despite the trickery with
the interspersed spacers.
Thanks Grip! I couldn't find the disk-drive config though, but I gave the Amiga500 1MB of Chip RAM instead which made it run :)
This is amazing! Why can other groups change twice the number of colors per scanline compared to Ephidrena? Do you turn off some DMA, interrrupts or some other trickery to boost the color changing powers?
This is amazing! Why can other groups change twice the number of colors per scanline compared to Ephidrena? Do you turn off some DMA, interrrupts or some other trickery to boost the color changing powers?
And ace pic by Farfar! 12-bit color palette maximized too!
np! Agree, that pic is delicious (and I second Magic, it's clearly Trap/Bonzai).
Everything rulez in this one!
Bald man in colorful picture rotating to chip music. World record. For now.
Beautiful!
I’m pretty sure I know the main trick being pulled here. Very sneaky! Does it count as a record?
Colours.
Records are meant to be broken! Gotta love the true oldskool attitude emanating from this one. And yes, whoever is on that image definitely looks like Trap!
@Jobbo / 2023-01-23
This would lead to a shifting of the color slots since only 112 of the
113 copper cycles per line are used, right? So, there must be some
kind of correction - maybe something like an extra move (nop) after
two lines in order to waste some extra time (2 cycles) and to bring
the slots back to their original position.
@Jobbo / 2023-01-26
Any bean-spiller intentions and willing to give a hint?
Quote:
The copper list looks like nothing special to me, just 54 color
moves racing the beam perfectly and a skip/jump pair to loop.
This would lead to a shifting of the color slots since only 112 of the
113 copper cycles per line are used, right? So, there must be some
kind of correction - maybe something like an extra move (nop) after
two lines in order to waste some extra time (2 cycles) and to bring
the slots back to their original position.
@Jobbo / 2023-01-26
Quote:
I’m pretty sure I know the main trick being pulled here.
Any bean-spiller intentions and willing to give a hint?
Quote:
... maybe something like an extra move (nop) after two lines in order to waste some extra time (2 cycles) ...
So, yes I'd been trying exactly that, one nop every other line. It definitely works, you can display 56 colors on each line.
The problem is that without the loops your code now has to fill all four rows with color data. With all the bitplane and copper activity there just isn't enough bandwidth to do that.
Quote:
Any bean-spiller intentions and willing to give a hint?
In fact there isn't enough bandwidth in Blueberry's version to run the rot-zoom and fill just 54x71 colors.
This is where Photon's version has an advantage, he has less bitplane activity because he's using the sprites in place of the right-hand side of the image.
So, how is Blueberry's version running at 50hz? Well, notice that it only stays up for at most a second of activity before the screen goes black again.
From what I can tell Blueberry is pre-filling a huge ring buffer of copper lists, then when the effect runs the code tries to keep filling but eventually the display drains the buffer and that's when it goes black.
So, does that really count? I don't know, I really love it all the same!
I'd love to hear from Blueberry, especially if I've gotten that all wrong.
I like it
Quote:
... notice that it only stays up for at most a second of activity before the screen goes black ...
Wanted to correct that and say it's staying up for 4ish seconds.
@Jobbo / 2023-01-27
Thanks for sharing your thoughts and the insights. But - as you
wrote - Blueberry is using copper loops. So, there must be some
(compatible) trickery with that.
Maybe (???):
1) The 4px high texels are split up (2 x 2px) by using two identical
consecutive copper loops. This would give one the chance to insert
the needed 2 cycle spacer in between which could be setting
$dff086 that has to be done anyway. Drawback: Time, since the
number of 'color value pokes' into the copperlist is doubled.
or
2) The 4px high texels are left intact (=no splitting) but then the
address where the copjmp will jump to has to be set per hand
outside the copperlist once per copper loop when line 2 is being
displayed. Drawback: Timing; don't know if it's feasible.
Schtroumpf à Lunettes over and out.
Thanks for sharing your thoughts and the insights. But - as you
wrote - Blueberry is using copper loops. So, there must be some
(compatible) trickery with that.
Maybe (???):
1) The 4px high texels are split up (2 x 2px) by using two identical
consecutive copper loops. This would give one the chance to insert
the needed 2 cycle spacer in between which could be setting
$dff086 that has to be done anyway. Drawback: Time, since the
number of 'color value pokes' into the copperlist is doubled.
or
2) The 4px high texels are left intact (=no splitting) but then the
address where the copjmp will jump to has to be set per hand
outside the copperlist once per copper loop when line 2 is being
displayed. Drawback: Timing; don't know if it's feasible.
Schtroumpf à Lunettes over and out.
supra-optimal!
Coloured thumb up !
Thanks for all the nice comments! So glad that you like the intro!
It's been fun to read your speculations about the internals of the effect. Time to sate some of that curiosity...
There's a bit more to the copperlist than meets the eye.
The first obstacle I hit when experimenting with a wait-free copperlist was, as has been alluded to, that the number of instructions that the copper can execute per scanline is not a whole number. Specifically, with a plain skip-and-jump loop, the number of instructions that can fit inside the loop is 52 and a half. In other words, a loop with 52 instructions in it will take 2 bus cycles less to execute than a whole scanline, which means that the color updates it performs will be skewed 4 pixels to the left for each successive scanline.
The approach Photon takes in his chunky is to alternate between color zero and some other color for the chunky pixels. The non-zero colors are all set beforehand, outside the loop, and the zero colors are set with perfectly synchronized writes inside the loop. Due to the skew, this approach will not work with a wait-free loop.
This intro takes a "FIFO" approach: all colors are written in chunky pixel order. With a sufficient head start, the color writes (which take 8 pixels each) are able to write all colors before the chunky pixels (which consume a color every 4 pixels) catch up. With a constant background color, the head start can be at most 31 colors before it has to start reusing colors. This reuse can't start until the first reused color has been displayed. And the last color has to be written before the last color is displayed. So there's an interval (inside the chunky display) in which all reused color updates have to take place.
It just so happens that even with the skew, the update region fits within the necessary interval. In other words, there's a possible placement such that the first line (which is furthest to the right) finishes before the last color is displayed, while the last line (which is 12 pixels further to the left) doesn't write the first reused color until after it has been displayed.
With just 52 instructions inside the loop, there's a bit of extra time between the loops. Specifically, in order for the next loop to start at the same horizontal position, there needs to be exactly 3 copper instructions between the loops. These are used for setting the loop target for the next loop and for setting the first 2 colors (which are then untouched inside the loop), resulting in a total width of 54 chunky pixels.
With the 2 unlooped colors placed first in the chunky, the first reused color is the one for the third chunky pixel, so the update region has to start after that. It still fits, which thus enables the chunky memory layout to be completely linear, i.e. all color updates for a line are consecutive in memory and in chunky pixel order.
I did experiment with taking this approach one step further, by having only 51 color updates in the loop and 6 outside it, for a total of 57 chunky pixels. However, this increases the skew to 12 pixels per scanline, which unfortunately makes the update region wider than the interval it has to fit within, even if the fixed colors are moved to a different place (so the update can start after the 1st chunky pixel rather than the 7th).
The cycles needed by the blitter to perform that copy would be even more than the total needed by the CPU to update the chunky. So you would have a harder time hitting 25fps with that approach than 50fps with a looped approach.
This is true. There are two reasons for this. One is, as you point out, that my chunky consumes more bandwidth that Photon's. The other is that there are more pixels to fill. :)
Well, the specific record I am claiming is for the width of a solid 4x4 12-bit truecolor chunky on OCS that can be updated with one write per chunky pixel and does not need CPU involvement during the display. This is more or less the properties that Photon outlines in his readme.
Whether the CPU can actually update all the pixels in a full-height chunky within a single frame is a separate issue. So for the biggest 4x4 truecolor rotozoomer that can run at 50fps without taking breaks, Photon still has the lead. :)
It's been fun to read your speculations about the internals of the effect. Time to sate some of that curiosity...
Quote:
The copper list looks like nothing special to me, just 54 color moves racing the beam perfectly and a skip/jump pair to loop.
There's a bit more to the copperlist than meets the eye.
The first obstacle I hit when experimenting with a wait-free copperlist was, as has been alluded to, that the number of instructions that the copper can execute per scanline is not a whole number. Specifically, with a plain skip-and-jump loop, the number of instructions that can fit inside the loop is 52 and a half. In other words, a loop with 52 instructions in it will take 2 bus cycles less to execute than a whole scanline, which means that the color updates it performs will be skewed 4 pixels to the left for each successive scanline.
The approach Photon takes in his chunky is to alternate between color zero and some other color for the chunky pixels. The non-zero colors are all set beforehand, outside the loop, and the zero colors are set with perfectly synchronized writes inside the loop. Due to the skew, this approach will not work with a wait-free loop.
This intro takes a "FIFO" approach: all colors are written in chunky pixel order. With a sufficient head start, the color writes (which take 8 pixels each) are able to write all colors before the chunky pixels (which consume a color every 4 pixels) catch up. With a constant background color, the head start can be at most 31 colors before it has to start reusing colors. This reuse can't start until the first reused color has been displayed. And the last color has to be written before the last color is displayed. So there's an interval (inside the chunky display) in which all reused color updates have to take place.
It just so happens that even with the skew, the update region fits within the necessary interval. In other words, there's a possible placement such that the first line (which is furthest to the right) finishes before the last color is displayed, while the last line (which is 12 pixels further to the left) doesn't write the first reused color until after it has been displayed.
With just 52 instructions inside the loop, there's a bit of extra time between the loops. Specifically, in order for the next loop to start at the same horizontal position, there needs to be exactly 3 copper instructions between the loops. These are used for setting the loop target for the next loop and for setting the first 2 colors (which are then untouched inside the loop), resulting in a total width of 54 chunky pixels.
With the 2 unlooped colors placed first in the chunky, the first reused color is the one for the third chunky pixel, so the update region has to start after that. It still fits, which thus enables the chunky memory layout to be completely linear, i.e. all color updates for a line are consecutive in memory and in chunky pixel order.
I did experiment with taking this approach one step further, by having only 51 color updates in the loop and 6 outside it, for a total of 57 chunky pixels. However, this increases the skew to 12 pixels per scanline, which unfortunately makes the update region wider than the interval it has to fit within, even if the fixed colors are moved to a different place (so the update can start after the 1st chunky pixel rather than the 7th).
Quote:
Could you get 56 colors by removing the loops and using the blitter to duplicate the lines or would that steal too many cycles from the cpu rotator code?
The cycles needed by the blitter to perform that copy would be even more than the total needed by the CPU to update the chunky. So you would have a harder time hitting 25fps with that approach than 50fps with a looped approach.
Quote:
In fact there isn't enough bandwidth in Blueberry's version to run the rot-zoom and fill just 54x71 colors.
This is where Photon's version has an advantage, he has less bitplane activity because he's using the sprites in place of the right-hand side of the image.
This is true. There are two reasons for this. One is, as you point out, that my chunky consumes more bandwidth that Photon's. The other is that there are more pixels to fill. :)
Quote:
Does it count as a record?
Well, the specific record I am claiming is for the width of a solid 4x4 12-bit truecolor chunky on OCS that can be updated with one write per chunky pixel and does not need CPU involvement during the display. This is more or less the properties that Photon outlines in his readme.
Whether the CPU can actually update all the pixels in a full-height chunky within a single frame is a separate issue. So for the biggest 4x4 truecolor rotozoomer that can run at 50fps without taking breaks, Photon still has the lead. :)
Thanks for the info Blueberry. I wasn't paying attention to skips and jumps taking longer than a move. You're workaround is very clever.
@Blueberry / 2023-01-29
Thanks from my side too for the explanation. Thinking about how it was
realized was a mixture of fun, torment, and frustration and became a
bit pathologically obsessive in the end :-)
Brain needs break.
Thanks from my side too for the explanation. Thinking about how it was
realized was a mixture of fun, torment, and frustration and became a
bit pathologically obsessive in the end :-)
Brain needs break.
BETRAYED by my own!! :o Haha, nice to see and my only problem with it is greetings and not fuckings to me in the scrolltext... ;)
Moar colorz, moar pleasure!
Love both the style and the attitude. And the code, of course.
Quote:
my only problem with it is greetings and not fuckings to me in the scrolltext... ;)
Humiliation via sarcasm is my style of fuckings. ;)
Too bad it's one "killer" effect.
Out of interest, what's the 7 bpl hack?
I always 👍 anything from Photon... wait... it's not from Photon!!!
Quote:
Out of interest, what's the 7 bpl hack?
If you set the number of bitplanes to 7 on OCS/ECS, you'll get a 6 bitplane mode (i.e. either EHB, HAM or DPF depending on flags), but DMA will only be active for the first 4 bitplanes, so bitplanes 5 and 6 will repeatedly output the 16-bit values written to BPL5DAT and BPL6DAT, respectively.
It's immensely useful. :)
Finally saw it. Not bad. :)
Lacks a solid logo and plasma effect is not as colorful as the first part, which deceived me a little bit.
Otherwise very good looking, cool effect!
Otherwise very good looking, cool effect!
Record
only 2 FX in 40k ?
@Blueberry / 2023-01-29
After a longer break (and cooling down of my brain) I thought about
the explanation:
52x moves (104 cycles) -> colors
1x skip ( 2 cycles)
1x move ( 2 cycles) -> copjmp
----------------------------------------
54 (108 cycles) -> total numbers
Considering a line is 56.5 moves (113 cycles) then (56.5-54=) 2.5
moves which corresponds to 5 cylces are not used by the loop which
would result in a drift of 20px per line. That is, 2 "color moves"
and(!) 8 additional "nop moves" would be necessary between the
loops to compensate for the total drift of (4 x 20px=) 80px after 4 lines.
I am a bit confused - which happens fairly often :-) Where is the
mistake? Obviously I have missed something?!
After a longer break (and cooling down of my brain) I thought about
the explanation:
52x moves (104 cycles) -> colors
1x skip ( 2 cycles)
1x move ( 2 cycles) -> copjmp
----------------------------------------
54 (108 cycles) -> total numbers
Considering a line is 56.5 moves (113 cycles) then (56.5-54=) 2.5
moves which corresponds to 5 cylces are not used by the loop which
would result in a drift of 20px per line. That is, 2 "color moves"
and(!) 8 additional "nop moves" would be necessary between the
loops to compensate for the total drift of (4 x 20px=) 80px after 4 lines.
I am a bit confused - which happens fairly often :-) Where is the
mistake? Obviously I have missed something?!
Is the skip 2 cycles ?
I remember the Waterbear one-screener, and this is just ... wow
@Dan: I always thought it was 3 cycles like a wait and was a bit
surprised to find out / read up it is only 2 cycles.
Woke up in the middle of last night and suddenly it flashed on my
(= found answer to my last question). Aha!
One problem less in my life :-)
surprised to find out / read up it is only 2 cycles.
Woke up in the middle of last night and suddenly it flashed on my
(= found answer to my last question). Aha!
One problem less in my life :-)
@ROG_VF, 2023-04-12 & 2023-04-05
"Difficult Birth"
Oops, the information of the online HRM was misleading.
HRM says:
"The MOVE and SKIP instructions require two memory cycles...each"
Testing shows that apparent consumption of skip is 16px which
would be equivalent to 4 cycles.
I hope I'm not talking nonsense again :-|
Or to quote Toni Wilen:
"Skip = 3 (same as wait)"
and
"Copper WAIT cycle is:
<IR1> <IR2> <sleep start> (sleeping) <wakeup> (next instruction's
IR1 fetch). Real total is 4 copper cycles. Internally wakeup cycle
generates request for IR1 (due to pipelining IR1 DMA transfer
happens in next copper cycle) so technically you could also say WAIT
is 3 cycles even if it isn't the whole truth"
Maybe this is helpful for other confused and lost souls. Sorry for the
inconvenience. Cheers.
"Difficult Birth"
Oops, the information of the online HRM was misleading.
HRM says:
"The MOVE and SKIP instructions require two memory cycles...each"
Testing shows that apparent consumption of skip is 16px which
would be equivalent to 4 cycles.
I hope I'm not talking nonsense again :-|
Or to quote Toni Wilen:
"Skip = 3 (same as wait)"
and
"Copper WAIT cycle is:
<IR1> <IR2> <sleep start> (sleeping) <wakeup> (next instruction's
IR1 fetch). Real total is 4 copper cycles. Internally wakeup cycle
generates request for IR1 (due to pipelining IR1 DMA transfer
happens in next copper cycle) so technically you could also say WAIT
is 3 cycles even if it isn't the whole truth"
Maybe this is helpful for other confused and lost souls. Sorry for the
inconvenience. Cheers.
Clever piece of code.
Impressive onescreener with a crispy chip
nice!
Great one
^
lists containing this prod
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 !