Jump to content
IGNORED

320 mode colours question


karri

Recommended Posts

4 hours ago, saxmeister said:

I've really found this to be true. I straddle both worlds and I have been struggling with using GIMP to make 320C graphics.

 

I do recall there are plug-ins for GIMP might make that easier. I know for sure using indexed colors instead of RGB might color editing a lot easier.

  • Like 1
Link to comment
Share on other sites

I've been experimenting and trying to get graphics in the different modes working. So far, 160A and 320A are the easy ones. 160B and 320B are slightly more difficult. And 320C and 320D are the most difficult.

 

Using the suggested SMB3 graphics (I won't post ROMs here since that draws attention) I tried to layout the graphics in the different approaches on the 7800.

 

160A - 1:1 graphics copy (squished)

smb3_160A.thumb.png.d4ea5aacc1f8b58cb64b0f21e775a32c.png

160A - Double-height graphics

smb3_160A_tall.thumb.png.a142afc7334fa88858ca6687255dbba2.png

320B - High Res - 6 color

smb3_320B.thumb.png.7095a04ae6e7561cdbc32aa9b8da0a41.png

320C - High Res - 8 color

smb3_320C.thumb.png.14fcbbc27c0b15989b45b521110da575.png

320D - High Res - 6 color

smb3_320D.thumb.png.2c2491d1299538c8ee797edde1ab7ad2.png

As you can see, I haven't quite worked out how to make this work 100%. I have tried swapping palettes and color positions out, reworking graphics, importing different ways. etc.

  • 320B was supposed to work without pixel position limitations, but I could only get it to work with palette #0 and not palette #4
  • 320C - I need to rework the graphics to use the correct pairs and positions
  • 320D - I'm totally lost here. Does each image have a 4-color palette or an 8-color palette?

(Sorry for the colors - JS7800 has a very different color palette to a7800 in warm mode)

  • Like 2
Link to comment
Share on other sites

23 hours ago, saxmeister said:

(Sorry for the colors - JS7800 has a very different color palette to a7800 in warm mode)

:ponder:

image.thumb.png.8fe0f19db009b1011e99e7860c05aaba.pngimage.thumb.png.5370e85a63194d069777a375a0369679.png

 

Is the same region (PAL or NTSC) being selected for both emulators?

 

The main difference is JS7800 default has a brighter and more saturated palette than A7800 at default.

Link to comment
Share on other sites

On 8/7/2023 at 5:24 PM, KrunchyTC said:

That is very interesting to see on the 7800. I'm very curious how SMB3 would work here.

Very well!! It would have been great and probably wouldn't have needed an additional memory mapper chip to make it work. 😁

 

23 hours ago, Trebor said:

Is the same region (PAL or NTSC) being selected for both emulators?

I was using NTSC on a7800, so it should have been the same on JS7800. Yes, JS7800 does seem more saturated. No worries. I love JS7800!!!!!

Link to comment
Share on other sites

12 minutes ago, saxmeister said:

Very well!! It would have been great and probably wouldn't have needed an additional memory mapper chip to make it work. 😁

 

I was using NTSC on a7800, so it should have been the same on JS7800. Yes, JS7800 does seem more saturated. No worries. I love JS7800!!!!!

320C would be the closest to SMB3, but it looks awful in that shot. Don't know if I understand the limitations correctly. But in 320C mode, if you place a pixel/color somewhere, you have to place another right beside it that is either the same color, or one of the background colors? That sounds very tricky to pull off, and make look good.

Link to comment
Share on other sites

I started doing this a while ago, just out of curiosity and as an exercise. I converted some sprites and tiles to 320C mode in order to compose a full screen with 7800 real graphics. This is meant to be just a graphic example and show that good results can be achieved by using the background color as an additional color. As you can see from the images, the NES graphics will appear horizontally stretched due to the lower resolution and different pixel aspect ratio compared to the 7800. For the black side borders in the 7800 version you can use 320A for the playingfield and 320D for the score zone (both 1bpp mode).

 

Please do not use this graphic in a Demo, for obvious reasons. Thanks.

 

 

Atari7800-SMB3sprites.thumb.PNG.f989d56fbd040eabf6db3c866a982287.PNG

 

 

Atari7800-SMB3spritesb.thumb.PNG.9b11a2be5cc9871bcd9692438d6c89c5.PNG

 

 

Atari7800-SMB3spritesc.thumb.PNG.0c18cdbd6f73baf9e15931823da630f6.PNG

 

 

 

Atari7800-SMB3graphics_zoomed_.thumb.PNG.9fa583e83934061b37f6ef5dd2ee8eca.PNG

** For the black side borders in the 7800 version you can use 320A for the playingfield and 320D for the score zone (both 1bpp mode).

 

NESSMB3graphics_zoomed_.thumb.PNG.cf577da250531337cc195f59cf446094.PNG

 

  • Like 5
Link to comment
Share on other sites

5 hours ago, KrunchyTC said:

Such an odd restriction lol

You cant use the colors from those blocks in the back?

 

If you mean to overlap two sprites, this doesn't work because a single background color pixel will not be transparent, to achieve transparency you need to have two adjacent background color pixels in the same pair. However, this is a positive feature because the background color can be used voluntarily as an additional color while the transparency would create some defects to the graphics when the sprites overlap other sprites or tiles (and you wouldn't have the cycles needed to overlap all the sprites). Anyway, considering the high resolution, I like the result although 320C mode works best with games that have a black background such as classic arcade games.

 

Having said that, I just heard a great news from Eagle, with MariaECI it will be possible to enable transparency even with individual pixels and we have plenty of cycles to overlay the graphics, so the limitations of pixel placement will not affect the final result. Furthermore, it will be possible to use 320 resolution for the entire playing field without worrying about counting every single cycle and having super-optimized code.

 

I am attaching just one example, for convenience I am using the same pixel aspect ratio for both systems in order to better understand the advantage of high resolution with 320C mode.

 

 

MariaECi.thumb.PNG.84a3f5b8fc7fe55b17cd0dbcb934cb6f.PNG

 

 

NESvs7800..thumb.PNG.457f7d260695dd4fa4c1fbff26ca7b36.PNG

 

 

NESvs7800.PNG.8248b0d91f859334fdde7a644e5f72fd.PNG

  • Like 4
Link to comment
Share on other sites

@Defender_2600, these examples are great. Thank you! And I had not fully understood the power of MariaECI. It still amazes me that super-talented homebrew developers can not only fix the bugs of the original designs, but also create a more powerful version that expands the power of the system. Completely blown away!

 

@Eagle, my mind is blown!

mind-blown-meme-vobss-9.jpg.88702f577404624e167cf11cc724b7e8.jpg

 

  • Like 1
Link to comment
Share on other sites

On 8/11/2023 at 3:25 AM, Defender_2600 said:

I started doing this a while ago, just out of curiosity and as an exercise. I converted some sprites and tiles to 320C mode in order to compose a full screen with 7800 real graphics. This is meant to be just a graphic example and show that good results can be achieved by using the background color as an additional color. As you can see from the images, the NES graphics will appear horizontally stretched due to the lower resolution and different pixel aspect ratio compared to the 7800. For the black side borders in the 7800 version you can use 320A for the playingfield and 320D for the score zone (both 1bpp mode).

 

Please do not use this graphic in a Demo, for obvious reasons. Thanks.

 

If you're worried about certain company, may I suggest using games that were on the NES but weren't not trademarked by that company. Like Gradius/Nemesis, Castlevania, or Mega Man.

 

I'm impressed about your insights with 7800 graphics. I designed the character graphics for b*nq. While people did like the designs, I always felt more could've been done with it. Now I see evidence that more could have been done.

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

  • 4 weeks later...
1 hour ago, Muddyfunster said:

I decided a long time ago that 320 modes are a bit like my wife shopping....best left alone and nothing good will come from me getting involved.

The pain of picking a mode, drawing loads of graphics in it but deciding to try other modes 'just in case' only to circle back to what you already had after hours of wasted effort...

...yeah I don't know what you're trying to say 🤐

  • Haha 2
Link to comment
Share on other sites

4 hours ago, EricBall said:

In those docs, it mentions the shared bus being the 7800's biggest weakness, which is well known. But how much can that weakness be overcome through optimization?

Link to comment
Share on other sites

What I don't understand about using 320A and 320C modes is that it seems that the only way to avoid artifacting is by treating the 320 modes like 160 modes. It seems like if I understand correctly, having a pixel pair where one pixel is a foreground color and the other is background, then there will be artifacting. 

Link to comment
Share on other sites

2 hours ago, KrunchyTC said:

In those docs, it mentions the shared bus being the 7800's biggest weakness, which is well known. But how much can that weakness be overcome through optimization?

We see overcoming, or at least working around of, weakness with mappers such as Souper and Bankset, tools such has 7800basic and cc7800, along with a slew of additional items.  The 7800 did not have the resources allocated to it, back in the day, as its contemporaries were provided.  For both software and hardware aspects of the system, relatively recent developments have really helped level the playing field more evenly; though each platform will still have their respective native strengths and weaknesses regardless.

  • Like 3
Link to comment
Share on other sites

21 minutes ago, Trebor said:

We see overcoming, or at least working around of, weakness with mappers such as Souper and Bankset, tools such has 7800basic and cc7800, along with a slew of additional items.  The 7800 did not have the resources allocated to it, back in the day, as its contemporaries were provided.  For both software and hardware aspects of the system, relatively recent developments have really helped level the playing field more evenly; though each platform will still have their respective native strengths and weaknesses regardless.

Ah, that makes sense. It's too bad the 7800 didn't have the resources it needed back in the day, which may have made it more attractive to 3rd parties. which probably explains why games looked, and performed the way they did.

  • Like 1
Link to comment
Share on other sites

4 hours ago, Karl G said:

