Amiga GFX noob questions - Page 2

Samurai_Crow · 23 December 2018, 20:45

On PC graphics cards you have to worry about binding textures which transfers them to video RAM from main memory. On Amiga, once they are in Chip RAM they stay there until you program it to go elsewhere. There's no need to keep all the images on one sheet, in other words.

In your final game the sheet will be divided into single frame images stored separately to avoid failures of allocation due to large chunks in fragmented memory.

Other than that, there's no problem with your palette plans as long as it fits into the available Chip RAM.

d4rk3lf · 24 December 2018, 00:44

Yeah... that makes sense.
Thanks.

I guessed I don't need to use the same image for everything, but how do I ensure that 2 images shares the same 64 (or 32) colors, unless I combine them, and convert them together?
What is the workflow?

What I do now... is putting all together, then converting to 32 colors, then crop to character, save as IFF.character, then undo... then cropping again to tiles, then save as IFF...
Here is how looks my raw PSD image:
https://i.ibb.co/R27w0j3/Screen-01.jpg

Anyway, here is my first test of background I did.

That black line you see, shouldn't be there, because all tiles should... tile

However... this freaking Photoshop... whenever I scale down image (even in nearest "neighbor mode" ) it makes edges opacity...
(so... comment to everybody non experienced... never scale image in PS (transform-scale)... better open it individually... scale it in canvas... save... open... and then drag to the main file)
-----------

Thanks for all the help people!
I would still struggle with main character, if there were no such huge help from all of you.

d4rk3lf · 27 December 2018, 02:05

Update on the tiles:

DamienD · 27 December 2018, 02:06

Wow, looking good d4rk3lf

d4rk3lf · 27 December 2018, 16:25

Thanks a lot man.

Still, ground looks like crap, need to make smoother transitions between tiles, but I am learning as I go, and so far, I have been creating only 32x32 px tiles. Will start making 16x16 ground tiles.
Hopefully that should give me more variation.

Cheers!

Ricardo · 04 January 2019, 22:53

Glad you liked MKII :-)

In most of the Amiga stuff I did, I used a 32 colour screen with 16 colour background (backdrop and score panel) and 16 colour foreground (blitted character sprites).

For MK1&2, as the players were human based they shared skin tones - I forget now but it was something like 6 colours for each player plus, 3 skin tones and transparent = 6+6+3+1 = 16 colours.

In Primal Rage, because the characters were aliens each one had its own 7 colour palette + transparency. So 8 colours each, this also allowed the source graphics to only occupy 3 bit planes (less storage).

Don't forget with the Amiga its also easy to change the palette dynamically. So although you might have a 32 colour, 5 bit plane display. You could for example have a background consisting of 3 bands of 16 colours. A feint palette for the top 3rd of the screen, a bold palette for the bottom third and a transition palette for the centre. That gives you a 48 colour background, with good depth shading.

If your score panel never overlaps the player graphics, then that could use its own 16 colour palette (15 plus transparency). So that way you then end up with an 80 colour display (48 background + 16 panel + 16 player).

For some inspiration I have attached the source graphic frames for Scorpion from Amiga MK2 - amazing what you can find on a Mac SSD with a few clicks ;-)

d4rk3lf · 05 January 2019, 22:24

Thanks man.
That's great, and thanks for clarification, it will help me, and others even much more.
I was surprised to see scorpion sprite made of a separate images for every frame. I was thinking it was a spritesheet for each character on the single image.
I thought this approach would be memory inefficient... but what do I know?

I am using RedPill game engine for testing my sprite and background, because my knowledge of the real programming is bellow zero. So far, I did what I wanted (I only wanted to see my sprite walking), yet , I am hoping, I could make some demo level of gameplay... and then.. who knows...

idrougge · 06 January 2019, 03:59

I would just leave Photoshop behind and use Personal Paint. It has supreme palette handling and the drawing tools are more geared towards pixel graphics.

d4rk3lf · 06 January 2019, 09:08

@idrougge
Yeah, well...
the main reason is because I know very little to use PPaint. The second reason is because in PS I have all layers, grid based canvas, very organised, and it's very fast and easy to update spritesheet and tiles.
---------------------------------

HUGE UPDATE!

- Updated tiles of a background.
- Added idle (fighting pose) for the character
- Added simple combo for the character
- Extended game area from static screen to much larger area

Here is the video:

[ Show youtube player ]

Unfortunately, video is a little bit jerky, and on my comp, gameplay is very smooth.
The reason is because game is set to 50fps, and I can record at maximum 40fps (it's a free recorder).

Ricardo · 06 January 2019, 13:19

I need to dig deep into my memory now so this may not be 100% but here goes! The Scorpion LBMs are the source frames that were processed to generate the files used in the game. They show what the resultant on screen graphics looked like. The actual process was:

1) Arcade machine graphics were extracted into individual frames.

2) These were re-sized (shrunk) and re-coloured from the original 64 colours per character down to the specific palette used for the character on the Amiga. Each of these frames were stored as an LBM (as above) with contrasting background.

3) The folder full of LBMs were then processed by a program called “CRISP” (Carls Really Interesting Sprite Processor) which got all the LBMs as it’s input and output 3 files. A table file, map file and character file. These were used in the game.

CRISP loaded each image in turn and cut them into 16 x 16 pixel tiles. Each tile was compared against all the tiles generated so far to see if they had already been created. To increase the chance of a match each tile was shifted by 1 pixel and the comparison was made again, doing this 16 times. I recall each horizontal strip of 16 pixels was also rotated in 16 steps to makes comparisons too.

Each tile was also reflected vertically and horizontally again to see if there were any matches, with each unique 16 x 16 pixel tile being added to the character set file.

To build frames out of the character set each frame had a map containing the frames width and height in characters an offset in x and y to position the frame in relation to an origin, the character numbers required (matrix of rows and columns as per the width and height) and a shift factor for the character.

Finally the table was created which stored the offset within the mat file of each frames description. Each table entry being 16bits.

After all that, each 16 x 16 tile was then compressed. Converting all zero bytes into a single 0 bit and then using increasing bit patterns to represent increasingly rare values.

So we ended up with 3 files for each player:
Table file (2 bytes per frame)
Mat file (multiple bytes per frame)
Chr file (all the compressed tiles)

So to draw a single frame the game would:

1) Get the frame number and double it to get the offset in the table file as a pointer to the Mat file.

2) Read the details of the Mat file to define what to do including the width and height plus offsets for each character in the chr file.

3) The 68000 would then decompress each tile from Fast RAM into a chip RAM buffer and trigger the blitter to move the tile into a larger frame buffer whilst at the same time the 68k decompressed the next tile into another tile buffer. As part of the decompression the data was also reflected if required given all frames were stored facing one way.

4) Once the frame was built it was blitted to the screen. The shadow being generated from every 4th pixel line.

I think that was it!

The problem back then was simply a lack of memory. It was always a problem especially for coin op conversions as they had loads of ROM as their storage system.

MigaTech · 06 January 2019, 18:22

This is certainly starting to look like a Team 17 title. Keep up this superior work, truly outstanding!

d4rk3lf · 08 January 2019, 15:48

@Ricardo
Just Wow!

Man, my thread is not worthy of such detailed reply, when I am sure many people that are on coders podforum would die to hear these tips and tricks. I don't beleave they often visit this podforum, unfortunately.
However, I got 2 questions (one on topic, second off topic)
1) Do you think (with today technology) is better that I keep both background and character sprite on one image (16 million colors), and then to convert it to 32 colors, then make 2 images (sprite and tiles) out of that.
Or... make 2 images (sprite and tiles). And both convert to 16 colors.
Or you think it's different from case to case, and depends on project overall?

