graphics for an Amiga/megadrive vertical scrolling shmup-some questions

[Photon]

Love to see this, many games for Amiga left palette planning as afterthought (or if port from ST, added no work).

[Adrian Browne]

Originally Posted by Samurai_Crow

Palette cycling is quick. You can change banks with the background palette in a single copper instruction.

Ah ok. Using copper I expect. I guess its something to consider when i get a coder for it-

[Master484]

Would it be plausible to do animated water tiles in an ocean level?

Yes, if not all tiles are updated at once, then this sort of thing can be done with directly drawn animated tiles. So some kind of slowly moving waves could by possible. But as already mentioned, palette cycling is usually a better way to do it.

[Samurai_Crow]

Originally Posted by Adrian Browne

Ah ok. Using copper I expect. I guess its something to consider when i get a coder for it-

Have you considered using an engine for your game? RedPill on the Aminet is an Amiga program that allows you to create games or prototypes using point-and-click style "reduced coding" experience.

Edit:
Here's a thread about RedPill http://eab.abime.net/showthread.php?t=108100

[Adrian Browne]

Originally Posted by Master484

Yes, if not all tiles are updated at once, then this sort of thing can be done with directly drawn animated tiles. So some kind of slowly moving waves could by possible. But as already mentioned, palette cycling is usually a better way to do it.

AH, Samurai Crow was referring to colour cycling like D-paint used to do- yes its easy to do with Pro-motion NG. I can do that

[Adrian Browne]

Attached is a Quick and very unfinished mock-up for an ocean level.

[Adrian Browne]

Originally Posted by Samurai_Crow

Have you considered using an engine for your game? RedPill on the Aminet is an Amiga program that allows you to create games or prototypes using point-and-click style "reduced coding" experience.

Edit:
Here's a thread about RedPill http://eab.abime.net/showthread.php?t=108100

I may play around with Red pill on my A1200 at some point yes. For this game Nivrig who made Turbo Tomato will likely code it later.

[Samurai_Crow]

Originally Posted by Adrian Browne

I may play around with Red pill on my A1200 at some point yes. For this game Nivrig who made Turbo Tomato will likely code it later.

Cool!

[DanielAllsopp]

Originally Posted by Master484

No, there is no need to do that.

To clarify:

On AGA you can always make the sprite colors separate from your main palette. So in 64 color mode your palette setup will look like: 64 + 16. So you'll still have your four 16-color palettes, and in addition to them a separate 16 color sprite palette. So in total you have 80 colors, of which 16 is for sprites only.

So: when sprite colors are outside of the main palette, only then they're reserved for sprites only. And when they are inside the main palette, then they simply use the same colors as your other graphics do.

This isn't possible with a 6 bitplane, or 64 colour setup. Your (attached) 16 colour sprites have to share 16 colour entries of the available 64. Those colours can also be used for BOBs, but you definitely don't get 64 unique colours for the bitplanes, and an extra 16 colours for sprites I'm afraid.

You could raise the number of bitplanes to 7, or 128 colours and have a separate bank for the sprites and 112 unique colours for the bitplanes but that will be slower again.

[saimon69]

AND that should answer the guy that in the Flying Shark thread asked "Why only 16 colours"?

[Samurai_Crow]

Originally Posted by DanielAllsopp

This isn't possible with a 6 bitplane, or 64 colour setup. Your (attached) 16 colour sprites have to share 16 colour entries of the available 64. Those colours can also be used for BOBs, but you definitely don't get 64 unique colours for the bitplanes, and an extra 16 colours for sprites I'm afraid.

You could raise the number of bitplanes to 7, or 128 colours and have a separate bank for the sprites and 112 unique colours for the bitplanes but that will be slower again.

Extra halfbrite mode and AGA true 6-bitplane are two different modes. On AGA modes, you can relocate the sprite banks up to the end banks.

[DanielAllsopp]

Originally Posted by Samurai_Crow

Extra halfbrite mode and AGA true 6-bitplane are two different modes. On AGA modes, you can relocate the sprite banks up to the end banks.

I know, I never mentioned EHB, I’m writing a game in 6 bitplanes on AGA hardware right now; you can’t have a 6 bitplane screen, or 64 colours, and then add another 16 colours (making 80) just for sprites.

[Adrian Browne]

Originally Posted by DanielAllsopp

I know, I never mentioned EHB, I’m writing a game in 6 bitplanes on AGA hardware right now; you can’t have a 6 bitplane screen, or 64 colours, and then add another 16 colours (making 80) just for sprites.

Is that definite? Well then I guess I'll go with 64 colours and share some of those for sprites?

[hooverphonique]

Originally Posted by Adrian Browne

Is that definite? Well then I guess I'll go with 64 colours and share some of those for sprites?

You can select between 16 sets of 16 palette entries for both even and odd sprites using BPLCON4, independently of other screen mode features (ham,dpf).

[Adrian Browne]

Originally Posted by DanielAllsopp

This isn't possible with a 6 bitplane, or 64 colour setup. Your (attached) 16 colour sprites have to share 16 colour entries of the available 64. Those colours can also be used for BOBs, but you definitely don't get 64 unique colours for the bitplanes, and an extra 16 colours for sprites I'm afraid.

You could raise the number of bitplanes to 7, or 128 colours and have a separate bank for the sprites and 112 unique colours for the bitplanes but that will be slower again.

So, can I use any of the 64 colours freely for sprites then? Or do i designate a fixed set of 16 colours from the total 64 colours?

[Samurai_Crow]

You can use an independent 16 colors for sprites and 64 colors for BOBs. I don't know what's going on with the code that's being written by the other guy.

[Samurai_Crow]

Originally Posted by DanielAllsopp

I know, I never mentioned EHB, I’m writing a game in 6 bitplanes on AGA hardware right now; you can’t have a 6 bitplane screen, or 64 colours, and then add another 16 colours (making 80) just for sprites.

You did something wrong then. You can bank select any of the 16 banks of 16 colors for sprites.

[Adrian Browne]

Originally Posted by Samurai_Crow

You can use an independent 16 colors for sprites and 64 colors for BOBs. I don't know what's going on with the code that's being written by the other guy.

Ok- cool.

[Tsak]

Originally Posted by Adrian Browne

I may play around with Red pill on my A1200 at some point yes. For this game Nivrig who made Turbo Tomato will likely code it later.

Oh that's nice. Nivrig has done an amazing coding work with Turbo Tomato, so you're definitely in good hands

Still, if you're interesting in prototyping or trying something yourself, I'd strongly suggest to check the Scorpion Engine instead of Redpill. More so since you're planning for a Megadrive release. Scorpion recently got Megadrive support as well, so you can have a project exported for Amiga AND Megadrive. This way you can also directly start testing whatever you're planning to do with gfx.

[Adrian Browne]

Originally Posted by Tsak

Oh that's nice. Nivrig has done an amazing coding work with Turbo Tomato, so you're definitely in good hands

Still, if you're interesting in prototyping or trying something yourself, I'd strongly suggest to check the Scorpion Engine instead of Redpill. More so since you're planning for a Megadrive release. Scorpion recently got Megadrive support as well, so you can have a project exported for Amiga AND Megadrive. This way you can also directly start testing whatever you're planning to do with gfx.

Yes, I'm doing the graphics for his new R-Dek game and I suggested doing a multi platform shmup- he seemed interested- I'm not sure I could get my head around scorpion-tbh.