Arcade / Console --> Amiga conversion discussions

[kovacm]

Axa. It is problem in multitasking with more apps running.
But if you code game or demo, then cpu data cache is no problem?

[frank_b]

Originally Posted by kovacm

Axa. It is problem in multitasking with more apps running.
But if you code game or demo, then cpu data cache is no problem?

It can only be enabled on some individual computers accelerator. Chip ram isn't datacached. I assume it's inhibited via hardware. If I ever get my a2k up and running again. I'll test the datacache from chip ram. It has an old 030 accelerator in it.

[idrougge]

Are you saying that Individual accelerators support caching chip RAM?

[Retro-Nerd]

I assume he means a specific accelerator, not the ones from IC.

[frank_b]

Originally Posted by Retro-Nerd

I assume he means a specific accelerator, not the ones from IC.

It's an option in ACtune.
http://wiki.icomp.de/wiki/ACAtune#chipcache

[roondar]

Originally Posted by frank_b

It's an option in ACtune.
http://wiki.icomp.de/wiki/ACAtune#chipcache

And one that you'd best leave off (it made my A600 really unstable). The same as the fastchip option - when these options worked it was nice, but many, many things can (and eventually will) go wrong.

[frank_b]

Originally Posted by roondar

And one that you'd best leave off (it made my A600 really unstable). The same as the fastchip option - when these options worked it was nice, but many, many things can (and eventually will) go wrong.

Oh yeah. It's off for a reason
It can't be done safely on the Amiga for the reasons I pointed out in the thread.

[ReadOnlyCat]

Originally Posted by zero

I did a few experiments today, admittedly on my A4000/060, but it certainly seems like even a very small amount of fast RAM would really provide a massive boost for an unexpanded Amiga. With caches off the difference between running code from chip RAM and fast RAM is dramatic, especially when you have lots of DMA enabled.

My little test code could easily plot 2x as many dots to screen with code in fast RAM, without any optimization.

0x0 CPUs with x>=2 benefit much more from Fast RAM than the stock 68k since they have a much higher frequency and lower cycle counts per instruction and thus much increased potential memory bandwidth.

They will be slowed down by the 7MHz chip bus whereas the 68k will not, unless bitplane DMA or the Blitter in nasty mode steal some of its cycles of course but even then, the 68k only requires memory access in one out of every four cycles to run at full speed so the slowdown would not necessarily be crippling.

Also, this kitten likes this thread.

[zero]

The 68000 is really limited by the large number of cycles that instructions take. It makes sense for a workstation CPU to have fairly complex instructions and highly orthogonal instruction set that was good for the C compilers of the day, but for games...

For games having more instructions per second is more important. I've said it before but the 8 bit 6502 derivative in the PC Engine, running at 7MHz, is a much better fit for assembler code and games that just need to move sprites around and implement some game logic.

The best way I can think of to offset this on the Amiga is to take advantage of its relatively large RAM. You can pre-compute things like movement patterns, use triple buffering and generally trade RAM for CPU cycles wherever possible.

I think that Anima´s works is awesome and people speak so much and acts little.
I see a MSX2 (8bit), much less capable machine than Amiga, doing marvelous things:

Ghosts'n Goblins MSX turbo R V9990 (in developement)
[ Show youtube player ]

The King of Dragons like game for MSX2 V9990 (in developement)
[ Show youtube player ]

Pointless Fighter -Street Fighter II clone for MSX2 Moonsound (voices and sound FX)
[ Show youtube player ]

Everything is possible we only need to know how...

[idrougge]

Truth to be told, an MSX Turbo R with V9990 is more capable than the basic Amiga when it comes to implementing a typical arcade game (Street Fighter notwithstanding).

[zero]

Many systems benefit from having better sprites than the Amiga. The Amiga graphics are better in other ways though. The trick is to write games that maximize the Amiga's advantages while minimizing the weaknesses.

As such, arcade ports where the hardware typically has loads of sprites and a tile mapped display can be challenging.

[sandruzzo]

Is better to have game Designed Around Amiga than try to port game from Arcade

[TuRRIcaNEd]

Originally Posted by zero

That's pretty far fetched. For a start, the arcade system has more colours than OCS can display.

True, but there's usually a significant difference between what arcade hardware *could* display versus what it actually *did* display more often than not.

I've mentioned my "mad dream" project to see what kind of conversion of OutRun might be possible with Amiga hardware on another thread, and while I was doing some test graphics extraction and conversion, as an afterthought I grabbed one of the first scenes in the attract mode (the most complex in terms of what's on-screen), busted it down to 32 colours and imported it into DPaint.



As you can see, at a casual glance almost all of the important detail is retained, in spite of the overall palette reduction (32,768 vs. 4,096) and the on-screen limit of 32 colours. Without having the original grab side-by-side to compare, all that is immediately obvious is the missing road stripes and the grey detail on the background cloud. The text gradient is affected, but any conversion would be using copper palette effects for that anyway.

Originally Posted by robinsonb5

The custom chips can't access it - the point you seem to be missing is that the STe's blitter *can* access the expanded RAM.

Maybe so, but I don't think the ST's DMA setup could access things as efficiently - having a blitter only solves half the problem.

With 20/20 hindsight it's easy to point at the ChipRAM / Fast- or BogoRAM setup as a weak link in the Amiga architecture, but we have to remember that much of the Amiga's design and development gestation coincided with the first significant global RAM shortage since home computing became affordable. This is also a factor in why a planar system was used for the display architecture, because it was the most memory-efficient method of generating a display with the desired resolutions and palettes.

Of course, what was absolutely the right design choice between 1982 and '85 (to the extent that it put Amiga almost 10 years ahead of the competition) ended up holding things back when the competition eventually started to catch up. But it could still have been remedied had CBM International not been such a dysfunctional basket case post '87-88...

... because the vast majority of A500 owners had either an extra 512k of slow RAM or a Gary-hacked 1.5meg expansion - still slow RAM - rather than true Fast RAM ... Zeewolf 2, for example, is much improved ...

If I understand things correctly, the general technique was usually that if a game was written to detect and take advantage of a (non Chip-) RAM expansion, the code and logic (along with any data which didn't require direct addressing by the chipset) would be shunted into the expansion address space. The space this saved in the ChipRAM address area could then be used either for enhanced graphics and sound (e.g. F/A-18 Interceptor), or simply to load more of the existing material in to reduce loading times (e.g. Lemmings). If the expansion was genuine FastRAM (i.e. not locked to the chipset cycles), then you'd get a slight speed increase as a side-effect regardless of whether the code was intentionally written to do so.

Originally Posted by Miggy4eva

copying data between chipram and fast ram, keeping the executable outside of chipram, only holding data in chipram that the chipset needs to work on. You have 2MB to play with, it's plenty.

Yup, that works too; though you probably wouldn't want to be copying large blocks of RAM in code that needs to run quickly - the middle of your main game loop, for example...

Originally Posted by zero

Many systems benefit from having better sprites than the Amiga. The Amiga graphics are better in other ways though.

True, though what constitutes "better" can sometimes be a bit on the subjective side! What I didn't discover until relatively recently is that when talking raw numbers in terms of sprite count, with some earlier arcade and 16-bit console specs, that count referred to the individual 8x8 blocks that could be combined to make a larger "sprite", and where that was the case those numbers could be considered a little misleading. On paper, Denise's 8 * (4-colour, 16px*screenH) sprite implementation looks a little underwhelming, but that doesn't take into account that when combined with the copper, those sprites can be re-used/multiplexed on subsequent scanlines and repeated per-scanline.

The trick is to write games that maximize the Amiga's advantages while minimizing the weaknesses ... As such, arcade ports where the hardware typically has loads of sprites and a tile mapped display can be challenging.

Correct, however I'd add that based on my reading it seems that the Amiga hardware could be made to have a decent stab at most things with a bit of lateral thinking. Unfortunately, for most of the Amiga's heyday, the big-name publishers who usually landed the most sought-after licences were almost entirely focused on getting at least some kind of conversion out on all the platforms, and almost never gave their dev teams time to figure out how to leverage the Amiga even half-properly.

Originally Posted by sandruzzo

Is better to have game Designed Around Amiga than try to port game from Arcade

It's certainly true that the games which best showed the Amiga's capabilities were almost always original titles designed for the platform as opposed to conversions. However there were enough exceptions to the rule (e.g. Super Hang-On, Pang!, Rodland) to argue that the Amiga could give the consoles a run for their money if approached right.

[dlfrsilver]

something it's even better to make the player thinks the amiga is really doing it (computing), when in fact it simply do the illusion, it's just displayed images. The CPU cost is of course not the same.

About Rodland, there is nothing that would makes it hard for the amiga to do. Ron even enhanced the enemies AI, so there was room to use

Pang is a simple Z80 game. Nothing the amiga can't do. fixed screen with 256 colors.

Super hang-on is a game where you would typically use the illusion of display, instead of replicating the coin-op logic (too heavy the amiga CPU).

[zero]

I agree with everything...

Originally Posted by TuRRIcaNEd

True, though what constitutes "better" can sometimes be a bit on the subjective side! What I didn't discover until relatively recently is that when talking raw numbers in terms of sprite count, with some earlier arcade and 16-bit console specs, that count referred to the individual 8x8 blocks that could be combined to make a larger "sprite", and where that was the case those numbers could be considered a little misleading. On paper, Denise's 8 * (4-colour, 16px*screenH) sprite implementation looks a little underwhelming, but that doesn't take into account that when combined with the copper, those sprites can be re-used/multiplexed on subsequent scanlines and repeated per-scanline.

Sprites on the Amiga seem to work best when not used as sprites. For example, Shadow of the Beast makes great use of sprites for background animation and parallax.

As for Outrun, I think the main issue is the amount of on-screen sprite objects. Obviously you are going to pre-scale everything so you are just doing a blitter copy, but when you think about the amount of overlapping huge sprites on screen, especially in the "tunnels"... I guess you could space them further apart, but with 5 bitplanes I just don't think there is enough bandwidth to get 25 fps.

You also have the issue that generating the road requires dual-playfield on OCS. On AGA I guess you could use sprites. Well, maybe there is another way... Use the copper to fill the main width of the road, and use sprites to clean up the edges. The horizontal resolution of the copper is low but the sprites fix that.

[dlfrsilver]

Originally Posted by zero

I agree with everything...



Sprites on the Amiga seem to work best when not used as sprites. For example, Shadow of the Beast makes great use of sprites for background animation and parallax.

As for Outrun, I think the main issue is the amount of on-screen sprite objects. Obviously you are going to pre-scale everything so you are just doing a blitter copy, but when you think about the amount of overlapping huge sprites on screen, especially in the "tunnels"... I guess you could space them further apart, but with 5 bitplanes I just don't think there is enough bandwidth to get 25 fps.

You also have the issue that generating the road requires dual-playfield on OCS. On AGA I guess you could use sprites. Well, maybe there is another way... Use the copper to fill the main width of the road, and use sprites to clean up the edges. The horizontal resolution of the copper is low but the sprites fix that.

a good example of an outrun-like game is Crazy Cars III. It has great colors, and incredible speed, way way faster than Lotus 2 for instance.

[zero]

I always liked Road Rash. Okay, the frame rate was low, but it was one of the most enjoyable racing games on the Amiga. It also had hills that were much steeper than other games, because other games couldn't cope with the road partially obscuring distant objects.

[sandruzzo]

On Aga you can have the road fully textured almost for free, using dual playfields and copper list to bend road to have curves and hills

[zero]

Originally Posted by sandruzzo

On Aga you can have the road fully textured almost for free, using dual playfields and copper list to bend road to have curves and hills

Care to explain that further?

What are you suggesting, using palette changing per scanline to use the road bitmap as a kind of copper chunky? The resolution is going to be rather low.

Any examples of people doing that?

Also, how are you planning to do hills and obscuring further back graphics?