2) I am not sure how much you are aware, but Final Fight conversion (by Richard Aplin) for the Amiga is considered by many (maybe 80-90%), a very bad port. Maybe not because of the graphics conversion so much, but much more because of the bad gameplay feel. Yet, you did port of games that are no less challenging (to say at least), like MK 1 and 2, and Golden Axe (that is considered best beat em up for the Amiga).
What's your thoughts on this? Do you think you could do better job on FF port?
I saw in some interview that Richard claims that no one could do a better job on that, and I am not sure I can agreed with him.
(but, to be fair, I must say also, that he (totally alone) did all the stuff in 6 month, and FF worked on unexpanded A500 512k)
I'd like to hear your thoughts on this.
It's unfortunate, that besides Golden Axe, we don't have any beat em up on Amiga, and even Golden Axe (imho), arcade version, is not really that well done in gameplay feel (like arcade Final Fight, Captain Commando, Punisher, Cadillacs and Dinosaurs... etc)

@MigaTech
Thanks a lot man,
but what you are saying is waaaaaay overestimating my skills. Team 17 is like Blizzard for the Amiga, and my skills on RedPill are not in pair with poorest of poorest coder in the world. I also struggle very much with graphics (that's why I opened this thread

)

d4rk3lf · 08 January 2019, 16:03

Ok, time for update.

Meet our first enemy: Malko
(before apocalypse he was a talented lawyer, but with terrible marriage experience. The nukes leaves so bad looking scars on him, that some people thought that he is a zombie. The burning of his body outside, releases his inner rage, and he is now a machine of robbing and raping survivors. He start chasing our heroine)

screenshot:

Here you can see him in action.
So far, I managed to make him, follow the main character:

[ Show youtube player ]

DamienD · 08 January 2019, 16:09

Quote:

Originally Posted by d4rk3lf

Meet our first enemy: Malko
(before apocalypse he was a talented lawyer, but with terrible marriage experience. The nukes leaves so bad looking scars on him, that some people thought that he is a zombie. The burning of his body outside, releases his inner rage, and he is now a machine of robbing and raping survivors. He start chasing our heroine)

How appropriate; hey malko?

d4rk3lf · 08 January 2019, 16:12

Quote:

Originally Posted by DamienD

How appropriate;?

Hah... why?

You're a lawyer? :P

Quote:

Originally Posted by DamienD

How appropriate; hey malko?

Omg!
I just throw a name that first falls on my mind.
I'll check now who is this guy.

Edit:
Well.. it might be my subconquestnes that I picked the name that I read here. We can change it easely.

If Malko is bothered, I will change it to... hmm... Doran? Quisky? El-something? Damien? :P

DamienD · 08 January 2019, 16:21

Quote:

Originally Posted by d4rk3lf

Meet our first enemy: Malko

Leave it as Malko; as I said it's very appropriate

Quote:

Originally Posted by d4rk3lf

If Malko is bothered, I will change it to... hmm... Doran? Quisky? El-something? Damien? :P

You can use my name; Damien is apparently the devil so...

...but maybe save me for a boss for something; hahahahaha

d4rk3lf · 08 January 2019, 16:33

Quote:

Originally Posted by DamienD

You can use my name; Damien is apparently the devil so...

You must see that with Malko. I'll keep it Malko, until Malko disagree.
I have a back-story pretty much completed, and long story short "our heroine daughter is kidnapped", she goes to rescue her. I never thought of daughter name.
Interested? :P

Like... Damien-a... or something

grelbfarlk · 09 January 2019, 04:25

Quote:

Originally Posted by d4rk3lf

Alright,

So I downloaded free 3D rigged and animated model from Mixamo site, lighted it in 3DS Max, fixed some problems, and rendered.

Whoa, whoa hold up there. Did you carefully check the license of the free model before you made plans what to do with it for the eventual release?

Also will this be playable on a 256K A1000 via floppy?

d4rk3lf · 09 January 2019, 05:32

Quote:

Originally Posted by grelbfarlk

Whoa, whoa hold up there. Did you carefully check the license of the free model before you made plans what to do with it for the eventual release?

Hah....

here you go:

Quote:

Adobe Fuse CC and Mixamo online animation services are currently in a limited duration technology preview, and during that preview they are available for free, with no licensing or royalty fees, for unlimited commercial or non commercial use.

https://forums.adobe.com/thread/1992542

But man, even if they aren't free, do you know how character looks when you change a texture and render in so small res?
Even if I took Schwarzenegger 3D model, and rendered it in 32x32 px, nobody would recognize him.

Besides, this is for learning purpose, and I'd gladly give whole project to anyone that likes to look at it.

Quote:

Originally Posted by grelbfarlk

Also will this be playable on a 256K A1000 via floppy?

Not only that. It will be playable on Atari 2600, and Odisey consoles! :P

Joke aside. , I've already made my goal (and that is: making character walk), and this is all bonus I am doing for fun.
However it would be so cool if I can make whole 1st level as demo, with 3-4 enemies and boss at the end.

RedPill is (so far), only ECS, AGA based, but I am making whole graphics like it is OCS. If I ever finish this one, and if any programmer like it, and want to remake it in some of the coder languages, I'd gladly give him all assets.

As I see it, these game makers apps (like RedPill and Backbone) are amazing for testing purposes. I would use them, even if I am an asm programmer to test my assets, because you can quickly see how something looks and feels, before throwing bunch of codes.

Hewitson · 09 January 2019, 09:14

Great work so far. But to me those sprites look a bit odd on that background. I really think you'd be much better off finding someone to recreate those sprites instead of trying to convert them from a high resolution 3D model.

06 January 2019, 13:19	#30
Ricardo Registered User Join Date: Jul 2009 Location: Nottingham / UK Posts: 155	I need to dig deep into my memory now so this may not be 100% but here goes! The Scorpion LBMs are the source frames that were processed to generate the files used in the game. They show what the resultant on screen graphics looked like. The actual process was: 1) Arcade machine graphics were extracted into individual frames. 2) These were re-sized (shrunk) and re-coloured from the original 64 colours per character down to the specific palette used for the character on the Amiga. Each of these frames were stored as an LBM (as above) with contrasting background. 3) The folder full of LBMs were then processed by a program called “CRISP” (Carls Really Interesting Sprite Processor) which got all the LBMs as it’s input and output 3 files. A table file, map file and character file. These were used in the game. CRISP loaded each image in turn and cut them into 16 x 16 pixel tiles. Each tile was compared against all the tiles generated so far to see if they had already been created. To increase the chance of a match each tile was shifted by 1 pixel and the comparison was made again, doing this 16 times. I recall each horizontal strip of 16 pixels was also rotated in 16 steps to makes comparisons too. Each tile was also reflected vertically and horizontally again to see if there were any matches, with each unique 16 x 16 pixel tile being added to the character set file. To build frames out of the character set each frame had a map containing the frames width and height in characters an offset in x and y to position the frame in relation to an origin, the character numbers required (matrix of rows and columns as per the width and height) and a shift factor for the character. Finally the table was created which stored the offset within the mat file of each frames description. Each table entry being 16bits. After all that, each 16 x 16 tile was then compressed. Converting all zero bytes into a single 0 bit and then using increasing bit patterns to represent increasingly rare values. So we ended up with 3 files for each player: Table file (2 bytes per frame) Mat file (multiple bytes per frame) Chr file (all the compressed tiles) So to draw a single frame the game would: 1) Get the frame number and double it to get the offset in the table file as a pointer to the Mat file. 2) Read the details of the Mat file to define what to do including the width and height plus offsets for each character in the chr file. 3) The 68000 would then decompress each tile from Fast RAM into a chip RAM buffer and trigger the blitter to move the tile into a larger frame buffer whilst at the same time the 68k decompressed the next tile into another tile buffer. As part of the decompression the data was also reflected if required given all frames were stored facing one way. 4) Once the frame was built it was blitted to the screen. The shadow being generated from every 4th pixel line. I think that was it! The problem back then was simply a lack of memory. It was always a problem especially for coin op conversions as they had loads of ROM as their storage system. Last edited by Ricardo; 06 January 2019 at 14:21.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Questions from yet another Gotek noob	Amiga1992	support.Hardware	2	16 May 2017 06:27
Stupid noob TOSEC questions	antonvaltaz	project.TOSEC (amiga only)	6	15 August 2010 00:59
whdload noob questions	beatnik	project.WHDLoad	2	23 July 2010 21:53
WHDLoad noob questions	beanz	project.WHDLoad	9	17 May 2008 12:58
Noob Questions	Crackersixx	Coders. General	12	21 January 2006 23:53

