CPCWiki forum

Hi !
I would be very interesting to propose a screen for such a project, but I definitively do not want to take part to this organization.Having being involved in the 30th anniversary version, https://www.cpcwiki.eu/forum/demos/30-years-megademo-released!/, releasing few demos during the last decade, I have a good idea of were of difficulties, tensions, time-eater stuffs in such projects.I can provide guidance/share code with the person that would organize it.

I would say safe rules to have a project that end properly would look like to (of course it is just a guidance):

- anyone can participate whatever is his/her (lack of) history and production on the scene- each participant provides one part in one file. Of course, we expect at least one demo in this file. The part has access to the main memory only and uncrunches itself (it MUST be crunched with a state-of-the-art cruncher) makes calls to the demo system to play the music (so the music is written AFTER all parts have been submitted), request launch of the next part. Each part MUST leave by itself after 20s maximum (even less is better). Each screen starts and stops with a specific crtc configuration (demo system may help on that) and is most of the time at 50hz. The best is to have an original screen, but it is not mandatory. Screen composed of only a picture + standard scroll texts should be avoided
- the organizer provides the necessary files to allow the participants to work (test music + demo system)
- each screen must at least be fully compatible with crtc 0 and crtc 1; it can crash on crtc 2. it is a bonus if it works properly on crtc 3/4
- no fancy intro / menu just a bunch of uncorrelated parts that are shown one after the other - only the music makes the link between them. If there are few participants, everything fits in memory. Otherwise, it is necessary to load from disc (the best is to do it using system routines to be be stick with floppy-disc support)

With such rules:- to participate is not that much difficult and time eating- to manage the project is simpler than managing a real modern fancy CPC demo and a limited time-eater. I strongly suggest to use crossdev tools to automatize demo construction
- final result can be great, and it is feasible to share it in 2023

Lots of historical groups/persons have not participated in the 30YOMD, it is the opportunity for them to be present there.
I am not confident that this post will motivate people to organize such things; but it would be great anyway.

Why would the "demo system" be needed to play music? I don't understand this point. Are you talking about a trackmo (in which case this could apply)?

I don't think that I am the right guy to organize the demo, but I would definitely like to participate! Just as I wanted for the 30 years demo,
but I did not have the proper tools back then. I have learned a lot about cross-dev and improved my CPC dev tool-chain quite much,
so that at least concerning a part for the demo, I should be in a much better position to actually deliver something..

And I would also like to provide music! I guess it's possible to make a tune using the (ultimate) Soundtrakker
and then convert to whatever fancy new replay-routine will be state-of-the-art in 2023, hein?

Quote from: BSC on 10:28, 10 April 21I guess it's possible to make a tune using the (ultimate) Soundtrakker
and then convert to whatever fancy new replay-routine will be state-of-the-art in 2023, hein?

There's nothing wrong with using the original player, as long as it fits your demo, CPU wise. Alternative solutions for now:
- you can use the venerable AYC format from Madram from the YM (very fast, but memory consuming).
- you can import your .128 into Arkos Tracker 2, and after tweaking (which may not be much work), can export in any format AT2 supports (AKG, AKY...) according to your need of speed/memory.

Quote from: Targhan on 08:56, 10 April 21
Why would the "demo system" be needed to play music? I don't understand this point. Are you talking about a trackmo (in which case this could apply)?

I do not care ;) It is up to the organizer to discuss such things; it was just a suggestion.
In my opinion it is easier to say: do RST 0 to play the music instead of saying; switch to bank XXX and call adress YYYY with the risk that YYYY change later. This way you do not have to know in advance if the music spans over several banks or is small enough to fit one

I have no idea why the music should be part of the demo system. What if I use a A player, and someone else a B player, and someone else a C player? I agree the demo system should add facilities (CRTC detection, maybe keyboard handling?), but the music... It's just going to add complexity. Handling the music is part of the coder's job, just like he will handle the memory management of his effects.

Maybe I have forgotten to write that. in my hypothetical rules, the music is written AFTER participants provided the parts. This is where at least a bit of coherency is done. Participants do not provide a music  or a player
edit: it was written "to play the music (so the music is written AFTER all parts have been submitted),"
BTW as in my hypothetical rules, screens last no more than 20s, I am not sure it is a good idea to allow participants to provide a music...

Anyway, there is no need to exchange too much on that; I only put what I thought it would be good. Unless you want to be the organizer ?

Oh, I DID saw the part of the 20s per part, but I thought it was a typo (just like the The Demo parts automatically exit after X minutes, which is a nice touch).
I understand better the need of an external player in that case. So you expect a trackmo. It makes sense in that regards.

>Unless you want to be the organizer
Not really.......

I'm actually thinking, instead of making a megademo/trackmo/whatever... What about having all the participants create one demo for a specific deadline? X demos instead of one demo.

Hi there, I would like to participate with a little part.... Can you tell me the dead line date please?

I don't think there is any official dead line yet, since the project is not official yet. However, since the CPC appeared in 1984, I guess the deadline should be beginning of 2024? So there is still a bit of time. But never enough, as everybody knows :).

First of all: TGS (HAL6128 and I) also like to participate.


Now some first thoughts:

   
• As the 464 gets 40, we're talking about 64kB or 128kB RAM (cause Krusty mentioned bank-switching)?
• Nice would be to target Revision 2024?
• I like both ideas: everyone makes "little" parts and the music is the connection between. But then the player(s) have to be usable like the individual programmer needs them (irq, non-irq, reproducable raster lines etc.). But I also like the idea using a menu and each part runs standalone. (then we could provide a little amsdos-compatible loader, which only loads the menu again, and each part includes a (crunched) version of this. Then when the part is done, the loader is uncrunched, called and we're back to menu.

We are already close to 40 years? Wow, I feel old now..