Amiga's most efficient and cleanest coders.

[lordofchaos]

I was wondering what peoples thoughts are on this topic? Is their a particular game or application that was developed on the Amiga that's so well programed it's able to run on a wide range of processors 68000,68020 and Chipets etc...Or a game that has virtually no bugs... I know the later software became more scalable due to the different models they had to support but what about some early examples?

[Lord Riton]

I wrote some program one day, it had not a single bug !

here it is:

print "Hello world !"

[capehorn]

The space between the d and the ! is an error IMO. I also think it can be improved by capitalising the p.

[Photon]

Hehe lordofchaos, as you can tell it was a silly question.

Efficiency and cleanness are opposites on a fixed platform. Also, game programmers at the time didn't seem to have time [in their contracts] for writing clean or efficient code. Some purposely didn't (for cross-platform purposes). Also, there is no motivation to write beautiful code for a commercial product, but much more motivation to make the game fun, impressive, and appealing. I wouldn't say that motivation exists anywhere, or ever has, to be honest. Many coders cared about delivering proper and tested code, with a little optimization here and there, though. But it's quite clear that only a few coders in its heyday reached what the A500 was capable of.

When it comes to bugs, you really have to compare with the ambition. If you take a football type game, simple shooter, or platform jumper, there really isn't that much advanced code going on.

If you have a game containing a galaxy of planets that you can travel to with a crew and accelerate time as well as render this universe correctly, you have a whole set of new ambitious pieces of code that have to work together. Therefore I would suggest Braben and Woakes. I'm overlooking a bunch of programmers, of course. For example, Braybrook was a great coder, held back a little in performance by Graftgold's object-oriented programming system. While he wasn't "greedy in ambition", he nevertheless finished some ace game I still enjoy now and then.

If you're asking cos you're getting bugs in WHDLoad, that's a completely different story. The WHDLoad gang are adapting code written before accelerators and AGA existed, and it's generally hard to make all WHDLoad slaves work with such a rig. Very few games bugged at all on A500/kick 1.3. Maybe 1 out of 100, if that.

[Mrs Beanbag]

I write cleaner code now than I used to, I find it actually makes it easier to write, to maintain, and to extend. I program in an almost object-oriented style in Asm these days. But being able to support different processors really shouldn't be a problem... if you write for plain 68000 user mode it should work on anything, but for some reason a lot of game and demo coders felt the need to go into supervisor mode, I don't know why. And they didn't even do that the proper way.

The other thing that can screw things up is writing wherever you want in memory instead of using the OS functions to reserve memory, that's just plain lazy as far as I'm concerned, there's no excuse and you're just making trouble for yourself.

There were some A500 games that wouldn't work if you had fast RAM, I don't know why, maybe they did use the OS to reserve memory but didn't request Chip RAM for graphics and sound. Really basic error.

[StingRay]

Originally Posted by lordofchaos

Or a game that has virtually no bugs...

A game without bugs does not exist!

Originally Posted by Photon

Very few games bugged at all on A500/kick 1.3. Maybe 1 out of 100, if that.

That's quite a bold statement. There sure are bugs in every game, some obvious, some not so!

[discomeats]

Will this result in a "what games had the most bugs" thread?

[Photon]

Originally Posted by Mrs Beanbag

I program in an almost object-oriented style in Asm these days.

So each graphical element, sound effect, etc inherits a constructor and destructor from a general object that allocates its own space? And your garbage collection is running as a background task in the game when CPU load is less?

Not saying that you couldn't make such a game, but *cough* perhaps you're exaggerating a bit? I think you mean you make bobs objects by adding a few properties and some jump pointers, which is commendable, but just neat packaging really!

BTW, there's a way of making a bob delete+blit (move) itself (and "everything else" itself) which is very neat and doesn't waste many cycles (and faster than a blitter interrupt!), making the main render loop a simple list of calls.

Originally Posted by Mrs Beanbag

[...]for some reason a lot of game and demo coders felt the need to go into supervisor mode, I don't know why. And they didn't even do that the proper way.

Well, the basic answer is that they were trying to do their job. If you're going to take over the hardware, you can't do like some coders and just use the stack at whim in interrupts. You need to know where it is (i.e. set it), so you know you won't decrunch some graphics over the return address from an interrupt. If you don't know where the SSP is in your game, I suggest you find out - or refrain from using interrupts.
So any proper track-loaded game (in the day when Amiga games cost money) would be expected to stop interrupts, stop the processor and prefetching a div #0,d0 or similar Preferably also killing cartridge buttons and using longtracks.

