160B Sprites

[+Muddyfunster]

Sorry, I'm back with more questions

 

I managed to get banners and 160A sprites working quite nicely however I've found working with 160B sprites and managing the palette to be very challenging in an environment where I need to have multiple sprites sharing a palette.

 

Apologies for the long winded explanation :

 

Using the sprite editor, I created 2 simple test sprites (attached below), both using the same 12+1 160B palette. Warrior (original sprite - red cloak) and Warrior 2 (a copy of Warrior but with a couple of colours changed - blue instead of red).

 

In the picture below, row 1 is Warrior, Row 2 is Warrior2, Row 3 is Warrior and so on, attached program demonstrates a screenful of red cloaked warriors (program file attached - "Warrior no index").

 

In this sample I set my palette up, adjusting until Warrior 1 had everything the right colour. I then added the second PNG to my program and displayed them with the same palette, I expected "Warrior 2" to be off as I set it to use 2 colours different to the first PNG but they both display identically, so the interpreter is treating the reds and blues as the same colour (indexing I assume?). In the sprite editor they are different colours in different slots but I assume when they are encoded to PNG they are just "colours" the red and blue sharing the same spot in different files.

 

 

ah ha! I'll swap the offending colours around using the index thingy when I load them in.

 

 

In the second picture I've set the colour indexes to what I assume should be the default for "Warrior2" so that I have a starting point to figure out what colours to swap to ensure red swaps to blue. Like so :

 

incgraphic gfx/warrior2.png 160B  0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

 

I was expecting the same initial result as in picture 1. Nope, it sets them to something different including moving some of the transparent colours to actual colours so 0 1 2 3 4 5 etc is not the default. So I  have to set both PNGs to 0 1 2 3 4 etc and then start from scratch moving colours and transparencies around, and then fix the palette

 

I'm hoping i'm being really dumb and I'm missing a trick with this. Being able to share a palette for different sprites is key to the ideas I want to develop using 160B

 

My understanding of the syntax of incgraphic is that the numbers specify the colour palette "slot", so if I think for example that the colour red in slot 3 and blue in 9 are in each others place in my sprite, I can just flip them so I end up with something like incgraphic gfx test.png 160B 0 1 2 9 4 5 6 7 8 3 10 11 12 13 etc? I assume that 0 = first transparency in palette 0, colour 1 = P0C1, colour 2 = P0C2 and so on.

 

Am I missing some secret 160B sauce or is it a process of elimination until you get it right and setting the index to a default like 0 1 2 3 4 5 etc. If so, that sounds awfully long winded to set up graphics in a game where there are a lot of sprites sharing a palette.

 

I also tried with Gimp making a 13 colour indexed png with pretty much the same result.

 

Any help or guidance would be really appreciated and I appreciate there are some crossovers with the other thread I made on 160B banners.

 

 

 

 

warrior no index.bas warrior indexed colours.bas

Edited February 18, 2020 by Muddyfunster

[+Muddyfunster]

Think I've figured it out, lots of trial and error and shifting the transparent indexes out of the way.

 

[+Karl G]

That's some pretty cool art, too. I'm looking forward to seeing what you create.  ? 

[SlidellMan]

Those look rather nice.

[+Muddyfunster]

8 hours ago, Karl G said:

That's some pretty cool art, too. I'm looking forward to seeing what you create.  ? 

Thanks Karl & SlidellMan,

 

The Warrior graphic was just an experiment, probably not going to get used in any game for now.

 

I'm mostly figuring out what does and doesn't work on the 7800. With the 2600, even with DCP+ I found I had to rely a lot on "negative space" to create detail in the sprite and suddenly having 24 colours on screen to play with provides a lot more flexibility that I'm used to lol. Even with the dabbling I do on other platforms like the ZX Spectrum, I don't have this amount of colour flexibility out of the box.

 

I do find even 16x16 sprites look quite chunky in 160 so I'm going to experiment more with them and also some 8x8 sprites. I have about 20 ideas for games that I either ran out of motivation for or the idea wouldn't have worked well enough on the 2600 that I'd like to revisit at some point, like a village management game for based on the old BBC Micro game Yellow River Kingdom, so lots of ideas to get on with. I still think converting something like Dare Devil would be a good start so I can learn as I go.

Edited February 19, 2020 by Muddyfunster

[Trebor]

1 hour ago, Muddyfunster said:

...I do find even 16x16 sprites look quite chunky in 160 so I'm going to experiment more with them and also some 8x8 sprites...

Defender_2600 put together a great visual aid in the planning and development of sprites for the 160 modes.

 

 

Slimming down the sprite, while granted, may lose a little detail, can improve the final product significantly.

[RevEng]

6 hours ago, Trebor said:

Slimming down the sprite, while granted, may lose a little detail, can improve the final product significantly.

You could also go the other way, and increase the height. I put together a wip some years back for testing having tiles occlude the player sprite, which did that...

 

 

occlude.bas.a78 occlude.bas.bin

 

...I'm no graphics master, but it avoids the chunky look, and I think taller sprites is a nice change.

 

[+Muddyfunster]

Thanks @Trebor & @RevEng

 

I tried making my sprites thinner and maintain the height so they didn't look so chunky, that worked really well and I think for certain sprites that would be best, I guess it's situational. I also tried increasing the height per @RevEng's suggestion and that also worked really well but I've always liked big tall sprites.

 

My first try looked ok in the sprite editor (left sprite) but jebus, you would have needed a team of sherpas to cross the guy's chest when he rendered in 160.

 

 

I made him taller and slimmed him down just a touch and those proportions worked out nice when rendered. The barbarian is a bit meaty still across the chest but I think he wears it well.

 

 

 

Finally getting the hang of indexes and palettes!

 

 

Edited February 20, 2020 by Muddyfunster

[RevEng]

That's looking fantastic!

[SlidellMan]

You're getting better, just keep at it. I'd suggest that you study up on lines of action.

[+Muddyfunster]

Thanks for the feedback, appreciated. 

 

I worked a bit more on this and added some frames for the swordsman doing a chop.

 

Here's how he looks. I'm not 100% happy with him yet but the whole point of this for me is experimenting with a new medium, so with that in mind, it's so far so good

 

 

 

[+Muddyfunster]

I'm tempted to try an even taller version of the swordsman with proportions like those in the Barbarian games, rather than platformer or RPG sized.

 

 

[+Karl G]

That looks great! Have you considered a Prince of Persia style game?

[+Muddyfunster]

On 2/20/2020 at 5:18 PM, Karl G said:

That looks great! Have you considered a Prince of Persia style game?

Bloody hell Karl  That would be some undertaking! 

[+Karl G]

2 minutes ago, Muddyfunster said:

Bloody hell Karl  That would be some undertaking! 

That didn't sound like a "no" to me. 

[fultonbot]

Hi, playing with 160B and I have a question.
In the image below, have you found the relationship between the colors in the painting palette and how they get indexed for display?

Are the saved across, down, or in some other manner?  Is it all trial and error?

 

Edited July 21, 2020 by fultonbot

[+SmittyB]

It's down to the editor but usually they'll go from top left to bottom right, row by row, with each new colour it finds being given the next spot on the palette.

 

Rather than relying on the palettes given by your editor of choice, the best thing you can do is set your palettes manually such as below...

   rem  **  set palette 0 colors to green, light green, and salmon
   P0C1 = $d2
   P0C2 = $d8
   P0C3 = $3b
   rem  **  set palette 1 colors to grey, white, and yellow
   P1C1 = $04
   P1C2 = $0f
   P1C3 = $18

... and then re-order the colours as needed when you import such as in the below example where colours 1 and 2 are swapped around.

graphic filename.png [graphics mode] [color #0] [#1] [#2] [#3]

incgraphic foobar1.png 160A 0 2 1 3

 

[fultonbot]

59 minutes ago, SmittyB said:

It's down to the editor but usually they'll go from top left to bottom right, row by row, with each new colour it finds being given the next spot on the palette.

 

Rather than relying on the palettes given by your editor of choice, the best thing you can do is set your palettes manually such as below...

   rem  **  set palette 0 colors to green, light green, and salmon
   P0C1 = $d2
   P0C2 = $d8
   P0C3 = $3b
   rem  **  set palette 1 colors to grey, white, and yellow
   P1C1 = $04
   P1C2 = $0f
   P1C3 = $18

... and then re-order the colours as needed when you import such as in the below example where colours 1 and 2 are swapped around.

graphic filename.png [graphics mode] [color #0] [#1] [#2] [#3]

incgraphic foobar1.png 160A 0 2 1 3

 

I did not realize until this morning that you could re-order the colors in the palette.  
Still some trial and error to match them to what the image has encoded too.

160B is a very interesting mode. You get two 12-color palettes?  
I could see some neat uses for a day-night game and stuff like that.

 

-Steve

[+Muddyfunster]

160B is really nice but it comes at a price, the graphics take a lot more space to store. 

 

If it's just 1 sprite, I adjust the palette to the sprite, if it's more than 1 frame or sprite  then I tend to move the indexes to match each. I find setting every colour to something not in the sprite (like bright pink) means you can check that all of the transparency index are right. I then change 1 colour to say white, see where it changes on the sprite and substitute the correct colour. It sounds long winded but once you get used to it, it's not so bad. With 160A it's much quicker due to only being 3 colours instead of 12. The biggest pain is usually transparency indexes going awry.

Edited July 21, 2020 by Muddyfunster

[+mksmith]

@fultonbot unfortunately the indexes come out in an unindexed order from ADS (I tried many things to try to fix this!) - I think it may be with rgb or number of used pixels. So as Muddy outlined it is trial and error. Interestingly if you have a large number of frames they do show a pattern of order. I use a separate project which just loads and displays each frame quickly so I can adjust it and copy to the main project.

 

With 160B 0, 4, 8, 12 are your transparent indexes. 

 

Palettes are very flexible - Arkanoid not only uses each 7 palettes separately but also the 160b palettes 0-3 and 4-7 for some required objects. It took a fair bit to organising to get that working!

 

[fultonbot]

1 hour ago, mksmith said:

@fultonbot unfortunately the indexes come out in an unindexed order from ADS (I tried many things to try to fix this!) - I think it may be with rgb or number of used pixels. So as Muddy outlined it is trial and error. Interestingly if you have a large number of frames they do show a pattern of order. I use a separate project which just loads and displays each frame quickly so I can adjust it and copy to the main project.

 

With 160B 0, 4, 8, 12 are your transparent indexes. 

 

Palettes are very flexible - Arkanoid not only uses each 7 palettes separately but also the 160b palettes 0-3 and 4-7 for some required objects. It took a fair bit to organising to get that working!

 

Oh can you display 160B images on a 160A screen by specifying 160B when you load in the graphic?

 

[+Muddyfunster]

20 minutes ago, fultonbot said:

Oh can you display 160B images on a 160A screen by specifying 160B when you load in the graphic?

 

yup

 

You can also share the individual palettes between sprites, so you could, as Matt stated, have a 160B palette (palettes 0 through 3) but still have a 160A sprite that uses palette 2 or 1. It's fiddly to line that up, but is doable.

Edited July 22, 2020 by Muddyfunster

[+mksmith]

Certainly adds some flexibility.  For example your main character can have a little bit more color which I did with Millie and Molly or in the case of Arkanoid the vaus and Doh head currently.

[fultonbot]

So right now the inly issue then it figure out an pattern/method to approach getting the pallet colors correct So far I have not found one.

[+Muddyfunster]

That workflow is much easier with 160A sprites as you only have 4 indices and 3 actual colours (+ transparent).

 

With 160B you have more of both so the work flow is more complex. To recap what @SmittyB wrote, you either have to adjust the palette declarations (P1C1=$xx and so on) or tweak the index for each graphic.

 

For example, if you have 2 sprites, you might load them something like this :

 

incgraphic moose.png 160A 0 1 2 3

incgraphic dog.png 160A 0 2 1 3

 

In the first example, moose.png just has default index settings applied (0 1 2 3) so no changes, it's displaying exactly how I want.

 

In the second, dog.png has the indexes in a different order (0 2 1 3) that's because maybe it's using a palette i'm already using for something else and I don't want to adjust the palette colours (P2C2 etc) to make dog.png look correct because that would screw up the other sprites using that palette (you don't want to start playing palette wack-a-mole), so in stead I swap colour 2 and colour 1 around by changing the index (0 2 1 3)

 

I also found this initially a bit confusing and it is more complex dealing with 160B sprites due to more colours and sometimes the transparency index ends up being moved to something other than 0,4,8,12. Best way I found was to fiddle about with some sprites and palettes. Expect them to end up looking like an explosion in a hello kitty factory while you figure it out  but you will nail it. 

 

I find I have the least bother with the editor in ADS, more problems with GIMP.

 

I hope that helps at least a little bit.

 

If I get some time, I'll post a blow by blow example using a 160B sprite and my workflow / process.