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