320B color question

[Lillapojkenpåön]

Can I use a 320B sprite on a 160A background?

 

It compiles and has the correct size but I can't get the colors right

I'm guessing "pairs of pixels" means you can only change color every other horisontal pixel, so the colors are still 160A resolution and only the horisontal pixels increase with 320B?

I made a 16x16 sprite and colored it with 2-pixel wide columns of three random colors + 1 transparant column just to try it

but it shows up as black, blue, black, transparant

 

Does it not work, or am I doing it wrong?

 

How do I incgraphic with 320B

 

  incgraphic playerSprite.png 320B 0 1 2 3 1

  incgraphic playerSprite.png 320B 0 1 2 3  ;and only chose palette when plotting?

  incgraphic playerSprite.png 320B 4 5 6 7

[+Karl G]

No - the display needs to be in 320B mode to display 320B (oe 320D) sprites. Multiple graphics modes on the same screen can only be done in separate vertical regions.

[Lillapojkenpåön]

Time to start over then

[Lillapojkenpåön]

I don't get the "pairs of pixels using the same color" I'm looking at the tiles in Rikki & Vikki and it looks like they can color them however they want?

Can someone direct me to a 320B demo if one exist?

[+Muddyfunster]

Sorry, I don't have any experience that I can share with 320B, it's something I've not experimented with at all.

 

 

[Mord]

I suppose one way to describe it is that a 320 mode is basically a 160 mode as far as placing sprites are concerned, but each sprite has the fat pixels broken up into two halves with regards to their color. (ie: "pixel pair") 

 

In 320B in particular both halves of the pair have conditions for being displayed.  Specifically in order for the C1 palette entry to display, it must be paired with a C2 or C3 for the other half of the pair. If you try to have a pair C1's or a C1 + BG, both halves end up being the background color. C2 and C3 can be displayed freely.

 

Also, if you're playing with 320B, make sure you aren't testing in ProSystem. It doesn't understand the palette condition above and will display C1 freely like C2 and C3. Real hardware, A7800, and BupSystem (fairly certain about Bup but haven't tested personally) will display with the rule above.

 

 

 

Edited November 9, 2020 by Mord
Adding note about prosystem and testing.

[+Muddyfunster]

2 hours ago, Mord said:

I suppose one way to describe it is that a 320 mode is basically a 160 mode as far as placing sprites are concerned, but each sprite has the fat pixels broken up into two halves with regards to their color. (ie: "pixel pair") 

 

In 320B in particular both halves of the pair have conditions for being displayed.  Specifically in order for the C1 palette entry to display, it must be paired with a C2 or C3 for the other half of the pair. If you try to have a pair C1's or a C1 + BG, both halves end up being the background color. C2 and C3 can be displayed freely.

 

Also, if you're playing with 320B, make sure you aren't testing in ProSystem. It doesn't understand the palette condition above and will display C1 freely like C2 and C3. Real hardware, A7800, and BupSystem (fairly certain about Bup but haven't tested personally) will display with the rule above.

 

 

 

Does JS7800 interpret 320B correctly ? (I know a few folks use that a lot).

[Lillapojkenpåön]

2 hours ago, Mord said:

I suppose one way to describe it is that a 320 mode is basically a 160 mode as far as placing sprites are concerned, but each sprite has the fat pixels broken up into two halves with regards to their color. (ie: "pixel pair") 

 

In 320B in particular both halves of the pair have conditions for being displayed.  Specifically in order for the C1 palette entry to display, it must be paired with a C2 or C3 for the other half of the pair. If you try to have a pair C1's or a C1 + BG, both halves end up being the background color. C2 and C3 can be displayed freely.

 

Also, if you're playing with 320B, make sure you aren't testing in ProSystem. It doesn't understand the palette condition above and will display C1 freely like C2 and C3. Real hardware, A7800, and BupSystem (fairly certain about Bup but haven't tested personally) will display with the rule above.

 

 

 

Thanks now I get it! That's alot less restricted than I thought

I also read you only have 7 colors

so is that palette 0 and 1 + transparant?

 

[+SmittyB]

6 minutes ago, Lillapojkenpåön said:

