pouët.net

Just back from the party. Thank you all for the feedback!

@Cego We tested it on A1000 with 0.5 chip and fast and it worked fine. If you are running from floppy, maybe it is a bad disks issue? During our tests, it happened to us several times and using new disks fixed it.



In any case, we hope we can fix the compatibility issues that eluded our testing.

Thanks!

@Cego During the Gotham scene with the Joker in the background, an icon appears at the bottom right indicating the disc change if needed.
What memory expansion do you use? (A screenshot of the workbench / showconfig might help). Thanks for the feedback!

@wysiwtf Thanks for the feedback! Some flickering on some screens is even wanted, for example on the Gotham City lights. On other screens, on the other hand, it should be quite moderate on CRT.

@Cego Thank you very much! If you have twitter, can you add me here: @BATMAN_GROUP ?
Or any other way I can speak privately with you?
Thank you and sorry for the inconvenience.

@djh0ffman Thanks for the feedback!
We didn't have TF1260 during our testing, but we just got one, so I guess we'll be able to fix that. Our intention is to release an update soon with all the compatibility issues we can fix from the reports we are getting now, so thanks again!

@bifat Thank you for your honest feedback! We really did everything we could to keep the classic old school spirit of fxs at 50 fps :)

About vector players, I like to see it as an fx in itself that can be implemented more or less efficiently, just like any other fx. In our case, the challenge was to beat Eon's vector player by implementing similar scenes but at 50 fps instead of 25 fps, which implied not only improving the player speed but also the data compression, since double the fps also implies double the frames. The optimization here involves not only the player but also the additional tools and, overall, I would say that from a strict code point of view, it is a bigger challenge than breaking the record for the number of dots in a tunnel or the faces of a glenz vector.

I also think vector animations are a powerful storytelling tool and can complement the classic fxs concept well. I don't see it as a Manichean question about classic demos vs anim demos but it can all be tools that we have at our disposal.

On the other hand, objectively I can't agree that the fxs in this demo are few, since you can remove the parts that include vector animations and still get a demo of about 4-5 minutes, many of the parts where we use vector anims are complemented with additional code fxs, for example, the background of the crow scene or in the greetings, where the lighting of the background vector anim is in real time, as well as the vector red light beam. On the other hand, there are parts that are composed of 4 or 5 simultaneous fxs, such as for example the formation of our BG logo at the beginning, that includes a background plasma, zoom out of the logo with curves, classic realtime vectors for the "group" zoom out, and a little vector animation too :)

@mikev @Jumbo Burger @Aghnar Thanks!
@Charlie
Yes, we are now trying to fix some compatibility issues in order to release a trackmo update and then we will release a file version as well.
Thanks!

Soundtrack from DJ Uno now available for download in mod format!

We have added a minisite with a write-up about the narrative side of the demo. We hope you enjoy it!
Once again, thank you all for the feedback!

Live recording at Posadas Party Autumn Edition 2022 added!

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.

@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.

@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!

@ChrisLDN Make sure your A1000 has at least 1mb of RAM and 0.5mb of chip. We have only been able to test it on a pal A1000 and it works fine.

Nowadays, with the amount of Amiga configurations that exist, and the extreme optimizations for A500 that this demo needed, reaching 100% compatibility seems more complicated than I had anticipated. In any case, after a break, we will soon fix the compatibility issues we can, and we are also planning to release a file version.

Thanks for the feedback.

@superplek For some time now, in the art of comic books (with works such as "Batman: Year One" or "Batman: The Dark Knight Returns"), movies and pop culture in general, works about Batman are generally for an adult audience.
I do not believe, for example, that Matt Reeves' recent film "The Batman" is aimed at a child audience, nor do we intend our demos to be more "childish" than others because they are based on the Batman universe, although it's perfectly understandable that there are those who don't like the character.

@Serpent I agree, you don't need to be a fan of ancient Egypt to enjoy Desert Dream. And yes, too late and too old to change :)

We have just released an update with compatibility improvements and some minor bug fix (see the readme for more details).
Thanks!

Thanks Paraj!