Originally Posted by Mrs Beanbag

The other thing that can screw things up is writing wherever you want in memory instead of using the OS functions to reserve memory, that's just plain lazy as far as I'm concerned, there's no excuse and you're just making trouble for yourself.

If you kill the interrupts and take over the hardware, the hardware is yours, of course, including all the memory the OS previously used. Just use the OS functions to find out what hardware you have first (see "documentation" below)

Originally Posted by Mrs Beanbag

There were some A500 games that wouldn't work if you had fast RAM, I don't know why, maybe they did use the OS to reserve memory but didn't request Chip RAM for graphics and sound. Really basic error.

Games written before the A500 should be excused, since about zero Amiga users owned fastmem expansion before then (see "documentation" below). Also, with kick 1.3 the included OS command "FastMemFirst" screwed up some CLI/WB games. Some trackloaded games may have missed a few exotic fastmem expansions later on, but the main problem was that most of the games didn't even utilize more than the first 512K until about 1990...!

I've never had to switch off my slowmem expansion on my A500 in order to play a trackloaded game, ever.

Pretty much all of the "future incompatibility bugs" can be blamed on C= for not providing as good and explicit hardware and OS documentation as everyone else. They really didn't see the Amiga as having anything to do with games and Assemblers at all.

The early game developers did f*cking great under the conditions at the time! (Not all games were great, of course, and many wrote slow code.)

Originally Posted by StingRay

[Re: my "<1 of 100 A500 games are buggy"]
That's quite a bold statement. There sure are bugs in every game, some obvious, some not so!

Well, you're a proper coder who has converted many games to WHDLoad, so safe to say you have seen some atrocious practices, maybe even code that works by sheer luck.

But I mean buggy to someone who plays the game, ruins your game for you (like this: ), not ones with shaky code, the occasional stutter or graphical glitch, or some enemy not moving when he's supposed to if you died near him, that kind of thing.

Many bugs were due to the vast majority of games released (so far) were coded for kick 1.2/1.3 (and later kicks (primarily kick 2.0) being so incompatible). I think arguing C= swapping out the OS in 1992 from under the feet of some game made in 1988 doesn't make it buggy - with the exception of calling fixed ROM addresses, of course.

Today, if I want to play an Amiga game, I put a floppy in my A500 kick 1.3 (which happens to have an A2000 HDD interface+8mb fastram+slowram), and every single game I have just works. There should be such a perfect platform for WHDLoad games, but I haven't found one yet. My A500+040 or without it, my A600+ACA630 or without it, or my A1200-060 is simply not one of them. Always some game doesn't recognize the exit key or throws an exception. WHDLoad works best on my A1200-060, and WHDLoad is definitely my choice to play AGA games, but it's clear that the WHDLoad wrapper/slaves hasn't rid OCS games of the bugs with the same success rate as just putting a floppy in an A500.

If only more people would put their floppy in their A500...

[Harry]

Just to put some numbers in the room:

Of the about 70 games I installed, there were the following problems I can remember from memory, present on a stock A500:

Naughty Ones crashes if you play the bonus level too long, by collecting all the hearts
RocknRoll hangs if you fall in an abyss and try to roll out of it while falling down - you roll back, but cannot move when you reached solid ground again (not fixed yet in the install)
German version of Dragon Wars crashes in various places
Deflektor crashes if you try to turn a mirror in both directions at the same time, possible with keyboard control on my A2000
Atomix has a preset hiscore entry of 900000, but the highest possible score is only about 360000
Jumping Jackson has a score overflow
German Thunderhawk has manual questions which are impossible to answer

So the amount of major errors even present on the target system is rather 10%.

[Galahad/FLT]

Powermonger has a problem in that if you watch the introduction sequence right until the very end, the game will hang before it loads properly meaning it won't play.

[Codetapper]

The Real Ghostbusters has an end sequence, but if you complete the game it gets stuck in the high score table code and you can't do anything (except reboot). If you fail to complete the game, the high score routine works.

Summer Camp was duplicated with some corrupt data causing the music to play bizarre samples. Don Adan fixed this by copying the correct samples from another game (as Dave Lowe reuses several samples in a lot of his games!)

Afterburner also suffers from a corrupt sample problem. Track 15 was duplicated badly causing sound corruption.

Puzznic has a faulty palette while loading the title screen, one of the palette entries was missed so the colours are bizarre. Shifting the table by one word fixes the problem.

There are also a few games that hit the kickstart 1.2 ROM routines directly thus consigning them to only working on kickstart 1.2. They do things like assume a routine is at a particular address or that the topaz font is at a certain memory address.

[Photon]

Galahad, Codetapper: that's pretty much what I mean about separating bugs-on-certain-platforms from errors-in-programming. I already mentioned "direct ROM calls are bad, mkay??" and WHDLoad insists on running the original game, which is great, but if errors occur in copying the originals you can't really blame the developer or publisher who added copy protection (and most all of them offered to swap disks if a disk was bad, it did happen since 3.5" was relatively new). You know all this of course, I'm just stating it for the record for others.

Originally Posted by Harry

Just to put some numbers in the room:

Of the about 70 games I installed, there were the following problems I can remember from memory, present on a stock A500:

Naughty Ones crashes if you play the bonus level too long, by collecting all the hearts
RocknRoll hangs if you fall in an abyss and try to roll out of it while falling down - you roll back, but cannot move when you reached solid ground again (not fixed yet in the install)
German version of Dragon Wars crashes in various places
Deflektor crashes if you try to turn a mirror in both directions at the same time, possible with keyboard control on my A2000
Atomix has a preset hiscore entry of 900000, but the highest possible score is only about 360000
Jumping Jackson has a score overflow
German Thunderhawk has manual questions which are impossible to answer

So the amount of major errors even present on the target system is rather 10%.

My definition of a game being buggy is that you can't finish it. The rest is just poor design. Should we call the horrible unplayable collision detection in Xenon 2 a "bug"?

Make sure also that you're calling a game buggy, and not the crack of it. Just to make sure, you say "installed" and "installer" - is this cracks or originals, on floppy, on the A500+512k slowmem? (Because that was the 'optimal platform' my claim was about, just to make clear.)

I've not been able to hang Rock'n'Roll, and I've played it a lot. (As a curious fact I whistled the title tune this afternoon.)

The Atomix one is evilness by the programmer but I wouldn't say that makes it unplayable or crashy. If I know crackers they may have jacked up hiscores even higher on some games

[Mrs Beanbag]

Originally Posted by Photon

So each graphical element, sound effect, etc inherits a constructor and destructor from a general object that allocates its own space? And your garbage collection is running as a background task in the game when CPU load is less?

Not saying that you couldn't make such a game, but *cough* perhaps you're exaggerating a bit? I think you mean you make bobs objects by adding a few properties and some jump pointers, which is commendable, but just neat packaging really!

Well I did say "almost"! A lot of my code is quite old, but I am working towards that. Although garbage collection isn't a defining feature of Object Orientation, it is merely "common". Personally I prefer to enforce a concept of scope, and link counters. Don't confuse OOP for "Java and its clones" Even if you are doing garbage collection, it could be done at any time (for instance after completing a level), it doesn't have to be a background task. In fact I do a simple sort of garbage collection upon exiting back to DOS because I keep all my pointers to reserved memory in a contiguous area.

Although I guess it would be fair to say that the stage I'm at now is closer to C than C++... but I'm planning an Object Oriented scripting language for "Beanbag Creator".

Well, the basic answer is that they were trying to do their job. If you're going to take over the hardware, you can't do like some coders and just use the stack at whim in interrupts. You need to know where it is (i.e. set it), so you know you won't decrunch some graphics over the return address from an interrupt. If you don't know where the SSP is in your game, I suggest you find out - or refrain from using interrupts.

If one has reserved memory using the OS functions, it is surely guaranteed the SSP won't point into it, surely? And it is possible to use interrupts in an OS-friendly way, VBL interrupts at least.

So any proper track-loaded game (in the day when Amiga games cost money) would be expected to stop interrupts, stop the processor and prefetching a div #0,d0 or similar Preferably also killing cartridge buttons and using longtracks.

Why not do a Supervisor() exec call? And is there an advantage of trackloaders aside from avoiding the filesystem overhead? Attempts at copy protection didn't seem to stall the crackers for very long. But I guess they had to try.

What is a "cartridge button"?

If you kill the interrupts and take over the hardware, the hardware is yours, of course, including all the memory the OS previously used. Just use the OS functions to find out what hardware you have first (see "documentation" below)

Fine as long as you don't want to return to DOS afterwards! Everyone treated the Amiga like a console in those days.

Games written before the A500 should be excused, since about zero Amiga users owned fastmem expansion before then (see "documentation" below).

While true, Commodore can hardly be blamed for this. Were they meant to not release memory upgrades in case it broke some games? Even with bad documentation, surely they mentioned the difference between Chip and Fast somewhere?

I guess people were still programming the way they always had on the 8-bits. Up until that point home computers didn't really get upgrades, they stayed more-or-less the same for their entire product life, there were about a hundred different platforms that weren't mutually compatible in any way and every so often someone just invented another one (and the C64 was still going strong for some years). Amiga broke that trend, with its "internally 32 bit" 68000 it was ready for the future.

[lordofchaos]

Wow, some very interesting comments indeed, I would be lying if I said I completely understand all the terminology but very interesting all the same I must confess I love reading coders talk about their craft.

Oh and when I said a game with "virtually no bugs", I meant more along the lines of a game having no real obvious game breaking bugs or at least none that are instantly noticeable, I'm not so naive to think there are games without bugs.

A part of me wishes to be a kid again so I can stop worrying about game bugs and seeing all the imperfections and just enjoy the dam thing for what it is. Although thanks to the WHDLoad crew I've been enjoying more Amiga games than I ever did

[hooverphonique]

I tend to agree with Mrs Beanbag here.. A lot of the problems was due to coders not adhering to the rules (for whatever reason), not due to C= keeping documentation for themselves..

[Minuous]

>Games written before the A500 should be excused, since about zero Amiga users owned fastmem expansion before then (see "documentation" below).

>Pretty much all of the "future incompatibility bugs" can be blamed on C= for not providing as good and explicit hardware and OS documentation as everyone else.

I must disagree, the official hardware manual clearly explains the difference between chip and fast RAM. It it obvious to anyone reading it that using fast RAM instead of chip RAM is not going to work.

[demolition]

Originally Posted by Photon

Pretty much all of the "future incompatibility bugs" can be blamed on C= for not providing as good and explicit hardware and OS documentation as everyone else.

This doesn't fit well with the NASA video where they explain why they chose Amigas to manage the space shuttles. Their reason was that they could get piles of documentation on both the software and the hardware which made it possible for them to make their own hardware additions as well as software and ensure a very high stability. They could not get this from any other computer manufacturer.

[pmc]

Originally Posted by Mrs Beanbag

What is a "cartridge button"?

The little button on a freezer cartridge (such as Action Replay) that you can press to interrupt the currently running software.

Also @Mrs Beanbag - I think views on how to use the hardware and its resources very much depend on your perspective. I tend to share the same perspective as Photon in that my personal preference is to take over the hardware and do whatever I like but the ultra clean approach you advocate is, in my view, equally valid depending on the circumstances.

[Harry]

Originally Posted by Photon

My definition of a game being buggy is that you can't finish it. The rest is just poor design. Should we call the horrible unplayable collision detection in Xenon 2 a "bug"?

Ok, in a sense that you can hardly avoid a bug while playing the game the above list is reduced to 2 (Dragon Wars and RockNRoll). The other problems I mentioned are extremely annoying to me. BTW: I find nothing wrong with the collision detection of Xenon 2, the game is perfectly playable for me.

Originally Posted by Photon

Make sure also that you're calling a game buggy, and not the crack of it. Just to make sure, you say "installed" and "installer" - is this cracks or originals, on floppy, on the A500+512k slowmem? (Because that was the 'optimal platform' my claim was about, just to make clear.)

All problems mentioned by me happen with the original disk(s), and are not memory expansion related. If I counted in the memory detection problems the list would have been longer.

Originally Posted by Photon

I've not been able to hang Rock'n'Roll, and I've played it a lot. (As a curious fact I whistled the title tune this afternoon.)

I have played it a lot, and hung it a lot until I learned not to try to roll out of an abyss, but use the parachute instead.

Originally Posted by Photon

The Atomix one is evilness by the programmer but I wouldn't say that makes it unplayable or crashy. If I know crackers they may have jacked up hiscores even higher on some games

It is very annoying when you have only 2 possible chances of 8 to get a hiscore entry, I qualify this as unusable.

[Galahad/FLT]

@ Mrs.Beanbag, dumping the OS was essential on Amiga to getting the best out of it in the days of 68000.

Returning back to DOS was largely irrelevant, as a reset takes seconds and you can simply load something else, its only with the advent of cheaper expansion ram and cheaper hard drives that having a game quit back to DOS was advantageous.

And the Amiga was first designed as a console, hence its console-eque programming