pouët.net

Blueberry information 1339 glöps

• general:
• level: user
• personal:
• first name: Aske Simon
• last name: Christensen
• cdcs:
• cdc #1: Nexus-7 by Andromeda [web]
• cdc #2: Tint by The Black Lotus [web]
• cdc #3: Gift by Potion
• cdc #4: STS-02: Electric Kool-Aid by Synesthetics
• cdc #5: TBC Realtime Experience by Too Bloody Cheesy [web]

• 40k Amiga OCS/ECS Water My Grey Beard by Loonies [web] & Struts
• Quote:

  my only problem with it is greetings and not fuckings to me in the scrolltext... ;)

  
  Humiliation via sarcasm is my style of fuckings. ;)
• isokadded on the 2023-01-30 11:52:36
• demo Amiga OCS/ECS Clubisque by SMFX & Lemon. & Insane [web]
• Nice one. Enjoyed the graphical style.
• rulezadded on the 2023-01-29 13:17:51
• demo Amiga OCS/ECS AMIGARAVE by Desire [web]
• Party favorite for me! Focused and effective.
• rulezadded on the 2023-01-29 13:03:49
• 40k invitation Amiga AGA For real by Spaceballs [web]
• Proper Spaceballs attitude put to good use. :)
• rulezadded on the 2023-01-29 12:55:47
• 40k Amiga OCS/ECS Water My Grey Beard by Loonies [web] & Struts
• 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...
  
  
  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. :)
• isokadded on the 2023-01-29 12:33:57
• demo Amiga OCS/ECS Batman Rises by Batman Group
• Next-level production. Amazing.
• rulezadded on the 2022-12-18 19:18:11
• 256b MS-Dos Peacock by Jin X
• Delicious.
• rulezadded on the 2022-10-28 22:53:57
• demo Windows The Box by Ümlaüt Design [web]
• Top entertainment, perfectly executed.
• rulezadded on the 2022-09-11 20:40:30
• 1k invitation Amiga OCS/ECS Be a star by Loonies [web] & Fnuque [web]
• bifat: You need to come to TRSAC for that! ★
• isokadded on the 2022-07-18 13:24:06
• demo Amiga OCS/ECS rage OS by AttentionWhore
• The fact that you reverse engineered Rose is worth several thumbs on its own. I'm honored. ;)
  
  ... and entertained as well! :-D
• rulezadded on the 2022-07-11 22:28:11