Irgendwer Posted October 2, 2009 Share Posted October 2, 2009 (edited) That is horrible quality. Are you sure you have not seen what the C64 has to offer? I am sure if you did, you would not post a picture like this Ok, you caught me. No violet/purple as well as to less brownish colours. Edited October 2, 2009 by Irgendwer Link to comment Share on other sites More sharing options...
thealgorithm Posted October 2, 2009 Share Posted October 2, 2009 ... but why would it want to be a replica of that? ... Maybe you like a replica of this: That is horrible quality. Are you sure you have not seen what the C64 has to offer? I am sure if you did, you would not post a picture like this. The below is from my MUSC converter (and bear in mind that this only has sprite underlay) FLI in combination with this would look FAR better. pic.bmp Link to comment Share on other sites More sharing options...
popmilo Posted October 2, 2009 Share Posted October 2, 2009 I had to try something: Original screenshot from Amiga version of Turrican 2: Resolution taken down to 4x2 pixels and number of colors reduced to 16: Luminances (0-3) for same pixels: Combined images (If I understood GTIA mode mixing correctly): And here is a quick conversion using MSCU on C64: Looks interesting @Analmux: I have seen Altar when I already made these... It would be good experiment to convert same screenshot to that method (with interlace)... For static image it would be ok... But to move it... uuhhmmmm.... Problems arise... p.s. Same goes for moving anything in MSCU mode on C64 Link to comment Share on other sites More sharing options...
popmilo Posted October 2, 2009 Share Posted October 2, 2009 ... The below is from my MUSC converter (and bear in mind that this only has sprite underlay) FLI in combination with this would look FAR better. Congrats on really great tool btw !!! Link to comment Share on other sites More sharing options...
STE'86 Posted October 2, 2009 Share Posted October 2, 2009 (edited) mate that is bloody awful. it looks like a pc svga screen stripped down without dither to a 16 colour gif. its all very well saying "well the c64 cant do it" but basically no bloody self respecting c64 artist would post stuff thats as crap as u keep posting in 64 colours. the fact that the 64 cant display those colours is pretty immaterial if u cant post an a8 screen that uses the colours, which looks as good as a good 16 colour 64 one. edit this was not in reference to the turrican thing but the previous page. Steve Edited October 2, 2009 by STE'86 Link to comment Share on other sites More sharing options...
ANTIQ Posted October 2, 2009 Share Posted October 2, 2009 Are they APAC? Yep. Also, try attaching them full size so the blockiness isn't scaled away Try clicking on them! Link to comment Share on other sites More sharing options...
PeteD Posted October 2, 2009 Share Posted October 2, 2009 Are they APAC? Yep. Also, try attaching them full size so the blockiness isn't scaled away Try clicking on them! I did!! that's what I'm saying (I swear I need a head hammer to get a point across on this forum) people glancing at them and comparing to the fully sized posted C64 shots will go, yeah, not "too" blocky. If they don't click on them to get the full size/effect they'll stay under that illusion. Pete Link to comment Share on other sites More sharing options...
andym00 Posted October 2, 2009 Share Posted October 2, 2009 (edited) For static image it would be ok... But to move it... uuhhmmmm.... Problems arise... p.s. Same goes for moving anything in MSCU mode on C64 It's not *that* bad.. Scrolling vertically is no problem (apart from the usual choice of how to do it, plus the bonus is that there's no colour ram to shift about), horizontally a bit more problematic so since 7 sprites only fill 288 pixels leaving 16 to accomodate somehow since you can't have the 8th on both sides at the same time.. So either 12 pixel preshifted set sprites to switch to at the magic moment or clever level design.. But then you could VSP the screen and have a bucketload of time left available.. Plotting sprites in this mode isn't going to be that bad as long as you keep the the hires bitmap sprites and their sprite midlays you draw from overlapping other background stuff.. And all of that also means some sensible design to the sprite colours and also for the setup of how your software sprite colour are arranged, either one constant set of 3 colours for the entire screen underlay/midlay (whatever you want to call it), or some setup allowing the background areas to use sprite colours freely, leaving a blank region for software-sprites.. Or you design the levels in such a way that the sprites are intelligently re-used so that there's always some hardware sprites left around to draw sprites, so for example in your Turrican shot, the floor could eat all the sprites up for display, likewise the roof use only the sprites it needs, leaving the rest free to be multiplexed in a traditional fashion, but still drawing Hires bitmap overlays on them as well That Boss would look awesome in proper hires =) Granted, not the fastest sprite system in the world, but it's doable, and there's a fair whack of processing time left.. And would be seriously fecking impressive Edited October 2, 2009 by andym00 Link to comment Share on other sites More sharing options...
PeteD Posted October 2, 2009 Share Posted October 2, 2009 (edited) MSCU uses raster per line colour changes of the sprites though, no? and doesn't it have colour ram as well? Pete Edited October 2, 2009 by PeteD Link to comment Share on other sites More sharing options...
thealgorithm Posted October 2, 2009 Share Posted October 2, 2009 (edited) MSCU uses raster per line colour changes of the sprites though, no? and doesn't it have colour ram as well? Pete No Standard Mucsu only splits the sprites 9 times per screen. The updated version of my converter splits two colors every raster line (MUSC) although i can split more for higher quality. It does have color ram (1 byte = 2 nybbles (ink/paper color) eg speccy Edited October 2, 2009 by thealgorithm Link to comment Share on other sites More sharing options...
PeteD Posted October 2, 2009 Share Posted October 2, 2009 (edited) MSCU uses raster per line colour changes of the sprites though, no? and doesn't it have colour ram as well? Pete No Standard Mucsu only splits the sprites 9 times per screen. The updated version of my converter splits two colors every raster line (MUSC) although i can split more for higher quality. It does have color ram (1 byte = 2 nybbles (ink/paper color) eg speccy Sorry, getting my muscs mixed with my mucsus etc So does MUSC trigger an irq per line or just runs a loop? either way it's going to eat a fair bit of cpu but if irq per line maybe not too much to preclude doing some fairly hefty "game" processing. *edit* big loop I see safest way of course but buggers up doing game code with it. I reckon a mix of the two would be ideal for a game. I've messed with similar stuff back in the 80s as far as using sprites for extra background colour but never thought of doing an entire game with it. btw, before someone shouts off topic again it might be an idea for some a8 guys to learn about some of the c64 modes/possibilities before you write it off without knowing what it can do Pete Edited October 2, 2009 by PeteD Link to comment Share on other sites More sharing options...
thealgorithm Posted October 2, 2009 Share Posted October 2, 2009 MSCU uses raster per line colour changes of the sprites though, no? and doesn't it have colour ram as well? Pete No Standard Mucsu only splits the sprites 9 times per screen. The updated version of my converter splits two colors every raster line (MUSC) although i can split more for higher quality. It does have color ram (1 byte = 2 nybbles (ink/paper color) eg speccy Sorry, getting my muscs mixed with my mucsus etc So does MUSC trigger an irq per line or just runs a loop? either way it's going to eat a fair bit of cpu but if irq per line maybe not too much to preclude doing some fairly hefty "game" processing. btw, before someone shouts off topic again it might be an idea for some a8 guys to learn about some of the c64 modes/possibilities before you write it off without knowing what it can do Pete Standard MUCSU only needs to update sprite pointers and banks every 21 lines or so. The MUSC (Multicolor Sprite Underlay Copper) changes two main sprite colors per raster line FLI based modes in combination will give even better quality but memory requirements are higher and in the case of NUFLI etc use more than one bank for one picture Link to comment Share on other sites More sharing options...
ANTIQ Posted October 2, 2009 Share Posted October 2, 2009 Nice colour graduations on those but I don't think that's the one...I'm so bored I think I'll go scan through my issues of Atari User to find the one with the review of Technicolor Dream in it and take a snapshot now while the hot water is on Found some demo disks for it too but they didn't have the house or the sphinx picture I remember. I got them from here by mistake! Link to comment Share on other sites More sharing options...
PeteD Posted October 2, 2009 Share Posted October 2, 2009 MSCU uses raster per line colour changes of the sprites though, no? and doesn't it have colour ram as well? Pete No Standard Mucsu only splits the sprites 9 times per screen. The updated version of my converter splits two colors every raster line (MUSC) although i can split more for higher quality. It does have color ram (1 byte = 2 nybbles (ink/paper color) eg speccy Sorry, getting my muscs mixed with my mucsus etc So does MUSC trigger an irq per line or just runs a loop? either way it's going to eat a fair bit of cpu but if irq per line maybe not too much to preclude doing some fairly hefty "game" processing. btw, before someone shouts off topic again it might be an idea for some a8 guys to learn about some of the c64 modes/possibilities before you write it off without knowing what it can do Pete Standard MUCSU only needs to update sprite pointers and banks every 21 lines or so. The MUSC (Multicolor Sprite Underlay Copper) changes two main sprite colors per raster line FLI based modes in combination will give even better quality but memory requirements are higher and in the case of NUFLI etc use more than one bank for one picture Yup, totally understand how it works and what FLI etc can do, I'm just following up from Popmilo and Andym00's posts about the usefulness of various modes for doing games. MUCSU of course is easy, MUSC and anything else that runs a looped raster routine for accuracy has eaten away that much screen/cpu time so isn't great for game coding. The idea is to get as much colour and hires without hammering the CPU so you can still do scrolling, software sprites etc. Pete Link to comment Share on other sites More sharing options...
emkay Posted October 2, 2009 Share Posted October 2, 2009 I think this is a good example of what is possible just with 2 bitmap screens and palette swapping. and this is a great image showing what is possible with ZERO CPU usage...ie just using the video ram and colour ram in standard 2 colour per charblock mode. And for a nice bit of FMV with realtime decoding on a standard C64...(about 1 min on the time slider) I was looking for those demo pictures from Technicolor Dream by Redrat and couldn't find a proper screen capture of them but I do remember being stunned by them and the cottage picture would have been a perfect contrast to the house picture above...the usual trade-off Atari = blocky but high colour rez C64=sharp hires but less colours to play with hence the palette swapping interlace needed. Think that sums it up really...apart from does anyone have a link to the Tron FMV sequences played back on a C64 and A8 on youtube? I can't find them but they were good comparisons too. The pictures are ok in some cases, but the video is like some asswipe paper... I have seen it at youtube already.... Link to comment Share on other sites More sharing options...
emkay Posted October 2, 2009 Share Posted October 2, 2009 That is horrible quality. Are you sure you have not seen what the C64 has to offer? I am sure if you did, you would not post a picture like this Ok, you caught me. No violet/purple as well as to less brownish colours. Independant of any C64 freak's limited taste, the pic really has some flaws which make it odd in some cases. Link to comment Share on other sites More sharing options...
thealgorithm Posted October 2, 2009 Share Posted October 2, 2009 I think this is a good example of what is possible just with 2 bitmap screens and palette swapping. and this is a great image showing what is possible with ZERO CPU usage...ie just using the video ram and colour ram in standard 2 colour per charblock mode. And for a nice bit of FMV with realtime decoding on a standard C64...(about 1 min on the time slider) I was looking for those demo pictures from Technicolor Dream by Redrat and couldn't find a proper screen capture of them but I do remember being stunned by them and the cottage picture would have been a perfect contrast to the house picture above...the usual trade-off Atari = blocky but high colour rez C64=sharp hires but less colours to play with hence the palette swapping interlace needed. Think that sums it up really...apart from does anyone have a link to the Tron FMV sequences played back on a C64 and A8 on youtube? I can't find them but they were good comparisons too. The pictures are ok in some cases, but the video is like some asswipe paper... I have seen it at youtube already.... What do you expect at 500 bytes per frame! Each frame is 1k uncompressed (pointing to universal codebook - which is 2k) it depacks to 1k frames on the fly Link to comment Share on other sites More sharing options...
+wood_jl Posted October 2, 2009 Share Posted October 2, 2009 And for a nice bit of FMV with realtime decoding on a standard C64...(about 1 min on the time slider) http://www.youtube.com/watch?v=75Dht2acVnE Naaah, too much teasing - not enough actual certifiable, undeniable boobage. Show me the boobage and I'll have more respect for your machine. Link to comment Share on other sites More sharing options...
andym00 Posted October 2, 2009 Share Posted October 2, 2009 Yup, totally understand how it works and what FLI etc can do, I'm just following up from Popmilo and Andym00's posts about the usefulness of various modes for doing games. MUCSU of course is easy, MUSC and anything else that runs a looped raster routine for accuracy has eaten away that much screen/cpu time so isn't great for game coding. The idea is to get as much colour and hires without hammering the CPU so you can still do scrolling, software sprites etc. The older MUCSU tool was my inspiration.. Even it's really simple method absolutely changes the character of the hires screen totally.. Even with just 3 fixed greys it's like a whole new graphics mode to play with Link to comment Share on other sites More sharing options...
thealgorithm Posted October 2, 2009 Share Posted October 2, 2009 MSCU uses raster per line colour changes of the sprites though, no? and doesn't it have colour ram as well? Pete No Standard Mucsu only splits the sprites 9 times per screen. The updated version of my converter splits two colors every raster line (MUSC) although i can split more for higher quality. It does have color ram (1 byte = 2 nybbles (ink/paper color) eg speccy Sorry, getting my muscs mixed with my mucsus etc So does MUSC trigger an irq per line or just runs a loop? either way it's going to eat a fair bit of cpu but if irq per line maybe not too much to preclude doing some fairly hefty "game" processing. btw, before someone shouts off topic again it might be an idea for some a8 guys to learn about some of the c64 modes/possibilities before you write it off without knowing what it can do Pete Standard MUCSU only needs to update sprite pointers and banks every 21 lines or so. The MUSC (Multicolor Sprite Underlay Copper) changes two main sprite colors per raster line FLI based modes in combination will give even better quality but memory requirements are higher and in the case of NUFLI etc use more than one bank for one picture Yup, totally understand how it works and what FLI etc can do, I'm just following up from Popmilo and Andym00's posts about the usefulness of various modes for doing games. MUCSU of course is easy, MUSC and anything else that runs a looped raster routine for accuracy has eaten away that much screen/cpu time so isn't great for game coding. The idea is to get as much colour and hires without hammering the CPU so you can still do scrolling, software sprites etc. Pete In most cases MUCSU is sufficient enough. MUSC and Super MUSC (SMUSC not released yet) are line based and only really suitable for still imagary with lots of colors in small area ranges. Link to comment Share on other sites More sharing options...
thealgorithm Posted October 2, 2009 Share Posted October 2, 2009 Yup, totally understand how it works and what FLI etc can do, I'm just following up from Popmilo and Andym00's posts about the usefulness of various modes for doing games. MUCSU of course is easy, MUSC and anything else that runs a looped raster routine for accuracy has eaten away that much screen/cpu time so isn't great for game coding. The idea is to get as much colour and hires without hammering the CPU so you can still do scrolling, software sprites etc. The older MUCSU tool was my inspiration.. Even it's really simple method absolutely changes the character of the hires screen totally.. Even with just 3 fixed greys it's like a whole new graphics mode to play with The New MUCSU converter has the classic MUCSU mode (but improved allowing 7 individual main sprite colors) at same cpu usage (eg 9 splits per frame) as well as the option of using the MUSC mode. Link to comment Share on other sites More sharing options...
emkay Posted October 2, 2009 Share Posted October 2, 2009 32 - CASTLE WOLFENSTEIN CASTLE WOLFENSTEIN: 7.4 Star Raiders II: 7.5 The game also clearly shows what was real... The A8 version looks far more "professional" But The C64 version has some additional arts. So the "standard" question: What stopped them to add those "additional arts" to the A8 version.... And the answer is....: Link to comment Share on other sites More sharing options...
oky2000 Posted October 3, 2009 Share Posted October 3, 2009 oky? Do the originals of those exist, I mean before they were APAC'd ? Or whatever contraption mode that is ? It's a custom mode from the art package Technicolor Dream. I've looked at what demo disks for that program are available and no I can't find them. Think it mixes two modes hence the scanlines and the resolution is about 160x100(?) I didn't link to that Atarimania scan because it's just not possible to get any detail from it. And no I am thinking of another house/cottage pic I think but who knows...have to find the original review in Atari User (UK). Link to comment Share on other sites More sharing options...
oky2000 Posted October 3, 2009 Share Posted October 3, 2009 The pictures are ok in some cases, but the video is like some asswipe paper... I have seen it at youtube already.... For realtime codec work it is impressive for a 1mhz 6510 in any case. Looks better than those A8 Matrix reloaded videos anyway and faster too I can't find the bloody Tron lightcycles C64 realtime video on youtube though which was great. Link to comment Share on other sites More sharing options...
atariksi Posted October 3, 2009 Share Posted October 3, 2009 Well, it's currently just a hodge-podge of comparing Apples and Oranges. You can't put up interlaced images captured with emulator and compare with non-interlaced images as the flicker doesn't show up and is more significant on C64. And you can't compare shaded imagery with miscolored imagery. It's no hodge podge of whatever fruit analogy you choose to use.. I'll say it again just to be 100% clear this time.. They're not interlaced pictures, therefore there is no flicker.. They're just plain old fashioned Hires modes, or (in the case of the last 4) FLI'd hi-res or NU-FLI hires.. That wasn't a reply to you. That was a reply to the generic pictures posted having no relevance to the point I raised regarding shading. My point is simple and anyone who denies it denies reality. You can't do images relying on shading on C64 and just posting some arbitrary colored images dosen't make up for the shading. Your missing the point. You just want to make some OTHER point but pretending to be replying to my point which you haven't done. I understand your pictures are hi-res but some others posted are interlaced and flickering type and/or hog up all the CPU time. Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts