Hardware pushed to the limits according to Sega-16 members

[NekoNiaow]

Do you think the Amiga might have been better utilized by devs had the ST not existed? I've been watching a lot of Amiga/ST videos lately and it's cringe worthy how much the ST held it back.

Indeed. Many ports are the ST version verbatim with only changes to the graphics due to the different bitplane organization and different sounds (Amiga uses samples, ST uses synthesis).

I think the cheapo ST-to-Amiga ports are more a consequence than the cause of anything.

Commodore's business model for the Amiga platform is the real cause IMO. The license fees were much lower than the ones asked by Sega and especially Nintendo AFAIK (keep in mind the much lower number of units sold worldwide when compared to NES, SNES, Mega Drive, etc.), so you have that double-edged sword of providing an entrance level that is reachable even by very small companies, with very limited budget. That resulted in a HUGE library with lots of innovative ideas but it also leaves a huge door open for low-quality releases and quick dirty ports.
Had the Atari ST not existed (or not co-existed), the companies responsible for those ports you're referring to would probably: 1) Find another way to split their costs, maybe borrowing code from an even weaker platform than the Atari ST; 2) Would produce even worse games given they would probably have an even lower budget for those games; 3) Would simply not develop for the Amiga.

OTOH, had Commodore set a decent development studio by themselves or some kind of strong 2nd party partnership, they could eventually drive up the overall quality of the library.

To some extent, that's what companies such as Psygnosis, Core Design and Team17 did for the Amiga as a platform, they raised the bar a little bit. Hadn't those companies existed or ever developed for the Amiga and I think we would have far less memorable Amiga games to talk about.

The bulk of Amiga software support came from Europe though. The ST was the lead platform for a couple of years, until Commodore released the more affordable A500. The original Turrican was pretty much a straight port of the ST game, with Amiga sound added to it. It was pretty much like early European releases for the C-64, that clearly showed that they were ports of Spectrum games over to the hardware.

The existence of the ST definitely had a negative impact on Amiga software development, especially games.
Jack Tramiel unfortunately managed to convince about everyone that the ST was selling way more than the Amiga which led developers to make that machine the lead one for the 1985-1988 period when the ST was actually not selling well at all: it seems that the Amiga did in fact outsell it fairly early after the A500 model was introduced but alas the damage was made and developers blissfully unaware of the reality of the market continued to develop for the ST first with the Amiga version as an afterthought.

As Kamalh noted, replacing CPU based sprite routines with blitter ones would not take more than a few days of work for any competent developer so the fact that this was rarely done serves as a great illustration of the sorry state of game development of that era with publishers cutting costs as much as possible without regard for the platforms capabilities. There were plenty of talented coders but they rarely were given a chance to shine and a great example is the port of Final Fight for the Amiga where a single coder (Richard Aplin) was tasked with both ST and Amiga conversions under six months of work without access to any original Capcom material safe for an Arcade cabinet of which he ended up dumping and disassembling the ROMs of his own initiative. Even if I consider the port to be pretty crap, it is nevertheless quite a technical exploit under these conditions.

Combine this with Commodore absolute ineptitude in packaging and marketing the machine and you had a recipe for long term failure, a shame given how ahead of its time and cheaper the machine was.

No, I'm not. All I remember was Amiga forums comments from former developers comparing the costs to release a game to the Mega Drive or Mega CD to Amiga or CD32.
I remember the costs were much lower but if there were no license fees on the Amiga side, that would make all the sense to me.

There were initially some license fees to become a registered developer and have access to the documentation but these were relaxed after a few years and anyone could purchase the hardware documentation, which incidentally I did as soon as it became available in the Amiga shop in my home town.

The problem is FM itself, period. Manipulating the envelopes is easy (once you understand what part of the envelope is touched by each value) but oh boy modulation is a horribly unpredictable mess. Unless you know the value beforehand you're going to need lots of trial and error to get the tone you want. Not everybody had the time to learn this so the end result was seemingly random values just about everywhere (seriously, I keep dumping FM instruments and they look pretty random, I can usually figure out a similar (or even practically identical) sound with "cleaner" numbers).

This also meant that the 4-op YM2612 most of the time ends up sounding more like 2-op FM instead.

Interesting! I would say that this supports my hypothesis.

The randomness of the result of the modulation is why I was mentioning tools: with proper tools, one would expect to be able to sample an actual instrument, isolate a clean loop of the waveform, then use some analysis software to spit out the best approximate modulation parameters. Even during these days this would have been a fairly simple program to write.

I mean, most keyboard synths of that era used the same hardware as the console and arcade machines and they managed to produce relatively good sounding instruments so the capability definitely existed.

Eh, I doubt cars would have benefited since their polygons on screen are relatively small. The roads probably were a much better target for this since they have large polygons that are very prone to show noticeable artifacts. Actually this is also how Crash Bandicoot handles this (the polygon list is for the map, not the player or other objects).

The reason I was mentioning cars is that any vertex not projected for the cars can be reused for something else so it is a worthwhile tradeoff. It is true that they do not usually suffer from perspective correction issues.

Also, the cars may be small but they require more details than the road or side objects because they need to be beautiful and realistic so they have a higher vertices/polygons density than the rest of game 3D elements. I do not remember the exact numbers but I think the cars in VRally 2 have more than 140 polygons at the highest LOD (of which there were two), so reducing this to two-thirds via pre-computing of polygon lists would allow an equivalent number of vertices to be added to the close parts of the road strip. Moreover cars are fairly boxy overall so they are well suited for angle based polygon elimination.

From-the-back viewpoint racing games on the console have framerate issues in general, is there even any of them running at 60FPS?

I only have Lotus II and Super Hang On on my MegaDrive (Genesis to be precise) and both have the same issue (Super Hang On being much worse but it is an early game) but I have been indeed wondering about that. I see no reason why a smooth 50/60Hz raster road cannot be easily achieved with tiled graphics + row-scroll but I have yet to see one on the MD.

[saturndual32]

From-the-back viewpoint racing games on the console have framerate issues in general, is there even any of them running at 60FPS?

No idea about its frame rate, but Street Racer seems really smooth to me.

[magicalsoundshower]

This is actually impossible, the Dual Playfield mode allocates even planes to playfield A and odd ones to playfield B so it is not possible to have 4 even planes and 2 odd ones and thus the maximum amount of colors for each playfield is 7 no matter how they are arranged.
Valid combinations of planes are: (even/odd) 1/0, 1/1, 2/1, 2/2, 3/2 and 3/3.

Now that is pretty interesting as there are a ton of games that appear to use a 16 color foreground/2 color background setup (James Pond 1 and 2, the castle stage in Lionheart, Turrican 2, Gods, Zool, Yo! Joe, and a ton of others). As a result, I assumed you had the choice between a 7+7 and 16+2 color setup. Could it be that those games don't use Dual Playfield mode, but something else?

[Kamahl]

Actually, you can, and plenty of games do (Shadow of the Beast, LionHeart, Jim Power, and plenty of others). One only needs to split the Blits which cross a scrolling boundary in two.

True but I can't think of one single layer game that does it. The fact that the blits would get cut is very annoying, makes it hard to do this like this:


Some of the later stages should be perfectly doable however, the Amiga should have had tons of shooters with great graphics...

The port of Shadow of the Beast on the MegaDrive is an abomination. There is literally nothing that the Amiga version achieves that the console cannot do natively, dual layers, line scrolling, large sprites, etc. The only trick it would need would be scanline interrupts in order to change the palette on the fly in order to achieve the 128 colors of the Amiga version but that is a very simple one.

You're looking at the wrong version of the port . The JP one is substantially nicer, even has a bit of a "copper gradient" in it, though the real deal only showed up in the SoTB 2 port.

Now that is pretty interesting as there are a ton of games that appear to use a 16 color foreground/2 color background setup (James Pond 1 and 2, the castle stage in Lionheart, Turrican 2, Gods, Zool, Yo! Joe, and a ton of others). As a result, I assumed you had the choice between a 7+7 and 16+2 color setup. Could it be that those games don't use Dual Playfield mode, but something else?

Correct, they're bruteforcing the background. It's the same way Agony does the 3rd layer.

[gamevet]

The trees still have that tiled look to them in SOTB on the Genesis. The rest looks pretty good though.

[Sik]

I mean, most keyboard synths of that era used the same hardware as the console and arcade machines and they managed to produce relatively good sounding instruments so the capability definitely existed.

Only Yamaha ones because Yamaha held a patent on FM, and those were usually much better - I mean, the DX7 was 6-op. Also Yamaha provided their own instruments (which they definitely had time to spend making and even was their main goal in this case), you didn't have composers scrambling for that unless they really wanted an unique sound.

No idea about its frame rate, but Street Racer seems really smooth to me.

Good call, forgot about that one (sprites move at 60FPS, road is also handled at 60FPS though the way it handles the texturing makes it look less smooth). Though it's also true that game isn't doing things like hills and such, and I don't recall it having much in the way of scenery either (for context, OutRun will lag by an entire frame whenever it needs to load new sprites for the scenery at the side of the road).

[Barone]

This is correct, when I worked on VRally 2 for the PS1, we chose to subdivide polygons closer to the camera in order to reduce the distortions caused by the lack of proper perspective correction. The problem with this approach is that this requires you to perspective project many more vertices which eats from the GTE (Geometric Transformation Engine, the set of vectorized additional instructions which were added to the PS1 CPU and are used for perspective projection of the vertices) bandwidth.
To compensate for this I advocated that we used pre-computed render lists for a fixed set of angles for the car models (as Crash Bandicoot does) but this was not judged feasible and anyway we probably would not have had the time to implement it anyway, we'll never know.

Are the physics and/or the AI of PS1 version simplified when compared to the PC ones?
Last time I checked the PS1 version I found the AI too easy (even on maximum difficulty settings) and the handling of the cars are pretty straightforward too.

I would say that cross platform games expose more the limitations of the development team that these of the hardware. With a proper asset pipeline one can produce quality assets and bake data in a way that is adapted to each target platform. Alas, very often during the PS1 era the asset pipeline was an area of development which suffered from heavy under-investment from many studios (Naughty Dog being an exception to the rule, which their post-mortem articles in GameDevelopers showed at that time).

I think most of the games ported to the Saturn suffered with that. Oh well.

The same is true of Lotus II for the MegaDrive: it displays nicely but lacks colors and runs at half the frame rate of the Amiga version for no clear reason. It seems quite obvious that the devs who ported Amiga games to the MD were either not that competent or lacked the proper time and budget to achieve a decent result.

IDK.
I remember Chilly Willy once said that games like Lotus on the Amiga could run that well because they used some hardware characteristics of the platform that the MD hardware doesn't have. I don't remember the details though, nor do I have found the link to the discussion anymore (which is sad).
The Amiga versions have some pretty big black borders, that's all negativity that I can find about them technically speaking. The performance is really impressive IMO.

I only have Lotus II and Super Hang On on my MegaDrive (Genesis to be precise) and both have the same issue (Super Hang On being much worse but it is an early game) but I have been indeed wondering about that. I see no reason why a smooth 50/60Hz raster road cannot be easily achieved with tiled graphics + row-scroll but I have yet to see one on the MD.

Super Hang-On has a lot of calcs going on, far more than the Lotus games.
And both games you cited run at 20 fps most of the time.

No idea about its frame rate, but Street Racer seems really smooth to me.

Street Racer has the track scrolling at 50 fps (I'm talking about the EUR version since it's the original one), the cars moving at 50 fps but IIRC the track side objects move at 25 fps.
There's not elevation changes in its tracks though and the handling of the cars is also pretty simplified in terms of calcs.
Another game whose tracks have no elevation changes and which scrolls at 60 fps on the Mega Drive is RoadBlasters. Also taking advantage of the big HUD on the bottom of the screen.

Out of the more "advanced" ones, I think only Fastest 1 scrolls the track at 60 fps (the cars animate at 30 fps IIRC) but it has some noticeable trade offs:
- The cars look pretty small (it looks like an 8-bit game in screenshots).
- Even in split screen mode there's a huge chunk of the screen which is filled with a black border and lap time info.
- Track side is pretty sparse is terms of sprites and details in general.
- There are "hills" in the tracks but the elevations are very slight and the draw distance is somewhat limited.
All in all, I like how Human managed to pull off a game with pretty much no slowdown in split screen mode back in 1991.

(for context, OutRun will lag by an entire frame whenever it needs to load new sprites for the scenery at the side of the road).

Good info there, thanks.
I think all track side objects of the Street Racers tracks are loaded only once, before the race starts.
The same goes for Fastest 1 IIRC.

[gamevet]

I cry tears of blood every night I think about it.
It certainly did not help that US Gold was a major publisher of arcade ports on the Amiga. 32 titles, most of them absolute rubbish (http://hol.abime.net/hol_search.php?..._publisher=615).
If there is a company which never pushed any hardware (except maybe their cash register) to its limits, that would be US Gold.

They had a pretty decent conversion of Forgotten Worlds. It's missing some levels, but the arcade game was way too long for the difficulty it provided.

https://www.youtube.com/watch?v=4hve1fm-Woc

[MasterGenesis]

I know this one is weird, but this game is in CGA on RGB mode on an MS-DOS computer.
Attachment 11660

[TheArcadeKid]

I always thought Alisia Dragoon on the Mega Drive/Genesis was a good example of a game pushing the hardware. No flicker, no slowdown, plays pretty much perfectly no matter what's going on. Looks great in general too - a bit drab, some might argue, but for me it goes well with the dark tone of the game. I can't recall many actions game on the Mega Drive that achieve so much and run as smoothly.

[Barone]

Amiga 500 real hardware capture:

[OverDrone]

I remember Chilly Willy once said that games like Lotus on the Amiga could run that well because they used some hardware characteristics of the platform that the MD hardware doesn't have. I don't remember the details though, nor do I have found the link to the discussion anymore (which is sad).

Yes I remember that too. Buggered if I know where it is though.

Another game whose tracks have no elevation changes and which scrolls at 60 fps on the Mega Drive is RoadBlasters

Very smooth track in that game, objects scroll convincingly as well. When you use the rocket engine power up the game is about as blindingly fast as you can get, yet if you've got quick enough reactions (or ESP) you can still dodge everything.

Staying with MD, what about the Road Rash engine? Elevation changes, intersecting roads, tons of objects and rear view mirrors all with software scaling. Sure, it runs at a pretty low frame rate, but the trade off is worth it IMO given the depth of the physics. I know the Amiga version forgoes the scaling for pre-rendered objects.

EDIT: That video of Prime Mover is pretty amazing, never even heard of it before. Elevation changes, overhead scenery and smooth FPS for the track.

And speaking of the Amiga, Elfmania, although a shitty fighting game, had amazing colourful linescroll background graphics that put other fighters on the machine to shame.

[NekoNiaow]

True but I can't think of one single layer game that does it. The fact that the blits would get cut is very annoying, makes it hard to do this like this:

Actually, there are plenty of one-layer games which do handle split Blits but for an entirely different reason. Vertically scrolling games often use a wrapping screen with the Copper changing the screen pointer mid-screen as the scroll progresses, since the screen frame buffer is not contiguous all blits which cross over the "cut" must be performed in two passes.
SWIV and Battle Squadron are examples of such games (cf http://www.codetapper.com/amiga/inte...eket-weeserik/, search for "split").

I do not know explicitly of any horizontal scroller which handles split blits but I would assume there are a few. If BOBs are properly sorted by their Y coordinate then the overhead of detecting which of them have to be split is very low.

Some of the later stages should be perfectly doable however, the Amiga should have had tons of shooters with great graphics...

Indeed, it should and I am fairly confident that it eventually will.

You're looking at the wrong version of the port . The JP one is substantially nicer, even has a bit of a "copper gradient" in it, though the real deal only showed up in the SoTB 2 port.

Oh, I was not aware of it, it does indeed look better than the version I own. Thanks.

Only Yamaha ones because Yamaha held a patent on FM, and those were usually much better - I mean, the DX7 was 6-op. Also Yamaha provided their own instruments (which they definitely had time to spend making and even was their main goal in this case), you didn't have composers scrambling for that unless they really wanted an unique sound.

Indeed. But I can't help but think that Sega could have invested a bit of their R&D time to have their talented musicians work on a standard set of quality sounds for re-use by developers. They also clearly had an interest in having the machine run games with good audio.

Are the physics and/or the AI of PS1 version simplified when compared to the PC ones?
Last time I checked the PS1 version I found the AI too easy (even on maximum difficulty settings) and the handling of the cars are pretty straightforward too.

My memory is a bit fuzzy in this area, the game was 95% C code and the only areas which required some rewrites were the GTE instructions (they were encapsulated in macros and functions though), the physics definitely made use of the GTE but I am not too sure anymore whether the fixed point maths was preserved as is or was converted to floating point when going to the PC.
But in any case, the underlying physics logic stayed the same, the only differences would be the precision and possibly the frequency of updates, both of which could have an influence on the final behavior. You would have to ask David Nadal to be certain.

I think most of the games ported to the Saturn suffered with that. Oh well.

And many more at least one generation further down the road in my personal experience. Only around 2007 did I witness some improvements in production pipelines.

IDK.
I remember Chilly Willy once said that games like Lotus on the Amiga could run that well because they used some hardware characteristics of the platform that the MD hardware doesn't have. I don't remember the details though, nor do I have found the link to the discussion anymore (which is sad).
The Amiga versions have some pretty big black borders, that's all negativity that I can find about them technically speaking. The performance is really impressive IMO.

Super Hang-On has a lot of calcs going on, far more than the Lotus games.
And both games you cited run at 20 fps most of the time.

Raster roads do play to the Amiga strengths since bitmap graphics allow to easily alter the image on a per line basis, but the MegaDrive with its row scroll tables can do the same by simply sliding each line of the desired amount. It also has a very large number of sprites available to display cars and roadside objects and I think that the dual layer architecture could probably be leveraged as well.

The Amiga on the other hand must refresh the moving parts of the bitmap screen every frame. Lotus for example does redraw the road every frame and must then blit all objects on top of it one after another at 50 FPS. The fact that it manages to do so tells me that the MegaDrive should be able to do much better but clearly the proof would be in the pudding.

Out of the more "advanced" ones, I think only Fastest 1 scrolls the track at 60 fps (the cars animate at 30 fps IIRC) but it has some noticeable trade offs:
- The cars look pretty small (it looks like an 8-bit game in screenshots).
- Even in split screen mode there's a huge chunk of the screen which is filled with a black border and lap time info.
- Track side is pretty sparse is terms of sprites and details in general.
- There are "hills" in the tracks but the elevations are very slight and the draw distance is somewhat limited.
All in all, I like how Human managed to pull off a game with pretty much no slowdown in split screen mode back in 1991.

Interesting. This is definitely surprising to me, a cursory reading of the specs of the VDP led me to think that the machine should be able to shine in this domain but I do not exclude the possibility that I am overlooking something.

They had a pretty decent conversion of Forgotten Worlds. It's missing some levels, but the arcade game was way too long for the difficulty it provided.

I must admit that the game runs relatively smoothly but they made some pretty questionable decisions regarding colors and controls. I am convinced that it would have been a better idea to sacrifice the parallax scrolling and go for a 32 colors palette instead, but admittedly this is a relatively early game.

[Sik]

Since Battle Squadron was brought up: the Mega Drive port. I mean, I suppose that on the Amiga doing the mirror enemies was easy (copy straight from the framebuffer and apply a mask on it), but on the Mega Drive it's much less trivial due to the lack of framebuffer. True, just look up which tiles were used under the enemy, then copy from them and apply the mask... but it must be a pain in the ass to code all that.

Streets of Rage 3 does the same with one of the bosses (or at least has the same visual effect).

Interesting. This is definitely surprising to me, a cursory reading of the specs of the VDP led me to think that the machine should be able to shine in this domain but I do not exclude the possibility that I am overlooking something.

Being limited to 64KB of video memory (with about usually 25% of that going to tables) with streaming not being particularly fast (there's only a short period of time to stream in new graphics, giving only a few KBs per frame) is probably not helping matters. These games are notoriously memory hungry because of all the prescaled sprites, and on top of that ROM being expensive so you wanted to compress as much as possible.

[Flygon]

Going by a conversation I had with Tiido... what, seven years ago? As I understood, Battle Squadron was pulling off some sort of hint/vint trickery for the 'invisible' enemies.

Take this with a massive grain of salt, though. Memories do not age well!