Jump to content
IGNORED

Atari 8-Bit Graphics Capabilities


Recommended Posts

Wow, just wow ! This is some incredible work. It absolutely deserves its separate thread!!!

 

Looks like you explored the hue blending to the max then ? Or do you think there is still some more ground to cover ?

 

 

How exactly do you handle the end-of-line jitter in your kernel ? Or is that why the many colors are somewhat distant from the screen edges as this way if one color change bleeds from end of previous scanline, it's hidden - correct ?

 

I presume you generate the kernel automatically through your toolset ? Surely you don't write kernel manually for each picture ?

Link to comment
Share on other sites

OK, I am loving this! Will this be a PC app that is released for conversions like Rastaconverter? Is there a chance of a paint program that runs on an atari to make graphics from scratch (and NOT like G2F where work has to be done on a PC), I want to do my artwork on a real Atari, not just get and end result for Atari image and have to use a PC for my art work. I much prefer doing my Atari art on an Atari. Actually Atari 8-bit is the only computer I do graphic art on, otherwise my artwork is all traditional painting and sketching, etc. Which is why I never use G2F. but just converting on a PC like Rasta is OK if that's all it comes too. When will the converter program for this be released? I'd love to hang up Rastaconverter, for a while anyway, and start doing conversions with this program. Assuming I'm understanding all this and that's what you are aiming for. Or is all this original pixel art you did on an Atari (or emulator) and there is no converter or paint program planned at all, just for use for programmers?

 

One of these days I was planning on taking pictures of all my traditional art and attempting Rasta conversions of it, which I may still do one day, but I'd love to do it with this too, and also be able to use these new modes for artwork on my Atari.

Edited by Gunstar
  • Like 1
Link to comment
Share on other sites

11 minutes ago, VladR said:

Wow, just wow ! This is some incredible work. It absolutely deserves its separate thread!!!

 

Looks like you explored the hue blending to the max then ? Or do you think there is still some more ground to cover ?

 

 

How exactly do you handle the end-of-line jitter in your kernel ? Or is that why the many colors are somewhat distant from the screen edges as this way if one color change bleeds from end of previous scanline, it's hidden - correct ?

 

I presume you generate the kernel automatically through your toolset ? Surely you don't write kernel manually for each picture ?

There is no problem with end of line jitter. There is wsync on every line, except badlines. And the kernel is static, same for every image. Only the bitmaps, charmaps (what char is inverted) and PMG data are different. It is however unrolled in character modes, as I said. Badlines are well .. bad.

Link to comment
Share on other sites

1 minute ago, Gunstar said:

OK, I am loving this! Will this be a PC app that is released for conversions like Rastaconverter? Is there a chance of a paint program that runs on an atari to make graphics from scratch (and NOT like G2F where work has to be done on a PC, I want to do my artwork on a real Atari, not just get and end result for Atari image and have to use a PC for my art work. I much prefer doing my Atari art on an Atari. Which is why I never use G2F. but just converting on a PC like Rasta is OK if that's all it comes too. When will the converter program for this be released? I'd love to hang up Rastaconverter, for a while anyway, and start doing conversions with this program. Assuming I'm understanding all this and that's what you are aiming for. Or is all this original pixel art you did on an Atari (or emulator) and there is no converter or paint program planned at all, just for use for programmers?

There will be convertor. And I think I'm getting close. The biggest problem is high amount of options and parameters every step has, and which have to be fiddled with for best results. But I'm settling down, abandoning some experimental features which didn't work, finding universal sets of parameters and so on, so it's getting simpler. At the moment it's nowhere near being usable by normal people, but that won't be that hard. Not promising anything, of course.

 

  • Like 5
Link to comment
Share on other sites

5 minutes ago, R0ger said:

There is no problem with end of line jitter. There is wsync on every line, except badlines. And the kernel is static, same for every image. Only the bitmaps, charmaps (what char is inverted) and PMG data are different. It is however unrolled in character modes, as I said. Badlines are well .. bad.

That is absolutely insane that you can get away with WSYNC butchering the CPU yet still get this kind of quality ! WTF ?!?

 

I would never in a million years believe this quality could be possible without precise cycle counting and without WSYNC. So, each scanline's kernel is just few simple LDA/STAs for color registers ended with STA WSYNC then ?!?

 

Which means, that this can still be pushed further :)

 

How exactly are badlines affecting this ? Doesn't WSYNC help with that or am I missing something about the nature of badlines ?

Link to comment
Share on other sites

51 minutes ago, R0ger said:

There will be convertor. And I think I'm getting close. The biggest problem is high amount of options and parameters every step has, and which have to be fiddled with for best results. But I'm settling down, abandoning some experimental features which didn't work, finding universal sets of parameters and so on, so it's getting simpler. At the moment it's nowhere near being usable by normal people, but that won't be that hard. Not promising anything, of course.

 

Believe me, I'm use to TONS of fiddling for best result on Rastaconverter and won't mind that too for this, but of course the less fiddling for quality results the better. I wish Rasta was still being upgraded too, but I've learned to live with what it can do, and have learned to make the most of it to come up with good images. With Rastaconverter, I've found that even though I don't understand the programming and algorithms behind it, that I have learned, sort of, how the algorithm reacts and how to adjust setting per image to get the most out of it, and maybe better results than the original programmer (Philsan? Or who? I forget atm) ever thought possible themselves, sort of like how though Jay Miner designed the 8-bit, modern programmers like yourself have learned to use what he designed and take Atari 8-bit graphics far beyond what he probably would have ever imagined. With Rasta, I feel I am continuing to learn to make it create images better than first thought could be done by manipulating it's settings, just like today's programmers, like yourself, have learned to manipulate the Atari's graphic modes and other hardware to make it do so much more than ever imagined back in the day. And just like you brilliant programmer keep stretching the graphic possibilities, I continue to learn and stretch Rastaconverter's abilities in conversions.

 

But Rastaconverter and now what you are doing, continues to prove, to me, how amazing Atari 8-bits are, and regardless of what other say, and regardless of other computer's better sprite capabilities, that the Atari still stands head and shoulders above any other 8-bit computer for graphics. More sprites in games, to me, doesn't compare even remotely to the Atari's possibilities for graphic art. And as always, am so glad I have had an Atari 8-bit instead of a C64 since the beginning (because I am an artist), and with stuff like this, I think it's even superior to the 16-bit Amiga and ST's (Spectrum 512) for artwork in some ways! As I've said in this thread, all those Atari graphic modes and the way you can mix them make it a superior machine graphically, than any other 8-bit and C64 and other 8-bit users can keep flouting their better sprites all they want, I don't give a damn and as Kirk said to Kahn, "I'm laughing at your superior intellect." Well, I'm laughing at your superior sprites C64! Just try and do real graphic images like the Atari! Of course it does depend on what you prefer to do with a computer, ok, so C64 can do better sprite-based games, and better sound quality per voice. Atari can do better graphic art, better 3D games like Lucasfilm or Stuntcar racer. So pick your medicine, or poison...I much prefer Atari's, but do like C64 too.

 

Again though, just because I believe the Atari to be superior to the C64, overall, I still like the C64 and would still be proud to have both side-by-side and enjoy both computers for what they can do. And believe them both to be the number 1 and 2 best 8-bits ever made and put the rest to shame. Why more C64 fans (i know there are some here that prefer the C64 but still like the Atari too, and that's fine) can't feel the same, even if they think the C64 is number 1, also think the Atari is number 2 and not constantly attempt to tear it down and say they are unimpressed with it. I'm impressed with the C64's sprites, and it's better sound chip in the SID (even if I personally prefer Pokey because it's what I am used to, and like the extra layer of the fourth voice over the extra Octaves, and what can be done by combining Atari voices) and am willing to give it props for what it does better. I have no problem saying the C64 is a fantastic machine, but I prefer the Atari. Why can't they say the reverse instead of just constantly bringing up less octaves and sound waves, and less sprites but ignore all the Atari does better?

 

After all these years, Atari's continue to be able to surprise and push the envelope in new ways. On so many fronts. 

Edited by Gunstar
Link to comment
Share on other sites

30 minutes ago, VladR said:

That is absolutely insane that you can get away with WSYNC butchering the CPU yet still get this kind of quality ! WTF ?!?

Well if you do several changes on every line, WSYNC and kernel is better than DLI. That's less predictable and takes a lot of time too.

Quote

I would never in a million years believe this quality could be possible without precise cycle counting and without WSYNC. So, each scanline's kernel is just few simple LDA/STAs for color registers ended with STA WSYNC then ?!?

It's more like .. fill all 3 registers with values. Do WSYNC. Write registers to hardware, and move whatever more you need.

Quote

Which means, that this can still be pushed further :)

 

How exactly are badlines affecting this ? Doesn't WSYNC help with that or am I missing something about the nature of badlines ?

On normal lines Antic eats cycle for every byte of image (and PNG and DLIST and memory refresh). That corresponds to every second CPU cycle.

On badline Antic eats 2 cycles for every character. It reads what character there is on the screen, and also first microline of character set. So it eats EVERY CPU cycle, when it's displaying characters. You have time just during HBLANK. It might not seem big difference, as I have to do all changes outside the picture anyway .. but I can load the registers for the next line. That's 6 cycles. I can't do that on badline. And as I said, I don't do WSYNC on badline. I don't have time for that.

Also in character mode I have to change not only 4 color registers, but also charset (every 3 lines, I do it on every line anyway). That's on the line before badline though. I don't use WSYNC on chset lines either, there is 16 cycle reserve on these lines (even more on normal lines, WSYNC is perfectly fine). On badlines there is no reserve.

Also it's all LDA #, the colors are constants in the kernel code. Reading it from memory wouldn't be possible either.

I suggest debugging it in Altirra. Turn on max overscan, so you can see where the beam is when the changes are being made. I think it's not 100% utilized in this version. I think I had one more hardware change in there at some point. Not sure. It is pretty close to 100% though.

 

I was thinking about where it could be pushed further. First the palette could be changed for every line. That wouldn't even cost any CPU, as the numbers are part of the kernel already. Bud besides that ? Not sure.

 

Edited by R0ger
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

7 minutes ago, R0ger said:

Well if you do several changes on every line, WSYNC and kernel is better than DLI. That's less predictable and takes a lot of time too.

It's more like .. fill all 3 registers with values. Do WSYNC. Write registers to hardware, and move whatever more you need.

True - there's no interrupt servicing, no registers push/pop and this way you should be able to reuse registers from previous scanline, as there's no CPU main code running anyway (the kernel itself is the main CPU code).

So, in the kernel coding, did you find the timing more predictable than with DLIs ? That's great to hear !

On normal lines Antic eats cycle for every byte of image (and PNG and DLIST and memory refresh). That corresponds to every second CPU cycle.

On badline Antic eats 2 cycles for every character. It reads what character there is on the screen, and also first microline of character set. So it eats EVERY CPU cycle, when it's displaying characters. You have time just during HBLANK. It might not seem big difference, as I have to do all changes outside the picture anyway .. but I can load the registers for the next line. That's 6 cycles. I can't do that on badline. And as I said, I don't do WSYNC on badline. I don't have time for that.

Also in character mode I have to change not only 4 color registers, but also charset (every 3 lines, I do it on every line anyway). That's on the line before badline though. I don't use WSYNC on chset lines either, there is 16 cycle reserve on these lines (even more on normal lines, WSYNC is perfectly fine). On badlines there is no reserve.

Also it's all LDA #, the colors are constants in the kernel code. Reading it from memory wouldn't be possible either.

I suggest debugging it in Altirra. Turn on max overscan, so you can see where the beam is when the changes are being made. I think it's not 100% utilized in this version. I think I had one more hardware change in there at some point. Not sure. It is pretty close to 100% though.

 

Thanks ! I totally forgot how bad the character processing is in Antic in terms of CPU consumption.

I was thinking about where it could be pushed further. First the palette could be changed for every line. That wouldn't even cost any CPU, as the numbers are part of the kernel already. Bud besides that ? Not sure.

WSYNC. It still pulls down the RDY line of 6502, halting it every scanline for some cycles. Those cycles could be used for additional color/PMG register changes. Now, unlike DLI, in theory, there should be less cycles butchered in the kernel than DLI. But perhaps without WSYNC you could 2 more color registers on average every 3-4 scanlines ? That would add up to additional colors (and, of course, complications in image processing :) )
 

But, more likely, when you iterate over hundreds of images, you will notice certain color patterns - certain combinations of hues and colors look better than others. So, basically, just more experience with the process.

 

 

Can you share how many register changes can you do in a kernel (compared to classic DLI) per scanline ?  I presume 5-7 should be possible without the DLI overhead ?

Link to comment
Share on other sites

I think on badline I can do 5 changes, that is 30 cycles. 5 times LDA #constant, STA address.

