#CPCRetroDev 2015: Complete Results and Games

[ronaldo]

Rules for #CPCRetroDev 2015 are published and submissions are open! . This year we are going to beat records with 900€ in prizes for the best Amstrad CPC games! And the contest is officially open to all the international community!

Deadline:friday, 23th of October, 2015 (CEST timezone, more than 4 months from now)

This year, there are 2 main categories: PRO y BASIC. There are also 2 special awards for technical innovations and originality. Like past year, a physical edition with all presented games will be published. Moreover, this year's physical edition will be distributed by award winning enterprise Devilish Games.

The contest is organized by University of Alicante, ByteRealms and Cheesetea, and has 2 collaborating entities (by now ): Devilish Games and RetroManiac. We organizers are extremelly grateful to collaborating entities for their extraordinary support

Here you are the most important links

• Official web for the contest (in english!)
• News published in RetroManiac (spanish)

]

[EgoTrip]

I might try and enter something, so everyone else who enters won't have to fear finishing in last place.

[ronaldo]

I can't believe in @EgoTrip being the only one willing to accept #CPCRetroDev Challenge. Come on! Where are you hidding, CPCWiki's superb developers? 

[Trebmint]

I can't believe in @EgoTrip being the only one willing to accept #CPCRetroDev Challenge. Come on! Where are you hidding, CPCWiki's superb developers? 

Im sure you'll get quite a few entries, but I guess people dont like to throw their hat into the ring too early

[Ygdrazil]

Im sure you'll get quite a few entries, but I guess people dont like to throw their hat into the ring too early

Heh... I think you are right there :-)


/Ygdrazil

[Optimus]

That's cool news! It almost made me recompile an old project, although I don't want to promise anything yet (I know I will fail to deliver), just keeping an eye on the compo.

[fgbrain]

Too bad it must be 464 only!!! All CPC models are retro machines 

[ronaldo]

Too bad it must be 464 only!!! All CPC models are retro machines 

@fgbrain, that's a decision we did based on several reasons:

• Games created for 464, unless badly programmed, will work on 472, 664 and 6128 (no CPC machine is discriminated)
• Games that enter the contest will be published, and we want them to be accessible for as much people as possible.
• Contestants should compete on similiar conditions: a game that uses 128K has much more possibilities than a 64K game. It is unfair to compare both of them.
• Games will be published on cassette tape: 128K games on cassette tape would be horrible to load.
• Part of the organizers are looking for technically skilled people and they consider that limiting computational resources to the minimum is a way to challenge people and asking them to find new ways for doing what they want to do. Overcoming limitations is a key characteristic of creative and technically skilled people. I agree with them in this point.

