Developing a versus fighter for the OCS

CMA Death Adder · 18 July 2010, 13:47

Hello, everyone.

My name is Brandon Cobb; president of Super Fighter Team, a producer of new games for classic video game systems. Recently I have come into possession of an Amiga 2000HD and would like to see it put to some good use.

One project we are working on at the moment is a bug-fix and overall improvement to the code of Sango Fighter, a versus fighter for the PC (DOS). The original game code is x86 assembly; we plan to adapt this code to other machines once our additions to it are complete. The Amiga is one platform I'd like to consider, but the goal would be to produce the game for the OCS, thus ensuring compability for all Amiga owners, and giving me the opportunity to test the game without having to buy additional hardware.

I have some questions in regard to this idea, which I would appreciate detailed answers to (the more detail the better). From what I understand, to produce the game for the OCS we:

* Would be limited to no more than 32 colors on screen at once, at a resolution of 320x200. However, is this 32 color limit a "global" restriction? I.E. - would we simply have ONE palette in use at any given time, which applies to the entire screen and everything on it (backgrounds, sprites, energy bars, etc.)? Or would we be looking at separate palettes of less than 32 colors for the different on-screen elements?

* Would require the user to have at least 1MB of RAM in their machine.

* Would need to ensure compatibility with AGA machines.

Could we truly hope to achieve a smooth-running, enjoyable gameplay experience on an OCS machine with 1MB of RAM, if the game were tightly coded in assembly by someone who knew his way around the hardware?

What other considerations should we be expected to make? What sacrifices, if any (aside from downscaling the color depth of the graphics), would we have to concern ourselves with?

Any feedback appreciated. Thank you.

Retro1234 · 18 July 2010, 14:01

If you check out games like shadow fighter and fightin spirit it suggests that such a conversion would be possible - It realy would be nice to have a decent Beat Em up

I know nothing of assembly and sure others around here could give you better info.

Nice Project and welcome to EAB

Steve · 18 July 2010, 15:38

Hardware Reference Manual: http://amiga-manuals.xiik.net/other/...Manual-ENG.pdf

This should tell you all you need to know about the OCS and ECS hardware.

The hardware is very capable indeed. Checkout 'Elfmania' which uses 32 colours and looks darn impressive:

http://hol.abime.net/2832/screenshot

Also 'Shadow Fighter' for the A1200

http://hol.abime.net/1889/screenshot

and A500

http://hol.abime.net/1888/screenshot

Personally for this project I would use the best standard hardware available which is an A1200 with 2MB of RAM and allows for 256 on-screen colours. Writing an A500 version is pretty pointless IMHO.

Thorham · 18 July 2010, 19:03

Quote:

Originally Posted by CMA Death Adder

* Would be limited to no more than 32 colors on screen at once, at a resolution of 320x200. However, is this 32 color limit a "global" restriction? I.E. - would we simply have ONE palette in use at any given time, which applies to the entire screen and everything on it (backgrounds, sprites, energy bars, etc.)? Or would we be looking at separate palettes of less than 32 colors for the different on-screen elements?

You can change 15 colors in the border on OCS machines per scan line, so you can have separate screen elements have different colors.

Also, with Extra Half Bright you have 64 colors; 32 definable ones and 32 that are half as bright as the 32 definable ones.

CMA Death Adder · 19 July 2010, 03:49

Hello. Thanks for the bits of info, guys - now I've got a good idea where to start mulling. If I've any additional questions, I'll toss 'em in here; but at this point it's refreshing to learn that a decent conversion to the OCS could be achieved, with the right amount of effort.

Quote:

Originally Posted by Steve

Personally for this project I would use the best standard hardware available which is an A1200 with 2MB of RAM and allows for 256 on-screen colours. Writing an A500 version is pretty pointless IMHO.

I will consider it, but honestly I would prefer to be able to reach as large of an audience as possible, which means starting at the bottom (OCS) and trying to wring the absolute most out of the hardware. The only potential downside I see to this approach is that those using newer machines to play the game wouldn't be as impressed with the downscaled graphics...

Amiga1992 · 19 July 2010, 17:09

The bottom nowadays is an A1200. Developing for OCS will lead you to project cancellation.
If you really want to do OCS you should develop with the A1200 as your base hardware and then make a downscaled OCS version. This is the best way to do things in my opinion since a lot of code will already work and the graphics will be easily converted to use on OCS etc.
Believe me, a 2MB, stock A1200 is enough challenge already.

If you need some help with music or graphics I might be available.

Zetr0 · 19 July 2010, 18:28

since 95% of the Amiga Game Software is OCS/ECS - its the most used chipset.

In regards to OCS/ECS to AGA personally I think that working in such a tight environment (OCS/ECS) should give you the opportunity to improve your skills and techniques - so when coding for AGA (other than a grahpics revision) you should be able to slide a smoother version in without to much fuss.

Amiga1992 · 19 July 2010, 22:42

Quote:

Originally Posted by Zetr0

since 95% of the Amiga Game Software is OCS/ECS - its the most used chipset.

That is not a reflection of the current userbase, it just has to do with what it was BACK THEN.

Quote:

so when coding for AGA (other than a grahpics revision) you should be able to slide a smoother version in without to much fuss.

That's not the way to work at all.
In most every media deployment creation, which includes videogames, you BETTER work with the highest standard and then downgrade to lesser specs.
If you make all your samples for a tune in 22Khz, how are you gonna improve their quality if you want to upscale them? No way, that is. What is lost is lost.

However if you start with the max, you can degrade easily.

Make an AGA version then a cut-down version for OCS. It will be as much of a challenge, if not more.

Photon · 20 July 2010, 01:39

Welcome CMA DA

I think the OCS/AGA choice

could be resolved with a forum poll - not that there aren't a bunch of gamers outside the active Amiga forums. That is, if you want the opinion of many gamers.

I'm a strong supporter of OCS, and understand why you'd want it available for all those A600, A500(+) etc out there.

I think the best way is to just start deving on the machine you have, you know, test convert/fix up some graphics, see how animation routines are working out, etc. You'll soon find out if your vision can come to life or if you have to sacrifice some ideas because you're running out of cycles or something

Then you could get an AGA dev machine and still use the same code.

For me, the biggest problem is the last 5-20% (I have at least 5 games nearly ready for release here...) and getting elbow-deep in it will soon explain which way you should go quite automatically, I think. I wish you the best of luck!

CMA Death Adder · 20 July 2010, 08:05

I believe the biggest problem we'd face would indeed be downscaling the graphics to fit within OCS limitations. Looking over the various versus fighting games available for the machine, the best looking (and performing) of the bunch were designed with these limitations in mind. They look great because their graphics were creatively shaped around what the machine's display could and could not do.

With Sango Fighter, we have a great looking game that was designed around the features of the VGA card: each character uses his own 16-color palette, backgrounds use 100+ colors each, and in cases where a character has a projectile or other energy-based attack, 3 - 4 additional colors over their normal palette are used. This is a lot to consider, with the OCS in mind for a possible adaptation of the game, because while we should be able to get things looking workable on the OCS, they'll never look big and beautiful like game graphics that were specifically designed for the hardware. It stings me a little, because we don't necessarily wish to produce a color-washed version for Amiga owners and in doing so, indirectly be telling them, "If you want it to look better, try it on the PC," especially when there are Amiga machines that could easily reproduce the game's existing graphical quality.

So it is a noodle-scratcher, no question. If there is someone here who has a good deal of experience working with graphics for the OCS hardware who would be interested to rap with me about this situation, that would be nice - just hit me up via private message. There's obviously no need to have anything redrawn; I'd just like to have someone who knows their way around the hardware work out a few color test samples to give me a clearer picture of what we could accomplish.

pandy71 · 20 July 2010, 13:37

Quote:

Originally Posted by CMA Death Adder

I will consider it, but honestly I would prefer to be able to reach as large of an audience as possible, which means starting at the bottom (OCS) and trying to wring the absolute most out of the hardware.

Then use a HAM...

Thorham · 20 July 2010, 13:47

Quote:

Originally Posted by pandy71

Then use a HAM...

HAM is very hard to use in a game like this for unaccelerated OCS Amigas. On AGA machines it's less of an issue because of the wider sprites that are available. Now you can use sprites for the characters and HAM for the background. Not so for OCS/ECS if the characters are too wide.

Leffmann · 20 July 2010, 14:36

Quote:

Originally Posted by CMA Death Adder

* Would be limited to no more than 32 colors on screen at once, at a resolution of 320x200. However, is this 32 color limit a "global" restriction? I.E. - would we simply have ONE palette in use at any given time, which applies to the entire screen and everything on it (backgrounds, sprites, energy bars, etc.)? Or would we be looking at separate palettes of less than 32 colors for the different on-screen elements?

* Would require the user to have at least 1MB of RAM in their machine.

* Would need to ensure compatibility with AGA machines.

I took a look at some screenshots and the color layout seems to be 96 colors for the background and 32 colors among the fighters. I left out the status panel at the bottom because you can have different vertically laid out screens with different colors on the Amiga.

I'm certain that using the 64 color EHB mode on the Amiga you could redraw the backgrounds and also fit the fighter graphics in these 64 colors, and make it look good, but you could never fit all of it into 512 kB of chip memory (think graphics memory). That leaves the A1000, A500 and most of the A2000's out, and so you'd need an A500+, A600, A3000 or any of the AGA machines to run the game. And you'd still have the huge task of redrawing all the graphics by hand because an automatic conversion simply wouldn't do.

So the way I see it is that for the same reason you're not converting the game to EGA because it's just not an EGA game, it's also not viable to convert the game to OCS.

On AGA you have 256 colors, 2 MB graphics memory and better performance, and the machine can output 50 or 60 Hz video signal (I would go with 60 Hz) and is IMO the only choice, and it's perfectly fine to cross develop with WinUAE (no need to get into the very super intricate nitty gritty's of the machine for this) which saves you from buying an actual machine to get started.

pandy71 · 20 July 2010, 15:40

Quote:

Originally Posted by Thorham

HAM is very hard to use in a game like this for unaccelerated OCS Amigas. On AGA machines it's less of an issue because of the wider sprites that are available. Now you can use sprites for the characters and HAM for the background. Not so for OCS/ECS if the characters are too wide.

I see no contradiction - HAM is challenging however it allow fully exploit the hardware - accordingly to

Quote:

Originally Posted by CMA Death Adder

I would prefer to be able to reach as large of an audience as possible, which means starting at the bottom (OCS) and trying to wring the absolute most out of the hardware.

seems to be best solution

fishyfish · 20 July 2010, 15:57

I'm sure some of this is just repeating, but I thought a bit of an overview of ocs/ecs hardware might be of use to you. Firstly you have between one and 5bit color available as "standard" color, but a 6th bit is available in the way of EHB, which is a copy of the 1st 32 colors, but with brightness halved. Also available is a dual playfield mode, with which 2x3bit playfields are available (playfields are seperate bitmaps/viewports with seperate palettes). In addition to this there's 8 hardware sprites which use different color registers 16-31, even if only using 16 colors (or less (or dual playfield)). There's both 4 (3 + transparent) and 16 (15+transparent) color sprites available, but using 16 color sprites the available sprite channels will half. Sprites are 16 pixels wide and as tall as a user wants. It's possible to do some sprite multiplexing as well to have more than 8 on screen at once, but "impossible" to have thier width exceeding 64 or 128 (4 or 16 colors) pixels in width in total along the same vertical line. Additionally it's possible to change palette color registers between scanlines creating a gradient of multiple shades using just one color, as well as being able to use the altered color palette within a bitmap, so you can have a lot more colors onscreen than the screen mode suggests. It's also possible to display multiple "screens" onscreen at once, each with thier own resolution, color depths and palettes, however they need to be seperated by 1 pixel. AGA introduces a few new things, although cripples it's use of some of them too. Firstly there's now 8bit screen depth available, which in turns means there's also 2x16 color playfields available. Sprites are also now available in 32 and 64pixel wide modes, although generally the higher color depth you use the more channels you lose (aga moved everything to the left to a point u cant physically view all sprites)... I'd hazard a guess the best you could get would be maybe 3x16 color sprites on a 6 or 7 bit depth screen. Even though theyre available I wouldnt use 256 colors for AGA in a game of this sort as it'd be too slow without an accelerator of some sort + ram expansion, 64 colors is probably more realistic. I made a quick mockup as to how a 32 color version of your fighter might look without any hardware trickey (although the panel assumes a seperate screen (ergo seperate palette) (really though it could look closer,... I only spent 1/2 an hour on it) .
http://tinypic.com/view.php?pic=11h5fk3&s=3
I'd be interested in helping you out on an amiga version of your game if you decide to do it.
Hope this is of some use to you.

p.s. just a thought, but ocs/ecs might be a bit tricky to recreate the gfx closely,... with my experiment of downscaling color I forgot to take into account the fighters own palettes, which obviously need to stay consistant and not change as the backdrops do. Your best bet here then is to maybe set up a shared 16 color palette for the fighters and change the rest as required. An added advantage there is you save some valuable chipram as the gfx can be stored in a 4 bit image. Might make it a bit trickier to keep it looking the same, but with a change of color (with it's palette "range" rather than just the individual palette entry) here and there you should still be able to get something very close using EHB on ocs/ecs. Probably wont be easy, but once youre familar with the amiga hardware you'll find it's a lot more capable than it sounds on paper.

Photon · 20 July 2010, 17:06

Quote:

Originally Posted by Leffmann

I took a look at some screenshots and the color layout seems to be 96 colors for the background and 32 colors among the fighters. I left out the status panel at the bottom because you can have different vertically laid out screens with different colors on the Amiga.

I'm certain that using the 64 color EHB mode on the Amiga you could redraw the backgrounds and also fit the fighter graphics in these 64 colors, and make it look good, but you could never fit all of it into 512 kB of chip memory (think graphics memory). That leaves the A1000, A500 and most of the A2000's out, and so you'd need an A500+, A600, A3000 or any of the AGA machines to run the game. And you'd still have the huge task of redrawing all the graphics by hand because an automatic conversion simply wouldn't do.

So the way I see it is that for the same reason you're not converting the game to EGA because it's just not an EGA game, it's also not viable to convert the game to OCS.

On AGA you have 256 colors, 2 MB graphics memory and better performance, and the machine can output 50 or 60 Hz video signal (I would go with 60 Hz) and is IMO the only choice, and it's perfectly fine to cross develop with WinUAE (no need to get into the very super intricate nitty gritty's of the machine for this) which saves you from buying an actual machine to get started.

If I know you, you've already made a calculation of the graphics size

But DeathAdder has already reduced graphics detail for his other fighter game, and I don't see why graphics can't be loaded... you make it sound like all the other fighting games for OCS didn't happen and are impossible

I still say he has bigger obstacles before it becomes reality. I say get started, convert some graphics, make a memory map, "what do we need loaded at the same time", play around a little and things will crystallize.

Leffmann · 20 July 2010, 17:39

Quote:

Originally Posted by fishyfish

I made a quick mockup as to how a 32 color version of your fighter might look without any hardware trickey (although the panel assumes a seperate screen (ergo seperate palette) (really though it could look closer,... I only spent 1/2 an hour on it) .
http://tinypic.com/view.php?pic=11h5fk3&s=3

That looks pretty good actually, but there's a problem:

It's fair to assume that you can select any two fighters and play against any background. The 32 colors in your image work for that particular scenario but not for any other.

There are over 500 possible combinations of fighters and backgrounds, and leaving it in the hands of an algorithm to dither and reduce to 32 colors in realtime is not viable. Doing it by hand would take thousands of working hours, not to mention the massive size of the resulting graphics files.

Leffmann · 20 July 2010, 17:56

Quote:

Originally Posted by Photon

If I know you, you've already made a calculation of the graphics size

But DeathAdder has already reduced graphics detail for his other fighter game, and I don't see why graphics can't be loaded... you make it sound like all the other fighting games for OCS didn't happen and are impossible

I did

and I estimated it would be very hairy, if even possible at all, to fit it all in those 512 kB. If a game needs more than 512 kB of chip memory, it's not very OCS friendly anymore.

But about the colors and stuff, see my previous post. You'd have to split the 32 colors into one background segment and one or two fighter segments. Suddenly you're looking at dithering 96+16+16 colors into 16+8+8 or something. It would even make Dan Malone cringe.

You could use 12+10+10 or such, and dither the background to use 12 unique colors per line and change these with the Copper. I guess in this case it could actually be possible to fit the graphics in 512 kB.

In any case I still think AGA is the best place to start. Then they can finish their port without changing any of the graphics, and look into an OCS port later.

fishyfish · 20 July 2010, 18:47

Quote:

Originally Posted by Leffmann

That looks pretty good actually, but there's a problem:

It's fair to assume that you can select any two fighters and play against any background. The 32 colors in your image work for that particular scenario but not for any other.

There are over 500 possible combinations of fighters and backgrounds, and leaving it in the hands of an algorithm to dither and reduce to 32 colors in realtime is not viable. Doing it by hand would take thousands of working hours, not to mention the massive size of the resulting graphics files.

Yeah, I realised not long after posting it (why I made the p.s. at the end of my post). I do still believe that the game could be translated quite accurately to ocs/ecs, but it wold require maybe a costume color change here and there. AGA would definately be easier, but the author mentioned wanting to try to squeeze as much as he can out of an ocs/ecs machine, and if that's what he is leaning towards, then I thought he might like to see that there neednt be much compromise with the graphics (bare in mind that's only 32 colors and far from properly optimised). If I could get my hands on even 1 frame from each character without having to manually remove backdrops myself (from the screenshots) I'd like to see how accurate it really could look (allowing for fighters palettes, etc).

Reynolds · 21 July 2010, 12:16

This is the standard if we're talking about fighting games on A500:

http://hol.abime.net/633/screenshot

The OCS/ECS can be good and there are many machines out there still living with only these...

18 July 2010, 13:47	#1
CMA Death Adder Rarity 9 Join Date: Jul 2010 Location: USA Posts: 12	Developing a versus fighter for the OCS Hello, everyone. My name is Brandon Cobb; president of Super Fighter Team, a producer of new games for classic video game systems. Recently I have come into possession of an Amiga 2000HD and would like to see it put to some good use. One project we are working on at the moment is a bug-fix and overall improvement to the code of Sango Fighter, a versus fighter for the PC (DOS). The original game code is x86 assembly; we plan to adapt this code to other machines once our additions to it are complete. The Amiga is one platform I'd like to consider, but the goal would be to produce the game for the OCS, thus ensuring compability for all Amiga owners, and giving me the opportunity to test the game without having to buy additional hardware. I have some questions in regard to this idea, which I would appreciate detailed answers to (the more detail the better). From what I understand, to produce the game for the OCS we: * Would be limited to no more than 32 colors on screen at once, at a resolution of 320x200. However, is this 32 color limit a "global" restriction? I.E. - would we simply have ONE palette in use at any given time, which applies to the entire screen and everything on it (backgrounds, sprites, energy bars, etc.)? Or would we be looking at separate palettes of less than 32 colors for the different on-screen elements? * Would require the user to have at least 1MB of RAM in their machine. * Would need to ensure compatibility with AGA machines. Could we truly hope to achieve a smooth-running, enjoyable gameplay experience on an OCS machine with 1MB of RAM, if the game were tightly coded in assembly by someone who knew his way around the hardware? What other considerations should we be expected to make? What sacrifices, if any (aside from downscaling the color depth of the graphics), would we have to concern ourselves with? Any feedback appreciated. Thank you.

20 July 2010, 08:05	#10
CMA Death Adder Rarity 9 Join Date: Jul 2010 Location: USA Posts: 12	... I believe the biggest problem we'd face would indeed be downscaling the graphics to fit within OCS limitations. Looking over the various versus fighting games available for the machine, the best looking (and performing) of the bunch were designed with these limitations in mind. They look great because their graphics were creatively shaped around what the machine's display could and could not do. With Sango Fighter, we have a great looking game that was designed around the features of the VGA card: each character uses his own 16-color palette, backgrounds use 100+ colors each, and in cases where a character has a projectile or other energy-based attack, 3 - 4 additional colors over their normal palette are used. This is a lot to consider, with the OCS in mind for a possible adaptation of the game, because while we should be able to get things looking workable on the OCS, they'll never look big and beautiful like game graphics that were specifically designed for the hardware. It stings me a little, because we don't necessarily wish to produce a color-washed version for Amiga owners and in doing so, indirectly be telling them, "If you want it to look better, try it on the PC," especially when there are Amiga machines that could easily reproduce the game's existing graphical quality. So it is a noodle-scratcher, no question. If there is someone here who has a good deal of experience working with graphics for the OCS hardware who would be interested to rap with me about this situation, that would be nice - just hit me up via private message. There's obviously no need to have anything redrawn; I'd just like to have someone who knows their way around the hardware work out a few color test samples to give me a clearer picture of what we could accomplish.

20 July 2010, 15:57	#15
fishyfish Banned Join Date: Jul 2010 Location: Australia Posts: 475	I'm sure some of this is just repeating, but I thought a bit of an overview of ocs/ecs hardware might be of use to you. Firstly you have between one and 5bit color available as "standard" color, but a 6th bit is available in the way of EHB, which is a copy of the 1st 32 colors, but with brightness halved. Also available is a dual playfield mode, with which 2x3bit playfields are available (playfields are seperate bitmaps/viewports with seperate palettes). In addition to this there's 8 hardware sprites which use different color registers 16-31, even if only using 16 colors (or less (or dual playfield)). There's both 4 (3 + transparent) and 16 (15+transparent) color sprites available, but using 16 color sprites the available sprite channels will half. Sprites are 16 pixels wide and as tall as a user wants. It's possible to do some sprite multiplexing as well to have more than 8 on screen at once, but "impossible" to have thier width exceeding 64 or 128 (4 or 16 colors) pixels in width in total along the same vertical line. Additionally it's possible to change palette color registers between scanlines creating a gradient of multiple shades using just one color, as well as being able to use the altered color palette within a bitmap, so you can have a lot more colors onscreen than the screen mode suggests. It's also possible to display multiple "screens" onscreen at once, each with thier own resolution, color depths and palettes, however they need to be seperated by 1 pixel. AGA introduces a few new things, although cripples it's use of some of them too. Firstly there's now 8bit screen depth available, which in turns means there's also 2x16 color playfields available. Sprites are also now available in 32 and 64pixel wide modes, although generally the higher color depth you use the more channels you lose (aga moved everything to the left to a point u cant physically view all sprites)... I'd hazard a guess the best you could get would be maybe 3x16 color sprites on a 6 or 7 bit depth screen. Even though theyre available I wouldnt use 256 colors for AGA in a game of this sort as it'd be too slow without an accelerator of some sort + ram expansion, 64 colors is probably more realistic. I made a quick mockup as to how a 32 color version of your fighter might look without any hardware trickey (although the panel assumes a seperate screen (ergo seperate palette) (really though it could look closer,... I only spent 1/2 an hour on it) . http://tinypic.com/view.php?pic=11h5fk3&s=3 I'd be interested in helping you out on an amiga version of your game if you decide to do it. Hope this is of some use to you. p.s. just a thought, but ocs/ecs might be a bit tricky to recreate the gfx closely,... with my experiment of downscaling color I forgot to take into account the fighters own palettes, which obviously need to stay consistant and not change as the backdrops do. Your best bet here then is to maybe set up a shared 16 color palette for the fighters and change the rest as required. An added advantage there is you save some valuable chipram as the gfx can be stored in a 4 bit image. Might make it a bit trickier to keep it looking the same, but with a change of color (with it's palette "range" rather than just the individual palette entry) here and there you should still be able to get something very close using EHB on ocs/ecs. Probably wont be easy, but once youre familar with the amiga hardware you'll find it's a lot more capable than it sounds on paper. Last edited by fishyfish; 20 July 2010 at 17:07.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Atari ST versus Amiga in pictures	Retro-Nerd	Retrogaming General Discussion	64	20 December 2020 20:53
Found: Shadow Fighter (Was: Anime Fighter)	LaundroMat	Looking for a game name ?	6	14 June 2017 20:52
Reboot command versus MapROM	jimbob	project.ClassicWB	15	29 September 2014 20:46
Playpower - 8 bit learning games for the developing world	girv	Retrogaming General Discussion	5	24 March 2009 22:00
Who are developing games for Amiga platform at the moment?	oldpx	Amiga scene	65	06 October 2002 17:41

18 July 2010, 14:01	#2
Retro1234 Phone Homer Join Date: Jun 2006 Location: 5150 Posts: 5,773	If you check out games like shadow fighter and fightin spirit it suggests that such a conversion would be possible - It realy would be nice to have a decent Beat Em up I know nothing of assembly and sure others around here could give you better info. Nice Project and welcome to EAB

18 July 2010, 15:38	#3
Steve I Identify as an Ewok Join Date: Jul 2001 Location: North Lincolnshire Age: 45 Posts: 2,356	Hardware Reference Manual: http://amiga-manuals.xiik.net/other/...Manual-ENG.pdf This should tell you all you need to know about the OCS and ECS hardware. The hardware is very capable indeed. Checkout 'Elfmania' which uses 32 colours and looks darn impressive: http://hol.abime.net/2832/screenshot Also 'Shadow Fighter' for the A1200 http://hol.abime.net/1889/screenshot and A500 http://hol.abime.net/1888/screenshot Personally for this project I would use the best standard hardware available which is an A1200 with 2MB of RAM and allows for 256 on-screen colours. Writing an A500 version is pretty pointless IMHO.

19 July 2010, 17:09	#6
Amiga1992 Registered User Join Date: May 2001 Location: ? Posts: 19,644	The bottom nowadays is an A1200. Developing for OCS will lead you to project cancellation. If you really want to do OCS you should develop with the A1200 as your base hardware and then make a downscaled OCS version. This is the best way to do things in my opinion since a lot of code will already work and the graphics will be easily converted to use on OCS etc. Believe me, a 2MB, stock A1200 is enough challenge already. If you need some help with music or graphics I might be available.

19 July 2010, 18:28	#7
Zetr0 Ya' like it Retr0? Join Date: Jul 2005 Location: United Kingdom Age: 49 Posts: 9,768	since 95% of the Amiga Game Software is OCS/ECS - its the most used chipset. In regards to OCS/ECS to AGA personally I think that working in such a tight environment (OCS/ECS) should give you the opportunity to improve your skills and techniques - so when coding for AGA (other than a grahpics revision) you should be able to slide a smoother version in without to much fuss.

20 July 2010, 01:39	#9
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,602	Welcome CMA DA I think the OCS/AGA choice could be resolved with a forum poll - not that there aren't a bunch of gamers outside the active Amiga forums. That is, if you want the opinion of many gamers. I'm a strong supporter of OCS, and understand why you'd want it available for all those A600, A500(+) etc out there. I think the best way is to just start deving on the machine you have, you know, test convert/fix up some graphics, see how animation routines are working out, etc. You'll soon find out if your vision can come to life or if you have to sacrifice some ideas because you're running out of cycles or something Then you could get an AGA dev machine and still use the same code. For me, the biggest problem is the last 5-20% (I have at least 5 games nearly ready for release here...) and getting elbow-deep in it will soon explain which way you should go quite automatically, I think. I wish you the best of luck!

21 July 2010, 12:16	#20
Reynolds Alien Breeder Join Date: Dec 2007 Location: Szigetszentmiklos / Hungary Age: 46 Posts: 1,096	This is the standard if we're talking about fighting games on A500: http://hol.abime.net/633/screenshot The OCS/ECS can be good and there are many machines out there still living with only these...

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