Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!rutgers!cbmvax!cbmehq!cbmdeo!icoast!hbrinch From: hbrinch@icoast.UUCP (Henrik Brinch) Newsgroups: comp.sys.amiga.programmer Subject: Re: Mike Farren Tutorial. Message-ID: <18eefaff.ARN0f80@icoast.UUCP> Date: 4 Apr 91 13:36:47 GMT References: <20115@cbmvax.commodore.com> <1991Mar27.012717.11541@starnet.uucp> <18ead851.ARN0f31@icoast.UUCP> Reply-To: hbrinch@icoast.UUCP Followup-To: comp.sys.amiga.programmer Organization: InfoCoast Technologies Lines: 72 > 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, Usually game programmers designed games for 512K (standard) models (at least the past years... probably changing when RAM prices decrease). > 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. > 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). Yep, that's what I found out! Another thought could be the difference in memory allocation between NTSC/PAL models. NTSC screens requires less memory and therefor it can result in memory-allocations a place you wouldn't have dreamed of (as garage-hacker!). > The funny thing is that it is so EASY to write relocatable code.. Some thinks its easier just to put the whole program for $c0 and upward! People who thinks relocatable code is difficult or annoying shouldn't be programming at all :) > 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. Because the average game-programmer hasn't any kind of education in either structured-programming or in how to plan a project. Their knowledge are self-taught and it's hard as h*ll to convince a game-programmer to make use of some of the OS-routines (partly I understand that) but why some doesn't make 680x0 compatible code and some make those damn processor pause's - that's really difficult for me to understand! > 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. What I'm going to say know is probably very "flame-able" but I'll do it anyway : The real programmers can do everything (full control over the system via OS routines or if they want via direct hardware access) - but people who just take's over hardware (av. game-programmers) doesn't know ANYTHING about the OS - they shouldn't really be allowed to call themselves "programmers"! > -Matt 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"