Synthpopalooza Posted May 8, 2012 Share Posted May 8, 2012 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. Quote Link to comment Share on other sites More sharing options...
devwebcl Posted May 9, 2012 Share Posted May 9, 2012 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. Quote Link to comment Share on other sites More sharing options...
kenjennings Posted May 9, 2012 Share Posted May 9, 2012 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.) Quote Link to comment Share on other sites More sharing options...
+Stephen Posted May 9, 2012 Share Posted May 9, 2012 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. Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted May 9, 2012 Share Posted May 9, 2012 (edited) 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 May 9, 2012 by Synthpopalooza 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted May 9, 2012 Share Posted May 9, 2012 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! Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted May 9, 2012 Share Posted May 9, 2012 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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 9, 2012 Share Posted May 9, 2012 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? Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted May 9, 2012 Share Posted May 9, 2012 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. Quote Link to comment Share on other sites More sharing options...
+rdemming Posted May 9, 2012 Share Posted May 9, 2012 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 Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 9, 2012 Share Posted May 9, 2012 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. Quote Link to comment Share on other sites More sharing options...
+Stephen Posted May 9, 2012 Share Posted May 9, 2012 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. Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted May 10, 2012 Share Posted May 10, 2012 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.