English Amiga Board

English Amiga Board (https://eab.abime.net/index.php)
-   Graphics. Work In Progress (https://eab.abime.net/forumdisplay.php?f=134)
-   -   Amiga Sprite art. Help? Hints and tips? (https://eab.abime.net/showthread.php?t=103798)

Adrian Browne 02 September 2020 18:59

Amiga Sprite art. Help? Hints and tips?
 
I am getting back into sprite art after years and am thoroughly enjoying it. I use pro motion and dawnbringer 32's palette.

Specifically, I want to work on creating a sprite sheet for a potential amiga game and develop my skills that way.

I guess in theory its an a500 game.

So, I have a 32 colour palette. Should I reserve specific colours for sprites and others for backgrounds?

About parallax. Any tips on scaling the different layers size, relative to each other? Is there a sprite size limit I should stick to regarding big enemies like boss,s etc?

I suppose some boss,s could be drawn on the background layer if the screen was fixed ala rtype boss battles etc?

Or can I just draw a big sprite with minimal animation etc?

Total noob so excuse my questions. I am loving creating sprite art though.

I have been and will look at other tutorials. Currently I plan to make the sprites in a500 resolution. 320x200 if I remember correctly.

Please fill me with thine wisdoms

saimon69 02 September 2020 21:27

More details are needed, like the kind of game you want to do

Adrian Browne 03 September 2020 01:33

Quote:

Originally Posted by saimon69 (Post 1425464)
More details are needed, like the kind of game you want to do

I guess a side scrolling shooter akin to Menace by psygnosis. I want to at least build up a sprite sheet and learn as i go.

So, a first animation i did is attached and a work in progress brick tile also.

I have been practicing on and off for two weeks.

Daedalus 08 September 2020 17:10

There are a few factors regarding how the game is actually constructed that will influence the palette layout. If you're not the coder, you'll need whoever is to tell you the specifics. For example, if it's a dual playfield game, colours 0-7 are for the foreground, colours 8-15 are for the background and colours 16-31 are for the hardware sprites. (Speaking of sprites, I'm assuming you mean sprite as any moving game element, but in game engine terms, sprites and BOBs (Blitter OBjects) are separate entities that each have their own palette requirements and other pros and cons.)

A dual playfield display like this allows a very easy and fast single layer of parallax in the background, but limits you to 8 colours for any graphics in each layer (well, 7+transparent in the front layer), be they BOBs or parts of the level. If it's not dual playfield, you have all 32 colours available for blitted graphics, but blitting will be slower which will reduce the number of objects you can run at once.

Using (hardware) sprites gives you extra moving graphics that are more or less free in that they don't require blitting time, but you're limited to 8 of these with a maximum width of 16 pixels, and each pair is limited to a fixed 3 colour section of the palette between 16 and 31. In a dual playfield display, the sprites can be in front of or behind the front layer, and creative use of them can add a layer of parallax. You can join pairs of sprites together to either double the width to 32 pixels, or double the depth to 15 colours (again, taken from pens 16-31), but of course this means fewer independent sprites available. Sprite height is unlimited, which makes them convenient for using as side status bars in games.

Some games use a mixture of sprites and BOBs - perhaps a joined sprite for a 16-colour player, and then other sprites for powerups and BOBs for enemies, or some other combination.

They're the basics of an OCS/ECS setup. It's possible to perform certain copper tricks to increase the number of colours on screen, but that then needs integration with the code.

AGA gives you increased flexibility in many of these areas (individual sprite width up to 64 pixels, number of colours in dual playfield layers doubled, number of colours in single playfields upped to 256, flexible palette options for sprites, 24-bit palette instead of 12-bit), but of course means your game won't work on OCS and ECS Amigas.

If you don't have a specific game setup in mind, perhaps simply drawing them as you wish might work for now, and then when the game itself comes later you can modify and recolour the graphics to suit the code.

Adrian Browne 22 September 2020 20:21

Hi. Daedalus. Thanks for the informative response. Excuse my noobness- if possible I would like to aim as closely as possible to a particular set-up so as to minimize reworking the graphics at a later date. I am still learning sprite art but loving it so i am progressing quickly.

You said: A dual playfield display like this allows a very easy and fast single layer of parallax in the background, but limits you to 8 colours for any graphics in each layer (well, 7+transparent in the front layer), be they BOBs or parts of the level. If it's not dual playfield, you have all 32 colours available for blitted graphics, but blitting will be slower which will reduce the number of objects you can run at once.

So dual play-field mode allows me to use only 16 colours or 32? If i have fixed colours for each layer and fixed colours for say player/enemies can i mix and match those colours between the layers or are they strictly reserved for those layers only?

Obviously the player ship is the same colour in each level- can the assigned colours for individual layers vary from game level to game level i.e a a different fixed number of colours for an individual layer in any given game level etc?

https://lospec.com/palette-list/dawnbringer-32

So in the above palette link I would literally just assign fixed colours for each layer etc?

Ideally i would like access to all 32 colours for the graphics- what is the optimum set-up i could work with right now that would require the least amount of graphics re-working later? Lot's of questions i know... At least i could work on enemies, player ship and foreground art-maybe some background art and if another graphical layer was needed later i could do that in the future.

redblade 22 September 2020 21:52

noob question here: If you were doing sprites, wouldn't you set Deluxe Paint III to 16 colours 4 bitplanes and draw them that way because the IFF convertor coverts them to sprite format?

Adrian Browne 22 September 2020 23:40

Quote:

Originally Posted by redblade (Post 1429370)
noob question here: If you were doing sprites, wouldn't you set Deluxe Paint III to 16 colours 4 bitplanes and draw them that way because the IFF convertor coverts them to sprite format?

Is that right? No idea. Hah. How's the amiga1200 I sold you?

Daedalus 23 September 2020 10:13

Yeah, sprites take their colours from the 16-31 pen range, but internally they're either 2 or 4 bitplanes deep, so they only have 4 or 16 colours (with the first one being transparent). I tend to have a master palette, which is what the game will use, and copy pens 16-31 to a new palette in positions 0-15 for creating the sprites.

redblade 23 September 2020 12:51

Quote:

Originally Posted by Adrian Browne (Post 1429393)
Is that right? No idea. Hah. How's the amiga1200 I sold you?

I got it recapped. It's going good. Don't have it set up at the moment, but I usually run it in DBLNTSC mode as I don't have a 15khz screen.

So I need to learn how to modify NTSC copperlists to DBLNTSC if I want to play games. I gave a mate of mine one of the Workbench manuals. I also gave him the WHD-Load CF card.

I think it's 1 16 colour sprite per scan line, or 1 4 colour sprite can be reused 8 times on scan line.

The ASM tutorials I saw your had to hand code the sprites in hex. Looking forward to seeing your work :)

Wow that dawnbringer palette and pixel art is amazing for 32 colours.

Daedalus 23 September 2020 14:51

You can have four 16-colour sprites or eight 4-colour sprites per line. 16-colour sprites are just two 4-colour sprites combined to give 4 bitplanes (16 colours) by adding the two 2-bitplane (4 colours) together.


All times are GMT +2. The time now is 13:58.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.

Page generated in 0.05192 seconds with 11 queries