I also read you only have 7 colors

so is that palette 0 and 1 + transparant?

You get palettes 0 and 4 plus background/transparency (taking into account the quirks with transparency in 320 modes).

 

[Lillapojkenpåön]

34 minutes ago, SmittyB said:

You get palettes 0 and 4 plus background/transparency (taking into account the quirks with transparency in 320 modes).

 

Thanks!

 

Is there some limits with tile width? I made 16 pixel wide ones and nothing shows up, just a blcak screen

 

 

  set romsize 128kRAM   ;extra 16k of RAM from $4000-$7fff.

  set zoneheight 8

  set doublewide off

  set screenheight 192

  set tv ntsc

  set dlmemory $4000 $4fff 

  set basepath gfx



  displaymode 320B 



 bank 1



 P0C1 = $a2 

 P0C2 = $a6

 P0C3 = $aa



/*

 P1C1 = $52

 P1C2 = $56

 P1C3 = $5a



 P2C1 = $c2

 P2C2 = $c6

 P2C3 = $1a



 P3C1 = $0f

 P3C2 = $00

 P3C3 = $00

*/



 P4C1 = $a2 

 P4C2 = $a6

 P4C3 = $aa



 incgraphic newTiles16x8.png 320B 0 1 3 2 0 




  characterset newTiles16x8

  incmapfile tiledMap16x8.tmx





  clearscreen

  plotmapfile tiledMap16x8.tmx tiledMap16x8 0 0 20 24

  savescreen



mainLoop



  ;logic here



  restorescreen 

  

  ;plot here

  

  drawscreen



 goto mainLoop thisbank



 bank 2



 bank 3



 bank 4



 bank 5



 bank 6



 bank 7



 bank 8

 

[+Karl G]

As SmittyB mentioned, you get palettes 0 and 4. If I remember correctly, this means that patelles 0-3 are the same, and 4-7 are the same. So, you will get 4 colors for sprites without restrictions, plus 2 more with restrictions. So, I would see if you can display your tiles show up if you define and use just palettes 0 and 4.

[+SmittyB]

Most of the limits for what you can draw including the width of objects are based on the number of bytes and the number of pixels you get for a byte changes based on the graphics mode.

 

For 160A, 320B, and 320C a single byte will represent a 4 pixel wide slice of graphics with 2 pixels for 160B, and 8 pixels for 320A and 320D.

This means that each 'tile' will actually be only 4 pixels wide.

 

You can enable 'doublewide' which tells the system to read 2 consecutive bytes at once, but of course that still only gives you a tile width of 8 pixels and not 16. (Doublewide would result in a tile width of 16 with the wider pixels of 160A however).

 

 

I can't see anything specifically wrong with your code example, so try 'plotsprite newTiles16x8 0 0 0' to see if that draws anything. If it does there's probably something in the mapfile that needs adjusting.

[Lillapojkenpåön]

2 hours ago, SmittyB said:

Most of the limits for what you can draw including the width of objects are based on the number of bytes and the number of pixels you get for a byte changes based on the graphics mode.

 

For 160A, 320B, and 320C a single byte will represent a 4 pixel wide slice of graphics with 2 pixels for 160B, and 8 pixels for 320A and 320D.

This means that each 'tile' will actually be only 4 pixels wide.

Hmm, I used to use 160A with doublewide on, and made my tiled maps with 8x8 pixels, so I assumed the 4 pixel character width was something under the hood I didn't have to worry about, and if I made wider tiles they just got split up somewhere along the way and would still appear on screen correctly.

 

I was also a little confused about doublewide, since it didn't seem to change the pixel width when using 160A, only read 2 consecutive bytes at once, but maybe I'm wrong?

 

But it sounds like you're telling me that if I want the finer resolution my tiles can only be 4 pixels wide, not 16 like now, I will try it

 

2 hours ago, SmittyB said:

try 'plotsprite newTiles16x8 0 0 0' to see if that draws anything. If it does there's probably something in the mapfile that needs adjusting.

Thanks, atleast something on screen

 

[+SmittyB]

Here's something that might help you visualise doublewide.