23 December 2018, 20:45	#21
Samurai_Crow Total Chaos forever! Join Date: Aug 2007 Location: Waterville, MN, USA Age: 49 Posts: 2,186	On PC graphics cards you have to worry about binding textures which transfers them to video RAM from main memory. On Amiga, once they are in Chip RAM they stay there until you program it to go elsewhere. There's no need to keep all the images on one sheet, in other words. In your final game the sheet will be divided into single frame images stored separately to avoid failures of allocation due to large chunks in fragmented memory. Other than that, there's no problem with your palette plans as long as it fits into the available Chip RAM.

24 December 2018, 00:44	#22
d4rk3lf Registered User Join Date: Jul 2015 Location: Novi Sad, Serbia Posts: 1,645	Yeah... that makes sense. Thanks. I guessed I don't need to use the same image for everything, but how do I ensure that 2 images shares the same 64 (or 32) colors, unless I combine them, and convert them together? What is the workflow? What I do now... is putting all together, then converting to 32 colors, then crop to character, save as IFF.character, then undo... then cropping again to tiles, then save as IFF... Here is how looks my raw PSD image: https://i.ibb.co/R27w0j3/Screen-01.jpg Anyway, here is my first test of background I did. That black line you see, shouldn't be there, because all tiles should... tile However... this freaking Photoshop... whenever I scale down image (even in nearest "neighbor mode" ) it makes edges opacity... (so... comment to everybody non experienced... never scale image in PS (transform-scale)... better open it individually... scale it in canvas... save... open... and then drag to the main file) ----------- Thanks for all the help people! I would still struggle with main character, if there were no such huge help from all of you.

27 December 2018, 02:05	#23
d4rk3lf Registered User Join Date: Jul 2015 Location: Novi Sad, Serbia Posts: 1,645	Update on the tiles:

27 December 2018, 02:06	#24
DamienD Banned Join Date: Aug 2005 Location: London / Sydney Age: 47 Posts: 20,420	Wow, looking good d4rk3lf

27 December 2018, 16:25	#25
d4rk3lf Registered User Join Date: Jul 2015 Location: Novi Sad, Serbia Posts: 1,645	Thanks a lot man. Still, ground looks like crap, need to make smoother transitions between tiles, but I am learning as I go, and so far, I have been creating only 32x32 px tiles. Will start making 16x16 ground tiles. Hopefully that should give me more variation. Cheers!

05 January 2019, 22:24	#27
d4rk3lf Registered User Join Date: Jul 2015 Location: Novi Sad, Serbia Posts: 1,645	Thanks man. That's great, and thanks for clarification, it will help me, and others even much more. I was surprised to see scorpion sprite made of a separate images for every frame. I was thinking it was a spritesheet for each character on the single image. I thought this approach would be memory inefficient... but what do I know? I am using RedPill game engine for testing my sprite and background, because my knowledge of the real programming is bellow zero. So far, I did what I wanted (I only wanted to see my sprite walking), yet , I am hoping, I could make some demo level of gameplay... and then.. who knows...