What I don't understand about using 320A and 320C modes is that it seems that the only way to avoid artifacting is by treating the 320 modes like 160 modes. It seems like if I understand correctly, having a pixel pair where one pixel is a foreground color and the other is background, then there will be artifacting. 

Yes and no. Here's a diagonal line that avoids artifacting, while still using 320 resolution...

 

-##-----
--##----
---##---
----##--
-----##-

 

...it's also an option to just ignore it and tell people that your game may artifact with composite video. (s-video won't, nor will component from 7800gd, MiSTer FPGA hdmi, etc.) That one doesn't sit right with me personally, but tbh i think I'm the odd man out, and most homebrew authors don't really think too much about composite artifacting.

  • Like 3
Link to comment
Share on other sites

It's worth spelling out that the shared bus impacts the 7800 resources in two ways... The first impact is lost cycles for the 6502, and the second impact is the shared address space, which limits the amount of graphics you can arbitrarily display in any one zone.

 

As Trebor pointed out, Souper and Banksets remove the second impact entirely, since Maria gets a separate address space of graphics rom, independent from the 6502.

 

The first impact is less of a big deal once you get to working with the 7800. You pre-bake stuff into the DLs to allow minimal updates. You use frame buffering so you don't have to partition cpu time into visible and non-visible buckets. You schedule events when needed rather than running them every frame. You optimise, pre-compute, and get a little clever about how you do things.

 

The 7800 port of Petscii Robots has nearly the whole screen's worth of 6502 cycles lost to dma, but it runs about as fast as other Petscii Robot ports on systems without DMA penalties. Those other systems aren't holding things back - they're running flat out. We just had to optimise things a bit.

 

I'm sure I'm coming across as cranky, but I get tired about reading about how terrible the shared bus is - the nes pundits like to bring it up a lot whenever one of these stupid vs threads comes up. Its kind of like complaining about how hard it is to keep a motorcycle upright at slow speeds, and concluding that cars are therefore better. If you personally have trouble keeping the bike upright, then I guess its true for you. A whole lot of us are managing to stay upright just fine, and doing it in style. 🤷

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

13 minutes ago, RevEng said:

It's worth spelling out that the shared bus impacts the 7800 resources in two ways... The first impact is lost cycles for the 6502, and the second impact is the shared address space, which limits the amount of graphics you can arbitrarily display in any one zone.

 

As Trebor pointed out, Souper and Banksets remove the second impact entirely, since Maria gets a separate address space of graphics rom, independent from the 6502.

 

The first impact is less of a big deal once you get to working with the 7800. You pre-bake stuff into the DLs to allow minimal updates. You use frame buffering so you don't have to partition cpu time into visible and non-visible buckets. You schedule events when needed rather than running them every frame. You optimise, pre-compute, and get a little clever about how you do things.

 

The 7800 port of Petscii Robots has nearly the whole screen's worth of 6502 cycles to dma, but it runs about as fast as other Petscii Robot ports on systems without DMA penalties. Those other systems aren't holding things back - they're running flat out. We just had to optimise things a bit.

 

I'm sure I'm coming across as cranky, but I get tired about reading about how terrible the shared bus is - the nes pundits like to bring it up a lot whenever one of these stupid vs threads comes up. Its kind of like complaining about how hard it is to keep a motorcycle upright at slow speeds. It's an issue I guess, if you can't hack it. 🤷

Yeah, I get what you are saying. It does get brought up a lot. And I'm glad that it's not that big of an issue, as many programmers have said.

  • Like 1
Link to comment
Share on other sites

On 9/7/2023 at 4:29 AM, RevEng said:

..it's also an option to just ignore it and tell people that your game may artifact with composite video. (s-video won't, nor will component from 7800gd, MiSTer FPGA hdmi, etc.) That one doesn't sit right with me personally, but tbh i think I'm the odd man out, and most homebrew authors don't really think too much about composite artifacting.

 

Yes I know, one of those people is me :) and, in a superficial way, I am generally only referring to what will be seen on the screen without explaining how it is happening (and I would do it wrong).

 

A philosophical problem instead can be deciding how to draw the graphics in 320 mode, therefore considering or ignoring the artifacts. Personally I don't think it's a very different decision from other questions, such as choosing whether to stick with RF and CRT or modify the console with composite video and display it on LCD, and this also leads me towards old talks about the legitimacy of putting hardware in cartridges, etc.

 

And then, thinking about the future? When CRT and composite video are no longer available (and I don't want to think where we will be at that time), how should graphics be drawn in 320 mode? Can/should artifacts be ignored? It reminds me of what happens with some vintage motorcycles for which it is necessary to update the type of tires because the original ones are no longer in production. And, what if the Atari 7800 had S-Video at the time, like the latest models in the 8-bit line?

 

However luckily I see that many games in 320 mode don't look so bad when they show artifacts that weren't considered when designing the graphics. Anyway I apologize if I'm not considering artifacts when I show my graphic examples.:)

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...