Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.programmer Subject: Re: Mike Farren Tutorial. Message-ID: Date: 2 Apr 91 20:03:48 GMT References: <20115@cbmvax.commodore.com> <1991Mar27.012717.11541@starnet.uucp> <18ead851.ARN0f31@icoast.UUCP> Organization: Not an Organization Lines: 83 In article <18ead851.ARN0f31@icoast.UUCP> hbrinch@icoast.UUCP (Henrik Brinch) writes: >In article , Matthew Dillon writes: > >> I agree with Randell completely, all these idiot game writers insist on >> taking over the machine when, in fact, they do not have to. My solution >> alone (simply reduce the task priority of CPU hogging tasks) guarentees >> a game the CPU when it needs it, yet still allows said game to use >> DOS & intuition when/if it needs to. >> >> It just isn't a problem. > >I tell you the problem. MEMORY - not everybody has 1Mb (or more) and >killing the system will give you app. 200Kb more and the ability for more >sophisticated diskloaders / protections. Memory can indeed be considered a problem, but only for machines that don't have much of it. This is easily determined by AvailMem() and, frankly, if a game can allocate the memory it needs via AllocMem(), it should. A little cleverness, like NOT using an absolute origin, means the game will run that much better on even minimally expanded machines. >(Please don't flame me about this, I'm a system-programmer and wouldn't > kill the system.... I'll do anything to keep that wonderfull system alive!). No flame, it's a good arguing point, and clashes the philosophy of designing for a specific memory mind-set (so to speak), which is frankly a first rate way to program yourself into a corner, as has already been mentioned. >I disagree with you about the absolute ram locations, if you shut down the >system PERFECTLY (interrupts, tasks....EVERYTHING!) then any address from >about $c0-$7ffff should be okay. BUT(!) if the system is partly alive >NO absolute ram locations is allowed (I've learned that from hard experience!). > > >> Matthew Dillon dillon@Overload.Berkeley.CA.US It's too dangerous, just because it works NOW doesn't mean it will work later... at the very least one should AllocAbs() it to make sure it isn't being used, and what happens if you find that it *IS* being used? You can't run your game at all then. Any autoconfig board's driver can allocate memory anywhere, and it can occur before your game starts up, and it can be SENSITIVE to being ripped out from under it.. one cannot make the assumption that the memory is all free. One can't even assume he will be safe if he turns off all the interrupts! This is why so many games break when you, say, have a bridgeboard in your system (though not necessarily for the above stated possible scenerio). The funny thing is that it is so EASY to write relocatable code.. incredibly easy. I fail to understand why game programmers insist on assembling one big program in one shot to an absolute location when development goes much faster when you break it up into smaller modules that generate objects... so when you make a change you are changing only ONE SMALL object module and relinking instead of reassembling the whole thing. It took me about 2 hours to figure out the Amiga object file format, and only 5 minutes to understand the executable format. A game doesn't need to know anything beyond the executable format if it loads/relocs it itself, and even then it could be just as efficient to just use LoadSeg(), depending on your situation. Relocation information does not take that much space, especially when you use the small-data model (i.e. A4-relative). >Best Regards, > >InfoCoast /\ /\_ Henrik Brinch \ cbmehq!cbmdeo!icoast!hbrinch >Technologies /\/ \/ \ Kloevervej 7 \ FidoNet 2:230/112.3 >____________/ \ / \ 2800 Lyngby \ Voice/Fax tel.# +45 42 87 67 23 > / \/ \ Denmark \ "C is SILVER - But ASM is GOLD" -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA