Which Amiga games ARE better than on the ST?

[derSammler]

Many games converted from the ST to the Amiga had that issue and WHDLoad slaves have fixes for that. But Wings of Death, as claimed by dlfrsilver, was not one of such games.

Also keep in mind that this most likely never was due to lazyness. People had CRTs back then. When a game was too dark, you simply turned the brightness of the monitor up without thinking about it. Colors were not calibrated (analog RGB has no absolute color values anyway).

[alexh]

Originally Posted by lmimmfn

Apparently this was a thing(i never played this game) - https://amiga.lychesis.net/artists/OlivierCorviole.html

I believe you. If you only have an 9-bit palette (512) then going to a 12-bit palette (4096) I can imagine it would do this. But did it really affect Wings of Death? StingRay didn't seem to think so.

[pandy71]

Originally Posted by dlfrsilver

That's the other way around. They not exactly tried to match the Amiga hardware. What they did is pushing to the maximum the ST, and make no effort or even butchering the Amiga to make the ST version shine.

That's what i have noticed after reviewing and trying shit tons of games on Amiga and Atari STF/E

In reality, when the Amiga is pushed to the maximum, the ST is way way behind. There's no close up to Amiga Hardware possible/at all.

I've always had impression that ST coders trying to achieve same visual effect as you can see on Amiga, perhaps my impression is distorted but i think at some cases they was very close knowing fact that how limited is ST HW.

But this still don't change my overall impression that ST required higher degree of creativity how to use CPU with crap to get something decent.

[lmimmfn]

The Amiga vs the ST is a lot like the C64 vs the Anstrad CPC( im excluding the Spectrum simply because of how it handeled colour and didnt have raster splits etc.)
The C64 had all that wonderful hardware and the CPC only has rudimentary hardware for scrolling and rasters.
All screen drawing on the CPC has to be done by the CPU same as ST. Similarly split rasters are CPU controlled like the ST. The only difference on the CPC is its not really bitplane driven, its more chunky based.

The CPC can rarely match the C64 in smoothness but(moreso recent releases) games like Pinball dreams show how the machine csn be tsken advantage of, similar to the ST.
Another advantage of the CPC vs ST is that it can hardware scroll 2 wide pixels in mode 0 in hardware.
I only bring up the comparison as its essentially the same in terms of brute force CPU vs hardware.

[dlfrsilver]

Or more likely lack of money / resources / time.

This is an argument we can hear. But in many cases it just can't explain how wrong things were done.

I am not 100% sure about Wings of Death but Thalion first year titles the Amiga ports were done by their sound guy Jochen "MadMax" Hippel in his "spare time". They were not priority, contained lots of ST specific code that should have been removed, the reason was economics, the Amiga versions made little or no money and so had to be "acceptable" in the shortest possible time.

I'm very sorry to say that the ST was not doing money (it was even worse than the Amiga situation in fact). Wings of death sold 5.000 copies on Amiga and ST.

Stingray wrote in the slave :- "Back in 2014 a problem regarding the palette was reported on the Mantis bugtracker so I had a look. Turned out there was nothing wrong with the palette at all! I have no idea what you [Dlfrsilver] have seen but the palette and colors are completely correct! Nothing to do in that regard.

Technically Stingray is right (i won't question about him confirming that). However what is true, is that when they did the conversion of colors from the ST version, they did expand the palettes to the Amiga range, but the colors values themselves are off compared to the ST version. Turn the luminance up to get more brillant graphics doesn't work.
I did the compare between the game running on my STE sided with my A500, the graphics are shining on STE and dark on the Amiga. The Swamp level is the confirmation of that. It looks good on STE, and it looks nasty on Amiga.

Certainly not the case above.

It certainly is. There are quite of number of games that are, crackdown is one of them. Just read the interview on how the development was led, you will see that they spent way too much time on the ST version, to just fork out the Amiga version in 3 weeks, resulting in a shoved game with mastering error on every originals sold by U.S.Gold.

[dlfrsilver]

Originally Posted by lmimmfn

The Amiga vs the ST is a lot like the C64 vs the Anstrad CPC( im excluding the Spectrum simply because of how it handeled colour and didnt have raster splits etc.)

Not really. You're comparing apples with oranges here.

The C64 had all that wonderful hardware and the CPC only has rudimentary hardware for scrolling and rasters. All screen drawing on the CPC has to be done by the CPU same as ST.

This is incorrect. This is the opinion of a guy owning a C64 in 1986. Since 1990 (or better said even before), it's know that you can use the CPU to draw, but it's very slow. The CPC has a CRTC, which is dedicated to the Scrollings and display. In the 80's most professional did have no clue on how to use the CRTC in the CPC. It's the amateur demomakers who discovered how to use correctly the Amstrad CPC when the first complex demos appeared. Mike Lamb at Ocean was one of the first CPC pro coders who made use of the CRTC capacities, on Robocop, and then on Batman the Movie.
The real chain for the CPC for good games is CPU+Gate Array+CRTC. This is why Batman the movie and Robocop are top class on CPC and a pile of junk on the C64.

Games on CPC are 2 classes : Those who were ported from oldish and inferior C64 and ZX, that looks awful and plays very bad, and the second class, of games that are simply better as a whole compared to their C64 counterparts or even ZX. Chase HQ is another that spring to mind. Jon O'Brien was one of the best CPC/ZX coders at ocean, as good as Mike Lamb.

The other thing is the development system used to make the games. Converting or making a game from an Amiga or an ST to a CPC gave much better result than doing it from a C64 or a ZX spectrum. It always works much better from a superior machine from a lower machine, not the other way around.

Similarly split rasters are CPU controlled like the ST. The only difference on the CPC is its not really bitplane driven, its more chunky based.

Wrong again. Split rasters are CRTC controlled, not CPU. If you try to make split rasters with the CPU, it will be so slow that it will just won't work.
The CRTC on CPC can be used to make the equivalent of copperlists, like on the Amiga. You can change colors per lines and also per portion of a line, this thanks to the CRTC.

It seems that you don't know well the CPC hardware.....

The CPC is more complex than a ST. With an ST you do everything with the CPU, and hard scrolling are very hard to implement ingame. The CPC has hardware scrollings, and software sprites. This means that you can have huge sprites on CPC that a C64 just could not cope with. Just look at the blinking sprites for example in Dragon Breed C64

The CPC can rarely match the C64 in smoothness but(more so recent releases) games like Pinball dreams show how the machine can be tsken advantage of, similar to the ST.

There are 50fps scrolls game in 16 colors on CPC. Pinball Dreams can't be porte to C64, you will never have the equivalent of what the CPC delivers.
And Pinball Dreams uses only 40% of the CPC abilities, while most Commercial CPC games used at best 6% of the CPC capacities.... The CPC was a badly exploited computer back in the day with lots of possibilities that were only waiting to be discovered and used.

Another advantage of the CPC vs ST is that it can hardware scroll 2 wide pixels in mode 0 in hardware.

It can do pixel scroll. It has been discovered by Longshot/Logon System. Check his compendium this year.

I only bring up the comparison as its essentially the same in terms of brute force CPU vs hardware.

Well used the CPC can give more than the C64 (without going the 50fps route). Hardware scrolling, huge sprites (ex: Opwolf and Opthunderbolt), good game speed. But only with the hardware chips it uses, and not the CPU alone.

[dlfrsilver]

Originally Posted by derSammler

Many games converted from the ST to the Amiga had that issue and WHDLoad slaves have fixes for that. But Wings of Death, as claimed by dlfrsilver, was not one of such games.

My guess is that the tool they used only expanded the 9bits palettes to amiga 12bits palette, but not converting the colors correctly.

The very first time i bought Wings of death in original on Amiga, and on ST, i played the Amiga version from start to end in order to compare both version.
The main thing i noticed is that the Amiga graphics were simply dark, like if the brightness from the ST version was removed.

Also keep in mind that this most likely never was due to lazyness. People had CRTs back then. When a game was too dark, you simply turned the brightness of the monitor up without thinking about it. Colors were not calibrated (analog RGB has no absolute color values anyway).

It could be that, BUT, in fact not. the swamp level in WOD amiga shows that the colors are incorrectly converted, even if they have been expanded to 12bits amiga palette. The mud of the swamp is dark, the sprites are all dull and looks awful compared to the ST version.

I remember the game Iron Lord. The game used a mix of Atari ST pictures and Amiga pictures. The programmer did not convert the ST pictures to Amiga palette format. The end result is that some pictures are very dark.

Some games with the "ST palette bug" had graphic marks reduced in the magazines tests : "for an unknown reason, the amiga version has dark graphics, so we lower the graphic notation compared to the ST version". It has been the case for Wings of death in France for example.

[dlfrsilver]

Originally Posted by Megalomaniac

Enchanted Land may not be as many as 36 colours on every level, I assume you've only looked at level 1. Just because they're there doesn't mean you always have to use them. Push-scrolling aside (and that was hardly uncommon in 1990), ST Enchanted Land looks better than most contemporary Amiga platformers.

I said 36 colors on intro where the sprite is running, not the thalion screen.
Ingame i found 29 colors only.

Hidden messages in code weren't seen by people who bought the games, they were seen by people who cracked the games, hence the message being aimed at pirates.

Some messages were written in clear on the bootblock.

Even if those words were the programmer's pure sincere views, it's hardly confirmation of programmers intentionally making bad Amiga versions when they led with the ST.

They wanted the ST to surpass the Amiga, and they did all they could for that. The proof is that while many games are better on Amiga, the ST versions while inferior got the "clean'n'neat touch" and better polish, even if running at 10fps with slowdowns.

UK developers initially prioritised the ST version because it was easier to convert from ST to Amiga than vice-versa,

In truth, it's incorrect. I talked with Pang famed Pierre Adane regarding this aspect of the development, and he told that going the ST => Amiga way was illogical. You start from the weakest machine, to port a game on the best machine. By simply changing the I/O on the Amiga, you finish with a bad game or an average game on ST, and a dull and crap/rubbish game on Amiga. The easiest way Pierre Adane told me is the otherway around : You start the framework on the Amiga, then you code the best possible amiga version using the hardware, and in parallel you make the ST version by converting each hardware routines to software routines.

In the end, when the game is marketed, The ST shovel port will crash in term of sales, on both computers, no one wins. By using the Amiga to ST port, you get a very good game on Amiga and a good game on ST. Both wins.

Look what happened on the market : the ST to Amiga "quick porting" failed. The publishers had to stop pushing shit games.

....and pure Amiga code and artwork didn't necessarily make the game outsell lazy ST ports, all else being equal.

Certainly not equal. You have no idea of the money publishers lost with the ST. They had to develop on Amiga because the ST soft sales were ridiculous.
For 1 original soft sold on ST, 10 originals were bought on Amiga (even with piracy!). This is why the publishers stopped with the ST completely.

Pure business, sadly, even if they may have been slow to notice the moment where Amiga games were outselling ST ones.

It happened in the end quite fast. early 1990, the Amiga was already outselling the ST since a good while.

Were programmers, or publishers, responsible for the mastering? A mastering error isn't in itself evidence of a rush job - Spectrum R-Type had a similar mastering error (the final level wasn't recorded onto the original tapes) and that's usually considering a programming masterpiece.

For R-type, Bob Pape gave the master tape to Dave Looker for speedlock mastering (done on an Atari ST!) with all the game and levels correctly saved on tape. The fuck up happened during the mastering, the guy who did the mastering made an error by not writing the level 8 on the original tapes, he duplicated level 7 two times if i remember well).

for Crackdown, i would rather say that it an error made at the mastering plant. Because from memory, the faulty tracks are here, but they were incorrectly mastered. It looks like the guy messed up when preparing the master disk to be described to then be written on the final disks.

Istvan Fabian restored the missing or damaged parts of the tracks to make the IPF version of the game.

Also, very few of the most technically impressive ST titles were simultaneous ST/Amiga developments by a single team of coders.

Pang is one of them, as was Toki for example.

For 2D at least, what was amazing on the ST was only 'quite good' on the Amiga without a serious rework, and what was amazing on the Amiga needed redoing from the ground up to be workable on the ST. Hence guys like WJS

Yes. Because porting from ST you then got very poor graphics on Amiga, which would harm the customers and the sales, and the other way around, the amiga offered too much colors for the ST, so this meant removing the parallax, lower the colors from 64-32 back to 16, plus converting the hardware routines to software routines.

WJS did some very overated games. One of them is Spellbound. It looks good in the magazines, but was in fact appaling and a deception when played, even with a trainer.... The other one i think of is Ork....

[demoniac]

Originally Posted by dlfrsilver

Technically Stingray is right (i won't question about him confirming that). However what is true, is that when they did the conversion of colors from the ST version, they did expand the palettes to the Amiga range, but the colors values themselves are off compared to the ST version. Turn the luminance up to get more brillant graphics doesn't work.
I did the compare between the game running on my STE sided with my A500, the graphics are shining on STE and dark on the Amiga. The Swamp level is the confirmation of that. It looks good on STE, and it looks nasty on Amiga.

I don't own a real STE, but this video compares the 2 platforms and they look the same to me. The music on the other hand is better on the ST version.

[ Show youtube player ]

[AestheticDebris]

Originally Posted by dlfrsilver

This is an argument we can hear. But in many cases it just can't explain how wrong things were done.

It mostly does. And the other differences tend to come from the fact that the Amiga was a lot harder to program than the ST. A CPU and simple framebuffer design might be less capable, but it's a lot easier to get right than trying to balance all the different DMA demands to produce an optimal Amiga version.

Originally Posted by dlfrsilver

The real chain for the CPC for good games is CPU+Gate Array+CRTC. This is why Batman the movie and Robocop are top class on CPC and a pile of junk on the C64.

Batman the Movie and RoboCop share a codebase with the Spectrum versions and everything is done in software (aside from a single palette split for the status panel). Ocean certainly took the time to optimise the software routines for the CPC and put the effort into producing machine specific graphics rather than just quick porting it to the 4 colour mode, but it's still the same basic code.

Originally Posted by dlfrsilver

The other thing is the development system used to make the games. Converting or making a game from an Amiga or an ST to a CPC gave much better result than doing it from a C64 or a ZX spectrum. It always works much better from a superior machine from a lower machine, not the other way around.

You can't really take a game from the Amiga/ST and just port it to the CPC - that's going to end as a rewrite anyway. Sometimes graphics would get ported from the ST, although the results were often questionable (see the 128L version of Double Dragon for just how ugly that can end up).

Originally Posted by dlfrsilver

Wrong again. Split rasters are CRTC controlled, not CPU. If you try to make split rasters with the CPU, it will be so slow that it will just won't work.
The CRTC on CPC can be used to make the equivalent of copperlists, like on the Amiga. You can change colors per lines and also per portion of a line, this thanks to the CRTC.

It seems that you don't know well the CPC hardware.....

That's not how the CRTC works at all. It's a bunch of counters that control the position of the screen and what memory addresses will be read. It certainly doesn't run anything like copper lists and has absolutely no control over colours at all.

All the fancy CRTC tricks are the result of precisely timed CPU code modifying CRTC registers at specific times. Colour changes are also CPU based, in that case fiddling registers of the Gate Array at appropriate times. And lots of the timing of that is complicated by the fact there aren't really any timers in the system, except six evenly spaced interrupts per frame.

Originally Posted by dlfrsilver

The CPC is more complex than a ST. With an ST you do everything with the CPU, and hard scrolling are very hard to implement ingame. The CPC has hardware scrollings, and software sprites. This means that you can have huge sprites on CPC that a C64 just could not cope with. Just look at the blinking sprites for example in Dragon Breed C64

When you draw sprites in software, you end up with a more flexible system than fixed hardware sprites. That much is certainly true (and why Amiga coders use Bobs more than Sprites too). CPC games rarely used hardware scrolling though, as it's mostly considered too course - plus it causes additional complexity in addressing the screen (because addresses can wrap mid line) which makes drawing software sprites slower.

In general I'd say comparing C64/CPC is pretty similar to Amiga/C64. One of them relies a lot of hardware features, the other is mostly a software solution. Probably the only real difference is that the Amiga is a lot more capable at also running the software solution that the C64, which struggles a lot more when everything is done by the CPU (hence almost all 3D games being a lot weaker)

Originally Posted by dlfrsilver

And Pinball Dreams uses only 40% of the CPC abilities, while most Commercial CPC games used at best 6% of the CPC capacities.... The CPC was a badly exploited computer back in the day with lots of possibilities that were only waiting to be discovered and used.

Oh, honestly don't buy into that 40% kind of nonsense. It's just demo coder rhetoric to make them look clever. Things like Pinball Dreams are absolutely pushing the hardware as much as they can. If there was some other 60% on unused capacity, don't you think the Devs would use it to make it even better?

Originally Posted by dlfrsilver

It can do pixel scroll. It has been discovered by Longshot/Logon System. Check his compendium this year.

Yeah, kind of. Under very limited circumstances that you might only see in a demo or in something that has been very specifically tailored around allowing the effect.

Originally Posted by dlfrsilver

Well used the CPC can give more than the C64 (without going the 50fps route). Hardware scrolling, huge sprites (ex: Opwolf and Opthunderbolt), good game speed. But only with the hardware chips it uses, and not the CPU alone.

Opwolf and Opthunderbolt are just raw CPU grunt, no hardware scrolling involved at all. They're certainly good examples of what the CPC can pull off when you put the effort in.

[Seiya]

Originally Posted by demoniac

[ Show youtube player ]

in very few games, they used digitized sample audio that is very close or also better than Amiga sound like here:
[ Show youtube player ]

[Megalomaniac]

Lots to pick apart here.

Ordinary players never say the bootblock (even if written 'in clear'), even on pirated copies. Only the pirates saw them.

On what evidence do you make this claim that programmers preferred the ST to the Amiga? I'm not convinced of some sort of industry-wide bias in favour of a less capable machine. Maybe each individual programmer preferred the one they used first, which may well have been the ST as it was an affordable machine so much earlier (late-1985 compared to late-1987 for the A500).

Spectrum R-Type (a lovingly made technically impressive port) and Amiga Crack Down (less so) were indeed mastered by entirely separate people to the programmers, so why blame the programmers for mastering errors?

It's so frustrating that sales figures are so hard to find, even monthly charts aren't as common in magazines as we'd like, but I'm not sure Amiga owners didn't buy ST ports, at least until 1990 or so. You certainly see a lot more copies of Amiga Xenon 2 (an ST port that probably took a few weeks) than you do of Hybris or Battle Squadron (Amiga exclusives developed from the ground up as Amiga code) put together in the UK at least, despite Xenon 2 being now generally considered the weaker game.

Amiga games selling 10 times as many as the ST version is an exaggeration at best - ST Dungeon Master is said to have sold 40,000, what Amiga game sold 400,000? Wikipedia mentions that for the flight sim Falcon in 1988 "the Amiga version sold in six weeks twice as much as the ST version in nine weeks" (in the context of the quote mentioned, I assume that's for the US only - globally it was probably closer than that, but it might be a good ballpark figure for that time). ST Civilization sold over 20,000 in 1993 (in the UK alone, I think), and that was one meg only and nine months after the Amiga version (and 18 months after the PC one), so in the right circumstances (ideally having both 16-colour graphics from the PC and 'clean' 68000 code (that didn't use Amiga hardware trickery) from the Amiga to combine) ST game stayed profitable long after some people think



As for the Amstrad CPC, one issue I've seen mentioned elsewhere with the CRTC is that different CPCs had different, slightly incompatible CRTCs, so games coded to exploit the better ones would fail on the weaker ones. It wasn't on a predictable 'model X has one type, model Y has the other' kind of way, at least with A1200/STe/128K Spectrum its easy to tell buyers whether a game will work on their machine.

Have any CPC coders made any games that fully exploit Longshot's scrolling trickery? Until you've made a game with it, its advantages and potential is purely theoretical.

Comparing Amstrad v Spectrum to Amiga v ST is interesting - in each case the latter has more advanced hardware but a (roughly) 10% slower processor. However, my non-technical impression is that converting good Spectrum code to get adequate Amstrad code was more work than converting good ST code into adequate Amiga code, for a few reasons (correct me if I'm wrong). The Amiga did at least support the ST's screen mode and colour depth, so a lazy conversion from ST to Amiga could still be as good as the ST version, albeit much further from system potential than it was on the ST. The Amstrad couldn't do the Spectrum's 256x192 screen mode, you had either 320x200 in 4 colours or 160x200 in 16, so massive rewriting was needed to avoid everything looking squashed or the screen area being too small. Also, the Spectrum's screens took up a lot less memory, hence most Spectrum games scrolling smoothly. What scrolled smoothly on the Spectrum needed reworking to do so on the Amstrad, whereas anything that scrolled adequately on the ST would automatically scroll adequately on the Amiga.

[AestheticDebris]

Originally Posted by Megalomaniac

The Amstrad couldn't do the Spectrum's 256x192 screen mode, you had either 320x200 in 4 colours or 160x200 in 16, so massive rewriting was needed to avoid everything looking squashed or the screen area being too small. Also, the Spectrum's screens took up a lot less memory, hence most Spectrum games scrolling smoothly. What scrolled smoothly on the Spectrum needed reworking to do so on the Amstrad, whereas anything that scrolled adequately on the ST would automatically scroll adequately on the Amiga.

The Amstrad display is flexible enough that you can do 256*192*4 without effort. The problem with lazy ports is dealing with the colour depth.

Spectrum games typically store a sprite as a single bitplane and a single bitplane mask, but that's not optimal for the Amstrad. If you treat it's chunky representation of screen data as 3 colours+transparent, you can more optimally store sprite data in the same amount of memory and with less CPU overhead.

So lazy ports are typically keeping the data in a Spectrum style format and then remapping it on the fly whereas more carefully handled ports reprocess all the data at least so that it's more aligned with the screen format (and ideally actually recolouring them to either 3 colours or even the full 16 colour Mode 0).

[dlfrsilver]

It mostly does. And the other differences tend to come from the fact that the Amiga was a lot harder to program than the ST. A CPU and simple framebuffer design might be less capable, but it's a lot easier to get right than trying to balance all the different DMA demands to produce an optimal Amiga version.

For sure the Amiga is more difficult to program. But honestly, any good coder out there learnt and knew how to do the balance. Otherwise we would had no Amiga games and only junk games. What i pointed is that once the Amiga is done, the ST version is straight forward to do, but not the other way around.

Batman the Movie and RoboCop share a codebase with the Spectrum versions and everything is done in software (aside from a single palette split for the status panel). Ocean certainly took the time to optimise the software routines for the CPC and put the effort into producing machine specific graphics rather than just quick porting it to the 4 colour mode, but it's still the same basic code

Batman the movie and Robocop use an hard scroll through registers 12 & 13 of the CRTC. It's not a simple 'let's all do it with the CPU' game. The best CPC games makes use of the CRTC chip. Mike Lamb did not optimised, he programmed Batman and Robocop with advanced features. With the CPU only in the CPC, you get quite bad results. And then the ZX spectrum version is different from the CPC version, the playability is not the same, etc. Batman the Movie CPC is in fact a 16bits ports. Graphics were made on an ST, and the game was coded in a Z80 tool chain
running also on Atari ST. The Enemies in the CPC version are as nasty as in the Amiga or ST version. When you look at the ZX version, you see the IA is weaker, as is the C64 version of batman the movie (stupid enemies, no IA, shoot in 4 directions only, etc).

You can't really take a game from the Amiga/ST and just port it to the CPC - that's going to end as a rewrite anyway. Sometimes graphics would get ported from the ST, although the results were often questionable (see the 128L version of Double Dragon for just how ugly that can end up).

Of course it works! I talked with enough devs from back in the day, and very often, they had tools to convert Amiga and ST assets to either 4 colors mode 1 graphics, or mode 0 16 colors. And it worked better than converting from ZX spectrum or C64 (honestly, publishers did that for a short period, but the result was so bad that they stopped. Regarding Double Dragon 128k on CPC you're wrong. Richard Aplin back ported everything from the Amiga. The problem however, was that he had no graphist to fix the bad conversion colors (look Final Fight amiga, it's crude graphics ported from the Arcade, with no rework).

That's not how the CRTC works at all. It's a bunch of counters that control the position of the screen and what memory addresses will be read. It certainly doesn't run anything like copper lists and has absolutely no control over colours at all. All the fancy CRTC tricks are the result of precisely timed CPU code modifying CRTC registers at specific times. Colour changes are also CPU based, in that case fiddling registers of the Gate Array at appropriate times. And lots of the timing of that is complicated by the fact there aren't really any timers in the system, except six evenly spaced interrupts per frame.

It's counters, very simply. But they don't only control the position of the screen and what memory addresses will be read. It can act to make hard scrolls through register 12 & 13. And in effect you can do the equivalent of amiga copperlists. Just an example : Strider 2. This game use more than 16 colors on screen, and i'm not talking of the HUD. The main play window is made of rasters, each raster band has its own 16 colors palette. This makes the maps of the game impossible to rip with maptapper, which doesn't support this mode for instance (i'm doing CPC level map rips for the CPC power website).

Next, how do you think the CPC demos are done ? They're not done with only the CPU. When the CRTC emulation is not correct, the colors and positions are fucked up. This is why saying the CPC only use the CPU to display things is incorrect. I'm in contact since long year with CNGSOFT, he is a friend of mine, and i have sided with him regarding CPC emulation support. So i'm well aware of the CPC internals.

When you draw sprites in software, you end up with a more flexible system than fixed hardware sprites. That much is certainly true (and why Amiga coders use Bobs more than Sprites too). CPC games rarely used hardware scrolling though, as it's mostly considered too course - plus it causes additional complexity in addressing the screen (because addresses can wrap mid line) which makes drawing software sprites slower.

For sure. But you need some CPU power also, It's not a free feature. Quite a number of games uses hardware scrolling on CPC. 19 games uses vertical hard scroll, and 40 games using horizontal hard scroll. That's very limited, very few coder tried to do something good. The best example is out of this world from ariolasoft. It uses Horizontal Hard Scroll + Overscan hard scroll. Quite a number also use Hardware double buffer.

In general I'd say comparing C64/CPC is pretty similar to Amiga/C64. One of them relies a lot of hardware features, the other is mostly a software solution. Probably the only real difference is that the Amiga is a lot more capable at also running the software solution that the C64, which struggles a lot more when everything is done by the CPU (hence almost all 3D games being a lot weaker)

The C64 is out of reach from the Amiga regarding the possibility and the hardware possibilities, the comparison just can't be done. The C64 has limited hardware tricks, that were in many cases badly used. The first example coming to mind is Batman the Movie, where when batman is falling, he is like falling on the moon with no gravity. On the CPC version, when you fall, you fall. It's done in software but correctly executed.

The CPC has more grunt, the C64 is too much assisted with its weak CPU.

Oh, honestly don't buy into that 40% kind of nonsense. It's just demo coder rhetoric to make them look clever. Things like Pinball Dreams are absolutely pushing the hardware as much as they can. If there was some other 60% on unused capacity, don't you think the Devs would use it to make it even better?

I don't buy anything The Batman Group is probably the most enlighted group of devs, which know the CPC better than almost anyone out there. So yes, when Rhino says PD uses only 40% of the CPC abilities, he is right. There is still 60% to be explored. Thinking that Pinball Dreams is sucking out all the CPU power at the limit is just wrong. Your opinion was "true" in the 80's. We are in 2023, and we know that the CPC can do much much more. As said above, most commercial games of the CPC era were underusing completely this computer.

Yeah, kind of. Under very limited circumstances that you might only see in a demo or in something that has been very specifically tailored around allowing the effect.

Well let's see what the future will bring. Vespertino will be the next game to come

Opwolf and Opthunderbolt are just raw CPU grunt, no hardware scrolling involved at all. They're certainly good examples of what the CPC can pull off when you put the effort in

Both use an hardware double buffer, which allows a smooth horizontal scrolling.

[dlfrsilver]

Originally Posted by Megalomaniac

Lots to pick apart here.

Ordinary players never say the bootblock (even if written 'in clear'), even on pirated copies. Only the pirates saw them.

I'm curious and i always looked at the bootblock. However, i missed most message inside the game code.

On what evidence do you make this claim that programmers preferred the ST to the Amiga? I'm not convinced of some sort of industry-wide bias in favour of a less capable machine. Maybe each individual programmer preferred the one they used first, which may well have been the ST as it was an affordable machine so much earlier (late-1985 compared to late-1987 for the A500).

Devs are not machines or robots. They are like us, human beings, with preferences. Just to make it clear, there were even fanboys in the Dev teams.
Exactly like in the users base of each machine. And of course, they did their best to make shine the machine they prefered, and make the game less good on the machine "not in their heart". To be honest, that's a normal human reaction

Just to illustrate with an example, publishers were ordering games to the dev teams as an "order". When they asked for ST games as lead, devs were ok. When the publishers started to ask games with Amiga as lead, Devs in interviews were already pointing that they were not keen to that, but since they had no choice, because the one who pay is the one who decide, you got some silly messages either on the bootblocks or hidden in the game code regarding that matter.

Spectrum R-Type (a lovingly made technically impressive port) and Amiga Crack Down (less so) were indeed mastered by entirely separate people to the programmers, so why blame the programmers for mastering errors?

as i said above, the mastering error on R-type speccy was done by someone at Speedlock Associates when mastering. Bob Pape explained that in his book regarding development.

It's so frustrating that sales figures are so hard to find, even monthly charts aren't as common in magazines as we'd like, but I'm not sure Amiga owners didn't buy ST ports, at least until 1990 or so. You certainly see a lot more copies of Amiga Xenon 2 (an ST port that probably took a few weeks) than you do of Hybris or Battle Squadron (Amiga exclusives developed from the ground up as Amiga code) put together in the UK at least, despite Xenon 2 being now generally considered the weaker game.

We have quite a number of games with the sales figures. Amiga owners got so much fed up with ST shovelwares that they sent mail to the magazines to report their anger, stating that they did not paid for the better machine, just to get straight ports of the Atari ST made with no care. Then the Amiga software sales went over the ST software sales. The publishers then heard the message, and started doing amiga first games.

This is why games released between 1987 and 1988 on Amiga are for some very hard to find : they sold badly at the time, because it was the ST shovelware era, and Amiga users did not wanted them.

Even a great dev like Jez San said it in interview : "Amiga users are buying more softwares than ST users".

Amiga games selling 10 times as many as the ST version is an exaggeration at best - ST Dungeon Master is said to have sold 40,000, what Amiga game sold 400,000?

You're misinterpreting my words. I have not said Amiga games sold 10 times as many as ST version, i have said that for 1 original game on ST sold, 10 originals were sold on Amiga. It's not exactly the same thing.

Lemmings Amiga sold 500.000 units alone. I don't even speak about the data disks and the sequels released afterwards.

Most ST games sold between 10.000 - 40.000 copies at best. You average amiga title sold between 40.000 - 80.000 copies.

You see the difference in term of benefits at the end of the day for the publishers ? This is the reason why they stopped developping on the ST and making commercial games on it.

Wikipedia mentions that for the flight sim Falcon in 1988 "the Amiga version sold in six weeks twice as much as the ST version in nine weeks" (in the context of the quote mentioned, I assume that's for the US only - globally it was probably closer than that, but it might be a good ballpark figure for that time).

You see my point ? Falcon is not the only case.

ST Civilization sold over 20,000 in 1993 (in the UK alone, I think), and that was one meg only and nine months after the Amiga version (and 18 months after the PC one), so in the right circumstances (ideally having both 16-colour graphics from the PC and 'clean' 68000 code (that didn't use Amiga hardware trickery) from the Amiga to combine) ST game stayed profitable long after some people think

You should get the sales of Civilization Amiga, just to see the huge gap.
As i said above, imagine, Civilization was a top class game and it only sold 20.000 copies on Atari ST. Civ Amiga requires 1mb of ram too. Civilization most probably doesn't use the Amiga hardware. It's a game coded in C ported from the PC version with ASM parts. 20.000 copies is not profitable, it's very average. Just for the record, Maupiti Islands sold 15.000 copies on Amiga, ST, PC. the game is cult, but it was not a best seller.

As for the Amstrad CPC, one issue I've seen mentioned elsewhere with the CRTC is that different CPCs had different, slightly incompatible CRTCs

You talk about CRTC 2. Only specific models used this one. Most 464 and 6128 used CRTC 0 and 1, which are mostly compatible.

so games coded to exploit the better ones would fail on the weaker ones. It wasn't on a predictable 'model X has one type, model Y has the other' kind of way, at least with A1200/STe/128K Spectrum its easy to tell buyers whether a game will work on their machine.

Of course not. You have routines that allows to detect which type of CRTC your CPC have without opening it. Some game included both CRTC 0 and 1 routines for compatibility.

Have any CPC coders made any games that fully exploit Longshot's scrolling trickery? Until you've made a game with it, its advantages and potential is purely theoretical.

It has been discovered in 2023. Let some time to the devs to use and master it.

Comparing Amstrad v Spectrum to Amiga v ST is interesting - in each case the latter has more advanced hardware but a (roughly) 10% slower processor.

It depends how it's coded as usual.

However, my non-technical impression is that converting good Spectrum code to get adequate Amstrad code was more work than converting good ST code into adequate Amiga code, for a few reasons (correct me if I'm wrong).

Mmhhh not exactly. In both cases, it took few time, the problem is the end result. easy for the dev, a pain in the ass and a crap game to the end user.

The Amiga did at least support the ST's screen mode and colour depth, so a lazy conversion from ST to Amiga could still be as good as the ST version,

As good ? It depends what you mean by as good. In most cases, the game was already weak on ST, and then with the ST to AM process, you get exactly the same crap on Amiga.

[/quote].....albeit much further from system potential than it was on the ST. The Amstrad couldn't do the Spectrum's 256x192 screen mode, you had either 320x200 in 4 colours or 160x200 in 16, so massive rewriting was needed to avoid everything looking squashed or the screen area being too small. Also, the Spectrum's screens took up a lot less memory, hence most Spectrum games scrolling smoothly. What scrolled smoothly on the Spectrum needed reworking to do so on the Amstrad, whereas anything that scrolled adequately on the ST would automatically scroll adequately on the Amiga.[/QUOTE]

You're kidding ? The 256x192 screen mode the CPC can do it in its sleep. There's not enough Speccy port in the wild ?

Anything that scrolled fine on the ST would do on the Amiga ? ahaha
No way, Hosé ! It doesn't work like that. The Amiga is not made to run games with "software shit scrolling". It was a recipe for catastrophy.

Just look Black Tiger. I digged the code and ressourced it, and the only hardware access it does on Amiga is the Vblank register, and the potgo register for joystick access/support. Everything else is an insane shit done in software.

[saimon69]

Originally Posted by dlfrsilver

Just look Black Tiger. I digged the code and ressourced it, and the only hardware access it does on Amiga is the Vblank register, and the potgo register for joystick access/support. Everything else is an insane shit done in software.

How long would take to rewrite that so that instead of calling its own scroll routines it goes to blitter? Just curious
(the guy that tried to rewrite from scratch seems undefinitely swamped)

[Megalomaniac]

Interesting explanation on the CRTCs. If 0 and 1 perform differently, does that mean that the game that scrolled perfectly on your mate's CPC might scroll badly on yours? Was one better for all games, or did it vary depending on which was being targetted by the programmer? Was CRTC 2 a later design that was the best of both worlds, did games designed for either 0 or 1 work perfectly on it?

Upgrading an ST to 1Mb was a bigger job than on the Amiga, and a far smaller proportion of STs or STes left the shops with 1Mb or more than Amigas did, that's why I mentioned ST Civ selling quite well (long after the machine's commercial peak) despite being 1Mb only.

Can the CPC do the Spectrum's 256x192 in 8 colours (let alone the 15 that the BRIGHT mode allows for)? A lot of (lazily) converted games can look quite squashed and not use the full screen. Obviously there's no colour clash on the Amstrad, but 160x200 is the maximum resolution for more than 4 colours.

There are ST games which scroll well enough, vertical scrollers mostly. If the code that's already there to do that on the ST does basically work, it can be reused on the Amiga. My point was that it's quicker to get ST code to work on the Amiga, than to get Spectrum code to work on the Amstrad.

[AestheticDebris]

Originally Posted by dlfrsilver

Batman the movie and Robocop use an hard scroll through registers 12 & 13 of the CRTC. It's not a simple 'let's all do it with the CPU' game. The best CPC games makes use of the CRTC chip. Mike Lamb did not optimised, he programmed Batman and Robocop with advanced features. With the CPU only in the CPC, you get quite bad results. And then the ZX spectrum version is different from the CPC version, the playability is not the same, etc. Batman the Movie CPC is in fact a 16bits ports. Graphics were made on an ST, and the game was coded in a Z80 tool chain
running also on Atari ST. The Enemies in the CPC version are as nasty as in the Amiga or ST version. When you look at the ZX version, you see the IA is weaker, as is the C64 version of batman the movie (stupid enemies, no IA, shoot in 4 directions only, etc).

It's exactly the same code between the Spectrum and Amstrad versions. I can beat them both on the same muscle memory, every enemy attacks in the same way at the same point.The graphics have been reworked, but they also clearly aren't from the Amiga or ST version in either case.

Originally Posted by dlfrsilver

It's counters, very simply. But they don't only control the position of the screen and what memory addresses will be read. It can act to make hard scrolls through register 12 & 13. And in effect you can do the equivalent of amiga copperlists.

The CRTC controls the position of the screen, the length of hsync and vsync pulses and the memory addresses the gate array uses to read an interpret screen bytes. You can use this in simple ways to do coarse character based scrolling or to double buffer the display (not often used on 64K games because each screen buffer is 16K and sacrificing half the RAM for double buffering is usually too extravagant). You can also abuse it by doing things like setting very short hsync pulses that the monitor will ignore, but will trick the rest of the system into displaying a second "frame" within a single pass of the display beam (known as rupture splitting). You can also cause some CRTCs to display border colour mid screen, or bend the screen by making rapid changes to screen position and relying on the analogue response of the monitor.

But everything to do with on screen colours or pixels is a result of changes to gate array registers. And only the CPU can change those, so mid screen colour changes have to be done with timed CPU code. Even on the Plus machines (which so have a form of copper-like DMA-based processor, that is intended for audio but can be abused to generate frequent line interrupts) there is no way of changing colours other than the CPU doing it.

I know this not because someone explained it to me, but because I've coded for these machines for decades and I'm well aware of what they can (and can't) do.

[AestheticDebris]

Originally Posted by Megalomaniac

Interesting explanation on the CRTCs. If 0 and 1 perform differently, does that mean that the game that scrolled perfectly on your mate's CPC might scroll badly on yours? Was one better for all games, or did it vary depending on which was being targetted by the programmer? Was CRTC 2 a later design that was the best of both worlds, did games designed for either 0 or 1 work perfectly on it?

Not really. Things like hardware scrolling and positioning of the screen are well within the spec of the CRTC and work the same on all variants. It's when you get into the weird edge cases, the side effects of making changes with very specific timing etc that things diverge. A demo might not look correct, but it's not something you'd experience in commercial games.

[dlfrsilver]

Originally Posted by saimon69

How long would take to rewrite that so that instead of calling its own scroll routines it goes to blitter? Just curious
(the guy that tried to rewrite from scratch seems undefinitely swamped)

I just don't know He did much better than me on the coin op, he has documented the source !

And yes, he is missing completely