pouët.net

Rhino/BG information 366 glöps

• general:
• level: user
• personal:
• first name: Alejandro
• last name: del Campo
• cdcs:
• cdc #1: Enigma by Phenomena
• cdc #2: Mental Hangover by Scoopex [web]
• cdc #3: Blood Sugar Rises by AttentionWhore

• 40k Amiga OCS/ECS Water My Grey Beard by Loonies [web] & Struts
• Good point
• rulezadded on the 2023-01-23 15:03:36
• demo Amiga OCS/ECS Clubisque by SMFX & Lemon. & Insane [web]
• Great music, gfxs and code!
• rulezadded on the 2023-01-22 20:14:16
• demo Amstrad CPC Purple Swirl by Genesis Project [web]
• Nice scroller and welcome to the CPC.
• rulezadded on the 2023-01-22 14:36:52
• 40k invitation Amiga AGA For real by Spaceballs [web]
• Cool invitro!
• rulezadded on the 2023-01-22 14:31:25
• demo Amiga OCS/ECS Batman is a Motherfucker by Arise
• Omg!
• rulezadded on the 2023-01-12 23:33:39
• demo Amstrad Plus Tempus Fugit by Impact
• Great visuals!
• rulezadded on the 2023-01-07 17:43:08
• demo Atari Jaguar Interpol is now 60 fps by Dune
• Nostalgic
• rulezadded on the 2023-01-04 11:53:04
• demo Amiga OCS/ECS Batman Rises by Batman Group
• @Scali That challenge sounds interesting, but I think the format of the data can greatly influence the final performance and can also be an important part of the challenge, so the scene could be in a "standard" format but with the option to be able to convert it to your own.
  
  @Jobbo @ROG_VF We may do some of that later. The skull rotator mixes horizontal line scrolling with pixels column scrolling with the blitter.
  
  @hot multimedia I agree, the main difficulty in an old skool demo like this is to find a context where more or less classic fxs can make sense within a narrative. The world of dreams and illusions, visions by mysticism or chemistry or anything that can justify an abstract world can work.
  
  @Preacher If the drama serves to motivate Photon to make an exquisite demo in its own way that proves us wrong, it will have been worth it.
  
  Happy New Year to all!
• isokadded on the 2023-01-02 11:48:37
• demo Amiga OCS/ECS Batman Rises by Batman Group
• @Photon I separated the fxs that include a vector player from those that do not, so that your fake-comment (suggesting that everything is "played back") would not mislead anyone. You can also see that classification of fxs as proof that there is no will in misleading anyone, those are just pretty strong claims that you make gratuitously.
  
  But in case you did not understand the above classification, I clarify that in the first category of 14 fxs there are several 3D engines optimized for running scenes at 50 fps, such as the 3D texture tunnel fx, the 3D dots tunnel, the 3D fx with lines, the 3D starfield above the galaxy, the polygon formed by particles or the 3D pixels that form the final logo. Even in fxs that you wrongly classify as 100% fakes include a real-time 3D engine like the one that was necessary for the beam of the greetings part. All of them are 3D engines optimized to do exactly what they do, which of course do not need a painter's algorithm to do what they must to do. But in your lack of experience and background, you are unaware of the most basic premises in engineering, such as not wasting time and resources on doing what you don't really need to do.
  
  If you knew anything about optimized fxs on Amiga, you would know that it is a path that sometimes leads you to make really elegant and beautiful code because of its simplicity, while others force you to deploy large amounts of auto-generated code, but that all those possibilities are valid if they fit within the limitations of the platform (the real equal terms) when what you are trying to is accomplish your goal. You also seem to be unaware that the effort curve required to improve the performance of very optimized fxs grows exponentially. There are fxs in the demo that I started them 2 years ago and I have periodically revised for 2 years to gain each time a lower % of performance.
  
  You seem to give a lot of importance to statements about code from people who are not coders or unfamiliar with the platform, while I only talked about what an experienced Amiga coder should know and I never met one experienced coder who believed that a demo like Eon is a real-time 3D engine, on the other hand, I have met some inexperienced coders who said that a demo like Eon is practically a raw animation player which is also false. I didn't say that expert coders like "fake fxs", what I said is that an expert coder should know how to value each thing for what it is and I think I already gave enough arguments above to support it, so I won't repeat myself.
  
  Your 100% fake-comment starts from a false premise (the demo is all played back) to reach an even more false conclusion (it kills the platform). It's been 30 years since SOTA or 9 fingers came out, and being these 90% vector player demos, instead of killing the platform they gave it new life, created more variety and richness in the demoscene and motivated many people to do things. Also Eon, which is now 4 years old, has motivated many people to return to Amiga coding (including myself). So your whole main argument falls down by the way of facts.
  
  You can't get around the fact that you confused a demo that is the product of 2 years of hardcoding and includes over 170k lines of assembly code with something that is "all played back" and that may be enough to never take a comment from you about Amiga code seriously again. I speak of confusion to be generous, since the other possibility is that you were knowingly trying to spread fakes for spurious reasons.
  
  To end, you can make a demo however you want, TBL can make a demo that is 90% vector player if they want and at BG we can make a demo like Batman Rises with a wide range of different effects and all that variety of demos will create richness for the platform. Just the opposite would be if we all made the same demo as you want, or that we all value the prods under your same criteria, that would definitely kill the platform. So, please, stop trying to kill the platform.
• isokadded on the 2022-12-31 12:10:14
• demo Amiga OCS/ECS Batman Rises by Batman Group
• In order that the @Photon review is not misleading (since he refers to the whole demo as if it were a "played back") and some clueless person thinks that the whole demo is a played back, I provide this detail of the fxs where you can see which ones include a vector player and which ones do not.
  
  
  
  As you can see, we have 14 fxs/parts that do not include vector player and 8 that include vector player, many of these as addition to real-time code (for example, the ball explosion over Gotham which includes a fire fx below, the greetings, where the lighting and the red vector beam are real-time, the Joker over Gotham whose distortion fx is real-time, or the crow's textured background). For reference, regarding the amount of fxs, recent Amiga demos like Rule 30 has 10 fxs in total, Transhuman/Pachinkoland has 13 fxs or Hologon 14 fxs. So, we can say that even removing all the fxs that included vector player, you still have a demo full of other fxs.
  
  About the eternal realtime vs precalculated debate, I have to say that what often determines the increased complexity of a code and the involvement of more innovative techniques is not the division between realtime and precalculated, but the level of performance optimization that an fx has. You can make a real time starfield routine that only moves 100 dots at 50 fps and it will be much simpler and easier to program than one that moves 5000 dots at 50 fps using innovative precalculated techniques of your own invention.
  
  On the other hand, anyone who has experimented with making new fxs knows that it is common to first devise the fx in real time and in later steps to think of new precalculated techniques to increase the performance of the fx. So, precalculated techniques come as a result of the evolution to make the fx look more spectacular within the limits of each platform.
  
  Therefore, the obsession by the real time seems to me to be typical of a coder without much real experience programming demo fxs and who does not know very well what he is seeing when he sees a demo. An experienced coder should know when an fx (whether precalculated or not) implies an innovation that significantly improves performance of previous versions of the same fx and, of course, to qualify anything that has a vector player as worthless also denotes little experience and thoroughness.
  
  It is true that in a vector player there is a large amount of pre-calculated data in PC, but even in this matter achieving maximum performance has implications that make programming a vector player not so obvious as from the lack of experience and rigor would have us believe. For reference, I will now go into some details about some innovations involved in the vector player that I implemented to increase performance.
  
  A new thing with respect to other vector players was to separate the thread that visualizes the frames (which is executed by interruptions) and the one that renders the frames, then I included a big chip buffer so that the render goes rendering frames in advance in the buffer while it has memory. Thus, during the rendering of less complex frames, the renderer gains time by prerendering more frames in advance so that when it is time to render complex frames, the thread that displays the animation will show the prerendered frames in the buffer and they will still be displayed at 50 fps.
  
  Then, the prerendered frames are not buffered as full screens, but only the screen area used by each frame, and the display thread also displays them this way, adjusting the screen size to each frame. In this way more frames can fit in the buffer while the dma is freer, and the previous frames can be deleted optimally with long movems while the blitter also does its job.
  
  Another additional optimization, in order to keep the cpu busy all the time, is that when the thread that renders cannot render any more because the buffer is full, it caches the line drawing blits of the complex frames that are about to be rendered overwriting the data of frames already rendered, that is, it advances the calculations that transform the coordinates of the lines into the data that are sent to the blitter so that when it has to render complex frames, it can do it ultra-fast.
  
  Without going into the details of compression and real-time decompression of data involved in order to play animations of more than 2000 frames, I hope that these brief notes can give an idea of the code-complexity that can be behind a high performance vector player, which, as I said before, to me is just another fx, which can be optimized with innovative techniques to render spectacular things.
  
  Still, when a demo is 90% vector player, even considering the complexity behind it, I understand that it had less code work and demonstrated less diversity of coding techniques than traditional demos, and somehow that should be reflected in the ratings as well.
• isokadded on the 2022-12-30 13:53:33