Heaven/TQA Posted February 19, 2013 Share Posted February 19, 2013 APAC Mode is not good still in emulation as you need the 50 PAL interlace. so best on TV still. Quote Link to comment Share on other sites More sharing options...
emkay Posted February 19, 2013 Share Posted February 19, 2013 APAC is interleave, not interlace Quote Link to comment Share on other sites More sharing options...
emkay Posted February 19, 2013 Share Posted February 19, 2013 (edited) Tempus, what kind of "game" do you think about, using "Gr.7" with colours? Edited February 19, 2013 by emkay Quote Link to comment Share on other sites More sharing options...
Tempus Posted February 19, 2013 Author Share Posted February 19, 2013 Tempus, what kind of "game" do you think about, using "Gr.7" with colours? ...some kind of raycasting game, but I'm at the very beginning . Therefore I'm asking for an approriate gfx resolution. For my understanding character modes are not useful for doing this due to the raycasting algorithm. Anyway I need as much CPU power as possible. The four standard colors of GR#7 are not enough, GR#9-11 offer more (I guess enough) colors, but a poor hres, even when using wide playfield. Therefore I'd like to have a hres of 160 with >4 colors... Quote Link to comment Share on other sites More sharing options...
emkay Posted February 19, 2013 Share Posted February 19, 2013 Wouldn't it also be interesting, to have such a game running as fast as possible? Quote Link to comment Share on other sites More sharing options...
Tempus Posted February 19, 2013 Author Share Posted February 19, 2013 Wouldn't it also be interesting, to have such a game running as fast as possible? sure - less pixels -> faster game...But would it be nice/playable with a gfx of 96x96? Quote Link to comment Share on other sites More sharing options...
Xuel Posted February 19, 2013 Share Posted February 19, 2013 It sounds like you might be out of luck. ANTIC simply doesn't fetch data fast enough to display full screen images with more than four colors at 160 pixels per line. You can use player/missile graphics to add bits of color here and there, but it is not general purpose and can be very CPU intensive if you have to adjust the horizontal position of the players for different parts of the screen. Perhaps your best bet would be to use a kind of dithering? For example, Mule Wars creates more "colors" by filling areas either with solid colors or with two-color mixtures of the base colors. However, it is also using ANTIC 4 character mode, so it's getting a fifth color to mix as well, so if you stick with ANTIC E, you'll have fewer mixtures to use. No PAL-blending: PAL-blending: BTW, I have my saturation turned up a bit in Altirra. Quote Link to comment Share on other sites More sharing options...
José Pereira Posted February 19, 2013 Share Posted February 19, 2013 Hi guys. Xuel was just thinking in Blending but that depends the game he wants. If in PAL it is possible, perhaps, we can get something remember (using GR.15, even 7)? Like in our talkings that small pixels dither (like in Mule Wars) even not true can still fool our eies even on NTSC. Tempus if you want a help maybe possible we get more than the 4colours by using Blending (something with PMGs?) Send me a P.M. with some gfxs and ideas you already have and maybe I can help. 1 Quote Link to comment Share on other sites More sharing options...
emkay Posted February 19, 2013 Share Posted February 19, 2013 sure - less pixels -> faster game...But would it be nice/playable with a gfx of 96x96? Well, Wolfenstein 3D has a visuable resolution lower/equal to 160x100. Yes, it's only 4 colours, but you always have the PMg with GPRIOR 0 setting, for colour enhancements. Quote Link to comment Share on other sites More sharing options...
Tempus Posted February 19, 2013 Author Share Posted February 19, 2013 ...wouldn't it be possible to generate a TIP like gfx mode based on GR#9-11, not in order to gain more colors, but to increase the hres? Quote Link to comment Share on other sites More sharing options...
emkay Posted February 19, 2013 Share Posted February 19, 2013 For some impression of a higher resolution, you have to use GR. 10 (instead of Gr. 11) and GR. 9. The pixel shift, caused by the Palette reading, helps here. You can chose from 9 colours in Gr. 10 and still use the 16 lumas from Gr.9 . Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted February 20, 2013 Share Posted February 20, 2013 (edited) ...wouldn't it be possible to generate a TIP like gfx mode based on GR#9-11, not in order to gain more colors, but to increase the hres? Well, many years ago, they invented HIP which is 160x200 pixels greyscale (Gr. 10 combined with Gr. 9, greyscale only). Later came RIP which is up to 160x240 pixels (Gr. 10 colors, combined with Gr. 9). The problem with RIP is strange/false colours, since Gr. 10 offers only 9 different colours. And of course such screens may use up to 19kbytes. HIP is fixed to 160x200 pixels, RIP can vary in resolution, so 160x100 could also be possible... Something I suggested here many times, but which has not been tested yet, is to use Gr. 10 GTIA shifting (sometimes called GTIA bug or HIP/RIP mode) for the higher resolution but combined with Gr. 11. So, Gr. 10 should give the greyscales (8 different greyscales possible*) and Gr. 11 should give the colours (16 different colours), so we have a new RIP mode with up to 160x240 pixels and up to 8x16=128 colours - but as said before with large memory usage (HIP, RIP, TIP and many other interleave Atari 8Bit modes are quite memory hungry) and maybe/quite likely too slow then... Maybe XLPaintMax and its RAW / MAX mode with up to 160x200 pixels and max. 16 colours requires less memory and/or is faster: http://madteam.atari...ytki/xlpaint.7z or simply look here for a XLPaintMAX video: http://www.atariage....50#entry2612682 Or maybe Paradox and its 16 colour gfx with up to 160x100 does the trick: http://satantronic.a...k/?str=xe_utils or simply look here for some PAL blending pics: http://www.atariage....g/#entry2609821 but afaik, XLPaintMax and Paradox / PAL blending are PAL only... -Andreas Koch. * I have been told that Gr. 10 allows up to 9 different colours, but if you use only greyscales in Gr. 10 then there are max. 8 different greys (the 9th grey is the same as another already existing grey)... Edited February 20, 2013 by CharlieChaplin 2 Quote Link to comment Share on other sites More sharing options...
popmilo Posted February 20, 2013 Share Posted February 20, 2013 Something I suggested here many times, but which has not been tested yet, is to use Gr. 10 GTIA shifting (sometimes called GTIA bug or HIP/RIP mode) for the higher resolution but combined with Gr. 11. So, Gr. 10 should give the greyscales (8 different greyscales possible*) and Gr. 11 should give the colours (16 different colours), so we have a new RIP mode with up to 160x240 pixels and up to 8x16=128 colours - but as said before with large memory usage (HIP, RIP, TIP and many other interleave Atari 8Bit modes are quite memory hungry) and maybe/quite likely too slow then... Problem with those kinds of modes (half large pixel shift in every second row) is that colors are not independent from each other... We get these diagonaly mixed colors that can not be easily handled like plain square pixels... It sure would be interesting to test mode like that with dynamic game-like graphics. Or maybe Paradox and its 16 colour gfx with up to 160x100 does the trick: http://satantronic.a...k/?str=xe_utils That is essentially Pal-blending mode that was mentioned earlier. Here is an example of 'Paradox' editor picture: Once again, I'm giving my vote up for Pal Blending Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted February 20, 2013 Share Posted February 20, 2013 Problem with those kinds of modes (half large pixel shift in every second row) is that colors are not independent from each other... We get these diagonaly mixed colors that can not be easily handled like plain square pixels... It sure would be interesting to test mode like that with dynamic game-like graphics. That is essentially Pal-blending mode that was mentioned earlier. Here is an example of 'Paradox' editor picture: Once again, I'm giving my vote up for Pal Blending Yes, correct. Thats why I edited my post (while you were posting here)... Not sure where Tempus is from (NTSC or PAL region), so he may like or not like PAL blending... -Andreas Koch. Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted February 20, 2013 Share Posted February 20, 2013 many years ago, they invented HIP which is 160x200 pixels greyscale (Gr. 10 combined with Gr. 9, greyscale only). Later came RIP which is up to 160x240 pixels (Gr. 10 colors, combined with Gr. 9). The problem with RIP is strange/false colours, since Gr. 10 offers only 9 different colours. And of course such screens may use up to 19kbytes. HIP is fixed to 160x200 pixels, RIP can vary in resolution, so 160x100 could also be possible... Something I suggested here many times, but which has not been tested yet, is to use Gr. 10 GTIA shifting (sometimes called GTIA bug or HIP/RIP mode) for the higher resolution but combined with Gr. 11. So, Gr. 10 should give the greyscales (8 different greyscales possible*) and Gr. 11 should give the colours (16 different colours), so we have a new RIP mode with up to 160x240 pixels and up to 8x16=128 colours - but as said before with large memory usage (HIP, RIP, TIP and many other interleave Atari 8Bit modes are quite memory hungry) and maybe/quite likely too slow then... I did experiments with 11+10 in char mode (a mode I named CHIP) ... the main disadvantage with it is that the color map is all one luminance, so you don't really get the sharply defined resolution that you get with HIP/RIP mode. I did one experiment that rendered a HIP picture in 8K. What you do is a scanline change between 9 and 10 every two scanlines, then use a scanline shift to shake the picture up and down by a scanline. Here's an example: eplan.obx I also did this example, using 15+10, a screencapture from the R-type game. rtype.obx This is the same mode, using the Ninja game: ninja3.obx Not sure how this looks on PAL, but it gives good results on NTSC. These examples give a simulated vertical resolution of 192, due to the vertical scanline shifting. Quote Link to comment Share on other sites More sharing options...
emkay Posted February 20, 2013 Share Posted February 20, 2013 Something I suggested here many times, but which has not been tested yet, is to use Gr. 10 GTIA shifting (sometimes called GTIA bug or HIP/RIP mode) for the higher resolution but combined with Gr. 11. So, Gr. 10 should give the greyscales (8 different greyscales possible*) and Gr. 11 should give the colours (16 different colours), so we have a new RIP mode with up to 160x240 pixels and up to 8x16=128 colours - but as said before with large memory usage (HIP, RIP, TIP and many other interleave Atari 8Bit modes are quite memory hungry) and maybe/quite likely too slow then... That mode would not make much sense. As the real benefit of the GTIA Modes IS the 16 lumas. Quote Link to comment Share on other sites More sharing options...
Tempus Posted February 20, 2013 Author Share Posted February 20, 2013 ...thanks for all the productive inputs. I think I'll start with GR#9-11. If the achievable frame rate is high enough, I can try to get a higher resolution using the GTIA shift error or switching to GR#7 and using DLIs. PAL blending is an interesting technique, but I'd like to have the same program running on PAL and NTSC machines without modification. 1 Quote Link to comment Share on other sites More sharing options...
popmilo Posted February 20, 2013 Share Posted February 20, 2013 ...thanks for all the productive inputs. I think I'll start with GR#9-11. If the achievable frame rate is high enough, I can try to get a higher resolution using the GTIA shift error or switching to GR#7 and using DLIs. PAL blending is an interesting technique, but I'd like to have the same program running on PAL and NTSC machines without modification. If you are up for speed (you probably are ), you could do something like NRV did in Project M: Draw your objects (vertical rays) one byte at a time. Count whole byte as one pixel in your calculations (it will be two GTIA pixels on screen of course). Don't worry much about saving time with tricks for vertical doubling lines and such... Simple repeating LMS's in Display list are enough for pixel sizes like 4x2 or 4x4 (hires pixels). There are lots of other parts of code that you need to optimize before that becomes important. Most important: just go for it! We need projects like that 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.