On normal line I do 1 more. Not sure how much more is possible. In many cases you don't have to do all the changes before the image starts. But in this mode I have to. I have about 20 cycles reserve on normal lines, but that has to cover the time when Antic is reading bytes, which is also 20 cycles. So take this as rough figures. You have to fine tune it anyway.

Also you have to stabilize the kernel on the beginning. It's started with DLI in my case, but it could be done by simply waiting too. In both cases there will be some range of cycle offset between frames. So you have to do WSYNC on first line, or even 2. I think in some cases WSYNC can return 1 cycle off. But after that, with no IRQ, the CPU to ANTIC is 100% stable and repeatable. Which helps immensely. Often in DLI or kernel you manage 1 change less just because the jitters.

If you look at these images in Altirra, you disable artifacting and frame blending, and enable full overscan, you will see small jitter on the upper left corner. Thats the 1 cycle difference after first WSYNC. But after that you can see the changes in COLBK from black to blue .. and it's rock solid. You can also see how the timing is just so slightly different around badline.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

How would you stabilize the kernel without DLI on the very first line via waiting ? Waiting after what exactly ? vblank ? Would that be remotely precise ?

We need a starting Antic's reference point. DLI on first blank line seems easiest and safest, no ?

 

Thinking about it, kernel now seems easier (and more useable) to me than a DLI (for non-game purposes, that is). You get at least 6 register changes per scanline and I'm pretty sure that with careful positioning of scene elements, you could get away with WSYNC completely by avoiding the adjusted colors in the jitter area (hence no visible external jitter). But, the image must have vertical zones, unfortunately.

 

Let's do some break-down. 1 Horizontal scanline is worth 114 cycles.

40c goes towards Antic reading the FrameBuffer data (say, for a 160x192 mode)

9c goes towards Refresh (if I recall correctly)

1c is lost

Anything I forgot ? Can't seem to find that detailed Antic's cycle breakdown on my computer right now...

 

That's about 50c per scanline, so theoretically - within a kernel - in a noncharacter mode - one should have ~64 (114-50) cycles, right ? That's 10 pairs of LDA/STA without WSYNC.

 

Of course, this presumes you don't do any of that manually, but have the converter do all the heavy lifting, automatically. Doing that manually would be sheer lunacy :)

 

Link to comment
Share on other sites

By manual waiting I mean actively waiting for some specific VCOUNT value. Typically you have CMP adrres, BNE, which should be 8 cycles loop. DLI can only be triggered on instruction end, so that's possible 7 cycles. So the precision you get is similar. You have to use WSYNC anyway.

 

As for available time, yes. Lets talk bitmap mode. That's 40 cycles for the field. 9 for refresh. 1 for DLIST, and 5 for PMG IIRC.

But that doesnt mean you have 60 cycles to do whatever you want. For 40 of those remaining cycles you are already displaying the data. You can't store colors, or charset (well unless you want to make change in the middle of the line). You can load values into registers though, and write them just as the line finishes. Also most of the values has to be written like 2 cycles ahead, before they are being used. I don't analyze it much beforehand. I just try something simple and then I'm adding changes, till it breaks. Then I know what I can do, and I can fine tune things like order, if I can reuse some value, and so on. Altirra with max overscan turned on is great for this, as debugging the process is well .. not simple .. but doable. You can see the image as it's being generated, you see the position of the beam, and in history window you see cycle number on the current scanline. And then there's Altirra hardware reference, which describes the timing in great detail. Basically without Phareon, nothing of this would be possible ? Good luck fine tuning kernels on real hardware.

 

 

 

  • Like 2
Link to comment
Share on other sites

12 minutes ago, tane said:

Looks very well.

It reminds me the progress of the wolf3d project. Wolfenstein 3D attached.

Wolfenstein 3D (NTSC).xex 60.49 kB · 1 download Wolfenstein 3D (PAL).xex 60.46 kB · 1 download

Yes, this trick using GTIA modes is well known, and used even back in the day. Doing the same in 4 color mode, that's the difference. I'm not even saying it's new, it was done before. My contribution I think is experimenting with 6 color modes (charmode+PMG) and flickering, and focus on true color source images, ie. photos.

Link to comment
Share on other sites

43 minutes ago, R0ger said:

By manual waiting I mean actively waiting for some specific VCOUNT value. Typically you have CMP adrres, BNE, which should be 8 cycles loop. DLI can only be triggered on instruction end, so that's possible 7 cycles. So the precision you get is similar. You have to use WSYNC anyway.

 

As for available time, yes. Lets talk bitmap mode. That's 40 cycles for the field. 9 for refresh. 1 for DLIST, and 5 for PMG IIRC.

But that doesnt mean you have 60 cycles to do whatever you want. For 40 of those remaining cycles you are already displaying the data. You can't store colors, or charset (well unless you want to make change in the middle of the line). You can load values into registers though, and write them just as the line finishes. Also most of the values has to be written like 2 cycles ahead, before they are being used. I don't analyze it much beforehand. I just try something simple and then I'm adding changes, till it breaks. Then I know what I can do, and I can fine tune things like order, if I can reuse some value, and so on. Altirra with max overscan turned on is great for this, as debugging the process is well .. not simple .. but doable. You can see the image as it's being generated, you see the position of the beam, and in history window you see cycle number on the current scanline. And then there's Altirra hardware reference, which describes the timing in great detail. Basically without Phareon, nothing of this would be possible ? Good luck fine tuning kernels on real hardware.

 

 

 

Wait, why would you need the current scanline and CMP/BNE ?

Isn't the whole purpose of kernel to have a code for each and every scanline of the screen?

Meaning for 160x192 bitmap mode you have 192 batches of 5-6 LDA/Sta (and wsync).

 

Is there perhaps some reason this approach doesn't work in practice? 

 

As for the 60 cycles - yeah I forgot about PMG. That's at least 5 or more cycles lost.

 

But I thought you are racing the beam here, hence majority of register changes are for current scanline. I presume your tool on PC has some safety threshold range for each change that you painstakingly discovered while debugging on Altirra - e.g. those 2 color clocks.

 

Otherwise, there wouldn't be time to do the 5-6 changes while the beam jumps from end of current scanline to the start of the next one.

 

As for the kernel debugging on Atari, I once tried it - as an attempt to improve the DLIs - about 3 decades ago and after half day of fighting had only 8 scanlines to show for it. Then I realized my sanity is more important :)

 

 

Link to comment
Share on other sites

32 minutes ago, VladR said:

Wait, why would you need the current scanline and CMP/BNE ?

Isn't the whole purpose of kernel to have a code for each and every scanline of the screen?

 

 

I was talking about how to start the kernel. I use DLI, this active waiting is the other option. It's just important to rememeber, that even DLI won't fire EXACTLY. It will wait for the current instruction to finish.

In the beginning of this project I made a mistake. I had simple main thread .. just one jump loop. I fine tuned the kernel, and then I added RMT to the main loop. And whole kernel just started to dance ! In my test case I could only get 0..2 cycle delay, but with real code running in the main thread, it could be 0..5 (7 cycle instructions are rare). That's what lead me to better kernel syncing and it allowed me more control in the end. Moral of the story is, if you tune kernel, DLI or even IRQ, make sure the main thread uses all possible instruction sizes.

 

Edited by R0ger
Link to comment
Share on other sites

I was noticing, while checking out these images on my real hardware, that the darkest "black" areas of the images really look to be a very dark red color, then I took a closer look at the screen shots here and it looks that way too. Why is that? If it's possible to explain to a non-programmer like me (well just starting to learn, but really barely know anything yet). It isn't a big deal at all, really, just wondering.

 

I was also noticing that there is very slight visible flickering in darker areas and overall the brighter pictures flickering is far less noticeable or not noticeable at all if it's there in some areas, even on my LCD screen . But in any case there is slight flickering.

 

Though, this could also be a side-effect of my feeding it through an S-video to VGA converter/upscaler. I have to set my converter to have the 3D Y/C comb filtering/motion adaptive de-interlacing off or there's a lot of flickering and artifacting. Whereas with Rastaconverter things are drastically improved with it on (over normal S-video) So maybe what I'm seeing is just an effect of it going through the converter anyway.

 

Link to comment
Share on other sites

The red is simple. I can't really do black. On the hue lines, there is always one color from red, green, blue or yellow. So whatever the original image was closer to, that's what you get. It's one of the areas I improved recently, for flickering images. I can flicker blue and yellow, which will average as gray. I construct 10 hues out of those 4 base ones, instead of just 8, which you can see in these images.

The same reason also introduces some chroma noise in composite signal, making dark areas brighter. It's good idea to adjust TV brightness / contrast so the darkest colors in the picture are dark enough. Also these pictures are on average 50% darker than full image. So that can be adjusted for too. And boosting color saturation won't hurt either :-D Some TVs will do all these adjustments automatically to some extent.

 

