How graphics are stored in games?

Brick Nash · 25 May 2016, 12:19

Hi folks,

I'm considering trying my hand at a game in the (distant) future but first I'm trying to understand how the Amiga works at storage etc. on a basic level.

For example I know that graphics such as sprites are stored in 16x16 tiles like below (Plundered from Codetapper's site) -

What I want to know is are the graphics drawn as a whole and then split up into these tiles by hand in DPaint and then assigned numbers/addresses or do you just draw them as a whole and then the Amiga simply stores them this way automatically in a certain format. I've notice the extensions .mps and .sms used when I look at some disks.

Would there be a maximum number of tiles that could be stored in one block like in the picture (255 say) and are the tiles called apon by their memory address or given another tag in whatever code is use?

Sorry for the basic question but I'm just trying to ease my brain into it all with simple questions. I'm trying to get familiar with Planar terms but just an overall broad questions will do for now.

Many thanks!

Steve T · 25 May 2016, 20:54

Quote:

Originally Posted by Brick Nash

What I want to know is are the graphics drawn as a whole and then split up into these tiles by hand in DPaint and then assigned numbers/addresses or do you just draw them as a whole and then the Amiga simply stores them this way automatically in a certain format.

I don't know much beyond art asset creation, but I think in that specific example you're just looking at the product of an artists work to accomplish a certain size of character within a certain area of bitmap. Drawn whole then broken up into game friendly chunks, the artist or programmer would define the tile areas (i guess you could do this with some level of automation) which are stored as additional information and the Amiga instructed what do from there to make them appear in the game as required.

gimbal · 25 May 2016, 21:33

You should have posted this in the programming section I think, you'd get far more eyes than in the off-topic section - for this on-topic question!

Brick Nash · 25 May 2016, 22:13

Thanks for the replies folks.

I sort of assumed that the graphics would be drawn whole and then chopped but I just wanted to make sure as I know in some games like First Samurai they were actually drawn specifically to the tile boxes.

And yes I think I am in the wrong area. I don't want to double post so if any admins out there could move my question that would be great!

Mrs Beanbag · 25 May 2016, 22:19

it is entirely up to the programmer how the graphics are stored in memory and on disk, every game has its own unique requirements. Sometimes tiles are used (usually for scrolling backgrounds) sometimes "sprite sheets" are used (a big image with all the sprites on, which may or may not be on a grid like a tileset), or each sprite image could be stored independently.

On disk storage can use various sorts of compression algorithm that the programmer can devise, such as "run length encoding" (as used in most image formats such as gif, png, iff-ilbm &c) or block-based compression like AMOS uses. On top of that some generic data compression can be applied, such as Powerpacker or a hand-rolled variation of the same.

Brick Nash · 26 May 2016, 19:51

That's great Mrs Beanbag, I was unsure if it was a developer's choice or it was just how the Amiga read graphics in general as I've heard the 16x16 thing quite a lot and I just assumed it was how the hardware operated by reading things in those chunks and so anything bigger would need to be tiled.

I'm assuming if they are there will be custom 'sprite builder' routines by the programmer which will piece together the tiles before they are assigned to the object.

I'm having a go at Amos right now and learning quite a lot, especially about Bobs and Sprites and it seems like sprites are the ones that tend to get chopped up and hence are more fiddly to use but save on memory.

You mentioned tiles are used for scrolling backgrounds, I take it it just saves loads of memory having tiles rather than just one big background block or it makes scrolling easier?

I'm far from making my own game but tricks and memory saving things like this interest me and it's great to know for future reference.

Mrs Beanbag · 26 May 2016, 20:39

yes indeed, by using a level constructed out of tiles (16x16 is the most common but any other size is possible, 32x32 is also occasionally used), one can have a level that is many screens wide and/or high without needing to use large amounts of RAM; the backgrounds are continuously drawn as the screen is scrolled along. Memory is linear and all Chip memory can be used for anything; there is no special "screen" or "sprite" memory as such, so the programmer decides on the layout. A scrolling game with a level that is only two or three screens wide might just use a big screen that it pans across. James Pond II: Robocod renders an entire level to one big screen IIRC, but it is still stored as tiles to save disk space. If graphics data were stored uncompressed on a floppy disk you would only fit 22 screens worth (of 16 colours) on a single floppy! It also makes designing a big level much easier, as it also includes information about whether each tile is solid, climbable, deadly &c.

Hardware sprites on OCS/ECS machines can only be 16 pixels wide but can be any height, if you need wider sprites you have to place two or more side-by-side. They can still be stored on disk as one piece though, and split up by software for drawing on the screen.

Bobs can be any size at all, although typically they are multiples of 16 pixels wide because the Blitter can only copy data at multiples of 16 bits so if you don't use them all it might seem like a waste.

Some game like Street Fighter has very large player sprites (actually Bobs) but maybe they split them up to avoid having to blit blank portions of the image as a performance optimisation.

Codetapper · 26 May 2016, 21:01

Quote:

Originally Posted by Mrs Beanbag

Some game like Street Fighter has very large player sprites (actually Bobs) but maybe they split them up to avoid having to blit blank portions of the image as a performance optimisation.

Street Fighter is a great example of how inefficient and stupid you can be storing graphics. Tiertex strikes again!

Mrs Beanbag · 26 May 2016, 21:43

oh i see, above graphics are from Final Fight, fair enough... i'll be honest i don't know one fighting game from another, not my scene, but maybe you can explain the mangled arrangement.

By looking it seems they split each sprite into 16-pixel high strips of variable width, i would guess this saves on both blitter time and memory.

prowler · 26 May 2016, 21:56

Quote:

Originally Posted by gimbal

You should have posted this in the programming section I think, you'd get far more eyes than in the off-topic section - for this on-topic question!

Quote:

Originally Posted by Brick Nash

And yes I think I am in the wrong area. I don't want to double post so if any admins out there could move my question that would be great!

Thread moved.

Brick Nash · 26 May 2016, 22:58

Thanks Prowler!

Wow, this is a ton of good and clear information. I realise I now have two question in this section about roughly the same thing but one is about sprites/bobs and one is about backgrounds so I think I'm ok.

I'm a big fan of fighting games particularly Final Fight and Street Fighter. Both of those didn't do that well on the Amiga. Street Fighter was indeed dreadful.

Final Fight was technically really good but it was a complete bare arsed skeleton of a game.

It's scrolling brawlers like that which I'd eventually like to have a go at so finding out about stuff like this where the graphics are concerned and how they are put together to work with scrolling is gold!

idrougge · 27 May 2016, 11:36

Look up Leathered's Final Fight AGA thread to learn more about the Amiga's limitations when it comes to beat'em'ups.

Brick Nash · 27 May 2016, 12:24

Quote:

Originally Posted by idrougge

Look up Leathered's Final Fight AGA thread to learn more about the Amiga's limitations when it comes to beat'em'ups.

I've actually been reading that thread recently. It's cool to see that Richard Aplin the programmer of the US Gold Amiga Port gave so much information.

I think Leathered did his version in Blitz Basic but I've just started learning Amos because it was the first one I came across but I'm wondering which would be better for a game of this sort as I've heard Amos isn't as flexible compared to Blitz but that it's easier to learn and more reliable.

I wouldn't like to get to the stage where I'm confident enough to try to write a game and then find out some limitations of Amos wouldn't let me.

sandruzzo · 30 May 2016, 07:18

About Final Fight Amiga Ecs, it is the real Amiga limit, or lazy programmers? Would be great to see if ECS/OCS can move all that Gfx with better colors and better velocity

roondar · 30 May 2016, 10:26

I haven't looked at the Final Fight Amiga code, but it does have pretty big bobs and lots of them. I wouldn't be surprised if the slowness is mostly due to the Blitter not being fast enough to deal with all the bobs and not due to programmers being 'lazy'.

idrougge · 30 May 2016, 11:26

Quote:

Originally Posted by Brick Nash

I wouldn't like to get to the stage where I'm confident enough to try to write a game and then find out some limitations of Amos wouldn't let me.

That's exactly the stage you do want to get to. By then, you have reached a sufficient level to know what you're doing.

dlfrsilver · 30 May 2016, 12:14

To answer about the graphics storage, they can be stored as tiles (Final Fight), bitmap images (Simpsons, Double dragon III), In Atari ST graphic format or Amiga, or even PC format ! (yeah yeah, don't say it's untrue, it has been verified!).

For instance, games like Alien Breed Tower Assault and Parasol Stars stores their sprites/graphics on disk in PC chunky format, which is then converted on the fly in planar mode. Ahah

Just to avoid people lurking with their greasy hands on the disk contents !

sandruzzo · 30 May 2016, 14:31

Quote:

Originally Posted by roondar

I haven't looked at the Final Fight Amiga code, but it does have pretty big bobs and lots of them. I wouldn't be surprised if the slowness is mostly due to the Blitter not being fast enough to deal with all the bobs and not due to programmers being 'lazy'.

In fact, i did a question not a statemant. Would be great to test all that amount of bobs!

Mrs Beanbag · 30 May 2016, 20:13

it seems funny to call chunky-pixels "PC format" since they are the norm on plenty of other systems too, and if it's just file formats you can store anything how you like! Chunky pixels format is more friendly to techniques like Run Length Encoding, i use this myself in my own file formats. I've pondered using PNG myself in future productions because it's ubiquitous and actually very good for this kind of graphics (much better compression than ILBM).

roondar · 30 May 2016, 21:24

Quote:

Originally Posted by sandruzzo

In fact, i did a question not a statemant. Would be great to test all that amount of bobs!

Yeah, sorry about that.

Been reading far too many posts with people claiming any and all Amiga games that had shortcomings always had them due to developer laziness.

25 May 2016, 12:19	#1
Brick Nash Prototron Join Date: Mar 2015 Location: Glasgow, Scotland Posts: 420	How graphics are stored in games? Hi folks, I'm considering trying my hand at a game in the (distant) future but first I'm trying to understand how the Amiga works at storage etc. on a basic level. For example I know that graphics such as sprites are stored in 16x16 tiles like below (Plundered from Codetapper's site) - What I want to know is are the graphics drawn as a whole and then split up into these tiles by hand in DPaint and then assigned numbers/addresses or do you just draw them as a whole and then the Amiga simply stores them this way automatically in a certain format. I've notice the extensions .mps and .sms used when I look at some disks. Would there be a maximum number of tiles that could be stored in one block like in the picture (255 say) and are the tiles called apon by their memory address or given another tag in whatever code is use? Sorry for the basic question but I'm just trying to ease my brain into it all with simple questions. I'm trying to get familiar with Planar terms but just an overall broad questions will do for now. Many thanks!

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
demos with graphics from games?	s2325	request.Demos	72	11 January 2017 16:12
Powering up a stored a500	MoreBITS	support.Hardware	8	07 December 2011 18:26
Vector graphics games (ok, other games too...) with great INGAME(!) music?	dex	Nostalgia & memories	22	27 August 2011 15:57
Where are icons stored in workbench?	gmiaow	New to Emulation or Amiga scene	8	11 December 2008 20:36
What's stored in the UAEFSDB file?	Bloodwych	support.WinUAE	2	20 June 2002 18:24

25 May 2016, 21:33	#3
gimbal cheeky scoundrel Join Date: Nov 2004 Location: Spijkenisse/Netherlands Age: 42 Posts: 6,946	You should have posted this in the programming section I think, you'd get far more eyes than in the off-topic section - for this on-topic question!

25 May 2016, 22:13	#4
Brick Nash Prototron Join Date: Mar 2015 Location: Glasgow, Scotland Posts: 420	Thanks for the replies folks. I sort of assumed that the graphics would be drawn whole and then chopped but I just wanted to make sure as I know in some games like First Samurai they were actually drawn specifically to the tile boxes. And yes I think I am in the wrong area. I don't want to double post so if any admins out there could move my question that would be great!

25 May 2016, 22:19	#5
Mrs Beanbag Glastonbridge Software Join Date: Jan 2012 Location: Edinburgh/Scotland Posts: 2,243	it is entirely up to the programmer how the graphics are stored in memory and on disk, every game has its own unique requirements. Sometimes tiles are used (usually for scrolling backgrounds) sometimes "sprite sheets" are used (a big image with all the sprites on, which may or may not be on a grid like a tileset), or each sprite image could be stored independently. On disk storage can use various sorts of compression algorithm that the programmer can devise, such as "run length encoding" (as used in most image formats such as gif, png, iff-ilbm &c) or block-based compression like AMOS uses. On top of that some generic data compression can be applied, such as Powerpacker or a hand-rolled variation of the same.

26 May 2016, 19:51	#6
Brick Nash Prototron Join Date: Mar 2015 Location: Glasgow, Scotland Posts: 420	That's great Mrs Beanbag, I was unsure if it was a developer's choice or it was just how the Amiga read graphics in general as I've heard the 16x16 thing quite a lot and I just assumed it was how the hardware operated by reading things in those chunks and so anything bigger would need to be tiled. I'm assuming if they are there will be custom 'sprite builder' routines by the programmer which will piece together the tiles before they are assigned to the object. I'm having a go at Amos right now and learning quite a lot, especially about Bobs and Sprites and it seems like sprites are the ones that tend to get chopped up and hence are more fiddly to use but save on memory. You mentioned tiles are used for scrolling backgrounds, I take it it just saves loads of memory having tiles rather than just one big background block or it makes scrolling easier? I'm far from making my own game but tricks and memory saving things like this interest me and it's great to know for future reference.

26 May 2016, 20:39	#7
Mrs Beanbag Glastonbridge Software Join Date: Jan 2012 Location: Edinburgh/Scotland Posts: 2,243	yes indeed, by using a level constructed out of tiles (16x16 is the most common but any other size is possible, 32x32 is also occasionally used), one can have a level that is many screens wide and/or high without needing to use large amounts of RAM; the backgrounds are continuously drawn as the screen is scrolled along. Memory is linear and all Chip memory can be used for anything; there is no special "screen" or "sprite" memory as such, so the programmer decides on the layout. A scrolling game with a level that is only two or three screens wide might just use a big screen that it pans across. James Pond II: Robocod renders an entire level to one big screen IIRC, but it is still stored as tiles to save disk space. If graphics data were stored uncompressed on a floppy disk you would only fit 22 screens worth (of 16 colours) on a single floppy! It also makes designing a big level much easier, as it also includes information about whether each tile is solid, climbable, deadly &c. Hardware sprites on OCS/ECS machines can only be 16 pixels wide but can be any height, if you need wider sprites you have to place two or more side-by-side. They can still be stored on disk as one piece though, and split up by software for drawing on the screen. Bobs can be any size at all, although typically they are multiples of 16 pixels wide because the Blitter can only copy data at multiples of 16 bits so if you don't use them all it might seem like a waste. Some game like Street Fighter has very large player sprites (actually Bobs) but maybe they split them up to avoid having to blit blank portions of the image as a performance optimisation.

26 May 2016, 21:43	#9
Mrs Beanbag Glastonbridge Software Join Date: Jan 2012 Location: Edinburgh/Scotland Posts: 2,243	oh i see, above graphics are from Final Fight, fair enough... i'll be honest i don't know one fighting game from another, not my scene, but maybe you can explain the mangled arrangement. By looking it seems they split each sprite into 16-pixel high strips of variable width, i would guess this saves on both blitter time and memory.

26 May 2016, 22:58	#11
Brick Nash Prototron Join Date: Mar 2015 Location: Glasgow, Scotland Posts: 420	Thanks Prowler! Wow, this is a ton of good and clear information. I realise I now have two question in this section about roughly the same thing but one is about sprites/bobs and one is about backgrounds so I think I'm ok. I'm a big fan of fighting games particularly Final Fight and Street Fighter. Both of those didn't do that well on the Amiga. Street Fighter was indeed dreadful. Final Fight was technically really good but it was a complete bare arsed skeleton of a game. It's scrolling brawlers like that which I'd eventually like to have a go at so finding out about stuff like this where the graphics are concerned and how they are put together to work with scrolling is gold!

27 May 2016, 11:36	#12
idrougge Registered User Join Date: Sep 2007 Location: Stockholm Posts: 4,342	Look up Leathered's Final Fight AGA thread to learn more about the Amiga's limitations when it comes to beat'em'ups.

30 May 2016, 07:18	#14
sandruzzo Registered User Join Date: Feb 2011 Location: Italy/Rome Posts: 2,344	About Final Fight Amiga Ecs, it is the real Amiga limit, or lazy programmers? Would be great to see if ECS/OCS can move all that Gfx with better colors and better velocity

30 May 2016, 10:26	#15
roondar Registered User Join Date: Jul 2015 Location: The Netherlands Posts: 3,423	I haven't looked at the Final Fight Amiga code, but it does have pretty big bobs and lots of them. I wouldn't be surprised if the slowness is mostly due to the Blitter not being fast enough to deal with all the bobs and not due to programmers being 'lazy'.

30 May 2016, 12:14	#17
dlfrsilver CaptainM68K-SPS France Join Date: Dec 2004 Location: Melun nearby Paris/France Age: 46 Posts: 10,474	To answer about the graphics storage, they can be stored as tiles (Final Fight), bitmap images (Simpsons, Double dragon III), In Atari ST graphic format or Amiga, or even PC format ! (yeah yeah, don't say it's untrue, it has been verified!). For instance, games like Alien Breed Tower Assault and Parasol Stars stores their sprites/graphics on disk in PC chunky format, which is then converted on the fly in planar mode. Ahah Just to avoid people lurking with their greasy hands on the disk contents !

30 May 2016, 20:13	#19
Mrs Beanbag Glastonbridge Software Join Date: Jan 2012 Location: Edinburgh/Scotland Posts: 2,243	it seems funny to call chunky-pixels "PC format" since they are the norm on plenty of other systems too, and if it's just file formats you can store anything how you like! Chunky pixels format is more friendly to techniques like Run Length Encoding, i use this myself in my own file formats. I've pondered using PNG myself in future productions because it's ubiquitous and actually very good for this kind of graphics (much better compression than ILBM).

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