English Amiga Board


Go Back   English Amiga Board > Other Projects > project.Amiga Game Factory

 
 
Thread Tools
Old 30 January 2020, 00:57   #61
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,638
Quote:
Originally Posted by Galahad/FLT View Post
I think there are more 512kchip/512kslow machines than there are 1meg chip.

1Meg chip came with the later 1.3 Kickstart about 6 months before the A500+ came out I think.
To be honest, it doesn't matter - the goal is to beat Tiertex with a stock Amiga ... no ram expansion.
mcgeezer is offline  
Old 30 January 2020, 10:41   #62
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 1,261
I'd try to get rid of every second animation frame.

Most of these seem superflous. Looks good while animating, but not really needed.
Steril707 is offline  
Old 30 January 2020, 12:34   #63
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,614
Quote:
Originally Posted by Steril707 View Post
I'd try to get rid of every second animation frame.

Most of these seem superflous. Looks good while animating, but not really needed.
Seems like a good start to me. Compromises need to be made for most ports and this sounds like a good idea!

Alternatively, you could create a more complicated animation system where you only keep the changes between frames in memory or some such solution. Or perhaps use a more console style "tile based" animation system. Not saying it'll definitely fit, or even that it's easy to do so. But I think you might not actually need to keep all that animation data in memory at all times in the form of full frames.

Obviously such systems will add CPU/Blitter overhead. Swings and roundabouts.

For a more extreme solution, you could even look into a single buffered game. This will obviously be quite hard to do (may even be impossible), but if you can somehow guarantee you won't overrun a frame it may just be doable. Would save a ton of memory.
roondar is offline  
Old 30 January 2020, 12:56   #64
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 1,261
Quote:
Originally Posted by Asman View Post
@saimon69
blit 1 - block0,
blit 2 - block1,
blit 3 - block2,
blit 4 - block3

If you change order of blocks then you will have enemy with differ colors
blit 1 - block1,
blit 2 - block0,
blit 3 - block2,
blit 4 - block3
I didn't know that one.. Thanks, Asman!
Steril707 is offline  
Old 30 January 2020, 14:16   #65
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 418
Here is one palette trick that might work. This is how it's done in Blitz Basic, but surely ASM can do it also.

Use a 32 color palette and split it in two parts: enemy colors and background colors.

And then split the 16 enemy colors into Even and Odd colors, which contain two 8 color palettes for two different enemies. The first enemy uses Even colors and the second enemy uses Odd colors.

And then make two objects: one 4 bitplane enemy, that uses the Even colors only, and another "enemy" that is a solid color 1 bitplane BOB.

And after this, blitting the 4 bitplane enemy alone will make it appear in Even colors, and when you blit the 1 bitplane bob on top of it, the Even colors will change to Odd colors.

And at any time during the gameplay, you can change either the Odd or Even colors, or both, to activate more color schemes. And because the rest of the graphics will be in the other palette part, they won't be affected by this.

Although only two enemy color schemes can be active at the same time, but it shouldn't matter that much; enemies die and re-appear at a fast pace, and at those spots you can change either the Even or Odd colors.

Here is an image that shows how it works:




In that image I used the Tiertex graphics, because they were easy to convert into two sets of 8 colors. But this system should also work for the arcade assets, although then you might need to expand the "enemy palette" part into the other palette half to get more colors, which makes the enemy BOB to have 5 bitplanes. But the trick will still work in the same way.

Also this 1 bitplane bob trick will only alter Even colors, Odd colors won't change. So it's easy to take some Odd colors from the background palette part, such as some general purpose grays, and use them in the enemies.

So you only need one set of 4 or 5 bitplane enemy frames + one set of solid color 1 bitplane enemy frames to do every possible enemy color scheme, which should save a ton of chip RAM.
Attached Thumbnails
Click image for larger version

Name:	RTPaletteSwapV2.png
Views:	232
Size:	3.5 KB
ID:	66049  
Master484 is offline  
Old 30 January 2020, 16:46   #66
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,638
@Master484

So yes this is similar to what I'm thinking and I keep coming back to it.

I'll have a 5 bitplane display. I'll use 16 colours of the available 32, different enemy colour will correspond to the bitmap selection as I choose below.

Code:
Bit	1	2	3	4	5
Val	1	2	4	8	16
Colours	0-1	2-3	4-7	8-15	16-31
					
Enemy 1	0	1	1	1	1
Enemy 2	1	0	1	1	1
Enemy 3	1	1	0	1	1
Enemy 4	1	1	1	0	1
Enemy 5	1	1	1	1	0
This should yield the following available palettes in the colours registers.

Code:
Register	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
Enemy 1=	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y
Enemy 2=	Y	Y	N	N	Y	Y	N	N	Y	Y	N	N	Y	Y	N	N	Y	Y	N	N	Y	Y	N	N	Y	Y	N	N	Y	Y	N	N
Enemy 3=	Y	Y	Y	Y	N	N	N	N	Y	Y	Y	Y	N	N	N	N	Y	Y	Y	Y	N	N	N	N	Y	Y	Y	Y	N	N	N	N
Enemy 4=	Y	Y	Y	Y	Y	Y	Y	Y	N	N	N	N	N	N	N	N	Y	Y	Y	Y	Y	Y	Y	Y	N	N	N	N	N	N	N	N
Enemy 5=	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N
Each enemy type I'll just blit the required 4 bitplanes, it won't be the fastest method as I prefer to do one shot blits with full interleaved masks but this is a compromise.

The other compromises I will do are to hold the death frames of the main guy in fast ram and use a CPU sprite based copy when needed which is only when the guy dies. The other compromise is to hold the tiles in slow ram and cpu copy those too.

My calcs are roughly like this...
Chip ram
135Kb CHIP Triple Screen buffer (45kb * 3)
60Kb CHIP Main Dude Bobs+Mask
140Kb CHIP Enemies Bobs+Mask
80Kb CHIP Mod
40Kb CHIP SFX
2Kb CHIP COPPER
30Kb CHIP Hardware Sprites for Fences/Mesh Bob/Mask
487Kb Total

120Kb FAST Game Tiles
40Kb FAST Main Dude Death Bobs+Masks
50Kb FAST Evil Due Bobs+Masks
80Kb FAST Game Code/Data
290Kb Fast

All guestimates but I think it will work.
mcgeezer is offline  
Old 30 January 2020, 19:10   #67
redblade
Zone Friend

redblade's Avatar
 
Join Date: Mar 2004
Location: Middle Earth
Age: 35
Posts: 1,419
Quote:
Originally Posted by mcgeezer View Post
I cant port something that will run at 25fps.
Is that your company motto?

[QUOTE=Master484;1374909]And about the enemy graphics, them I would handle this way: for most frames I would separate the boots from the main body. The reason is that the boots can be made with 3 colors, so they can be 2 bitplane BOBs. Every enemy will then use these same boots. This in a way "shortens" the enemy graphics height by some 10 pixels. And for the rest of the body I would try to make a unified 8 color palette for all enemy types, if possible.

Also when the enemies die, this I would simplify by using only 3 shades of gray for all those frames when the enemy "melts" into the ground, so that all enemies can then use this same death animation. And also the player's pants I would make with those same 3 shades of gray. This would make about half of the player a 2 bitplane BOB, saving a lot of chip RAM.

And sprites I would maybe use for the bullets, in combination of BOBs if all sprites are already in use. Or maybe sprites could be used to bring more color to the backgrounds if the game uses 16 color mode. The ceiling fans could be sprites, or maybe the sprites could be behind the playfield, and used for the opening doors, or stuff like that. And I think some enemy types never go behind the fences or come from doors...so they could be sprites.

Quote:
Originally Posted by Asman View Post
@saimon69
Great example to explain how save memory for enemy sprites.
as far as I remember all four enemies from your screenshots share the same frames but differ colours. Its very easy to do this on Amiga. One enemy frame has 32x64x4 stored as four 1 bpl frames/blocks (as sequence), frame = 4 blocks (block0, block1, block2, block3), more technically there are four memory blocks 32x64 pixels ( 4 * 64 = 256 bytes). So enemy frame takes 1024 bytes. Of course you need mask which takes 256 bytes. To blit enemy you need 4 blits.
blit 1 - block0,
blit 2 - block1,
blit 3 - block2,
blit 4 - block3

If you change order of blocks then you will have enemy with differ colors
blit 1 - block1,
blit 2 - block0,
blit 3 - block2,
blit 4 - block3

But I am pretty sure that trick is well known for programmers But the problem is to organize colors in proper way, I think.

Even with this idea I am think that 512KB CHIP is not enough. Too many objects with many frames, especially I mean about later levels when objects with differ levels are mixed.
Quote:
Originally Posted by Master484 View Post
Here is one palette trick that might work. This is how it's done in Blitz Basic, but surely ASM can do it also.

Use a 32 color palette and split it in two parts: enemy colors and background colors.

And then split the 16 enemy colors into Even and Odd colors, which contain two 8 color palettes for two different enemies. The first enemy uses Even colors and the second enemy uses Odd colors.

And then make two objects: one 4 bitplane enemy, that uses the Even colors only, and another "enemy" that is a solid color 1 bitplane BOB.

And after this, blitting the 4 bitplane enemy alone will make it appear in Even colors, and when you blit the 1 bitplane bob on top of it, the Even colors will change to Odd colors.

And at any time during the gameplay, you can change either the Odd or Even colors, or both, to activate more color schemes. And because the rest of the graphics will be in the other palette part, they won't be affected by this.

Although only two enemy color schemes can be active at the same time, but it shouldn't matter that much; enemies die and re-appear at a fast pace, and at those spots you can change either the Even or Odd colors.

Here is an image that shows how it works:




In that image I used the Tiertex graphics, because they were easy to convert into two sets of 8 colors. But this system should also work for the arcade assets, although then you might need to expand the "enemy palette" part into the other palette half to get more colors, which makes the enemy BOB to have 5 bitplanes. But the trick will still work in the same way.

Also this 1 bitplane bob trick will only alter Even colors, Odd colors won't change. So it's easy to take some Odd colors from the background palette part, such as some general purpose grays, and use them in the enemies.

So you only need one set of 4 or 5 bitplane enemy frames + one set of solid color 1 bitplane enemy frames to do every possible enemy color scheme, which should save a ton of chip RAM.
Thanks for that guys, interesting tutorial on palette selection there.
redblade is offline  
Old 30 January 2020, 22:30   #68
saimon69
J.M.D - Bedroom Musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 1,257
Quote:
Originally Posted by Master484 View Post
Here is one palette trick that might work. This is how it's done in Blitz Basic, but surely ASM can do it also.

Use a 32 color palette and split it in two parts: enemy colors and background colors.

And then split the 16 enemy colors into Even and Odd colors, which contain two 8 color palettes for two different enemies. The first enemy uses Even colors and the second enemy uses Odd colors.

And then make two objects: one 4 bitplane enemy, that uses the Even colors only, and another "enemy" that is a solid color 1 bitplane BOB.

And after this, blitting the 4 bitplane enemy alone will make it appear in Even colors, and when you blit the 1 bitplane bob on top of it, the Even colors will change to Odd colors.

And at any time during the gameplay, you can change either the Odd or Even colors, or both, to activate more color schemes. And because the rest of the graphics will be in the other palette part, they won't be affected by this.

Although only two enemy color schemes can be active at the same time, but it shouldn't matter that much; enemies die and re-appear at a fast pace, and at those spots you can change either the Even or Odd colors.

[snip]

Also this 1 bitplane bob trick will only alter Even colors, Odd colors won't change. So it's easy to take some Odd colors from the background palette part, such as some general purpose grays, and use them in the enemies.

So you only need one set of 4 or 5 bitplane enemy frames + one set of solid color 1 bitplane enemy frames to do every possible enemy color scheme, which should save a ton of chip RAM.
Once again, one of the tricks appeared in Powder, but there we were using just four bitplanes
saimon69 is offline  
Old 30 January 2020, 23:16   #69
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,614
Out of interest (and because I still think it can apply here as well): did Amiga games actually use "partial*" animations?
Or did everyone just store full frames of animation?

It seems such a logical way to save space, yet I never seem to hear much about it.

*) meaning, keeping only the part that actually changes in memory and then updating the bob using just those small parts? Or building a bob out of smaller chunks instead of having full images? Or perhaps go full-on-tile based and blit bobs based on 16x16 chunks? Or some other way to build bobs up in several stages to save memory?

Stuff like that.

Last edited by roondar; 30 January 2020 at 23:44.
roondar is offline  
Old 31 January 2020, 04:58   #70
lmimmfn
Registered User

 
Join Date: May 2018
Location: Mullingar
Posts: 68
Quote:
Originally Posted by Galahad/FLT View Post
I think there are more 512kchip/512kslow machines than there are 1meg chip.

1Meg chip came with the later 1.3 Kickstart about 6 months before the A500+ came out I think.
I can't remember the Release date of the a500+ but I got my A500 in October 1990( Screen Gems pack) and it had 1 Meg chip when I added a 2 MB expansion card.

My own experience in general coding is the more optimization required the more time consuming it is.

Would prefer if possible to target 1MB A500 with a view to scaling back for 512MB A500 with another 512MB slow ram, I. E. Simplest form half the framerate and only show half the sprite/Bob animations.
Only my opinion though and I know the difficulty and appreciate that this may finally happen
lmimmfn is offline  
Old 31 January 2020, 12:05   #71
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 45
Posts: 1,336
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by roondar View Post
Out of interest (and because I still think it can apply here as well): did Amiga games actually use "partial*" animations?
Or did everyone just store full frames of animation?

It seems such a logical way to save space, yet I never seem to hear much about it.

*) meaning, keeping only the part that actually changes in memory and then updating the bob using just those small parts? Or building a bob out of smaller chunks instead of having full images? Or perhaps go full-on-tile based and blit bobs based on 16x16 chunks? Or some other way to build bobs up in several stages to save memory?

Stuff like that.
Metro Siege uses partial animation bobs using an old version of Spriter for the part alignment editing.
Samurai_Crow is offline  
Old 31 January 2020, 12:23   #72
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 1,261
I second that, really insightful stuff here.
Always wondered how I'd do different colors for players in a fighting game with each selecting the same fighter without keeping two copies of the same player in RAM.

This is the solution..
Steril707 is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Rolling Thunder Dustyarddog Games images which need to be WHDified 5 30 January 2020 22:24
New Sh*t Game Time video: Rolling Thunder (Amiga) ZEUSDAZ Retrogaming General Discussion 5 11 April 2017 01:56
Rolling Thunder vs Thunder Jaws Solo Kazuki HOL data problems 1 20 June 2016 08:09
Rolling Thunder ++ sareks support.Games 9 16 September 2010 18:09
Rolling Thunder NfernalNfluence support.Games 31 05 August 2008 14:42

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 09:46.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.07897 seconds with 14 queries