This is an "old" experiment to use char based software sprites, with source included. Plus a nice intro using pcm 4+4 samples, with the screen on (the only reason for this to use a 1MB cartridge).
Many thanks to MrFish for improving the original graphics, adding color to the level, and creating that nice car
Features: - 10 cars with logic to check collisions and move through the maze, every car with a different speed and acceleration. - char based, pre shifted and pre compiled software sprites (with sizes that changes between 2x3, 3x2 and 2x2 chars). - full copy of the background and proper masking for every sprite. - NTSC, 60 fps, with free time to do 1 or 2 more cars probably (more in PAL). - double buffered screen (40x25, antic4 graphic mode) and font. - some DLI's used through the screen, to add extra color (no interleaved fonts).
I did a second version of this, but without using pre compiled sprites. Reading the data from tables I could display 7 cars in more or less the same time (not bad I suppose).
But after my experiments with software sprites years ago, I was a little disappointed with the results that I got. I mean, using software sprites in a bitmap mode is a lot simpler and probably faster in some cases, than using the same resolution in a char mode. For example, if you have many small sprites (let's say 4x2 pixels) in char mode, you are going to need to touch (copy) a lot more memory, than using those same sprites in graphic mode (in average). And in general you are going to move more memory in a char mode, for sprites of the same (small - medium) size.
The good thing with using chars is that you can get an extra color, or do some visual tricks just plotting chars, or maybe do font animations without touching the screen data. And restoring the screen ("erasing" the sprites), should be faster than in a graphic mode. Probably with bigger sprites, using chars is a win-win.
Pre shifted and pre compiled sprites use a lot of memory by definition. In this case the car has 28 frames (4 going right, 4 going left, 4 diagonals, 8 going up, 8 going down), that amounts to something below 12KB. I probably could reduce that number to something below 9KB, by optimizing the size of the 16 frames for the vertical movement, that also include the empty space at the start and end of the car (to pad to the height of 3 chars). I did it like that just because it was faster and easier to implement.
The pre-shifted frames are also used to have the tires animation, so they have more reason to exist.
I 've been doing some testing of the PWM technique to play samples (thanks Phaeron and Xuel for the examples).
Is nothing great, but I think that maybe the code could be of use to people doing similar experiments.
It's for a 1Mb cart and there are two small songs only, but in different qualities.
The options are:
1 - Song 1, PWM at 15720 Hz, sample values between 0 and 109, a little lower than 7bit depth. "Normal" PWM quality, with one sample per scan line.
2 - Song 1, PWM at 21013 Hz, sample values between 0 and 80, higher than 6bit depth. This is a failed experiment.. I tried to play 4 samples every 3 scan lines, but getting the perfect timing for this seems impossible, because of the refresh cycles.
I wasn't that far off, but the small imperfections in timing are enough to add an undesired frequency sound.
3 - Song 1, PWM at 31440 Hz, sample values between 0 and 52, lower than 6bit depth. This worked well but it eats memory x) (30 seconds max for a 1Mb cart).
This plays two samples per scan line, the timing was a little tricky because you need to avoid the refresh cycles and also balance your worst case code branch with the rest of the code.
The good thing is that the normal carrier frequency produced by PWM (that at 15KHz is still annoying for some people) is not an issue.
The bad thing is that playing more samples in the same time, implies that the bit depth is lower (for PWM).. so at the end of the day I don't think this is an improvement over the 15KHz PWM.
4 - Song 1, at 15720 Hz, sample values between 0 and 15, classic 4bit depth. This could sound better, but I didn't allowed much clipping, so maybe the volume is too low.
5 - Song 2, PWM at 15720 Hz, same as the first option, but with a larger song.
The 15720 Hz rate sounds perfect in NTSC and just a bit slower in PAL (there the rate should be 15600 Hz).
All samples converted with Sox and then with some scripts in C#, to move the data to the correct range allowed by every method.
Main code is in rtech_cart.asm, done in Mads.
I think that using 15KHz PWM is an improvement over the classic 4bit sound, if you are playing songs without much silence (where the 15Khz carrier frequency can bother some people).
Also you can do some simple track sequencing with the screen on, so a nice intro for a game in a 1MB cart can use this. I already have code for this, but that's coming later
Here is a port of the Solaria "teaser" done for our A8's (ntsc version only for now). The original palette used the 256 colors of the 7800, so it loses some of the more subtle color variations of the background, but is more or less the same. Also the scrolling text doesn't start from the bottom.. that maybe can be done, but it would be a pain in the ass x) It can be moved down right now, but it doesn't look that good starting near the sun (it loses legibility).