As for the noise, yeah, it can be pretty much everything, in analog world ..

These images mostly rely on PAL blending. And most TVs only do inter-line blend on HF and composite inputs. It's typically not applied on S-video.  But not always ! Some TVs will apply it even on S-video. Same with VGA or HDMI convertors. You simply have to try it.

 

  • Like 1
Link to comment
Share on other sites

Awesome work R0ger !

Great idea with pm and 5th color added lumas !

 

@VladR Here is cpu dma info for you:

Antic_Timings.txt

 

Kernels can be made 100% stable and predictable. Yes it takes couple of scanlines to stabilize wsync, but after that with known PM positions and hscrol values you can be sure in each cycle execution.

 

  • Like 3
Link to comment
Share on other sites

A bunch of posts read that caused some  de ja vu ;)   Interlace, flicker ? In some cases it could impress ...

 

Sigh....

 

One of THE  features to have stable graphics manipulations on the Atari is  WSYNC .

 

How about some special super duper hires color mode that allows 100 sprites at 30x60 pixel.

Well, I know, it's not possible....

 

Back in the days I planned to do a graphics mode in ANTIC D with software colors. It would result in NO scanlines ( yeah ) and allowed to have a lot manipulation due to the low Cycle Stealing. But then the Atari had to wait more than 12 Years on the Attic and all graphics tools had been lost.     

Link to comment
Share on other sites

1 hour ago, R0ger said:

The red is simple. I can't really do black. On the hue lines, there is always one color from red, green, blue or yellow. So whatever the original image was closer to, that's what you get. It's one of the areas I improved recently, for flickering images. I can flicker blue and yellow, which will average as gray. I construct 10 hues out of those 4 base ones, instead of just 8, which you can see in these images.

The same reason also introduces some chroma noise in composite signal, making dark areas brighter. It's good idea to adjust TV brightness / contrast so the darkest colors in the picture are dark enough. Also these pictures are on average 50% darker than full image. So that can be adjusted for too. And boosting color saturation won't hurt either :-D Some TVs will do all these adjustments automatically to some extent.

 

As for the noise, yeah, it can be pretty much everything, in analog world ..

These images mostly rely on PAL blending. And most TVs only do inter-line blend on HF and composite inputs. It's typically not applied on S-video.  But not always ! Some TVs will apply it even on S-video. Same with VGA or HDMI convertors. You simply have to try it.

 

Yeah, I set the bright and contrast for optimum on them. Thanks for the answers. As to half-bright, yes that is something I understand as a graphic artist and also an electronics guy, when you have images with interlaced/mixed light and dark horizontal lines, and just like 240p images on a CRT screen are half as bright as 480p because scan-lines are skipped and left black and also half the color saturation for the same reason. That's one of the advantages of LCD. for both lack of scan-lines (but in this case you are purposely re-introducing lines similar to scan lines in that sense) and also richer color for 240p, etc. images since you don't have just half the screen showing color on horizontal lines. But my S-video 2.1 upgrade with the chroma boost on my 1200XL also makes all Atari graphics have MUCH better saturation than Atari's without the chroma boost like my 800. But all my color saturation has to come from my Atari, since once I convert it to VGA there is no color saturation adjust on my LCD TV's for VGA, it grays those options out in the menus. But my saturation is already superb without color bleeding like you get when you increase saturation too much with analog video signals on either LCD or especially CRT screens.

Edited by Gunstar
Link to comment
Share on other sites

47 minutes ago, emkay said:

A bunch of posts read that caused some  de ja vu ;)   Interlace, flicker ? In some cases it could impress ...

 

Sigh....

 

One of THE  features to have stable graphics manipulations on the Atari is  WSYNC .

 

How about some special super duper hires color mode that allows 100 sprites at 30x60 pixel.

Well, I know, it's not possible....

 

Back in the days I planned to do a graphics mode in ANTIC D with software colors. It would result in NO scanlines ( yeah ) and allowed to have a lot manipulation due to the low Cycle Stealing. But then the Atari had to wait more than 12 Years on the Attic and all graphics tools had been lost.     

The flickering on these images is not nearly as bad as the old GTIA flicker you got with interlacing modes, not NEARLY, it's very minor in comparison, and would probably be even less with NTSC. Except you need PAL for the color blending here.

Edited by Gunstar
  • Like 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...