RE: Dizzy (was: Porting spectrum games...)
Thanks, ill have a quick go. The only thing wil be PNG is a very good format for compression. Are these colour reduced to sam already or not? Adrian -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: 29 July 2010 19:31 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) Oh, but I haven't actually tested the output stream yet. So for all I know, some error is lurking somewhere making my numbers smaller by accidentally throwing data away... On Thu, Jul 29, 2010 at 7:00 PM, Thomas Harte tomh.retros...@gmail.com wrote: I'll wager you can do better at compression than I can at present, as I'm almost completely new to this. But that makes it interesting. It's obviously wrong to focus too heavily on any test set, but I've bundled together the five images I'm currently testing with, in their optimal PNG forms, and uploaded to http://members.allegro.cc/ThomasHarte/temp/SamTestScreens.zip You should get files screen1 to screen5 (two from Dizzy, three from Flashback) which as PNGs are sized 5,553, 6,108, 10,643, 10,005 and 11,533 bytes respectively. The only thing implicit in my output data is that the images are 256 pixels wide. Not all are 192 pixels high but the height is left implicit from the total number of pixels. Palettes are included with the images. With that in mind, I'm currently at 5,531, 7,273, 11,956, 10,538 and 12,367 bytes. But still working on it. So I won't take offence if you embarrass me thoroughly... On Thu, Jul 29, 2010 at 4:18 PM, Adrian Brown adr...@apbcomputerservices.co.uk wrote: I hope these will support the EEPROM highscore saving or similar ;). Ive got some strange compression modes, bung me the image and ill see how well i can compress it. Good to see people looking at the Sam again. Im hoping to get some more time on Sam Uip soon Adrian -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: 28 July 2010 22:31 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) Hmmm, not doing very well with the Flashback image I chose to test (the top left screen) at all. PNG is 10,649 bytes and I'm 13,507 bytes. But unlike yesterday, that's with the Huffman tree stored (whoops!) and the palette thrown on. I've also tweaked the LZ77 stage a bit, so it's now a 256 pixel rolling buffer with repetitions up to 18 pixels in length and the entire screen compressed as one block. That said, at one point the storage space for all three images seemed to go up by about 1.5kb for absolutely no reason. So I don't thoroughly trust my code. I've tried sorting the palette by hue (to give it some sort of likelihood that nearby colours are near each other in the palette) and applying the various PNG prediction filters to the entire image with each and every one causing the file size to grow. Which is quiet probably why PNG picks them line by line. So that's the experiment for tomorrow night... On Wed, Jul 28, 2010 at 10:53 AM, Thomas Harte tomh.retros...@gmail.com wrote: The previously posted Fantasy World Dizzy map seems to have come from 'Hall of Light', which offers itself as 'the database of Amiga games' at http://hol.abime.net/. You can't just chop up the map and reuse it though, as they've watermarked it with an alpha transparency. It's large but quite spaced out, so I've just used screens that the watermark doesn't touch. And probably if you had a piece of software that was at all competent at reducing colour depth then you'd be able to wash it off again. On Wed, Jul 28, 2010 at 10:03 AM, Stefan Drissen stefan.dris...@gmail.com wrote: For Amiga Treasure Island Dizzy: http://www.vgmaps.com/Atlas/Amiga/TreasureIslandDizzy-TreasureIsland.png The www.vgmaps.com site has quite a few more cool maps (for example the Flashback ones in my previous post). Stefan -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Andrew Park Sent: Wednesday, July 28, 2010 10:29 To: sam-users@nvg.ntnu.no Subject: RE: Dizzy (was: Porting spectrum games...) It is great to see some activity on here again, 1 quick question where did the amiga dizzy map come from to get screens, i've been looking for good amiga screenshot maps everywhere as i'm not an artist and this stops me writing games, i like to see graphical progress when i'm writing. Anybody send me a link? Andy -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: 28 July 2010 00:11 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) Actually, late night spurt - with Huffman trees it's 5,528 bytes and 6,653 bytes respectively. No predictor yet. The former technically beats the PNG size, but I'd imagine
Re: Dizzy (was: Porting spectrum games...)
Actually, late night spurt — with Huffman trees it's 5,528 bytes and 6,653 bytes respectively. So going with the lowest figure I make that 330k for the whole map. The watermark isn't a problem as I'd want to make up each screen by hand anyway. I'd be happy to make a couple of test screens up for you to test your routines on but I'd have to put off doing the whole map until after I finish my current project. I don't think it would take a great deal of time to do but neither will my current thing and I really think I should finish one before starting another :)
Re: Dizzy (was: Porting spectrum games...)
Actually, I guess you don't really need test screens for what you're doing. the offer is there anyhow :)
RE: Dizzy (was: Porting spectrum games...)
I hope these will support the EEPROM highscore saving or similar ;). Ive got some strange compression modes, bung me the image and ill see how well i can compress it. Good to see people looking at the Sam again. Im hoping to get some more time on Sam Uip soon Adrian -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: 28 July 2010 22:31 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) Hmmm, not doing very well with the Flashback image I chose to test (the top left screen) at all. PNG is 10,649 bytes and I'm 13,507 bytes. But unlike yesterday, that's with the Huffman tree stored (whoops!) and the palette thrown on. I've also tweaked the LZ77 stage a bit, so it's now a 256 pixel rolling buffer with repetitions up to 18 pixels in length and the entire screen compressed as one block. That said, at one point the storage space for all three images seemed to go up by about 1.5kb for absolutely no reason. So I don't thoroughly trust my code. I've tried sorting the palette by hue (to give it some sort of likelihood that nearby colours are near each other in the palette) and applying the various PNG prediction filters to the entire image with each and every one causing the file size to grow. Which is quiet probably why PNG picks them line by line. So that's the experiment for tomorrow night... On Wed, Jul 28, 2010 at 10:53 AM, Thomas Harte tomh.retros...@gmail.com wrote: The previously posted Fantasy World Dizzy map seems to have come from 'Hall of Light', which offers itself as 'the database of Amiga games' at http://hol.abime.net/. You can't just chop up the map and reuse it though, as they've watermarked it with an alpha transparency. It's large but quite spaced out, so I've just used screens that the watermark doesn't touch. And probably if you had a piece of software that was at all competent at reducing colour depth then you'd be able to wash it off again. On Wed, Jul 28, 2010 at 10:03 AM, Stefan Drissen stefan.dris...@gmail.com wrote: For Amiga Treasure Island Dizzy: http://www.vgmaps.com/Atlas/Amiga/TreasureIslandDizzy-TreasureIsland.png The www.vgmaps.com site has quite a few more cool maps (for example the Flashback ones in my previous post). Stefan -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Andrew Park Sent: Wednesday, July 28, 2010 10:29 To: sam-users@nvg.ntnu.no Subject: RE: Dizzy (was: Porting spectrum games...) It is great to see some activity on here again, 1 quick question where did the amiga dizzy map come from to get screens, i've been looking for good amiga screenshot maps everywhere as i'm not an artist and this stops me writing games, i like to see graphical progress when i'm writing. Anybody send me a link? Andy -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: 28 July 2010 00:11 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) Actually, late night spurt - with Huffman trees it's 5,528 bytes and 6,653 bytes respectively. No predictor yet. The former technically beats the PNG size, but I'd imagine that just means the predictor is barely going to help and I'm gaining a small win by not including any of the normal file padding or headers. Or even the palette. On Tue, Jul 27, 2010 at 11:47 PM, Thomas Harte tomh.retros...@gmail.com wrote: Further to this: I've been playing around with it today using a couple of the more complicated screens from that Amiga map which didn't feature the watermark (since it's an alpha transparency, causing the number of colours to skyrocket), resized to 256 pixels across (which makes 141 pixels high). For a sensible lower bound on what I should expect, I saved them as PNGs and ran them through OptiPNG, PNGCrush, and AdvPNG, keeping the smallest version. The first (Dylan and a tree) is 5,553 bytes as a PNG. The second (featuring the Armorog) 6,108 bytes. In my quick dash at compression code, I implemented just a trivial little LZ77, using an exhaustive search to pattern match and treating each scan line as a completely separate thing to compress (and, as a result, rounded up to the next full byte). Five bits for a literal, 17 for a back reference, the native addressable thing being a nibble. From that, I got 6,080 bytes for the first screen and 7,170 for the second. And this is without yet implementing a Huffman tree (probably best done per screen) or any sort of predictor. So, it looks like on a 16 colour display the LZ77 may actually be the most of it. In which case it's going to be hard to support the conclusion that PNG is massively better than the various common techniques when the Sam was a going concern. A Huffman tree is an easy win and something I'll experiment with tomorrow hopefully
Re: Dizzy (was: Porting spectrum games...)
I'll wager you can do better at compression than I can at present, as I'm almost completely new to this. But that makes it interesting. It's obviously wrong to focus too heavily on any test set, but I've bundled together the five images I'm currently testing with, in their optimal PNG forms, and uploaded to http://members.allegro.cc/ThomasHarte/temp/SamTestScreens.zip You should get files screen1 to screen5 (two from Dizzy, three from Flashback) which as PNGs are sized 5,553, 6,108, 10,643, 10,005 and 11,533 bytes respectively. The only thing implicit in my output data is that the images are 256 pixels wide. Not all are 192 pixels high but the height is left implicit from the total number of pixels. Palettes are included with the images. With that in mind, I'm currently at 5,531, 7,273, 11,956, 10,538 and 12,367 bytes. But still working on it. So I won't take offence if you embarrass me thoroughly... On Thu, Jul 29, 2010 at 4:18 PM, Adrian Brown adr...@apbcomputerservices.co.uk wrote: I hope these will support the EEPROM highscore saving or similar ;). Ive got some strange compression modes, bung me the image and ill see how well i can compress it. Good to see people looking at the Sam again. Im hoping to get some more time on Sam Uip soon Adrian -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: 28 July 2010 22:31 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) Hmmm, not doing very well with the Flashback image I chose to test (the top left screen) at all. PNG is 10,649 bytes and I'm 13,507 bytes. But unlike yesterday, that's with the Huffman tree stored (whoops!) and the palette thrown on. I've also tweaked the LZ77 stage a bit, so it's now a 256 pixel rolling buffer with repetitions up to 18 pixels in length and the entire screen compressed as one block. That said, at one point the storage space for all three images seemed to go up by about 1.5kb for absolutely no reason. So I don't thoroughly trust my code. I've tried sorting the palette by hue (to give it some sort of likelihood that nearby colours are near each other in the palette) and applying the various PNG prediction filters to the entire image with each and every one causing the file size to grow. Which is quiet probably why PNG picks them line by line. So that's the experiment for tomorrow night... On Wed, Jul 28, 2010 at 10:53 AM, Thomas Harte tomh.retros...@gmail.com wrote: The previously posted Fantasy World Dizzy map seems to have come from 'Hall of Light', which offers itself as 'the database of Amiga games' at http://hol.abime.net/. You can't just chop up the map and reuse it though, as they've watermarked it with an alpha transparency. It's large but quite spaced out, so I've just used screens that the watermark doesn't touch. And probably if you had a piece of software that was at all competent at reducing colour depth then you'd be able to wash it off again. On Wed, Jul 28, 2010 at 10:03 AM, Stefan Drissen stefan.dris...@gmail.com wrote: For Amiga Treasure Island Dizzy: http://www.vgmaps.com/Atlas/Amiga/TreasureIslandDizzy-TreasureIsland.png The www.vgmaps.com site has quite a few more cool maps (for example the Flashback ones in my previous post). Stefan -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Andrew Park Sent: Wednesday, July 28, 2010 10:29 To: sam-users@nvg.ntnu.no Subject: RE: Dizzy (was: Porting spectrum games...) It is great to see some activity on here again, 1 quick question where did the amiga dizzy map come from to get screens, i've been looking for good amiga screenshot maps everywhere as i'm not an artist and this stops me writing games, i like to see graphical progress when i'm writing. Anybody send me a link? Andy -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: 28 July 2010 00:11 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) Actually, late night spurt - with Huffman trees it's 5,528 bytes and 6,653 bytes respectively. No predictor yet. The former technically beats the PNG size, but I'd imagine that just means the predictor is barely going to help and I'm gaining a small win by not including any of the normal file padding or headers. Or even the palette. On Tue, Jul 27, 2010 at 11:47 PM, Thomas Harte tomh.retros...@gmail.com wrote: Further to this: I've been playing around with it today using a couple of the more complicated screens from that Amiga map which didn't feature the watermark (since it's an alpha transparency, causing the number of colours to skyrocket), resized to 256 pixels across (which makes 141 pixels high). For a sensible lower bound on what I should expect, I saved them as PNGs and ran them through OptiPNG
Re: Dizzy (was: Porting spectrum games...)
Oh, but I haven't actually tested the output stream yet. So for all I know, some error is lurking somewhere making my numbers smaller by accidentally throwing data away... On Thu, Jul 29, 2010 at 7:00 PM, Thomas Harte tomh.retros...@gmail.com wrote: I'll wager you can do better at compression than I can at present, as I'm almost completely new to this. But that makes it interesting. It's obviously wrong to focus too heavily on any test set, but I've bundled together the five images I'm currently testing with, in their optimal PNG forms, and uploaded to http://members.allegro.cc/ThomasHarte/temp/SamTestScreens.zip You should get files screen1 to screen5 (two from Dizzy, three from Flashback) which as PNGs are sized 5,553, 6,108, 10,643, 10,005 and 11,533 bytes respectively. The only thing implicit in my output data is that the images are 256 pixels wide. Not all are 192 pixels high but the height is left implicit from the total number of pixels. Palettes are included with the images. With that in mind, I'm currently at 5,531, 7,273, 11,956, 10,538 and 12,367 bytes. But still working on it. So I won't take offence if you embarrass me thoroughly... On Thu, Jul 29, 2010 at 4:18 PM, Adrian Brown adr...@apbcomputerservices.co.uk wrote: I hope these will support the EEPROM highscore saving or similar ;). Ive got some strange compression modes, bung me the image and ill see how well i can compress it. Good to see people looking at the Sam again. Im hoping to get some more time on Sam Uip soon Adrian -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: 28 July 2010 22:31 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) Hmmm, not doing very well with the Flashback image I chose to test (the top left screen) at all. PNG is 10,649 bytes and I'm 13,507 bytes. But unlike yesterday, that's with the Huffman tree stored (whoops!) and the palette thrown on. I've also tweaked the LZ77 stage a bit, so it's now a 256 pixel rolling buffer with repetitions up to 18 pixels in length and the entire screen compressed as one block. That said, at one point the storage space for all three images seemed to go up by about 1.5kb for absolutely no reason. So I don't thoroughly trust my code. I've tried sorting the palette by hue (to give it some sort of likelihood that nearby colours are near each other in the palette) and applying the various PNG prediction filters to the entire image with each and every one causing the file size to grow. Which is quiet probably why PNG picks them line by line. So that's the experiment for tomorrow night... On Wed, Jul 28, 2010 at 10:53 AM, Thomas Harte tomh.retros...@gmail.com wrote: The previously posted Fantasy World Dizzy map seems to have come from 'Hall of Light', which offers itself as 'the database of Amiga games' at http://hol.abime.net/. You can't just chop up the map and reuse it though, as they've watermarked it with an alpha transparency. It's large but quite spaced out, so I've just used screens that the watermark doesn't touch. And probably if you had a piece of software that was at all competent at reducing colour depth then you'd be able to wash it off again. On Wed, Jul 28, 2010 at 10:03 AM, Stefan Drissen stefan.dris...@gmail.com wrote: For Amiga Treasure Island Dizzy: http://www.vgmaps.com/Atlas/Amiga/TreasureIslandDizzy-TreasureIsland.png The www.vgmaps.com site has quite a few more cool maps (for example the Flashback ones in my previous post). Stefan -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Andrew Park Sent: Wednesday, July 28, 2010 10:29 To: sam-users@nvg.ntnu.no Subject: RE: Dizzy (was: Porting spectrum games...) It is great to see some activity on here again, 1 quick question where did the amiga dizzy map come from to get screens, i've been looking for good amiga screenshot maps everywhere as i'm not an artist and this stops me writing games, i like to see graphical progress when i'm writing. Anybody send me a link? Andy -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: 28 July 2010 00:11 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) Actually, late night spurt - with Huffman trees it's 5,528 bytes and 6,653 bytes respectively. No predictor yet. The former technically beats the PNG size, but I'd imagine that just means the predictor is barely going to help and I'm gaining a small win by not including any of the normal file padding or headers. Or even the palette. On Tue, Jul 27, 2010 at 11:47 PM, Thomas Harte tomh.retros...@gmail.com wrote: Further to this: I've been playing around with it today using a couple of the more complicated screens from that Amiga map which didn't
RE: Dizzy (was: Porting spectrum games...)
It is great to see some activity on here again, 1 quick question where did the amiga dizzy map come from to get screens, i've been looking for good amiga screenshot maps everywhere as i'm not an artist and this stops me writing games, i like to see graphical progress when i'm writing. Anybody send me a link? Andy -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: 28 July 2010 00:11 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) Actually, late night spurt with Huffman trees it's 5,528 bytes and 6,653 bytes respectively. No predictor yet. The former technically beats the PNG size, but I'd imagine that just means the predictor is barely going to help and I'm gaining a small win by not including any of the normal file padding or headers. Or even the palette. On Tue, Jul 27, 2010 at 11:47 PM, Thomas Harte tomh.retros...@gmail.com wrote: Further to this: I've been playing around with it today using a couple of the more complicated screens from that Amiga map which didn't feature the watermark (since it's an alpha transparency, causing the number of colours to skyrocket), resized to 256 pixels across (which makes 141 pixels high). For a sensible lower bound on what I should expect, I saved them as PNGs and ran them through OptiPNG, PNGCrush, and AdvPNG, keeping the smallest version. The first (Dylan and a tree) is 5,553 bytes as a PNG. The second (featuring the Armorog) 6,108 bytes. In my quick dash at compression code, I implemented just a trivial little LZ77, using an exhaustive search to pattern match and treating each scan line as a completely separate thing to compress (and, as a result, rounded up to the next full byte). Five bits for a literal, 17 for a back reference, the native addressable thing being a nibble. From that, I got 6,080 bytes for the first screen and 7,170 for the second. And this is without yet implementing a Huffman tree (probably best done per screen) or any sort of predictor. So, it looks like on a 16 colour display the LZ77 may actually be the most of it. In which case it's going to be hard to support the conclusion that PNG is massively better than the various common techniques when the Sam was a going concern. A Huffman tree is an easy win and something I'll experiment with tomorrow hopefully and a predictor is a useful addition even when dealing with hard edged low colour graphics because it introduces the second dimension as a going concern whereas LZ77 has no concept of that. Would it be possible to get a single screen hand prepared to be really beautiful rather than ripped from a tilemap? On Tue, Jul 27, 2010 at 10:46 AM, Stefan Drissen stefan.dris...@gmail.com wrote: Fair enough. You could of course create PNG tiles so that you do not need to Flash! anything. You could then even also use a 256-colour PNG image as map editor, the colour determining the tile... ;-) Flashback would be very cool - on the PC I don't remember it having scrolling. You would however also need to create an animated PNG / MPEG player for the animated sequences. Lots of fun things to do... :-) -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of the_wub ! Sent: Monday, July 26, 2010 19:21 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) If png's can be used then I think we should do it even if using an image of tiles is a bit ironic! It would allow changes to be made to the image in the gimp rather than flash! if nothing else! ;) If a success, I don't dare to dream about scumm but another possible port would be Flashback, I can't remember how much if any scrolling is in there but something would be possible if pngs could be used as source gfx... I don't know enough to comment on the feasibility of it all but I do have a question, why use the PC bitmaps and not the ST? The Atari is already 16 colours and it would be easy enough to fancy them up a bit, make them a bit less tiley.. I'm saying this without having a good look at how the PC gfx would work in 16 colours though... Hey Warren! I'd guess that whichever direction the project goes there'll be tons to do. The more the merrier I say :)
RE: Dizzy (was: Porting spectrum games...)
For Amiga Treasure Island Dizzy: http://www.vgmaps.com/Atlas/Amiga/TreasureIslandDizzy-TreasureIsland.png The www.vgmaps.com site has quite a few more cool maps (for example the Flashback ones in my previous post). Stefan -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Andrew Park Sent: Wednesday, July 28, 2010 10:29 To: sam-users@nvg.ntnu.no Subject: RE: Dizzy (was: Porting spectrum games...) It is great to see some activity on here again, 1 quick question where did the amiga dizzy map come from to get screens, i've been looking for good amiga screenshot maps everywhere as i'm not an artist and this stops me writing games, i like to see graphical progress when i'm writing. Anybody send me a link? Andy -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: 28 July 2010 00:11 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) Actually, late night spurt with Huffman trees it's 5,528 bytes and 6,653 bytes respectively. No predictor yet. The former technically beats the PNG size, but I'd imagine that just means the predictor is barely going to help and I'm gaining a small win by not including any of the normal file padding or headers. Or even the palette. On Tue, Jul 27, 2010 at 11:47 PM, Thomas Harte tomh.retros...@gmail.com wrote: Further to this: I've been playing around with it today using a couple of the more complicated screens from that Amiga map which didn't feature the watermark (since it's an alpha transparency, causing the number of colours to skyrocket), resized to 256 pixels across (which makes 141 pixels high). For a sensible lower bound on what I should expect, I saved them as PNGs and ran them through OptiPNG, PNGCrush, and AdvPNG, keeping the smallest version. The first (Dylan and a tree) is 5,553 bytes as a PNG. The second (featuring the Armorog) 6,108 bytes. In my quick dash at compression code, I implemented just a trivial little LZ77, using an exhaustive search to pattern match and treating each scan line as a completely separate thing to compress (and, as a result, rounded up to the next full byte). Five bits for a literal, 17 for a back reference, the native addressable thing being a nibble. From that, I got 6,080 bytes for the first screen and 7,170 for the second. And this is without yet implementing a Huffman tree (probably best done per screen) or any sort of predictor. So, it looks like on a 16 colour display the LZ77 may actually be the most of it. In which case it's going to be hard to support the conclusion that PNG is massively better than the various common techniques when the Sam was a going concern. A Huffman tree is an easy win and something I'll experiment with tomorrow hopefully and a predictor is a useful addition even when dealing with hard edged low colour graphics because it introduces the second dimension as a going concern whereas LZ77 has no concept of that. Would it be possible to get a single screen hand prepared to be really beautiful rather than ripped from a tilemap? On Tue, Jul 27, 2010 at 10:46 AM, Stefan Drissen stefan.dris...@gmail.com wrote: Fair enough. You could of course create PNG tiles so that you do not need to Flash! anything. You could then even also use a 256-colour PNG image as map editor, the colour determining the tile... ;-) Flashback would be very cool - on the PC I don't remember it having scrolling. You would however also need to create an animated PNG / MPEG player for the animated sequences. Lots of fun things to do... :-) -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of the_wub ! Sent: Monday, July 26, 2010 19:21 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) If png's can be used then I think we should do it even if using an image of tiles is a bit ironic! It would allow changes to be made to the image in the gimp rather than flash! if nothing else! ;) If a success, I don't dare to dream about scumm but another possible port would be Flashback, I can't remember how much if any scrolling is in there but something would be possible if pngs could be used as source gfx... I don't know enough to comment on the feasibility of it all but I do have a question, why use the PC bitmaps and not the ST? The Atari is already 16 colours and it would be easy enough to fancy them up a bit, make them a bit less tiley.. I'm saying this without having a good look at how the PC gfx would work in 16 colours though... Hey Warren! I'd guess that whichever direction the project goes there'll be tons to do. The more the merrier I say :)
Re: Dizzy (was: Porting spectrum games...)
The previously posted Fantasy World Dizzy map seems to have come from 'Hall of Light', which offers itself as 'the database of Amiga games' at http://hol.abime.net/. You can't just chop up the map and reuse it though, as they've watermarked it with an alpha transparency. It's large but quite spaced out, so I've just used screens that the watermark doesn't touch. And probably if you had a piece of software that was at all competent at reducing colour depth then you'd be able to wash it off again. On Wed, Jul 28, 2010 at 10:03 AM, Stefan Drissen stefan.dris...@gmail.com wrote: For Amiga Treasure Island Dizzy: http://www.vgmaps.com/Atlas/Amiga/TreasureIslandDizzy-TreasureIsland.png The www.vgmaps.com site has quite a few more cool maps (for example the Flashback ones in my previous post). Stefan -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Andrew Park Sent: Wednesday, July 28, 2010 10:29 To: sam-users@nvg.ntnu.no Subject: RE: Dizzy (was: Porting spectrum games...) It is great to see some activity on here again, 1 quick question where did the amiga dizzy map come from to get screens, i've been looking for good amiga screenshot maps everywhere as i'm not an artist and this stops me writing games, i like to see graphical progress when i'm writing. Anybody send me a link? Andy -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: 28 July 2010 00:11 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) Actually, late night spurt — with Huffman trees it's 5,528 bytes and 6,653 bytes respectively. No predictor yet. The former technically beats the PNG size, but I'd imagine that just means the predictor is barely going to help and I'm gaining a small win by not including any of the normal file padding or headers. Or even the palette. On Tue, Jul 27, 2010 at 11:47 PM, Thomas Harte tomh.retros...@gmail.com wrote: Further to this: I've been playing around with it today using a couple of the more complicated screens from that Amiga map which didn't feature the watermark (since it's an alpha transparency, causing the number of colours to skyrocket), resized to 256 pixels across (which makes 141 pixels high). For a sensible lower bound on what I should expect, I saved them as PNGs and ran them through OptiPNG, PNGCrush, and AdvPNG, keeping the smallest version. The first (Dylan and a tree) is 5,553 bytes as a PNG. The second (featuring the Armorog) 6,108 bytes. In my quick dash at compression code, I implemented just a trivial little LZ77, using an exhaustive search to pattern match and treating each scan line as a completely separate thing to compress (and, as a result, rounded up to the next full byte). Five bits for a literal, 17 for a back reference, the native addressable thing being a nibble. From that, I got 6,080 bytes for the first screen and 7,170 for the second. And this is without yet implementing a Huffman tree (probably best done per screen) or any sort of predictor. So, it looks like on a 16 colour display the LZ77 may actually be the most of it. In which case it's going to be hard to support the conclusion that PNG is massively better than the various common techniques when the Sam was a going concern. A Huffman tree is an easy win and something I'll experiment with tomorrow hopefully and a predictor is a useful addition even when dealing with hard edged low colour graphics because it introduces the second dimension as a going concern whereas LZ77 has no concept of that. Would it be possible to get a single screen hand prepared to be really beautiful rather than ripped from a tilemap? On Tue, Jul 27, 2010 at 10:46 AM, Stefan Drissen stefan.dris...@gmail.com wrote: Fair enough. You could of course create PNG tiles so that you do not need to Flash! anything. You could then even also use a 256-colour PNG image as map editor, the colour determining the tile... ;-) Flashback would be very cool - on the PC I don't remember it having scrolling. You would however also need to create an animated PNG / MPEG player for the animated sequences. Lots of fun things to do... :-) -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of the_wub ! Sent: Monday, July 26, 2010 19:21 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) If png's can be used then I think we should do it even if using an image of tiles is a bit ironic! It would allow changes to be made to the image in the gimp rather than flash! if nothing else! ;) If a success, I don't dare to dream about scumm but another possible port would be Flashback, I can't remember how much if any scrolling is in there but something would be possible if pngs could be used as source gfx... I don't know enough to comment
Re: Dizzy (was: Porting spectrum games...)
Hmmm, not doing very well with the Flashback image I chose to test (the top left screen) at all. PNG is 10,649 bytes and I'm 13,507 bytes. But unlike yesterday, that's with the Huffman tree stored (whoops!) and the palette thrown on. I've also tweaked the LZ77 stage a bit, so it's now a 256 pixel rolling buffer with repetitions up to 18 pixels in length and the entire screen compressed as one block. That said, at one point the storage space for all three images seemed to go up by about 1.5kb for absolutely no reason. So I don't thoroughly trust my code. I've tried sorting the palette by hue (to give it some sort of likelihood that nearby colours are near each other in the palette) and applying the various PNG prediction filters to the entire image with each and every one causing the file size to grow. Which is quiet probably why PNG picks them line by line. So that's the experiment for tomorrow night... On Wed, Jul 28, 2010 at 10:53 AM, Thomas Harte tomh.retros...@gmail.com wrote: The previously posted Fantasy World Dizzy map seems to have come from 'Hall of Light', which offers itself as 'the database of Amiga games' at http://hol.abime.net/. You can't just chop up the map and reuse it though, as they've watermarked it with an alpha transparency. It's large but quite spaced out, so I've just used screens that the watermark doesn't touch. And probably if you had a piece of software that was at all competent at reducing colour depth then you'd be able to wash it off again. On Wed, Jul 28, 2010 at 10:03 AM, Stefan Drissen stefan.dris...@gmail.com wrote: For Amiga Treasure Island Dizzy: http://www.vgmaps.com/Atlas/Amiga/TreasureIslandDizzy-TreasureIsland.png The www.vgmaps.com site has quite a few more cool maps (for example the Flashback ones in my previous post). Stefan -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Andrew Park Sent: Wednesday, July 28, 2010 10:29 To: sam-users@nvg.ntnu.no Subject: RE: Dizzy (was: Porting spectrum games...) It is great to see some activity on here again, 1 quick question where did the amiga dizzy map come from to get screens, i've been looking for good amiga screenshot maps everywhere as i'm not an artist and this stops me writing games, i like to see graphical progress when i'm writing. Anybody send me a link? Andy -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: 28 July 2010 00:11 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) Actually, late night spurt — with Huffman trees it's 5,528 bytes and 6,653 bytes respectively. No predictor yet. The former technically beats the PNG size, but I'd imagine that just means the predictor is barely going to help and I'm gaining a small win by not including any of the normal file padding or headers. Or even the palette. On Tue, Jul 27, 2010 at 11:47 PM, Thomas Harte tomh.retros...@gmail.com wrote: Further to this: I've been playing around with it today using a couple of the more complicated screens from that Amiga map which didn't feature the watermark (since it's an alpha transparency, causing the number of colours to skyrocket), resized to 256 pixels across (which makes 141 pixels high). For a sensible lower bound on what I should expect, I saved them as PNGs and ran them through OptiPNG, PNGCrush, and AdvPNG, keeping the smallest version. The first (Dylan and a tree) is 5,553 bytes as a PNG. The second (featuring the Armorog) 6,108 bytes. In my quick dash at compression code, I implemented just a trivial little LZ77, using an exhaustive search to pattern match and treating each scan line as a completely separate thing to compress (and, as a result, rounded up to the next full byte). Five bits for a literal, 17 for a back reference, the native addressable thing being a nibble. From that, I got 6,080 bytes for the first screen and 7,170 for the second. And this is without yet implementing a Huffman tree (probably best done per screen) or any sort of predictor. So, it looks like on a 16 colour display the LZ77 may actually be the most of it. In which case it's going to be hard to support the conclusion that PNG is massively better than the various common techniques when the Sam was a going concern. A Huffman tree is an easy win and something I'll experiment with tomorrow hopefully and a predictor is a useful addition even when dealing with hard edged low colour graphics because it introduces the second dimension as a going concern whereas LZ77 has no concept of that. Would it be possible to get a single screen hand prepared to be really beautiful rather than ripped from a tilemap? On Tue, Jul 27, 2010 at 10:46 AM, Stefan Drissen stefan.dris...@gmail.com wrote: Fair enough. You could of course create PNG tiles so that you do not need to Flash! anything. You could
RE: Dizzy (was: Porting spectrum games...)
Fair enough. You could of course create PNG tiles so that you do not need to Flash! anything. You could then even also use a 256-colour PNG image as map editor, the colour determining the tile... ;-) Flashback would be very cool - on the PC I don't remember it having scrolling. You would however also need to create an animated PNG / MPEG player for the animated sequences. Lots of fun things to do... :-) -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of the_wub ! Sent: Monday, July 26, 2010 19:21 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) If png's can be used then I think we should do it even if using an image of tiles is a bit ironic! It would allow changes to be made to the image in the gimp rather than flash! if nothing else! ;) If a success, I don't dare to dream about scumm but another possible port would be Flashback, I can't remember how much if any scrolling is in there but something would be possible if pngs could be used as source gfx... I don't know enough to comment on the feasibility of it all but I do have a question, why use the PC bitmaps and not the ST? The Atari is already 16 colours and it would be easy enough to fancy them up a bit, make them a bit less tiley.. I'm saying this without having a good look at how the PC gfx would work in 16 colours though... Hey Warren! I'd guess that whichever direction the project goes there'll be tons to do. The more the merrier I say :)
Re: Dizzy (was: Porting spectrum games...)
Further to this: I've been playing around with it today using a couple of the more complicated screens from that Amiga map which didn't feature the watermark (since it's an alpha transparency, causing the number of colours to skyrocket), resized to 256 pixels across (which makes 141 pixels high). For a sensible lower bound on what I should expect, I saved them as PNGs and ran them through OptiPNG, PNGCrush, and AdvPNG, keeping the smallest version. The first (Dylan and a tree) is 5,553 bytes as a PNG. The second (featuring the Armorog) 6,108 bytes. In my quick dash at compression code, I implemented just a trivial little LZ77, using an exhaustive search to pattern match and treating each scan line as a completely separate thing to compress (and, as a result, rounded up to the next full byte). Five bits for a literal, 17 for a back reference, the native addressable thing being a nibble. From that, I got 6,080 bytes for the first screen and 7,170 for the second. And this is without yet implementing a Huffman tree (probably best done per screen) or any sort of predictor. So, it looks like on a 16 colour display the LZ77 may actually be the most of it. In which case it's going to be hard to support the conclusion that PNG is massively better than the various common techniques when the Sam was a going concern. A Huffman tree is an easy win and something I'll experiment with tomorrow hopefully and a predictor is a useful addition even when dealing with hard edged low colour graphics because it introduces the second dimension as a going concern whereas LZ77 has no concept of that. Would it be possible to get a single screen hand prepared to be really beautiful rather than ripped from a tilemap? On Tue, Jul 27, 2010 at 10:46 AM, Stefan Drissen stefan.dris...@gmail.com wrote: Fair enough. You could of course create PNG tiles so that you do not need to Flash! anything. You could then even also use a 256-colour PNG image as map editor, the colour determining the tile... ;-) Flashback would be very cool - on the PC I don't remember it having scrolling. You would however also need to create an animated PNG / MPEG player for the animated sequences. Lots of fun things to do... :-) -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of the_wub ! Sent: Monday, July 26, 2010 19:21 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) If png's can be used then I think we should do it even if using an image of tiles is a bit ironic! It would allow changes to be made to the image in the gimp rather than flash! if nothing else! ;) If a success, I don't dare to dream about scumm but another possible port would be Flashback, I can't remember how much if any scrolling is in there but something would be possible if pngs could be used as source gfx... I don't know enough to comment on the feasibility of it all but I do have a question, why use the PC bitmaps and not the ST? The Atari is already 16 colours and it would be easy enough to fancy them up a bit, make them a bit less tiley.. I'm saying this without having a good look at how the PC gfx would work in 16 colours though... Hey Warren! I'd guess that whichever direction the project goes there'll be tons to do. The more the merrier I say :)
Re: Dizzy (was: Porting spectrum games...)
Actually, late night spurt — with Huffman trees it's 5,528 bytes and 6,653 bytes respectively. No predictor yet. The former technically beats the PNG size, but I'd imagine that just means the predictor is barely going to help and I'm gaining a small win by not including any of the normal file padding or headers. Or even the palette. On Tue, Jul 27, 2010 at 11:47 PM, Thomas Harte tomh.retros...@gmail.com wrote: Further to this: I've been playing around with it today using a couple of the more complicated screens from that Amiga map which didn't feature the watermark (since it's an alpha transparency, causing the number of colours to skyrocket), resized to 256 pixels across (which makes 141 pixels high). For a sensible lower bound on what I should expect, I saved them as PNGs and ran them through OptiPNG, PNGCrush, and AdvPNG, keeping the smallest version. The first (Dylan and a tree) is 5,553 bytes as a PNG. The second (featuring the Armorog) 6,108 bytes. In my quick dash at compression code, I implemented just a trivial little LZ77, using an exhaustive search to pattern match and treating each scan line as a completely separate thing to compress (and, as a result, rounded up to the next full byte). Five bits for a literal, 17 for a back reference, the native addressable thing being a nibble. From that, I got 6,080 bytes for the first screen and 7,170 for the second. And this is without yet implementing a Huffman tree (probably best done per screen) or any sort of predictor. So, it looks like on a 16 colour display the LZ77 may actually be the most of it. In which case it's going to be hard to support the conclusion that PNG is massively better than the various common techniques when the Sam was a going concern. A Huffman tree is an easy win and something I'll experiment with tomorrow hopefully and a predictor is a useful addition even when dealing with hard edged low colour graphics because it introduces the second dimension as a going concern whereas LZ77 has no concept of that. Would it be possible to get a single screen hand prepared to be really beautiful rather than ripped from a tilemap? On Tue, Jul 27, 2010 at 10:46 AM, Stefan Drissen stefan.dris...@gmail.com wrote: Fair enough. You could of course create PNG tiles so that you do not need to Flash! anything. You could then even also use a 256-colour PNG image as map editor, the colour determining the tile... ;-) Flashback would be very cool - on the PC I don't remember it having scrolling. You would however also need to create an animated PNG / MPEG player for the animated sequences. Lots of fun things to do... :-) -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of the_wub ! Sent: Monday, July 26, 2010 19:21 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) If png's can be used then I think we should do it even if using an image of tiles is a bit ironic! It would allow changes to be made to the image in the gimp rather than flash! if nothing else! ;) If a success, I don't dare to dream about scumm but another possible port would be Flashback, I can't remember how much if any scrolling is in there but something would be possible if pngs could be used as source gfx... I don't know enough to comment on the feasibility of it all but I do have a question, why use the PC bitmaps and not the ST? The Atari is already 16 colours and it would be easy enough to fancy them up a bit, make them a bit less tiley.. I'm saying this without having a good look at how the PC gfx would work in 16 colours though... Hey Warren! I'd guess that whichever direction the project goes there'll be tons to do. The more the merrier I say :)
Re: Dizzy (was: Porting spectrum games...)
For a screenshot, I know its not Dizzy, but it is one of the other mentioned games: http://www.mobygames.com/game/flashback-the-quest-for-identity/screenshots I would expect this to be tiled, but it doesn't look directly tiled. See more mappy stuff at: http://www.vgmaps.com/Atlas/SuperNES/Flashback-QuestForIdentity-Level1-TitanJungle.png :-) On Wed, Jul 28, 2010 at 12:47 AM, Thomas Harte tomh.retros...@gmail.comwrote: Further to this: I've been playing around with it today using a couple of the more complicated screens from that Amiga map which didn't feature the watermark (since it's an alpha transparency, causing the number of colours to skyrocket), resized to 256 pixels across (which makes 141 pixels high). For a sensible lower bound on what I should expect, I saved them as PNGs and ran them through OptiPNG, PNGCrush, and AdvPNG, keeping the smallest version. The first (Dylan and a tree) is 5,553 bytes as a PNG. The second (featuring the Armorog) 6,108 bytes. In my quick dash at compression code, I implemented just a trivial little LZ77, using an exhaustive search to pattern match and treating each scan line as a completely separate thing to compress (and, as a result, rounded up to the next full byte). Five bits for a literal, 17 for a back reference, the native addressable thing being a nibble. From that, I got 6,080 bytes for the first screen and 7,170 for the second. And this is without yet implementing a Huffman tree (probably best done per screen) or any sort of predictor. So, it looks like on a 16 colour display the LZ77 may actually be the most of it. In which case it's going to be hard to support the conclusion that PNG is massively better than the various common techniques when the Sam was a going concern. A Huffman tree is an easy win and something I'll experiment with tomorrow hopefully and a predictor is a useful addition even when dealing with hard edged low colour graphics because it introduces the second dimension as a going concern whereas LZ77 has no concept of that. Would it be possible to get a single screen hand prepared to be really beautiful rather than ripped from a tilemap? On Tue, Jul 27, 2010 at 10:46 AM, Stefan Drissen stefan.dris...@gmail.com wrote: Fair enough. You could of course create PNG tiles so that you do not need to Flash! anything. You could then even also use a 256-colour PNG image as map editor, the colour determining the tile... ;-) Flashback would be very cool - on the PC I don't remember it having scrolling. You would however also need to create an animated PNG / MPEG player for the animated sequences. Lots of fun things to do... :-) -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of the_wub ! Sent: Monday, July 26, 2010 19:21 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) If png's can be used then I think we should do it even if using an image of tiles is a bit ironic! It would allow changes to be made to the image in the gimp rather than flash! if nothing else! ;) If a success, I don't dare to dream about scumm but another possible port would be Flashback, I can't remember how much if any scrolling is in there but something would be possible if pngs could be used as source gfx... I don't know enough to comment on the feasibility of it all but I do have a question, why use the PC bitmaps and not the ST? The Atari is already 16 colours and it would be easy enough to fancy them up a bit, make them a bit less tiley.. I'm saying this without having a good look at how the PC gfx would work in 16 colours though... Hey Warren! I'd guess that whichever direction the project goes there'll be tons to do. The more the merrier I say :)
Re: Porting spectrum games...
On Sun, 25 Jul 2010 23:54:41 +0200, Thomas Harte tomh.retros...@gmail.com wrote: PNG wasn't a leg pull, though I've been unable to find the Amiga map for Fantasy World Dizzy. However, the entire PC map (256 colour, individual screens slightly too large) is 250 kb as a PNG. So it'd be possible. Would this one do: http://hol.abime.net/pic_full/gamemap/0501-0600/502_gamemap1.png It would take some stiching to make it 100% and fit 256 pixels wide. Animated elements are going to need to be repainted frame by frame so are logically separate from the background anyway. My thought was that animated elements could be tiles in the same way as static tiles to save any special handling of those for each screen. However, I guess it would be rather straight forward to generalise animations as another layer instead? -Frode -- ^ Frode Tennebø | email: fr...@tennebo.com | fr...@irc ^ | with Standard.Disclaimer; use Standard.Disclaimer; |
RE: Dizzy (was: Porting spectrum games...)
Ummm... whats the point in using a png map if the png is based on tiles?!? I thought the idea for using png was to allow some really nice authentic graphics to be used that do not look tiley - which the Dizzy map obviously does. The png idea could be very good for something NOT tile based (SCUMM anyone?) I think the repeating tiles are what are allowing these maps to compress so well. Stefan -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Frode Tennebø Sent: maandag 26 juli 2010 08:37 To: sam-users@nvg.ntnu.no Subject: Re: Porting spectrum games... On Sun, 25 Jul 2010 23:54:41 +0200, Thomas Harte tomh.retros...@gmail.com wrote: PNG wasn't a leg pull, though I've been unable to find the Amiga map for Fantasy World Dizzy. However, the entire PC map (256 colour, individual screens slightly too large) is 250 kb as a PNG. So it'd be possible. Would this one do: http://hol.abime.net/pic_full/gamemap/0501-0600/502_gamemap1.png It would take some stiching to make it 100% and fit 256 pixels wide. Animated elements are going to need to be repainted frame by frame so are logically separate from the background anyway. My thought was that animated elements could be tiles in the same way as static tiles to save any special handling of those for each screen. However, I guess it would be rather straight forward to generalise animations as another layer instead? -Frode -- ^ Frode Tennebø | email: fr...@tennebo.com | fr...@irc ^ | with Standard.Disclaimer; use Standard.Disclaimer; | No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3027 - Release Date: 07/25/10 08:36:00
Re: Dizzy (was: Porting spectrum games...)
The gamble is that anything cartoony compresses better than anything photographic, that PNG is work subsequent to the Sam's heyday, explaining why we're able to be much more bullish about compression rates and that if the map stops fitting we can just break it into multiload. It may not work, but I think it's worth investigating. That the PC map fits into 250k and the Sam map will have half the bit depth, less than 80% of the pixels and the memory target is 50% larger than that is encouraging. I'm definitely pushing the idea as a way to avoid the look of tiles. I think that look instantly dates a game. On 7/26/10, Stefan Drissen stefan.dris...@gmail.com wrote: Ummm... whats the point in using a png map if the png is based on tiles?!? I thought the idea for using png was to allow some really nice authentic graphics to be used that do not look tiley - which the Dizzy map obviously does. The png idea could be very good for something NOT tile based (SCUMM anyone?) I think the repeating tiles are what are allowing these maps to compress so well. Stefan -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Frode Tennebø Sent: maandag 26 juli 2010 08:37 To: sam-users@nvg.ntnu.no Subject: Re: Porting spectrum games... On Sun, 25 Jul 2010 23:54:41 +0200, Thomas Harte tomh.retros...@gmail.com wrote: PNG wasn't a leg pull, though I've been unable to find the Amiga map for Fantasy World Dizzy. However, the entire PC map (256 colour, individual screens slightly too large) is 250 kb as a PNG. So it'd be possible. Would this one do: http://hol.abime.net/pic_full/gamemap/0501-0600/502_gamemap1.png It would take some stiching to make it 100% and fit 256 pixels wide. Animated elements are going to need to be repainted frame by frame so are logically separate from the background anyway. My thought was that animated elements could be tiles in the same way as static tiles to save any special handling of those for each screen. However, I guess it would be rather straight forward to generalise animations as another layer instead? -Frode -- ^ Frode Tennebø | email: fr...@tennebo.com | fr...@irc ^ | with Standard.Disclaimer; use Standard.Disclaimer; | No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3027 - Release Date: 07/25/10 08:36:00
RE: Dizzy (was: Porting spectrum games...)
I am not questioning implementing a PNG map in general - it would look great, it's just that the Dizzy map provided makes no sense since it is originally tile based. -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: maandag 26 juli 2010 11:19 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) The gamble is that anything cartoony compresses better than anything photographic, that PNG is work subsequent to the Sam's heyday, explaining why we're able to be much more bullish about compression rates and that if the map stops fitting we can just break it into multiload. It may not work, but I think it's worth investigating. That the PC map fits into 250k and the Sam map will have half the bit depth, less than 80% of the pixels and the memory target is 50% larger than that is encouraging. I'm definitely pushing the idea as a way to avoid the look of tiles. I think that look instantly dates a game. On 7/26/10, Stefan Drissen stefan.dris...@gmail.com wrote: Ummm... whats the point in using a png map if the png is based on tiles?!? I thought the idea for using png was to allow some really nice authentic graphics to be used that do not look tiley - which the Dizzy map obviously does. The png idea could be very good for something NOT tile based (SCUMM anyone?) I think the repeating tiles are what are allowing these maps to compress so well. Stefan -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Frode Tennebø Sent: maandag 26 juli 2010 08:37 To: sam-users@nvg.ntnu.no Subject: Re: Porting spectrum games... On Sun, 25 Jul 2010 23:54:41 +0200, Thomas Harte tomh.retros...@gmail.com wrote: PNG wasn't a leg pull, though I've been unable to find the Amiga map for Fantasy World Dizzy. However, the entire PC map (256 colour, individual screens slightly too large) is 250 kb as a PNG. So it'd be possible. Would this one do: http://hol.abime.net/pic_full/gamemap/0501-0600/502_gamemap1.png It would take some stiching to make it 100% and fit 256 pixels wide. Animated elements are going to need to be repainted frame by frame so are logically separate from the background anyway. My thought was that animated elements could be tiles in the same way as static tiles to save any special handling of those for each screen. However, I guess it would be rather straight forward to generalise animations as another layer instead? -Frode -- ^ Frode Tennebø | email: fr...@tennebo.com | fr...@irc ^ | with Standard.Disclaimer; use Standard.Disclaimer; | No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3027 - Release Date: 07/25/10 08:36:00 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3027 - Release Date: 07/25/10 20:36:00
RE: Dizzy (was: Porting spectrum games...)
Hey all just wanted to say, it's really great to see all the work going into a possible Dizzy game for Sam. Used to love playing them, so can't wait! On another note, I know there's people handling the graphics and so forth, but if there's an overflow at some point, and you need someone to knock out a few extra graphics, just let me know if I can help. :-) Looking forward to seeing the fantastic results! Quoting Stefan Drissen stefan.dris...@gmail.com: I am not questioning implementing a PNG map in general - it would look great, it's just that the Dizzy map provided makes no sense since it is originally tile based. -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Thomas Harte Sent: maandag 26 juli 2010 11:19 To: sam-users@nvg.ntnu.no Subject: Re: Dizzy (was: Porting spectrum games...) The gamble is that anything cartoony compresses better than anything photographic, that PNG is work subsequent to the Sam's heyday, explaining why we're able to be much more bullish about compression rates and that if the map stops fitting we can just break it into multiload. It may not work, but I think it's worth investigating. That the PC map fits into 250k and the Sam map will have half the bit depth, less than 80% of the pixels and the memory target is 50% larger than that is encouraging. I'm definitely pushing the idea as a way to avoid the look of tiles. I think that look instantly dates a game. On 7/26/10, Stefan Drissen stefan.dris...@gmail.com wrote: Ummm... whats the point in using a png map if the png is based on tiles?!? I thought the idea for using png was to allow some really nice authentic graphics to be used that do not look tiley - which the Dizzy map obviously does. The png idea could be very good for something NOT tile based (SCUMM anyone?) I think the repeating tiles are what are allowing these maps to compress so well. Stefan -Original Message- From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Frode Tennebø Sent: maandag 26 juli 2010 08:37 To: sam-users@nvg.ntnu.no Subject: Re: Porting spectrum games... On Sun, 25 Jul 2010 23:54:41 +0200, Thomas Harte tomh.retros...@gmail.com wrote: PNG wasn't a leg pull, though I've been unable to find the Amiga map for Fantasy World Dizzy. However, the entire PC map (256 colour, individual screens slightly too large) is 250 kb as a PNG. So it'd be possible. Would this one do: http://hol.abime.net/pic_full/gamemap/0501-0600/502_gamemap1.png It would take some stiching to make it 100% and fit 256 pixels wide. Animated elements are going to need to be repainted frame by frame so are logically separate from the background anyway. My thought was that animated elements could be tiles in the same way as static tiles to save any special handling of those for each screen. However, I guess it would be rather straight forward to generalise animations as another layer instead? -Frode -- ^ Frode Tennebø | email: fr...@tennebo.com | fr...@irc ^ | with Standard.Disclaimer; use Standard.Disclaimer; | No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3027 - Release Date: 07/25/10 08:36:00 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3027 - Release Date: 07/25/10 20:36:00
Re: Dizzy (was: Porting spectrum games...)
If png's can be used then I think we should do it even if using an image of tiles is a bit ironic! It would allow changes to be made to the image in the gimp rather than flash! if nothing else! ;) If a success, I don't dare to dream about scumm but another possible port would be Flashback, I can't remember how much if any scrolling is in there but something would be possible if pngs could be used as source gfx... I don't know enough to comment on the feasibility of it all but I do have a question, why use the PC bitmaps and not the ST? The Atari is already 16 colours and it would be easy enough to fancy them up a bit, make them a bit less tiley.. I'm saying this without having a good look at how the PC gfx would work in 16 colours though... Hey Warren! I'd guess that whichever direction the project goes there'll be tons to do. The more the merrier I say :)
Re: Porting spectrum games...
I've uploaded a demo to ftp://ftp.nvg.ntnu.no/incoming/Dizzy.zip I hope people can access it from there? I accidentally uploaded the unzipped version by mistake, this could be deleted as I have uploaded the packed archive now. I don't have permission to delete it myself. The demo is made up from the ST graphics which I've reworked a bit to fit the resolution. The big table has had to go for the time being at least.. it's just to test the animations and to get an idea of how it would look. I'll add the player sprite next. All the graphics line up to a 16x16 grid and a tile set would be pretty easy to make. From this screen quite a few tiles can be derived which appear through that part of the level. It wouldn't take long to have a few screens in an explorable state from this point, assuming I can get the player sprite added without too much bother... I don't know if the scheme to use png's was a leg-pull or not but I think making a tile set would be the most plausible way of getting this working. The difference in horizontal resolution creates a lot of problems..
Re: Porting spectrum games...
On Sun, 25 Jul 2010 20:12:41 +0200, the_wub ! the...@gmail.com wrote: I've uploaded a demo to ftp://ftp.nvg.ntnu.no/incoming/Dizzy.zip I have moved this to /pub/sam-coupe/temp/ as I will do with the images I consider/get the impression is work-in-progress. Let me know if/when you want them deleted from there or moved someplace... -Frode -- ^ Frode Tennebø | email: fr...@tennebo.com | fr...@irc ^ | with Standard.Disclaimer; use Standard.Disclaimer; |
Re: Porting spectrum games...
Just downloaded the demo now that Frode has moved it to a folder that we can download from. the_wub! - very nice work indeed * goes back to catching up with all the list emails from the last week or two... didn't have broadband for over a week :( * Colin = Quazar : Hardware, Software, Spares and Repairs for the SAM Coupé 1995-2010 - Celebrating 16 Years of developing for the SAM Coupé Website: http://www.samcoupe.com/ - Original Message - From: the_wub ! the...@gmail.com Subject: Re: Porting spectrum games... I've uploaded a demo to ftp://ftp.nvg.ntnu.no/incoming/Dizzy.zip I hope people can access it from there? I accidentally uploaded the unzipped version by mistake, this could be deleted as I have uploaded the packed archive now. I don't have permission to delete it myself. The demo is made up from the ST graphics which I've reworked a bit to fit the resolution. The big table has had to go for the time being at least.. it's just to test the animations and to get an idea of how it would look. I'll add the player sprite next. All the graphics line up to a 16x16 grid and a tile set would be pretty easy to make. From this screen quite a few tiles can be derived which appear through that part of the level. It wouldn't take long to have a few screens in an explorable state from this point, assuming I can get the player sprite added without too much bother... I don't know if the scheme to use png's was a leg-pull or not but I think making a tile set would be the most plausible way of getting this working. The difference in horizontal resolution creates a lot of problems..
Re: Porting spectrum games...
That's great, thanks very much. I'd like to remove those two wubtris demos and upload the latest build at some point, it is as finished as its going to get in this incarnation..
Re: Porting spectrum games...
On Sun, 25 Jul 2010 20:12:41 +0200, the_wub ! the...@gmail.com wrote: The demo is made up from the ST graphics which I've reworked a bit to fit the resolution. Again, I'm not a Dizzy fan myself, but the GFX looks fantastic... All the graphics line up to a 16x16 grid and a tile set would be pretty easy to make. With animations going on, wouldn't it be impractical not to have a tile based system? -Frode -- ^ Frode Tennebø | email: fr...@tennebo.com | fr...@irc ^ | with Standard.Disclaimer; use Standard.Disclaimer; |
Re: Porting spectrum games...
I can't take any credit for how things look :) Not only are they the work of someone else but the best of the blit routines are by Chris! With animations going on, wouldn't it be impractical not to have a tile based system? I agree, although if PNG files can be used then the time saved not having to make tiles could be spent making special instances for the animations..
Re: Porting spectrum games...
PNG wasn't a leg pull, though I've been unable to find the Amiga map for Fantasy World Dizzy. However, the entire PC map (256 colour, individual screens slightly too large) is 250 kb as a PNG. So it'd be possible. Animated elements are going to need to be repainted frame by frame so are logically separate from the background anyway. I'm unable to get Dizzy.zip (Permission denied), but at this point it does look more like I'll hold you back rather than help you. On Sun, Jul 25, 2010 at 9:41 PM, the_wub ! the...@gmail.com wrote: I can't take any credit for how things look :) Not only are they the work of someone else but the best of the blit routines are by Chris! With animations going on, wouldn't it be impractical not to have a tile based system? I agree, although if PNG files can be used then the time saved not having to make tiles could be spent making special instances for the animations..
Re: Porting spectrum games...
I'm sorry for suggesting a leg-pull that wasn't! The more I worked on drawing out the ST graphics the more unlikely it seemed possible to use a raw image.. I'm unable to get Dizzy.zip (Permission denied), but at this point it does look more like I'll hold you back rather than help you. You may be downloading from the original place I uploaded to. It has been moved to: ftp://ftp.nvg.ntnu.no/pub/sam-coupe/temp/ I think your help will be essential to make this happen. I haven't got a clue how half of this is going to work but I do have time and enthusiasm! :) If I can get enough tiles together would you be up for helping to build an editor for the levels and some way to manage the collision data? Or at least talk me through what I should be doing? I'd take as much or little input as you have patience for :) Either way I'm going to finish off the game I'm on before I get stuck into this. It's a good motivation to get done in fact! :)
Re: Porting spectrum games...
The Nes Dizzy I've seen is the first one, Dizzy the Adventurer. I'd forgotten how good it was, even without an energy bar.. So what size can a single 24kb screen compress down to? Hand drawn screens would be amazing. I've never used 1 or 2 bit tile maps for collision before so it would be great to learn this. I couldn't immediately see how it could be generated from the screen image itself though. For the test I would have sacrificed colour 0 for a duplicate black to out-line solid objects with. Collision could be detected from just the screen image itself but the collision tile map could be generated from a screen like that too. I'm not sure why there needs to be a foreground and background if the screens will be hand drawn? I was going to arrange the palette so several colours could be variable too, would this be a problem? That all being said, it's a disc-based machine so multiloads aren't a problem, are they? I vote aim high and break the world into chunks if we overshoot. I wouldn't have a problem with that.. I wrote a little Dizzy engine for the PC once, but have never built it for Windows (it's SDL) and was based on the PC sprites and metrics on a scrolling tile map. So it's not directly useful. I'm familiar with SDL so that would probably help a bit! I don't know what to say about the assembler option. I'm working on the real hardware and with Sim Coupe and I really want to carry on doing so at it is tremendous fun :) That said I can see the benefit of working with modern tools so maybe some sort of compromise could be reached? As to the screen format you propose, as I barely understand it and am potentially about to learn some very useful stuff from it I think it would be churlish to object! It would be good to establish what is on the table though. I'm just looking at how the Nes graphics translate to the Sams screen. ST or Miggy gfx look funny with the horizontal stretching and the Nes has a larger vertical resolution. Using the Spectrum screens as a starting point might be a good way to go but I need to do a bit more experimenting first. Also are we talking about porting a specific game or creating an original one? If original then the remit for the graphics changes dramatically. I would be more interested in remaking a specific version and then moving the objects to create a variation of the original. This could be an inital goal though. It would be easy to go back and make an original game later on using the same code and in the long term I think that would make the project more approachable for me. Rob.
Re: Porting spectrum games...
With foreground, middleground and background you'd be defining graphics which the sprites don't interact with and which they move in front of (that's the background), graphics which the sprites do collide with (the middleground; everything the player actually walks on/against/etc) and graphics which the sprites don't interact with and which they move behind of (everything in the foreground). So it's just a way of describing what's in front of and what's behind the player and what the player actually walks on (which I guess also would be nominally behind for drawing purposes, though overlap should be relatively limited). I've no idea how large a single screen will be on average... as I say, it looks likely we could get an entire existing game into memory from PNGs downloaded, but it's probably worth thinking of the PNG file size as an absolute best case. The PNG decompression algorithm doesn't look too taxing, which is why it's a good comparison — we're benefitting from lots of clever people having already addressed the problem and fully documented their solution. If on-screen objects can be in front of as well as behind the player then we can't embed collision information in the screen graphic, since e.g. if Dizzy walks behind a large tree then we have no way of knowing what he's walking amongst short of dedicating an entire bit to it and cutting the map palette to 8 colours. Though if we were to cut the map palette to 8 colours then I'd think the spare bit would be better used as a sort of lighting marker. Split the palette into a light half and a dark half and write the sprite routines to set e.g. the three lowest bits but preserve the top bit and we can define areas of light and shadow for the sprites. Just a thought, probably not worth following up. So, ummm, I'm not sure what you want to do about that. One solution that fits the hardware well is: (1) screen buffer, standard format (2) collision buffer, 1bit buffer, bit set for solid, bit clear for empty, half width resolution, so 128x192 for 3072 bytes total (3) in-front/behind buffer, same format as the collision buffer Which all together make exactly 30kb, pleasingly short of a page. The good fit is that using half-width buffers for (2) and (3) aligns those with with byte boundaries for pixel plotting. Both pyz80 and Jam are supersets of the Comet syntax, but I'm not sure what tools would be used to actually convert source back and forth (since I think it's stored tokenised on the Sam?). The source for my old Dizzy thing is at http://members.allegro.cc/ThomasHarte/files/dizzy/DizzySource.zip and relies on SDL, SDL_image and DUMB for music. It's also a few years old, so likely horribly formatted and barely commented. It's only recently I've started doing this for a living. There's a built OS X binary at http://members.allegro.cc/ThomasHarte/files/dizzy/DizzyOSX.zip. If you build and play then there's the Crash mini-Dizzy followed by some other stuff I was experimenting with. And it's all tilemap based, because I can't draw for toffee and was just messing about anyway. The Nes Dizzy probably isn't the one to go for with all its complicated scrolling and minigames, but I've always had a soft spot for Fantasy World Dizzy. Fancy giving that one a go? On Thu, Jul 22, 2010 at 10:33 AM, the_wub ! the...@gmail.com wrote: The Nes Dizzy I've seen is the first one, Dizzy the Adventurer. I'd forgotten how good it was, even without an energy bar.. So what size can a single 24kb screen compress down to? Hand drawn screens would be amazing. I've never used 1 or 2 bit tile maps for collision before so it would be great to learn this. I couldn't immediately see how it could be generated from the screen image itself though. For the test I would have sacrificed colour 0 for a duplicate black to out-line solid objects with. Collision could be detected from just the screen image itself but the collision tile map could be generated from a screen like that too. I'm not sure why there needs to be a foreground and background if the screens will be hand drawn? I was going to arrange the palette so several colours could be variable too, would this be a problem? That all being said, it's a disc-based machine so multiloads aren't a problem, are they? I vote aim high and break the world into chunks if we overshoot. I wouldn't have a problem with that.. I wrote a little Dizzy engine for the PC once, but have never built it for Windows (it's SDL) and was based on the PC sprites and metrics on a scrolling tile map. So it's not directly useful. I'm familiar with SDL so that would probably help a bit! I don't know what to say about the assembler option. I'm working on the real hardware and with Sim Coupe and I really want to carry on doing so at it is tremendous fun :) That said I can see the benefit of working with modern tools so maybe some sort of compromise could be reached? As to the screen format you propose, as I barely
Re: Porting spectrum games...
On 22 July 2010 10:59, Thomas Harte tomh.retros...@gmail.com wrote: Both pyz80 and Jam are supersets of the Comet syntax, but I'm not sure what tools would be used to actually convert source back and forth (since I think it's stored tokenised on the Sam?). Back in the day, Simon Cooke wrote a comet -- ASCII converter. It's probably on the ftp site somewhere. Alternatively, you can do the conversion one way by loading a source file in Comet itself, and printing it out - SimCoupe saves a text file of the printed output. Andrew
Re: Porting spectrum games...
I'm definitely up for doing Fantasy World Dizzy, it's also my favourite! I got in trouble several times for phoning the helpline number back in the 0898 days :) Happy memories!
Re: Porting spectrum games...
Thanks Andrew, that sounds perfect! It's up to Thomas to choose between pyz80 and Jam then. I can install whichever and have a go at moving some source around myself.
RE: Porting spectrum games...
I've looked into PNG more, and it is actually realistic to use exactly that algorithm on a Sam (albeit that there's no need to be identical in byte streams) - it's just a linear predictor and LZ77 + Huffman on the end. With that in mind, I've downloaded some of the classic Dizzy maps from those places that tile screenshots to produce game maps (in their Amiga versions) and they're all sub 400kb. Most would even fit into 256kb. Andrew did a DEFLATE implementation worth looking at for PNG: http://sourceforge.net/projects/samflate/ It could be worth-wile to look at some variant of modified Huffman RLE. Speed-wise it should be faster, but with an pre-optimised tree could also quite possibly be smaller given the low bit depth. : How about two pages for the current screen, each filled with the same data by the screen decompressor, which is (in order): 24576 bytes; normal screen image 6144 bytes; mask image - bit set = that pixel is in front of the character sprites, bit clear = that pixel is behind, same bit layout as a Mode 2 screen 768 bytes; collision tile map. 32x24 entries, each a byte in length, linear left-to-right, top-to-bottom as per Mode 1 attributes. Just use 0 = empty, 1 = solid for now? Never liked the Dizzy games myself, hence I haven't played them much, but shouldn't the collision detecion be more finely grained than that? -Frode
Re: Porting spectrum games...
Yes, Dizzy seems to have near pixel perfect collision, at least for defining the terrain. I thought the bitmap would be 256x192 bits; 0=empty, 1=solid? that would be 6144bytes per screen.
Re: Porting spectrum games...
Console Dizzy is quite clearly tile based for both graphics and collision. If I recall, Dizzy himself is three tiles high and when crossing a tile boundary may walk left or right provided that both of the top two tiles are clear. If he ends up with a tile overlapping his bottom third then he's pushed up one pixel/frame (or, possibly not exactly that number, but you get the point), to give a sort of soft boundary. Then if you're moving up a hill or whatever, he moves smoothly rather than hopping up a tile at a time. In the little PC Dizzy thing I wrote, that makes everything as simple as grab the up-to-twelve tiles that Dizzy is currently overlapping (he's two wide, so if not aligned exactly with the background may cover up to three tiles across and four tiles down), then make a decision purely on the coverage of those. If he has come to overlap somewhere with the top two tiles on his left or right, or any tiles above him then he gets an instantaneous push out of those blocks. If his feet are covered then he gets a soft push upwards. So there's no continuous state for collisions beyond his current position. And if he's rolling then he stops only if at the end of roll, with his feet on the ground. It's simple and super robust, while still being accurate to at least one real Dizzy. I guess that the same general stuff applies as you scale down the tilemap (all the way to 1 pixel, if you want), just the constants that go up. 256x192 1bpp would mean that an over/under mask doesn't fit onto the same page as a collision map and the framebuffer, so assuming it's better to keep over/under and collisions in the same format so that code is smaller and neater, I guess you want over/under placed immediately after the framebuffer and duplicated across both video pages (as you'll need it when drawing, and that makes paging easy), the collisions map placed somewhere else, with just one copy? Samflate will definitely get us off to a good start with graphics compression, as deflate is the main complicated part of it. The rest of it is just the linear predictor that dictates one of a small number of ways of predicting the next pixel (based on simple sums of the pixel to its left, the pixel above it and the pixel to its top left) and then stores the amount by which the prediction is wrong, the stream of those quantities tending to compress a lot better than raw pixel values. Quite probably Andrew's code will end up being 90% of the code for screen decompression. Or maybe 100%, depending on how well vanilla deflate does on the Fantasy World Dizzy map. Andrew's code comes with a pyz80 makefile, so that's the immediate candidate. I was planning to move my 3d stuff to Jam for the macros, but I guess Comet doesn't support those anyway? If we're saying Comet is the syntax and both Jam and pyz80 superset Comet then I guess it's academic which we use and we needn't even both use the same... On Thu, Jul 22, 2010 at 12:36 PM, the_wub ! the...@gmail.com wrote: Yes, Dizzy seems to have near pixel perfect collision, at least for defining the terrain. I thought the bitmap would be 256x192 bits; 0=empty, 1=solid? that would be 6144bytes per screen.
Re: Porting spectrum games...
I've been playing with the speccy version on the Sam this morning and I can see now the effect of the sprite being pushed up as you walk into the terrain. I'm not clear on how you're going to fit amiga screen shots into the Sam but I cannot wait to see it! I'll carry on making up a sprite set and putting together a test screen in the meantime.
Re: Porting spectrum games...
Right, so... framebuffer, 1bit per pixel over/under map, 1bit per tile 8x8 collision map? For a total of 30816 bytes? I'll assume that we're using 64kb for the two screen buffers, 64kb for main game code and music/sound, meaning that the map would ideally break into 96kb segments (for multiloading, with DOS still resident on a 256kb machine) and be less than or equal to 384kb total (for a single load on a 512kb machine, meaning we don't need DOS in memory)? On Thu, Jul 22, 2010 at 3:10 PM, the_wub ! the...@gmail.com wrote: I've been playing with the speccy version on the Sam this morning and I can see now the effect of the sprite being pushed up as you walk into the terrain. I'm not clear on how you're going to fit amiga screen shots into the Sam but I cannot wait to see it! I'll carry on making up a sprite set and putting together a test screen in the meantime.
Re: Porting spectrum games...
All sounds good to me.
Re: Porting spectrum games...
Hmmm, gmail shows that my previous email was sent twice. Apologies to all if that happened, I'll check it isn't happening repeatedly and if it is then I'll try to figure out why. I am perfectly happy saying things just once... I think there are three for the Nes, but the other two are just ports of Treasure Island Dizzy and Prince of Yolkfolk and I'm not sure if they were released here. I've looked into PNG more, and it is actually realistic to use exactly that algorithm on a Sam (albeit that there's no need to be identical in byte streams) — it's just a linear predictor and LZ77 + Huffman on the end. With that in mind, I've downloaded some of the classic Dizzy maps from those places that tile screenshots to produce game maps (in their Amiga versions) and they're all sub 400kb. Most would even fit into 256kb. So, I'm not sure what sort of art burden it creates, but I definitely think it's feasible to do a Dizzy game on the Sam that doesn't use a tile map, but rather has each and every screen hand drawn, which could look fantastic. Adding 1 or 2bit tile maps for collisions shouldn't be a memory killer. Probably automatically generating a collision map from the source art is easiest? If the designer can save out three layers — a background, middleground and foreground then an external tool can auto build a collision map for the middleground then composite the three to store as the actual screen (so it's one graphic + one collision map in game). Though if we have a foreground then I guess we need a pixel mask somewhere for sprites, which costs yet more bytes. That all being said, it's a disc-based machine so multiloads aren't a problem, are they? I vote aim high and break the world into chunks if we overshoot. I wrote a little Dizzy engine for the PC once, but have never built it for Windows (it's SDL) and was based on the PC sprites and metrics on a scrolling tile map. So it's not directly useful. Probably best to agree an assembler (I'm fine with pyz80 or Jam) and what information you need for screen management, then I can dash off and have a go at some of this screen compression stuff, hopefully to be slotted onto your test screen? How about two pages for the current screen, each filled with the same data by the screen decompressor, which is (in order): 24576 bytes; normal screen image 6144 bytes; mask image — bit set = that pixel is in front of the character sprites, bit clear = that pixel is behind, same bit layout as a Mode 2 screen 768 bytes; collision tile map. 32x24 entries, each a byte in length, linear left-to-right, top-to-bottom as per Mode 1 attributes. Just use 0 = empty, 1 = solid for now? Then there are 1280 spare bytes which my code explicitly won't touch, so anything you would use for cleaning up can go in there. On Tue, Jul 20, 2010 at 8:19 PM, the_wub ! the...@gmail.com wrote: The only console version I know is the Nes one and I haven't explored it much.. I'm more familiar with the ST versions but the two are not too far apart graphically. I wouldn't like to have to design as many levels as you could possibly fit in though! ;) I'd like to have a go at re-creating the Nes sprites and movement routines on a test screen. If I got something like that working would it go some way towards helping if combined with more graphics and your map ideas?
Re: Porting spectrum games...
The only console version I know is the Nes one and I haven't explored it much.. I'm more familiar with the ST versions but the two are not too far apart graphically. I wouldn't like to have to design as many levels as you could possibly fit in though! ;) I'd like to have a go at re-creating the Nes sprites and movement routines on a test screen. If I got something like that working would it go some way towards helping if combined with more graphics and your map ideas?
Re: Porting spectrum games...
I have to admit that my favourite Dizzy game is the console one - the energy bar is present, some of the arcadey spin-off titles have been rolled in to break up the gameplay and there's quite a limited amount of required travelling to the other side of the world just to pick up an object and travel back. Oh, and as far as I recall only a couple of the coins are of the secret 'press action here to reveal it' type, and they're in places where you might press action anyway like behind doors. None of the guessing the loose bit of handrail malarkey. Or, at least, very little. My memory is imperfect. I wonder how many unique screens you could fit into the Sam's memory (with compression) without resorting to a tile map. One of the things that's obvious after Big Red took over is that they switched quite a lot to a more vector style - not sure if it's actual vectors or just really big tiles, but it does make the world look less vanilla somehow. I guess something like PNG (ie, a standard binary compressor + per scanline switching of how graphics are encoded before compression) with a brute force optimiser (ala optipng/etc) would be the smart thing. And it'll likely always be worse than real PNG, so I guess that's a way to get an upper bound... On Sunday, July 18, 2010, the_wub ! the...@gmail.com wrote: I'm more than happy to write a Sam version of the Pooyan music if someone wants to do the easy bit and write the rest of the conversion ;-) ouch! though I guess I deserve that in hindsight! I honestly hadn't considered what would be involved with a port and I had presumed that starting from a spectrum version would be the easiest way to port anything to the Sam. I had the ST graphics from Strider ready and everything! ;) Dizzy... Arrggh!! I loathe those games! :-)) He's like Morrissey or Marmite it seems, people love him or hate him!
Re: Porting spectrum games...
I have to admit that my favourite Dizzy game is the console one - the energy bar is present, some of the arcadey spin-off titles have been rolled in to break up the gameplay and there's quite a limited amount of required travelling to the other side of the world just to pick up an object and travel back. Oh, and as far as I recall only a couple of the coins are of the secret 'press action here to reveal it' type, and they're in places where you might press action anyway like behind doors. None of the guessing the loose bit of handrail malarkey. Or, at least, very little. My memory is imperfect. I wonder how many unique screens you could fit into the Sam's memory (with compression) without resorting to a tile map. One of the things that's obvious after Big Red took over is that they switched quite a lot to a more vector style - not sure if it's actual vectors or just really big tiles, but it does make the world look less vanilla somehow. I guess something like PNG (ie, a standard binary compressor + per scanline switching of how graphics are encoded before compression) with a brute force optimiser (ala optipng/etc) would be the smart thing. And it'll likely always be worse than real PNG, so I guess that's a way to get an upper bound... On Sunday, July 18, 2010, the_wub ! the...@gmail.com wrote: I'm more than happy to write a Sam version of the Pooyan music if someone wants to do the easy bit and write the rest of the conversion ;-) ouch! though I guess I deserve that in hindsight! I honestly hadn't considered what would be involved with a port and I had presumed that starting from a spectrum version would be the easiest way to port anything to the Sam. I had the ST graphics from Strider ready and everything! ;) Dizzy... Arrggh!! I loathe those games! :-)) He's like Morrissey or Marmite it seems, people love him or hate him!
Re: Porting spectrum games...
That's great news, I'm sorry for suggesting that CM would not be up for it. I should have done some research first! I'd be very happy to lend a hand with graphics and sound for a Dizzy port/re-write if that would be useful to you and the same goes to Stefan with Pang. :) I'd like to learn what is involved in disassembling a spectrum program and getting the source into Comet. I realise there are modern tools on the PC but I'd rather use the real h/w if it can be done?
Re: Porting spectrum games...
When I was asked to port Sophistry from speccy to SAM I was given the speccy source code (devpac format I think) - this however was not the final source code... So I simply wrote a disassembler to disassemble the original game binary to Comet source. All CALLs, JPs,JRs and DJNZs were labelled Laddress, all lines were given a comment with their original address. This is repeated a few times to figure out which blocks contain graphics or other non-code, these were then moved out as binary files and MDAT'ed back in. Since Pang! is a 128k title, the Laddress convention was adjusted to also use Maddress and Naddress and Kaddress for the various original speccy memory banks. Then its a matter of running through everything, trying to figure out what does what, change the meaningless Laddress labels to something meaningful, removing all no longer required address comments. At any point you should be able to compile he set and run it (in MODE 1). Now that we have an understandable source to go from, its time to move in the SAM stuff... At the time I used Comet on a real SAM and was very happy with the speed of Comet - nowadays however... Best regards, Stefan On Sun, Jul 18, 2010 at 1:53 PM, the_wub ! the...@gmail.com wrote: That's great news, I'm sorry for suggesting that CM would not be up for it. I should have done some research first! I'd be very happy to lend a hand with graphics and sound for a Dizzy port/re-write if that would be useful to you and the same goes to Stefan with Pang. :) I'd like to learn what is involved in disassembling a spectrum program and getting the source into Comet. I realise there are modern tools on the PC but I'd rather use the real h/w if it can be done?
Re: Porting spectrum games...
Dizzy... Arrggh!! I loathe those games! :-)) Rob, if I were you I would be inclined to write your own code rather than try to disassemble the originals. The complexity and/or limit pushing of the original game will have a direct bearing on whether the original code is likely to be understandable in a pure disassembled form. Remember, none of the original source-code comments or labels will be available. Not to mention that areas of data and code will not be immediately obvious. If the original used unorthodox coding tricks, or the original coder wrote in an unorthodox style, it will be far simpler and quicker to write your own engine to do the tasks you require for your chosen game. Disassembling other programs is good when you're learning Z80, and can help you learn some tips and little tricks in code and so on. But a full-blown disassembly of a complete program to a stage where it becomes fully understandable and can be re-assembled on a different system is not something for the faint hearted!! Don't let that put you off though... If you feel the need then go for it! Regarding Spectrum ports... Why this road? I would have though that the SAM's 16-colour display would be more suited to many of the original (early/mid 80s) old-skool coin-op arcade games. These games offer far more potential than colourising old Speccy titles! Coin-op conversions... You know it makes sense!! ;-)) Chris. - Original Message - From: the_wub ! the...@gmail.com To: sam-users@nvg.ntnu.no Sent: Sunday, July 18, 2010 12:53 PM Subject: Re: Porting spectrum games... That's great news, I'm sorry for suggesting that CM would not be up for it. I should have done some research first! I'd be very happy to lend a hand with graphics and sound for a Dizzy port/re-write if that would be useful to you and the same goes to Stefan with Pang. :) I'd like to learn what is involved in disassembling a spectrum program and getting the source into Comet. I realise there are modern tools on the PC but I'd rather use the real h/w if it can be done?
Re: Porting spectrum games...
Regarding Spectrum ports... Why this road? I would have though that the SAM's 16-colour display would be more suited to many of the original (early/mid 80s) old-skool coin-op arcade games. These games offer far more potential than colourising old Speccy titles! Coin-op conversions... You know it makes sense!! ;-)) I'm more than happy to write a Sam version of the Pooyan music if someone wants to do the easy bit and write the rest of the conversion ;-)
Re: Porting spectrum games...
I'm more than happy to write a Sam version of the Pooyan music if someone wants to do the easy bit and write the rest of the conversion ;-) ouch! though I guess I deserve that in hindsight! I honestly hadn't considered what would be involved with a port and I had presumed that starting from a spectrum version would be the easiest way to port anything to the Sam. I had the ST graphics from Strider ready and everything! ;) Dizzy... Arrggh!! I loathe those games! :-)) He's like Morrissey or Marmite it seems, people love him or hate him!
Porting spectrum games...
Hi all, I just made a comment on World of Sam about porting speccy games and thought it would be worthwhile to post it here as well. I’d be interested in having a go at porting anything from the speccy to the Sam though. If another dev could help with disassembling the spectrum game and making sense of the source I’d be confident enough to add new gfx and sound code and I’d be happy to put in the time to redraw graphics in 16 colours and remake any music in e-tracker. Dizzy would be great except that it’s a Code Masters game. They might be a bit cease-and-desisty about it.. ;) My current Sam project is coming together nicely and I'm already looking ahead for something fun to do before I start on another original game. Small games with simple concepts that can be ported quickly rather than big licences would be the way to go IMO. That way time could be spent doing several games instead of one bigger one. It would also minimise the learning curve for me a bit ;) So would anyone be interested in helping me get something started in the near future? Rob.
Re: Porting spectrum games...
Having investigated that specific title in the past, I believe that the Dizzy IP is now co-owned 50:50 by CodeMasters and the Oliver Twins and there is a long standing agreement that people may create whatever fan titles they wish provided that they don't charge for them and include correct credits. So I'm not sure if that would extend to actually disassembling the Spectrum code (though plenty of other titles rip off the original series graphics), but putting out a version of Dizzy for the Sam shouldn't lead to legal troubles in principle. I guess with something like Dizzy you've got a huge advantage because quite probably the hardware specific bits would leap right out if you compared the Spectrum disassembly and the Amstrad CPC disassembly. I'm all for an effort to port games, even if it's a rewrite job. I've written a Dizzy engine for the PC before, albeit based more on the Fantastic Adventures-era Dizzy, might dust that off and have another look see. On Thu, Jul 15, 2010 at 2:51 PM, the_wub ! the...@gmail.com wrote: Hi all, I just made a comment on World of Sam about porting speccy games and thought it would be worthwhile to post it here as well. I’d be interested in having a go at porting anything from the speccy to the Sam though. If another dev could help with disassembling the spectrum game and making sense of the source I’d be confident enough to add new gfx and sound code and I’d be happy to put in the time to redraw graphics in 16 colours and remake any music in e-tracker. Dizzy would be great except that it’s a Code Masters game. They might be a bit cease-and-desisty about it.. ;) My current Sam project is coming together nicely and I'm already looking ahead for something fun to do before I start on another original game. Small games with simple concepts that can be ported quickly rather than big licences would be the way to go IMO. That way time could be spent doing several games instead of one bigger one. It would also minimise the learning curve for me a bit ;) So would anyone be interested in helping me get something started in the near future? Rob.
