Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.programmer Subject: Re: Lemmings - a tutorial Part V (last) Message-ID: Date: 31 Mar 91 22:58:44 GMT References: <23788@well.sf.ca.us> <23837@well.sf.ca.us> <781@tnc.UUCP> Organization: Not an Organization Lines: 195 In article mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >So what are the benefits of taking over? > >Well, I am guaranteed that ALL 512K are mine to use. I can ORG any >graphics, code, or audio data at any hard coded location I want. This >practice allows things like blitter routines to have hard coded constant >addresses in them, which saves CPU cycles where you need them the most. Read my lips: YOU CANNOT ORG A HARDWIRED RAM LOCATION, PERIOD Why the @#$#@$ would you want to anyway? Do you know how EASY it is to write a LoadSeg() equivalent to load relocatable executables? It took me less than two days to write my dynamic object loader and THAT deals with full object files, not just executables! What happens when an AutoConfig board allocates ram that just happens to overlap the ram that you DON'T bother to allocate? >I can put graphics screens and the stack anywhere I want. For a 16 >color game, I put the stack at $80000 and a screen at $78000. The >stack needed for any program I write is < 512 bytes. The resulting >memory map gives me from $100 to $78000 to squeeze the game into. And >I do mean squeeze. Arrg. Well, I'll tell you, I had a 450 line response to this whole thing but have decided that it simply is too emotional, so I'm cutting out a large portion of it (nice having an Amiga as a UUCP node, you can go back and fix postings before it batches out).. It's only 200 lines now. suffice it to say that except for the trackdisk.device, all of your tweaking amounts to less than 1% CPU utilization ... MUCH less. Your VBLANK interrupt based task scheme easily eats up 1-2% of the CPU in overhead alone, perhaps you should think less of absolute memory ORGs, using absolute word instead of A4-relative, and OR'ing and AND'ing the SR in supervisor mode and MORE about using better algorithms. You CAN take over much of the OS in a friendly manner and obtain 99.9% of the CPU for your game without SMEARing the OS so bad it requires a reboot. You CAN manage dynamic memory allocation and executable relocation without loosing a single iota of CPU. A single Forbid() goes a long way in a friendly take over, try it. EXEC memory allocation has 0 memory overhead, and you only need do it during initialization. You do NOT have to use OS calls if they are too slow, but you should at LEAST allocate the appropriate resources before you bang on hardware, and fail gracefully if the calls return an error. You do NOT have to make life difficult for yourself adding vapor complications, simple interleaving of CPU computations generally yields a more efficient design without putting the blitter into nasty mode, though it should be noted that there is nothing wrong with doing so per-say (just that you gave yourself a lot of grief trying to program around it after you did so). I think you will find that the performance gained by keeping $DFF000 in A4 instead of a small-data base is, well, negative... completely useless... A4 would be better served used for the small data base. Calculate the cycles required to LEA $DFF000,A0 at the beginning of a routine that needs it. CPU overhead < 1% assuming 500 blit starts / sec The point is, there are LOTS of tricks you can use that are perfectly legal. The end result of most of your illegal tweaking is to gain a few cycles that amounts to NOTHING. Sorry, didn't mean to insult, but you should really do some theoretical work before you write your programs, you'll be surprised. >1.2, 1.3, and 2.0). If the game were written under the OS, you'd have >nightmares testing all the possible software configurations. For example, >does the game work with GOMF installed? How about GOMF and DMouse? How >many possibilities do you see? I see bazillions :) And what if you >allow multitasking and some CHIP RAM pig program (like DPaint) is already Hey, the USER knows about all of that.. .the idea is that if you are OS friendly, nothing dies most of the time. Your solution -- forcing the user to not run ANYTHING, is not a solution because you KILL everything, as in destruct it, reboot when done. >No sh*t sherlock! The blitter is a very powerful coprocessor and >.. >because there is NO index. you are missing the fact that you do not have to share the blitter with the OS, since you don't appear to want to use the OS, you can still obtain the blitter and keep it until your game exits, at which time the OS continues on its merry way as if nothing happenned. >Unfortunately, the sales life of a game is about 3 months. Royalties >don't keep trickling in. Unless you write a really good game, I can think of many that have been on the market for years because they were created with care, very good games, though not necessarily OS friendly. It surprises me that game writers have a tendancy to ignore many amiga platforms... not only that, but ignore the bad press that occurs when most of the games fail to work on the reviewer's Amiga. It tends to cast an image of major greed on the game writers and companies. >The OS is definately worth knowing. I do know it. The first game I did >used the OS (the only one I will ever do that way). I have written >megabytes of software that uses the OS. It is a great OS. No argument >from me. It just is built to outperform a Mac, but not a C64. The >hardware blows away everything from C64s to Macs to the Genesis, but you >wouldn't know it from watching "performance oriented" games that use it. Not to be picky, but do you have any formal education in algorithm and theoretical design? Any operating system classes? graphics classes? Any BOOKS? Your attitude is similar to my attitude during Jr high in terms of programming, one I rapidly abandoned after being introduced to teletypes and, later, UNIX systems. --- There are many, many good algorithms, one does not appreciate how many and how good unless one receives some formal education that relates a few of them. Over the years I have bought thousands of dollars worth of books on algorithms, graphics, languages, and other fields and still don't know half of what interests me. We are not talking about required college reading here. I always surprise myself by finding something new in a field I thought I had mastered, and half of those surprises ends up in a major performance increase to some program of mine, easy to implement because said program was usually written in a high level language. Frankly, most game writers do not have that kind of background, most people WITH that kind of background generally aren't inclined to write games. Being able to say you have written a dozen games only says that you have written a dozen games... from my perspective it sounds quite dull, doing the same sort of thing a dozen times without really LEARNING anything. There is also this feeling amoung game writers, at least the ones I have talked to (possibly owing to the fact that 90% never got past highschool) that all the 'sophisticated' algorithms you learn in college and industry, and use for large highlevel language projects don't apply to games, or them.. They already *know* the best solution. , I always have to laugh at that... there is *always* a better way to do something and you need a good broad background (though not necessarily good grades) to grasp the better ones. --- I am not blanketing assembly language programmers, being one myself... However, I generally do all but the most critical routines in a high level language (C for now), you simply cannot do anything serious in assembly beyond games without taking a LONG time about it. Not everyone is like that... people like Jez are highly professional programmers who PREFER to write in assembly, and easily holds their own in any technical conversation. We spent a while comparing the algorithms used in DAS and ARGASM, the basic difference being that the two assemblers were designed for different end-user applications. DAS needed to have forward referenced branch optimization and support forward referenced XDEFs while ARGASM was designed for speed to assemble megabyte programs fast, and thus is able to forego many optimizations and some forward referencing capabiliy (for XREFs) to accomplish its job in a single pass while DAS does it's job in 5 passes (2 principle), yet DAS is only half as fast as ArgAsm. Similarly, certain DICE c.lib support routines are written in assembly. movmem(), setmem() and siblings, for example, though not strcpy() (DICE does a good enough job that I can leave that in C). You get the idea though, mix and match according to design requirements. >I agree here too. Looking at most Amiga games next to C64 games >makes me want to puke. It is painful to see Amiga games run at 8 >frames per second while the C64 version of the same game runs at >60. There is no excuse for this. If you can't achieve the performance >under the OS, boot it by all means. That is what the C64 guys do. It >is a proven technique. It's a matter of refinement that has nothing to do with the OS. After all, many of the games you are thinking of are most likely written all in assembly and take over the OS, right? :-) And they are still slow. It's all algorithms. The best example is the use of interrupts. Interrupts have a lot of overhead... I mean, a LOT. A directly vectored 68000 interrupt takes 10-20uS just to process! that's interrupt fetch to RTE. If you add even the most simplistic of service chaining or checking (for example, the CIA interrupt must handle 8 interrupt sources) you immediately add, oh, at least 200uS, or 1600 cycles of overhead and you haven't even gotten CLOSE to your interrupt handler yet. Your little task interrupt based on the VBI CIA chain is one of the absolute WORST ways to do it! -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA