English Amiga Board


Go Back   English Amiga Board > Main > Retrogaming General Discussion

 
 
Thread Tools
Old 25 December 2012, 02:51   #1
lordofchaos
TinkerTailorContentMaker

lordofchaos's Avatar
 
Join Date: Nov 2009
Location: Bedfordshire
Age: 39
Posts: 1,025
Amiga's most efficient and cleanest coders.

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?
lordofchaos is online now  
AdSense AdSense  
Old 30 December 2012, 02:10   #2
Lord Riton
Registered User
Lord Riton's Avatar
 
Join Date: Jan 2011
Location: France
Age: 45
Posts: 490
I wrote some program one day, it had not a single bug !

here it is:

Quote:
print "Hello world !"
Lord Riton is offline  
Old 30 December 2012, 02:46   #3
capehorn
Registered User
capehorn's Avatar
 
Join Date: Jul 2008
Location: UK
Age: 34
Posts: 1,268
The space between the d and the ! is an error IMO. I also think it can be improved by capitalising the p.
capehorn is online now  
Old 30 December 2012, 05:17   #4
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,452
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.
Photon is offline  
Old 30 December 2012, 17:48   #5
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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.
Mrs Beanbag is offline  
Old 30 December 2012, 17:59   #6
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,591
Quote:
Originally Posted by lordofchaos View Post
Or a game that has virtually no bugs...
A game without bugs does not exist!

Quote:
Originally Posted by Photon View Post
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!
StingRay is offline  
Old 30 December 2012, 18:24   #7
discomeats
Just add brown sauce.
discomeats's Avatar
 
Join Date: May 2008
Location: North East Englandland
Posts: 170
Will this result in a "what games had the most bugs" thread?
discomeats is offline  
Old 02 January 2013, 22:00   #8
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,452
Quote:
Originally Posted by Mrs Beanbag View Post
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.

Quote:
Originally Posted by Mrs Beanbag View Post
[...]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.
Quote:
Originally Posted by Mrs Beanbag View Post
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)

Quote:
Originally Posted by Mrs Beanbag View Post
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.)
Quote:
Originally Posted by StingRay View Post
[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...
Photon is offline  
Old 02 January 2013, 23:01   #9
Harry
HD Installer
Harry's Avatar
 
Join Date: May 2010
Location: Hamburg/Germany
Posts: 778
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%.
Harry is offline  
Old 03 January 2013, 00:46   #10
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 44
Posts: 6,606
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.
Galahad/FLT is offline  
Old 03 January 2013, 03:49   #11
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,135
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.
Codetapper is offline  
Old 03 January 2013, 04:31   #12
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,452
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.

Quote:
Originally Posted by Harry View Post
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
Photon is offline  
Old 03 January 2013, 14:45   #13
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by Photon View Post
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".

Quote:
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.

Quote:
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"?

Quote:
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.

Quote:
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.
Mrs Beanbag is offline  
Old 03 January 2013, 15:16   #14
lordofchaos
TinkerTailorContentMaker

lordofchaos's Avatar
 
Join Date: Nov 2009
Location: Bedfordshire
Age: 39
Posts: 1,025
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
lordofchaos is online now  
Old 03 January 2013, 18:06   #15
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 710
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..
hooverphonique is offline  
Old 03 January 2013, 18:07   #16
Minuous
Coder/webmaster/gamer
Minuous's Avatar
 
Join Date: Oct 2001
Location: Canberra/Australia
Posts: 1,658
>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.
Minuous is offline  
Old 03 January 2013, 19:51   #17
demolition
Unregistered User
demolition's Avatar
 
Join Date: Sep 2012
Location: Copenhagen / DK
Age: 37
Posts: 3,384
Quote:
Originally Posted by Photon View Post
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.
demolition is offline  
Old 03 January 2013, 23:21   #18
pmc
rebooting...
pmc's Avatar
 
Join Date: Apr 2007
Location: Elsewhere
Posts: 1,595
Quote:
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.

Last edited by pmc; 04 January 2013 at 10:48. Reason: Cos nothing kills a point like pedantry ;)
pmc is offline  
Old 04 January 2013, 00:46   #19
Harry
HD Installer
Harry's Avatar
 
Join Date: May 2010
Location: Hamburg/Germany
Posts: 778
Quote:
Originally Posted by Photon View Post
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.

Quote:
Originally Posted by Photon View Post
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.

Quote:
Originally Posted by Photon View Post
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.

Quote:
Originally Posted by Photon View Post
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.
Harry is offline  
Old 04 January 2013, 01:02   #20
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 44
Posts: 6,606
@ 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
Galahad/FLT is offline  
AdSense AdSense  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Most memory efficient way to run WHDLoad on a 2MB A600? e5frog project.WHDLoad 2 25 July 2010 20:41
remakes on amiga ??? coders wanted turrican3 Retrogaming General Discussion 24 03 October 2007 19:33
Amiga Coders Club (ACC) Daillew request.Other 5 24 July 2007 10:22
A huge challenge to all the Amiga coders/hackers out there! JohnnyWalker project.CARE 6 14 June 2005 23:04
Calling all amiga coders/gfxrs/etc... [crazy :P] Amiga Game Project! Akira Amiga scene 81 29 June 2004 05:10

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 21:14.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.47320 seconds with 11 queries