The white parts represent each byte-wide chunk of graphics so for 320B that would be 4 pixels. If you wanted to draw the below 6-byte-wide image in a tile map you would need have 6 bytes to represent it. With doublewide (represented by the red) you would only need 3 bytes in your tilemap as for each value in your tile map it would also draw the next one along.

 

So to summarise rather than storing '0,1,2,3,4,5' you'd just store '0,2,4'.

 

 

[Lillapojkenpåön]

Thanks, that's kind of how I thought about it, but then you wrote this

3 hours ago, SmittyB said:

You can enable 'doublewide' which tells the system to read 2 consecutive bytes at once, but of course that still only gives you a tile width of 8 pixels and not 16. (Doublewide would result in a tile width of 16 with the wider pixels of 160A however).

Which indicates it also doubles the pixel width, I never noticed any pixel width change with 160A and having doublewide on or off, but maybe it's hard to notice, or only doubles it in 320 mode?

 

I got my playfield displaying, but it stops drawing tiles near the right of the screen, does tiles counts as objects? It doesnt improve when I add more dlmemory, should be able to display 136 objects per zone it says

 

320B.bin

 

I just drew two lines across the screen, as you can see they stop at the same place

 

[Lillapojkenpåön]

I'm using doublewide on now and 8x8 tiles, Doesn't seem to result in doublewide pixels like 160, I think it's just a confusing name

 

320B doublewide on.bin

 

 

Edited November 9, 2020 by Lillapojkenpåön

[+SmittyB]

Neither of those binaries seem to work for me on either BupSystem or ProSystem.

 

The width of the pixels doesn't change, that's down to whether you pick one of the 320 modes or the 160 modes. What changes is how many bytes of data are read per entry in your tile map.

 

The 7800 doesn't have tile maps in the sense that other consoles have, but objects can draw their graphics based on a tile map. No single object on the 7800 can be wide enough to cover the whole screen so it's normal to have multiple objects per zone displaying a single tile map. 

There are also several limits to how much can be drawn so even though you have enough memory to store 136 objects per zone, you won't have enough time to set up that many objects and MARIA won't have enough time to draw them all.

 

[Lillapojkenpåön]

14 minutes ago, SmittyB said:

Neither of those binaries seem to work for me on either BupSystem or ProSystem.

That sounds not good, what's the A78 file? maybe that's the one I'm suppose to share?

 

Thanks for all the valuable information, I appreciate it, I would have given up on myself a long time ago

Edited November 9, 2020 by Lillapojkenpåön

[+SmittyB]

.bin is the binary as it would be burnt to a ROM. .a78 is the same but has a short header at the start that includes some extra details that emulators use to configure a few things.

[+Pat Brady]

24 minutes ago, Lillapojkenpåön said:

I'm using doublewide on now and 8x8 tiles, Doesn't seem to result in doublewide pixels like 160, I think it's just a confusing name

 

MARIA's character width setting controls whether characters in indirect mode are 1 or 2 bytes wide. It does not do anything else. The number of pixels per byte varies among graphics modes, as SmittyB described in post #12.

 

The character width setting has no effect in direct mode.

 

I'm using the Software Guide terminology, so you may need to translate that into 7800basic jargon.

[Lillapojkenpåön]

what might be the problem if my sprite flickers and appear to be dissapearing behind some zones when moving up and down?

[+SmittyB]

I would expect that to be because too much is being drawn in those zones, but it's hard to say.

[Lillapojkenpåön]

14 minutes ago, SmittyB said:

I would expect that to be because too much is being drawn in those zones, but it's hard to say.

there's just my map and a sprite on the screen

 

weird.a78

 

the pacman mouth is also something weird, the sprite is just a solid square

Edited November 10, 2020 by Lillapojkenpåön

[+SmittyB]

I think it's definitely struggling to draw it.

If you're not using doublewide and a zone height of 8 that little block of tiles in the middle would actually be a lot of data for MARIA to try and process.

[Lillapojkenpåön]

11 minutes ago, SmittyB said:

If you're not using doublewide and a zone height of 8

I'm using doublewide and zoneheight 8, bummer, this mode seemed promising