View Single Post
Old 03 January 2013, 13:45   #13
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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".

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.
Mrs Beanbag is offline  
Page generated in 0.09328 seconds with 9 queries