Lillapojkenpåön Posted November 8, 2020 Share Posted November 8, 2020 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 Quote Link to comment Share on other sites More sharing options...
+Karl G Posted November 8, 2020 Share Posted November 8, 2020 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. Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted November 8, 2020 Author Share Posted November 8, 2020 Time to start over then Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted November 8, 2020 Author Share Posted November 8, 2020 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? Quote Link to comment Share on other sites More sharing options...
+Muddyfunster Posted November 9, 2020 Share Posted November 9, 2020 Sorry, I don't have any experience that I can share with 320B, it's something I've not experimented with at all. Quote Link to comment Share on other sites More sharing options...
Mord Posted November 9, 2020 Share Posted November 9, 2020 (edited) 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. Quote Link to comment Share on other sites More sharing options...
+Muddyfunster Posted November 9, 2020 Share Posted November 9, 2020 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). Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted November 9, 2020 Author Share Posted November 9, 2020 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? Quote Link to comment Share on other sites More sharing options...
+SmittyB Posted November 9, 2020 Share Posted November 9, 2020 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). Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted November 9, 2020 Author Share Posted November 9, 2020 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 Quote Link to comment Share on other sites More sharing options...
+Karl G Posted November 9, 2020 Share Posted November 9, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+SmittyB Posted November 9, 2020 Share Posted November 9, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted November 9, 2020 Author Share Posted November 9, 2020 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 Quote Link to comment Share on other sites More sharing options...
+SmittyB Posted November 9, 2020 Share Posted November 9, 2020 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'. 1 1 Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted November 9, 2020 Author Share Posted November 9, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted November 9, 2020 Author Share Posted November 9, 2020 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+SmittyB Posted November 9, 2020 Share Posted November 9, 2020 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. 1 1 Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted November 9, 2020 Author Share Posted November 9, 2020 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+SmittyB Posted November 9, 2020 Share Posted November 9, 2020 .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. 1 1 Quote Link to comment Share on other sites More sharing options...
+Pat Brady Posted November 9, 2020 Share Posted November 9, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted November 10, 2020 Author Share Posted November 10, 2020 what might be the problem if my sprite flickers and appear to be dissapearing behind some zones when moving up and down? Quote Link to comment Share on other sites More sharing options...
+SmittyB Posted November 10, 2020 Share Posted November 10, 2020 I would expect that to be because too much is being drawn in those zones, but it's hard to say. Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted November 10, 2020 Author Share Posted November 10, 2020 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+SmittyB Posted November 10, 2020 Share Posted November 10, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted November 10, 2020 Author Share Posted November 10, 2020 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 Quote Link to comment Share on other sites More sharing options...
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.