popmilo Posted June 29, 2015 Share Posted June 29, 2015 One thing I noticed on Altirra was that colours were very washed with Filter Mode=Point and so Bilinear produced the greens in your screenshot. Which is the more faithful with real hardware and CRT? @Philsan @Wrathchild (about washed colors): In Altirra settings I've increased color saturation (same as you would do on CRT) and looks much better. On CRT it looks crazy not like Atari ps. Wrathchild - if you have some nice screenshot with background graphics, please upload it and we can see how it could look with more green and red details. Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted June 29, 2015 Author Share Posted June 29, 2015 3 Quote Link to comment Share on other sites More sharing options...
pseudografx Posted June 30, 2015 Share Posted June 30, 2015 (edited) Just a quick mock-up of a 5-colour version (for ANTIC 4 mode). Edited June 30, 2015 by pseudografx 6 Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted June 30, 2015 Author Share Posted June 30, 2015 What would the fifth/COLOR3 be? Quote Link to comment Share on other sites More sharing options...
José Pereira Posted June 30, 2015 Share Posted June 30, 2015 From what I see the PF2/PF3 is brown/green. Quote Link to comment Share on other sites More sharing options...
pseudografx Posted June 30, 2015 Share Posted June 30, 2015 Yes. :-) Quote Link to comment Share on other sites More sharing options...
popmilo Posted July 2, 2015 Share Posted July 2, 2015 No comment needed Executable: sonic2.xex ps. Source image is part of screenshot from Game Gear emulator. Couple grey colors not used at all... 9 Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted July 2, 2015 Author Share Posted July 2, 2015 What are your thoughts on background animations? (would still look great without them ) Would a double buffered approach work better here? I'm (slowly due to less time ATM) looking at a method of still using the Players to give extra colours over the screen pseudografx produced but extended to use an AND mask to punch holes in the background and then an OR mask to re-add colours from the Playfield to the Player image. So with a character based screen-map the animations could be controlled either through CHBAS redirection or writing into the charset itself. Quote Link to comment Share on other sites More sharing options...
popmilo Posted July 3, 2015 Share Posted July 3, 2015 My example is simple bitmap mode (for easier graphics conversion) with three colors changed every scanline. Nothing complicated. What makes this so colorful is 16 possible luma+color combinations. You can use same Pal blending effect in char mode or on only some pairs of pixels with simple dithering. In your example with PM over character graphics, you could mix PM colors in odd scanlines and background colors in even lines. Anyway, I like simple PM over background also Anything that gets one more color on screen is good by my standards 2 Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted July 5, 2015 Share Posted July 5, 2015 OK, I have a flicker technique. I use this a lot in super IRG (a doubled antic 4 with 14 colors). When blending colors, you use a checker board dithering technique so that colors blend on alternate frames. Like this ... 01010101 10101010 Second frame, reverse the pixels. Looks a lot better than full frame flicker. 1 Quote Link to comment Share on other sites More sharing options...
popmilo Posted July 6, 2015 Share Posted July 6, 2015 Dithering like that can always produce nice colors. Not so sure about mixing frames (maybe it's too flickery). Here is something similar to that (only changing screens to mix luma and chroma, no dither pattern). I've just added one line vertical shift every other frame: sonicflicker.xex Here is how it looks in Atari800 and 'save screenshot with interlace': Can someone try this on real CRT ? (I'm at my in-laws so my 800xl is currently ~50km away ). 2 Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted July 7, 2015 Share Posted July 7, 2015 The dither-flicker technique looks good if you are careful what colors you use. I used this to make a mockup of Rainbow Islands, to excellent results. I think this could also be used to multiplex pmgs too. http://atariage.com/forums/topic/202803-anyone-ever-thought-in-ways-to-get-rainbow-islands-on-a8/page-2?do=findComment&comment=2600221 As for scanline shift ... looks excellent in NTSC. :-) Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted July 7, 2015 Share Posted July 7, 2015 Dithering like that can always produce nice colors. Not so sure about mixing frames (maybe it's too flickery). Here is something similar to that (only changing screens to mix luma and chroma, no dither pattern). I've just added one line vertical shift every other frame: sonicflicker.xex Here is how it looks in Atari800 and 'save screenshot with interlace': sonic.png Can someone try this on real CRT ? (I'm at my in-laws so my 800xl is currently ~50km away ). Well, as expected, it is flicker-hell on a PAL Atari... too bad :-( Playing a fast action game (shoot-em-up/shmup) like "Space Harrier", the flicker is acceptable, not so in a jump & run game... 1 Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted July 7, 2015 Share Posted July 7, 2015 Another thing to keep in mind ... all scrolling and screen action is required to happen at 25 frames per second (30 NTSC) when using frame changes. Otherwise, it won't work properly. Quote Link to comment Share on other sites More sharing options...
kiwilove Posted July 8, 2015 Share Posted July 8, 2015 (edited) I would have thought that for a scrolling Sonic like game - that the best mode for this game type - would have been Antic 4 - and making full use of multiplexing of sprites and missiles. The downside is the use of only 5 colours as such - DLIs can be used for some extra colour (with severe horizontal restrictions) - but you can make use of an animated rear screen (for parallax effect) and animated characters - just think of AtariBLAST! transformed into a scrolling platform game? [There is not the intention to work on such a new project after AtariBLAST! - but I can probably say? That the field is wide open for anyone wanting to try that kind of project out.. they are welcome to do so.....] The real limitation is what you can do with the sprite hardware - in terms of design - that you couldn't draw a detailed Sonic like sprite - but probably have to use something simpler/plainer because of the limited pixels/colour available - Miner 2049'er and other such sprite designs come to mind. For it to be successful overall - it's important to get the scale just right - some projects end up with using a too small scale as such - in which there is a lack of 'character' (due to too few pixels/colour) present - and if you go the other way - which is what is illustrated here - not showing enough of the landscape/playfield works against the scrolling game format? With the scale as shown in the test here - it's even more crucial that it needs a high frame rate - as anything jerky and slow, would work against it. It will be very tight - to get something that does work well - that is pleasing to the eye - and able to satisfy the gameplay mechanics - such that it appears to be coin-op like quality for a home system. That at least it will seem to be an excellent approximation to a coin-op quality game. But what do I know? I am no programmer - and do not know the hardware intimately - and am only a graphics guy - who likes tweaking the graphics to a reasonable standard. Harvey Edited July 8, 2015 by kiwilove Quote Link to comment Share on other sites More sharing options...
+MrFish Posted July 8, 2015 Share Posted July 8, 2015 (edited) Dithering like that can always produce nice colors. Not so sure about mixing frames (maybe it's too flickery). Here is something similar to that (only changing screens to mix luma and chroma, no dither pattern). I've just added one line vertical shift every other frame: sonicflicker.xex Here is how it looks in Atari800 and 'save screenshot with interlace': sonic.png Can someone try this on real CRT ? (I'm at my in-laws so my 800xl is currently ~50km away ). It has a small amount of noticeable jitter on an NTSC CRT, but it's not bad at all. The jitter is more noticeable on the lighter colored areas of the screen (i.e.: light green, yellow - flower on NTSC...). Overall it looks really good. Edited July 8, 2015 by MrFish Quote Link to comment Share on other sites More sharing options...
popmilo Posted July 8, 2015 Share Posted July 8, 2015 Thanks for testing it! No wonder brighter colors are more noticeable... Antic 4 is logical choice for fast scrolling games and Harvey is right that problem is in those 5 colors and narrow sprites (not to mention only 4 of them). Good for quick movement, software sprites can increase number of moving objects (limited to same 5 colors) but with reduced speed (probably 25fps). Compared to that this is just a static bitmap screen test that takes probably 30% of cpu time away... So what ever game you make, speed won't be one of its main features Would love for somebody to surprise us and prove the opposite Antic 4 + Pal blending + use only hardware sprites - could be fast colorful game... Quote Link to comment Share on other sites More sharing options...
analmux Posted July 8, 2015 Share Posted July 8, 2015 @ popmilo Do you use only PAL blending, or also GTIA patch changes, f.e. running DLIs every scanline? Anyway, it would look interesting when also scrolling through the whole Sonic level. Quote Link to comment Share on other sites More sharing options...
Jetboot Jack Posted July 8, 2015 Share Posted July 8, 2015 This would be an awesome use of Nosty's Tomek Cart (https://www.youtube.com/watch?v=udMW9aeF-sk) If it ever sees the light of day... sTeVE 2 Quote Link to comment Share on other sites More sharing options...
kiwilove Posted July 8, 2015 Share Posted July 8, 2015 Thanks for testing it! No wonder brighter colors are more noticeable... Antic 4 is logical choice for fast scrolling games and Harvey is right that problem is in those 5 colors and narrow sprites (not to mention only 4 of them). Good for quick movement, software sprites can increase number of moving objects (limited to same 5 colors) but with reduced speed (probably 25fps). Compared to that this is just a static bitmap screen test that takes probably 30% of cpu time away... So what ever game you make, speed won't be one of its main features Would love for somebody to surprise us and prove the opposite Antic 4 + Pal blending + use only hardware sprites - could be fast colorful game... I don't think colours are everything - but that the game design / gameplay part must always come first - be delivered - if you can add extra colours on top of that - then that would be the icing on the cake. Prince of Persia shows what can be done with limited colour - admirably. Rick Dangerous shows what extra colour(s) can do in it's VBMX upgrade - but would have liked the ordinary hardware to provide. 5 colours is very hard to work with - but you can just get by, if chosen wisely. Hopefully multiplexing of players (ie. multi-coloured?) and missiles is better use of the hardware, rather than using the players for extra colour(s). But what do I know? I'm no technie - and am only a graphics guy who prefer tweaking other peoples' graphics where possible. I like to see a decent Galaga styled game being done - that show it is/was always possible? And a better Buck Rogers one... too. (Zaxxon too? Kind of...I will show something of this - not as a WIP or future project/etc but something to show others - they can have a go, if they want to?) Sure - Sonic can be added to the list - if that is what you want.... Harvey Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted July 8, 2015 Share Posted July 8, 2015 (edited) No comment needed Is there a special reason why you use $x2 lightness values for the color registers in the hue lines and not $x6 or even $x8 which would reduce the mean error (and also flicker in case of interlace) of the display? (These values are shown by the attached images (static/flicker blended). I even would try to set COLBK to $6 or $8 on those lines but I wasn't able to apply the patch so easily on your xex ) Edited July 9, 2015 by Irgendwer 2 Quote Link to comment Share on other sites More sharing options...
popmilo Posted July 9, 2015 Share Posted July 9, 2015 Do you use only PAL blending, or also GTIA patch changes, f.e. running DLIs every scanline?Don't know what you mean by gtia patch changes ? I'm only using one dli to fire bunch of lda,sta for three color changes and one sta wsync to wait for next scanline. There is around 30 cpu cycles free in bitmap mode per line so all in all we could use ~6000 cycles for something else. That's around 15% of raster time so wouldn't be bad at all. This would be an awesome use of Nosty's Tomek Cart (https://www.youtube.com/watch?v=udMW9aeF-sk)Yeah it would, just imho it looks like 'cheating' I don't think colours are everything - but that the game design / gameplay part must always come first... ... I like to see a decent Galaga styled game being done - that show it is/was always possible? Agreed 100%. Making fast galaga like game (like galaga deluxe on Amiga or later Warblade on pc) would be extra nice on Atari. With all it's vertical screen 'oriented' properties it could be perfect 8bit version. Is there a special reason why you use $x2 lightness values for the color registers in the hue lines and not $x6 or even $x8 which would reduce the mean error (and also flicker in case of interlace) of the display? (These values are shown by the attached images (static/flicker blended). I even would try to set COLBK to $6 or $8 on those lines but I wasn't able to apply the patch so easily on your xex ) Someone told me here on AA years ago to use 02 instead of 00 for black and it became a habit I didn't use higher values because I read somewhere that color saturation is higher at lower luma values and colors are 'pale' whith larger luma values. You just need to ask for source Quote Link to comment Share on other sites More sharing options...
analmux Posted July 9, 2015 Share Posted July 9, 2015 Don't know what you mean by gtia patch changes ? I'm only using one dli to fire bunch of lda,sta for three color changes and one sta wsync to wait for next scanline. There is around 30 cpu cycles free in bitmap mode per line so all in all we could use ~6000 cycles for something else. That's around 15% of raster time so wouldn't be bad at all. Yes, sorry, I was just puzzling. I mean GTIA 'palette', NOT 'patch'. And having a better look, now I see indeed that it runs heavy DLIs. Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted July 9, 2015 Share Posted July 9, 2015 (edited) I didn't use higher values because I read somewhere that color saturation is higher at lower luma values and colors are 'pale' whith larger luma values. That's not correct and PAL mixing doesn't care about the lightness but only takes the color angle into account and propagates that (like you can see in the images). It's also the principle 'JAG' relies on. In APAC however you have the problem, that on the hue lines the 'zero'-colour stays black - no matter what lightness is applied to the other indices. That let look those images odd if a lightness more than 2 is applied. Edit: If you could provide the example with $6 lightness hues (also for the 'black-color') the estimation would be quite interesting. Esp. the reduction of the flicker in the interlace version... Edited July 9, 2015 by Irgendwer Quote Link to comment Share on other sites More sharing options...
popmilo Posted July 10, 2015 Share Posted July 10, 2015 Here is version where you can control luma value of colors and change flicker with fire button (values in bottom text line). Looks good with luma 6. sonic_joystick_luma_flicker.xex ps. Works in Altirra, doesn't in atari800.. Think I've overwritten something in memory by using charset for status bar... No time to fix it now 3 Quote 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
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.