06 January 2019, 03:59	#28
idrougge Registered User Join Date: Sep 2007 Location: Stockholm Posts: 4,332	I would just leave Photoshop behind and use Personal Paint. It has supreme palette handling and the drawing tools are more geared towards pixel graphics.

06 January 2019, 09:08	#29
d4rk3lf Registered User Join Date: Jul 2015 Location: Novi Sad, Serbia Posts: 1,645	@idrougge Yeah, well... the main reason is because I know very little to use PPaint. The second reason is because in PS I have all layers, grid based canvas, very organised, and it's very fast and easy to update spritesheet and tiles. --------------------------------- HUGE UPDATE! - Updated tiles of a background. - Added idle (fighting pose) for the character - Added simple combo for the character - Extended game area from static screen to much larger area Here is the video: [ Show youtube player ] Unfortunately, video is a little bit jerky, and on my comp, gameplay is very smooth. The reason is because game is set to 50fps, and I can record at maximum 40fps (it's a free recorder).

06 January 2019, 18:22	#31
MigaTech Only Amiga !! Join Date: Apr 2017 Location: United Kingdom Posts: 588	This is certainly starting to look like a Team 17 title. Keep up this superior work, truly outstanding!

08 January 2019, 15:48	#32
d4rk3lf Registered User Join Date: Jul 2015 Location: Novi Sad, Serbia Posts: 1,645	@Ricardo Just Wow! Man, my thread is not worthy of such detailed reply, when I am sure many people that are on coders podforum would die to hear these tips and tricks. I don't beleave they often visit this podforum, unfortunately. However, I got 2 questions (one on topic, second off topic) 1) Do you think (with today technology) is better that I keep both background and character sprite on one image (16 million colors), and then to convert it to 32 colors, then make 2 images (sprite and tiles) out of that. Or... make 2 images (sprite and tiles). And both convert to 16 colors. Or you think it's different from case to case, and depends on project overall? 2) I am not sure how much you are aware, but Final Fight conversion (by Richard Aplin) for the Amiga is considered by many (maybe 80-90%), a very bad port. Maybe not because of the graphics conversion so much, but much more because of the bad gameplay feel. Yet, you did port of games that are no less challenging (to say at least), like MK 1 and 2, and Golden Axe (that is considered best beat em up for the Amiga). What's your thoughts on this? Do you think you could do better job on FF port? I saw in some interview that Richard claims that no one could do a better job on that, and I am not sure I can agreed with him. (but, to be fair, I must say also, that he (totally alone) did all the stuff in 6 month, and FF worked on unexpanded A500 512k) I'd like to hear your thoughts on this. It's unfortunate, that besides Golden Axe, we don't have any beat em up on Amiga, and even Golden Axe (imho), arcade version, is not really that well done in gameplay feel (like arcade Final Fight, Captain Commando, Punisher, Cadillacs and Dinosaurs... etc) @MigaTech Thanks a lot man, but what you are saying is waaaaaay overestimating my skills. Team 17 is like Blizzard for the Amiga, and my skills on RedPill are not in pair with poorest of poorest coder in the world. I also struggle very much with graphics (that's why I opened this thread )

08 January 2019, 16:03	#33
d4rk3lf Registered User Join Date: Jul 2015 Location: Novi Sad, Serbia Posts: 1,645	Ok, time for update. Meet our first enemy: Malko (before apocalypse he was a talented lawyer, but with terrible marriage experience. The nukes leaves so bad looking scars on him, that some people thought that he is a zombie. The burning of his body outside, releases his inner rage, and he is now a machine of robbing and raping survivors. He start chasing our heroine) screenshot: Here you can see him in action. So far, I managed to make him, follow the main character: [ Show youtube player ]

09 January 2019, 09:14	#40
Hewitson Registered User Join Date: Feb 2007 Location: Melbourne, Australia Age: 41 Posts: 3,771	Great work so far. But to me those sprites look a bit odd on that background. I really think you'd be much better off finding someone to recreate those sprites instead of trying to convert them from a high resolution 3D model.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)