These are our reasons for asking for 64K games (not limiting to 464 work, that's the minimum we ask for, not the maximum). Of course, we know that these reasons don't have to be shared by everyone, but no single set of reasons would. If we had selected 6128 as target machines some people with 464 will complain, if we open it to any kind of CPC, some people could reasonably complain that comparisons are unfair, and we'll have problems to create a single physical publication.

I'm sorry for not being able to satisfy everyone's desires: I'd love to have a way to do that. We've picked this contest model and hope you understand us, even if you don't share our view.

[MacDeath]

The point being having students doing things, 464 is good, I mean, to get coders handle only 64K (minus the Video buffer) is really a hard exercice.

The point is also to get small fun games I guess while the students (the ones aimed at by this competition) still have enough time for the rest of their studies... 
I mean serious projects like Orion Prime or R-Type remake could take years to be completed...

Really nice to have this running since 3 years.

I really think such experience can really benefit younger coders students.
When you apply for a job in coding, the project manager or any superior would be a 35-40 years old dude that actually started on those 8bit machines and this close to hardware approach is great.
Many jobs in coding are concerning Embedded systems with some very limited hardwares or specifications
My brother is developing some Embedded systems for his job : it has some 32bit cpu but like 128k RAM and 512k Flash only and very very low 1bpp display... basically a 32bit CPC/ZX81... lol... in a 1cm² thing.
he told me he had to take hand on this project after a young dude in professional traineeship... the code was so bad that my brother could reduce the power consumption 10 times because he is an older dude who happened to know the era of the 64k RAM and 4mhz.

youngsters coders would always waste so many CPU because... modern computers have too much of it.

when doing embedded systems, you really can help having experience from those old very limited systems. It also helps them to try and learn "exotic" systems... and it restores the very first vocation of those 8 bit machines : being game cons... er.... being learning machine. 

I mean, a young student who never knew anything beside very powerfull computers and graphic user interface and too many many gigas of anykind (Hz, bytes, colours, pixels...) to waste.
Bad unopmised code can work on new computers... but you may not realise you are using half the power of the computer to run a simple task program for nothing... and that it wouldn't run on somewhat more limited systems (like small tablets, older smartphones or even a computer with only 2 cores and 1go RAM...


Also to have the thing interested via prize money and non-students contestants makes sure students would get hard competitors by older dudes like the CPC community. And see what others can do.
Would be great if more universities could do such things.

could be like Robotic competitions between tech-schools.

"European universities Retro-computing coding competition", could be great.
Have you asked to some other universities teachers ? in France perhaps ?

[ervin]

Now that I've got cpctelera running nicely, I'm thinking of entering the comp.
Not sure what I'll do yet... maybe some sort of into-the-screen runner...

[ronaldo]

@MacDeath: all that you say are definitely part of my goals . I always want my students to be involved in real projects, not simple classroom exercises, and making them face against real consolidated developers is very educative for them. Moreover, having to deal with an Amstrad CPC 464 forces them to go low-level and face their non-optimal coding style against the machine. Then, learning to get the most out of the machine is the next step .

However, I also love to contribute to the community and continue giving new live to hour beloved Amstrads . The contest is a way to offer the best to both worlds: my students get exciting and educative projects, and the community has a great contest to enjoy and to impulse new and existing game projects to become real for our machines .

[ervin]

I'm spent some time playing with cpctelera today, and it is AWESOME. Love it.

So I'm going to try writing a game called RUN"CPC".
(Yes, rather pretentiously, the quotes are part of the name).

It will be an into-the-screen auto-runner, and it'll be done completely in cpctelera/SDCC, except perhaps for a fast CLS routine written in asm.
Hopefully I'll find the time to create this game! 

[Gryzor]

I love the title, if nothing else!


So it'll be pseudo-3D?

[ervin]

I'll actually be using proper 3d-to-2d projections, and then mapping the calculated points to character blocks on-screen.
Those points will then be used as the basis for where to draw sprites from tiles.

In fact I've already got some characters (numbers and letters) flying around the screen in proper 3D (though it is very buggy at the moment).
 

[Gryzor]

Ooh sounds exciting! What about the target window size and frame rate?

[ervin]

I'm not sure about the frame rate yet... it won't be amazing but should be perfectly playable.
I'm going for full-screen. 

[ronaldo]

I'm spent some time playing with cpctelera today, and it is AWESOME. Love it.

Comments like this give me much energy to continue doing more things for CPCtelera . Hope to make it a little bit better every day

So I'm going to try writing a game called RUN"CPC".
(Yes, rather pretentiously, the quotes are part of the name).
It will be an into-the-screen auto-runner, and it'll be done completely in cpctelera/SDCC, except perhaps for a fast CLS routine written in asm.

Curious name . I'm looking forward to see it finished

Btw, latest commit to CPCtelera at github includes cpct_memset_f8 function, which is a fast version of memset that uses SP / PUSH in chuncks of 8 bytes. That makes it able to set 16000 bytes (the whole screen in standard mode 0) in ~115K cycles, which is a little bit less than 2 VSYNCs, and 3 times faster than a standard memset.

I'm planning on providing another faster version (using 32-bytes chunks) to be able to clean the screen in 1 VSYNC .

Hope that is enough for you . If not, you can easily create your own version just by adding a .s file to your project, that will be compiled automatically by CPCtelera .

[ervin]

Thanks for adding cpct_memset_f8. Looks like a very useful function.
Unfortunately I can't seem to get it to work.
 

To set 16K, starting from 0xC000, I'm doing this:

Code: [Select]

u8* const g_SCR_VMEM=(u8*)0xC000; // Pointer to the start of default VRAM
cpct_memset_f8(g_SCR_VMEM,0xAA00,16384);
Am I doing something silly?
(I'm actually learning C as I work with cpctelera, so some things are a bit tricky for me).

When I use 16384 as the 3rd parameter, the program crashes.
When I use 16383, the program works, but leaves 8 bytes unfilled (which of course is because 16383 is not divisible by 8, so I presume the program is using 16376).

[EDIT] That's strange... when I use 16376, it fills the entire screen, which I presume is because there are a few bytes at the end of each raster line which don't get displayed on a default-size CPC screen.

By the way, I'm looking forward to cpct_memset_f32.
 

[alex76gr]

Programming contests is a real bless for the CPC.
CPC fans have received that way a great deal of quality software.
My appreciation goes to all the participants.
May the force be with you!

[ronaldo]

@ervin: you are using cpct_memset_f8 incorrectly. To clean the whole screen (fill it up with PEN 0) you should do this

Code: [Select]

// memset parameters:
//   1: pointer to the start of the memory area to be filled
//   2: 16-bit colour pattern for filling
//   3: Size (amount of bytes) to be filled
cpct_memset_f8((void*)0xC000, 0x0000, 0x4000)

You can use the colour pattern to fill memory with a different colour (PEN). If you wanted to fill it with PEN 15, you should do this

Code: [Select]

cpct_memset_f8((void*)0xC000, 0xFFFF, 0x4000)

As for the crashes, there was a bug in the implementation that I've solved this morning. Please, update to the last CPCtelera version from github.

With this last CPCtelera version, I also include a macro to simplify this. You can now clean up the screen with this simple call:

Code: [Select]

// Parameter: Colour pattern. 0 = 0x0000
cpct_clearScreen_f8(0);

Hope this helps .

[ervin]

Fantastic - thanks so much for that!

the cpct_clearScreen_f8 function is a great idea.
 

[ronaldo]

Well, after the last update things are this way:

• 3 different flavours for memset function: cpct_memset, cpct_memset_f8 and cpct_memset_f64
• Along with them, 2 different clearScreen macros:

Code: [Select]

------------------------------------------------------------------------
|MACRO                | TIME (VSYNCs) | CODE SIZE (bytes) | INTERRUPTS |
------------------------------------------------------------------------
|cpct_clearScreen     |    5.17       |       25          |     -      |
|cpct_clearScreen_f8  |    1.77       |       45          |  Disabled  |
|cpct_clearScreen_f64 |    1.33       |       71          |  Disabled  |
------------------------------------------------------------------------
So, depending on the use, you can pick up the memset function you require .

[Prodatron]

I wonder how to clear the screen in 1,33 VSYNC?
Each VSYNC takes 64x312 microseconds = 19968 microseconds.
One PUSH (writing 2 bytes) takes 4 microseconds.
One screen contains 16000 bytes.
16000 x 4 / 2 = 32000 microseconds.

This is still 1,6 VSyncs, and this can only be reached, if you have 8000 PUSH commands one after each other.

Maybe I made a mistake in my calculation?

CU,
Prodatron

[ronaldo]

Thank you for your argument, @Prodatron. Most probably my calculations are not good, so let's take this opportunity to understand why .

I usually make calculations in CPU cycles. 19968 microsecs = 79812 CPU Cycles running at 4Mhz. Gate array takes 1/6 cycles to read memory and feed the monitor. Therefore 79812 * 5/6 = 66560 available CPU processing cycles per VSYNC.

Taking raw CPU cycles required to process each instruction, when processing 0x4000 bytes:

• cpct_memset: 344172 CPU cycles / 66560 =~ 5.17 VSYNCs
• cpct_memset_f8: 117491 CPU cycles / 66560 =~ 1.77 VSYNCs
• cpct_memset_f64: 88819 CPU cycles / 66560 =~ 1.33 VSYNCs

These are my calculations. Could you please tell me where is my mistake(s)?

[Prodatron]

Thank you for your argument, @Prodatron. Most probably my calculations are not good, so let's take this opportunity to understand why .

I usually make calculations in CPU cycles. 19968 microsecs = 79812 CPU Cycles running at 4Mhz. Gate array takes 1/6 cycles to read memory and feed the monitor. Therefore 79812 * 5/6 = 66560 available CPU processing cycles per VSYNC.

Taking raw CPU cycles required to process each instruction, when processing 0x4000 bytes:

• cpct_memset: 344172 CPU cycles / 66560 =~ 5.17 VSYNCs
• cpct_memset_f8: 117491 CPU cycles / 66560 =~ 1.77 VSYNCs
• cpct_memset_f64: 88819 CPU cycles / 66560 =~ 1.33 VSYNCs

These are my calculations. Could you please tell me where is my mistake(s)?

It's a little bit more than just adding 1/6 from the Gate Array. In the CPC most single cycles within a command of the Z80 are "rounded up" to one microsecond. This results in the fact, that on the Amstrad all Z80 commands take an exact multiple of 1 microsec (="NOP").
Currently I don't find an english website about it, but here are the timings listed on a german site:

Das Schneider CPC Systembuch: Anhang: Die Z80: Ausführungszeiten für die
column "Zeit" = microsecs

Hope this already helps. I wonder, if there is also information in english or spanish available in the internet.

CU,
Prodatron