62 replies to this topic

[Synthpopalooza]

I had another thought ... it may be possible to save memory during the action scenes, where the picture doesn't change, just the characters which move around ... rather than try to image each frame.

[devwebcl]

Synthpopalooza, on Tue May 8, 2012 5:40 PM, said:

I had another thought ... it may be possible to save memory during the action scenes, where the picture doesn't change, just the characters which move around ... rather than try to image each frame.

that's the technic from gameboy color version.

[kenjennings]

Synthpopalooza, on Tue May 8, 2012 5:40 PM, said:

I had another thought ... it may be possible to save memory during the action scenes, where the picture doesn't change, just the characters which move around ... rather than try to image each frame.

Yup.  In many of the scenes the background is static with the character motion in the foreground.   Construct one background image reserving a portion of the pallete for that, then the only thing that changes is the moving characters.   The compression and playback of those sequences should be efficient.  

Unfortunately, not every scene is like that.   There are some where the scene pans which requires complete screen animation.  (or a very difficult horizontal scroll.)

[Stephen]

You'll never get anywhere near 12fps if you plan on using SIO devices.  Best I have managed on SDX using a CF based hard drive with screen DMA on is around 64kB/sec.  To do 12 fps loading that, you would be limited to 5.3kB per screen.  Good luck.

[Synthpopalooza]

5.3kb per screen might not be an issue if it's done using GraphicsTileMaster ... a PCIN mode pic would be about 2k for the double font and another 960 bytes for the screen data when compressed this way.  Take it down to about 768 bytes if we use narrow mode.

Edited by Synthpopalooza, Tue May 8, 2012 8:41 PM.

[Stephen]

Synthpopalooza, on Tue May 8, 2012 8:38 PM, said:

5.3kb per screen might not be an issue if it's done using GraphicsTileMaster ... a PCIN mode pic would be about 2k for the double font and another 960 bytes for the screen data when compressed this way.  Take it down to about 768 bytes if we use narrow mode.

Nice - I didn't realize they were that small!

[Chilly Willy]

The Atari ST and Amiga versions of the game got by with "standard" floppy rates, which are about 20 KB/sec. This was also on a higher resolution display with more color. It's all a matter of how you handle the images - as mentioned, most screens are static with only a few things changing. In the articles where they talked about making the ST/Amiga versions, the devs talked about how they grabbed the screens, cleaned then up, and pulled the moving objects off the unchanging background.

[Rybags]

I don't get the point of this game.  I watched a video of the ST version and there seems to be no user involvement in what's going on.

Or is it a case of having to hit the button or a direction at some certain time to take the favourable path?

[Chilly Willy]

Rybags, on Tue May 8, 2012 10:05 PM, said:

I don't get the point of this game.  I watched a video of the ST version and there seems to be no user involvement in what's going on.

Or is it a case of having to hit the button or a direction at some certain time to take the favourable path?

The latter. All those Video Disc games have you press a button or pick a direction at particular points to choose where the game goes next. In simple games like Dragon's Lair, the choice is death or continuing to the next segment. Space is basically the same.

[rdemming]

Chilly Willy, on Tue May 8, 2012 10:02 PM, said:

The Atari ST and Amiga versions of the game got by with "standard" floppy rates, which are about 20 KB/sec. This was also on a higher resolution display with more color. It's all a matter of how you handle the images - as mentioned, most screens are static with only a few things changing. In the articles where they talked about making the ST/Amiga versions, the devs talked about how they grabbed the screens, cleaned then up, and pulled the moving objects off the unchanging background.

I don't know how the Amiga/ST versions handled it but they have the CPU power to do decompression or other tricks as you describe. And also reading floppy data is using DMA so you need very little CPU time to load data so the CPU can decompress while loading the next data.
The Atari 8-bit does not have DMA loading so the CPU is occupied during loading. Combined with less CPU power there would be little time left to do decompression.

Robert

[Rybags]

Loading on the fly is possible but that takes away media independence and limits any DLI or kernal graphics trickery available.

The way I see it, big Ram + TIP Animator type tricks would do the trick.  But even a 1 Meg cart probably won't fit the bill - could be more a case of large IDE storage or big images over SIO2xx.

[Stephen]

Rybags, on Tue May 8, 2012 10:05 PM, said:

I don't get the point of this game.  I watched a video of the ST version and there seems to be no user involvement in what's going on.

Or is it a case of having to hit the button or a direction at some certain time to take the favourable path?

I always hated these games too.  It would be cool to see the little A8 pull it off, but I consider these to be "interactive slide shows", not games.

[Chilly Willy]

rdemming, on Wed May 9, 2012 2:43 AM, said:

Chilly Willy, on Tue May 8, 2012 10:02 PM, said:

The Atari ST and Amiga versions of the game got by with "standard" floppy rates, which are about 20 KB/sec. This was also on a higher resolution display with more color. It's all a matter of how you handle the images - as mentioned, most screens are static with only a few things changing. In the articles where they talked about making the ST/Amiga versions, the devs talked about how they grabbed the screens, cleaned then up, and pulled the moving objects off the unchanging background.

I don't know how the Amiga/ST versions handled it but they have the CPU power to do decompression or other tricks as you describe. And also reading floppy data is using DMA so you need very little CPU time to load data so the CPU can decompress while loading the next data.
The Atari 8-bit does not have DMA loading so the CPU is occupied during loading. Combined with less CPU power there would be little time left to do decompression.

Robert

Yes, the ST and Amiga are more powerful, and the disc loading (should) take less CPU time, but the A8 at least uses interrupts for the serial so you don't have to sit in a loop polling the serial. Many games use serial loading from the floppy at the same time as they do something else - look the LucasFilm intros that run while the game loads. However, the higher speed the serial (which we want for faster loading), the more cpu time will be taken by the loader code leaving less for other tasks like decompression. I suspect some tests will be needed to find the "sweet spot" between serial frequency and CPU overhead.