Which 320 mode to use for a new game?

[Ecernosoft]

Hello!

I wanted to make a sequel to ICT using 320 modes but didn't know if I wanted to use 320C or 320B.

I was thinking 320C but it is kind of wonky. 

Then there's 320B but it only has 3 colors per palette.

And what about 320D and 320A? Artifacting? Should I use that?

I'm not the most experienced with 320 modes so I was wondering what you guys would use.

 

Thanks!

 

[+Muddyfunster]

I would figure out what I want my game to be. What are the mechanics of the game will be and so on, and then that will likely inform what graphics modes make the most sense to use. (You don't need to answer that here, that's just the thought process).

 

When I start a new project I spend a little time just doing a bit of planning. "How will this work?", "How will I represent that?". Some stuff I don't answer until I get around to doing it. Do I want colour or detail?

 

I then usually have an idea of what graphics modes I want to use for what parts. 

 

Use whatever makes the most sense for your game. It's your game after all. Experiment !  

[Synthpopalooza]

320D has no usefulness that I've found yet, apart from a failed interlace experiment I tried once ...

[Synthpopalooza]

As for the others:

 

160B has more colors per character than 160A, but it costs in DMA time.  Same with 320B vs 320A.  This means that relying on it too much will cause some things to not display properly by the time MARIA draws the screen.

 

As for the other two:  320D has the lower DMA cost, vs 320C ... but it's odd color layout hampers usefulness, unless I can get the above interlace experiment I tried, to work properly.  The idea:  Character set swap, coupled with a color register swap, interlacing the character colors across vertical lines.  In theory, it's supposed to produce the same as 320B but without the high DMA costs involved.  In practice, nothing has come out readable on it yet ...

[Ecernosoft]

3 minutes ago, Synthpopalooza said:

As for the others:

 

160B has more colors per character than 160A, but it costs in DMA time.  Same with 320B vs 320A.  This means that relying on it too much will cause some things to not display properly by the time MARIA draws the screen.

 

As for the other two:  320D has the lower DMA cost, vs 320C ... but it's odd color layout hampers usefulness, unless I can get the above interlace experiment I tried, to work properly.  The idea:  Character set swap, coupled with a color register swap, interlacing the character colors across vertical lines.  In theory, it's supposed to produce the same as 320B but without the high DMA costs involved.  In practice, nothing has come out readable on it yet ...

You could write a line kernal to change the Pallete in the 320D so you could alter the interlacing, just an idea.

[Ecernosoft]

I was going to go with 320B. I saw Somari on NES and thought i could make something like that.

[Synthpopalooza]

Still the same problem though ... the 320 vertical lines don't seem to interlace well because of high resolution artifacting ....

 

320B is useful but watch the DMA usage.  Use only one of the two palettes per character line for sure.  You may have to experiment several times and see how the display comes out.

[Ecernosoft]

3 minutes ago, Synthpopalooza said:

Still the same problem though ... the 320 vertical lines don't seem to interlace well because of high resolution artifacting ....

 

320B is useful but watch the DMA usage.  Use only one of the two palettes per character line for sure.  You may have to experiment several times and see how the display comes out.

What do you mean?

I was going to go with 320B because of the artifacting to "Fake more colors".

 

Edit: I think I'll use 320B unless there's a good reason to use 320C other than "You get 9 colors instead of 7".

Edited August 30, 2022 by Ecernosoft

[Synthpopalooza]

Well, there is a limit to the number of cycles per scanline that MARIA can do ... it basically takes more processor time for MARIA to display multicolor palettes and multiple palette changes.  When MARIA gets overstressed, you will see elements drop out of your display when it is generated.  I learned this through experimenting.  I know Rikki and Vikki used 320B extensively, for both the sprites and character platforms, although I think the cart had some extra hardware on it to deal with things. 

 

Just experiment with it and see what you get ... keeping in mind you may have to adjust the display if you get dropouts.  Going from 40 characters wide to 32 wide can mitigate some of this overhead, too.

[Ecernosoft]

54 minutes ago, Synthpopalooza said:

Well, there is a limit to the number of cycles per scanline that MARIA can do ... it basically takes more processor time for MARIA to display multicolor palettes and multiple palette changes.  When MARIA gets overstressed, you will see elements drop out of your display when it is generated.  I learned this through experimenting.  I know Rikki and Vikki used 320B extensively, for both the sprites and character platforms, although I think the cart had some extra hardware on it to deal with things. 

 

Just experiment with it and see what you get ... keeping in mind you may have to adjust the display if you get dropouts.  Going from 40 characters wide to 32 wide can mitigate some of this overhead, too.

Well yes, I knew about the 454 cycle limit on MARIA.

 

Wish the CPU was faster to combat the DMA stuff though...

[+x=usr(1536)]

2 hours ago, Ecernosoft said:

Artifacting? Should I use that?

Artifacting really only works on NTSC machines, and even then it needs a CRT to be effective.

 

Not saying you shouldn't use it, but be aware of the restrictions.  Also check out what games using NTSC artifacting looked like on PAL.  Having grown up in PAL territory and occasionally playing games that used NTSC artifacting, it wasn't pretty.

[Ecernosoft]

8 hours ago, x=usr(1536) said:

Artifacting really only works on NTSC machines, and even then it needs a CRT to be effective.

 

Not saying you shouldn't use it, but be aware of the restrictions.  Also check out what games using NTSC artifacting looked like on PAL.  Having grown up in PAL territory and occasionally playing games that used NTSC artifacting, it wasn't pretty.

It worked on my HDTV.

; But then again, you are right. I've seen PAL artifacting and it doesn't really work. The middle between NTSC and Monochrome.

Edited August 30, 2022 by Ecernosoft

[+x=usr(1536)]

4 hours ago, Ecernosoft said:

It worked on my HDTV.

Remember: there's 'it works' and then there's 'it works'.

 

What I mean by that is while your HDTV is displaying the graphics as intended, it's not artifacting them as a CRT would.  It can't: the differences in physical construction between an LCD and CRT display make that impossible.  So while the code is working as expected, the intended result isn't being achieved.

 

Even CRT display filters and simulations in emulators struggle with artifacting to some degree.

 

Because of this, it's strongly recommended that you try your test code out on a CRT; the difference should be very visible.

 

[Ecernosoft]

8 hours ago, x=usr(1536) said:

Remember: there's 'it works' and then there's 'it works'.

 

What I mean by that is while your HDTV is displaying the graphics as intended, it's not artifacting them as a CRT would.  It can't: the differences in physical construction between an LCD and CRT display make that impossible.  So while the code is working as expected, the intended result isn't being achieved.

 

Even CRT display filters and simulations in emulators struggle with artifacting to some degree.

 

Because of this, it's strongly recommended that you try your test code out on a CRT; the difference should be very visible.

 

Ok, so I have a question:

1. Do you have a NTSC 7800? (RF or Composite?)

2. Do you have a CRT? (Also NTSC of course!)

3. If 1 and 2 are "Yes", then I have some things I would like to see on a CRT.

[+x=usr(1536)]

33 minutes ago, Ecernosoft said:

Ok, so I have a question:

1. Do you have a NTSC 7800? (RF or Composite?)

2. Do you have a CRT? (Also NTSC of course!)

3. If 1 and 2 are "Yes", then I have some things I would like to see on a CRT.

Yes, I have an NTSC 7800 and matching CRT TV.  However, if you want to determine how effective your artifacting code is on a CRT, that's something best seen with your own eyes.

 

Cameras will not give a good approximation of what is being seen on the CRT - at least, not without access to professional equipment that is horrendously expensive and not always easy to come by.  Even then, you're only going to be looking at a picture that is affected by room lighting, the camera's electronics, the display that you're viewing it on, any image codec in use, and so on and so forth.

 

Because the results are so subjective and not accurately conveyed photographically, it's recommended that you obtain your own CRT for experimentation.  They can be found from free to cheap; just keep an eye out for ones at the kerb being tossed out, or local ads.  Thrift stores have generally stopped carrying them, so while it doesn't hurt to check them I wouldn't expect to find one there.

[Ecernosoft]

=

Just now, x=usr(1536) said:

Yes, I have an NTSC 7800 and matching CRT TV.  However, if you want to determine how effective your artifacting code is on a CRT, that's something best seen with your own eyes.

 

Cameras will not give a good approximation of what is being seen on the CRT - at least, not without access to professional equipment that is horrendously expensive and not always easy to come by.  Even then, you're only going to be looking at a picture that is affected by room lighting, the camera's electronics, the display that you're viewing it on, any image codec in use, and so on and so forth.

 

Because the results are so subjective and not accurately conveyed photographically, it's recommended that you obtain your own CRT for experimentation.  They can be found from free to cheap; just keep an eye out for ones at the kerb being tossed out, or local ads.  Thrift stores have generally stopped carrying them, so while it doesn't hurt to check them I wouldn't expect to find one there.

Your right... Then again, a picture is still a picture

 

Also, I'll probably never have a CRT

Edited August 30, 2022 by Ecernosoft

[Ecernosoft]

On 8/29/2022 at 7:51 PM, Synthpopalooza said:

As for the others:

 

160B has more colors per character than 160A, but it costs in DMA time.  Same with 320B vs 320A.  This means that relying on it too much will cause some things to not display properly by the time MARIA draws the screen.

 

As for the other two:  320D has the lower DMA cost, vs 320C ... but it's odd color layout hampers usefulness, unless I can get the above interlace experiment I tried, to work properly.  The idea:  Character set swap, coupled with a color register swap, interlacing the character colors across vertical lines.  In theory, it's supposed to produce the same as 320B but without the high DMA costs involved.  In practice, nothing has come out readable on it yet ...

@Synthpopalooza, I'd try making a line kernal, like on 2600. Then, have a DLI trigger an IRQ and change the colors every scanline! Or something like that.

[Synthpopalooza]

Using my method, you can alternate checkerboard pixels in the two frames to get the blending.  It works better than doing it by scanlines.

[Ecernosoft]

16 hours ago, Synthpopalooza said:

Using my method, you can alternate checkerboard pixels in the two frames to get the blending.  It works better than doing it by scanlines.

Hmmm... Nah, I'm not going to use 320 modes, it's just too limited. Sorry.

I've already made a test using 160D (Special 160A trickery) which allows for color cells. Works with 320A as well.

ALSO- if you use indirect mode, and set up a scanline kernal, it will work! (Change charbase and pallete info for indirect sprite)

Edited September 4, 2022 by Ecernosoft