For the z80 we're not there yet but things aren't too bad either. Sometimes I look at the code generated and think "hey, that's pretty good", more often it's "alright, that's acceptable" (this is largely down to zsdcc using ix for a stack frame, something that would rarely be done in asm) and occasionally it's "wtf?. If you need to recover speed or code size, you change that C code or rewrite that part in asm. After some experience you get an idea of what will lead to better code, what will lead to bad code and what should be done in asm (hopefully we have a large part of the latter group covered by the assembly language libraries). Keep in mind only a fraction of the code in a project is in the time critical path so for most code it doesn't matter if you have optimal asm or not and that's where something like c can shine as it can save a great deal of development time and can promote innovation because it's easier to try things that would be difficult or time consuming to do in pure asm. The try in C and implement in asm when necessary is also a fruitful development path.
There are some things to keep in mind to help the code generators: use unsigned numbers whenever possible, use the smallest type possible (zsdcc especially does well with unsigned char), keep C functions uncomplicated when possible - if they get big split them, don't rely on the compilers to notice that intermediate values can be eliminated - do that explicitly instead, and try to reduce the number of parameters passed to a function. As always the best way to find out if the generated code is better one way or another is to look at the compiler output. I'd suggest writing C code as you normally would and then have a look at the generated code to see if something's gone awry if performance or code size seems poor. Most of the time you won't have to change anything.
However, even at 3.5MHz we do get pretty good results (there are 40-50 games out there using software sprites already) and at 28MHz with graphics hardware there is a lot of room to be imperfect. Even interpreted basic can do interesting things at that speed.
No I don't think so. There are reasons to use sccz80 instead of zsdcc.By the looks of is zsdcc does a very good job and is superior to the old compiler. Sccz80 will be phased out in the future?
Anyone using zsdcc will soon discover that with optimization set high (-SO3 --max-allocs-per-node200000) the compiler can be very slow. I have programs that take 15-25 minutes to compile on my laptop. This is for the 48k spectrum. Now imagine writing C code for the Next and its megabyte of memory (assuming C code fills a lot of space rather than just data which contributes little time to compilation). In this circumstance sccz80 becomes a very good development compiler since it can do quick modify/build cycles while writing code and then zsdcc could be used for release builds or for testing. Doing this does mean you need to restrict yourself to a smaller subset of C that sccz80 supports (principally no multi-dimensional arrays and you may not want to do this). You can also try reducing optimization level on zsdcc to speed things up but that will result in bigger code which may not fit in the designated memory space and it still may be slow. Moving to a makefile to build a project would help to mitigate this.
In the immediate future we will be moving to allow sccz80- and zsdcc-generated object files to be mixed in the same compile so that either compiler can be used for a particular .c file. At the moment this isn't possible for the most part for technical reasons.
Yes. You may have to synchronize with the raster before moving sprites to avoid gaps being display between them if only some positions are updated when the raster crosses the sprites. You don't even need to do it the "spectrum way" as you can either poll the current raster line or you can create a raster interrupt that will execute/flag after the last raster line is drawn at the bottom of the screen. Not having to wait for a vbi interrupt (raster line = 0) gives you even more time to finish updates.Yes, I was thinking about a very simple demo "Pong" program where the ball is one sprite (extremely simple as it is a black square) and the bats are 4 stacked sprites acting as one group (same black squares, so a lot easier than making a bad guy). This would be about the most basic example still showing the movement, bouncing and collision detection (with the walls, the bat groups and the border). With these sprites it should be easy.