Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!rosie!aozer From: aozer@next.com (Ali Ozer) Newsgroups: comp.sys.next Subject: Re: Low End NeXTs (was Re: Desktop publishing) Message-ID: <457@rosie.NeXT.COM> Date: 8 Apr 91 04:38:54 GMT References: <34936@athertn.Atherton.COM> <1991Apr3.220544.22348@cs.ubc.ca> Sender: news@NeXT.COM Distribution: na Organization: Next Computer, Inc. Lines: 54 Nntp-Posting-Host: twinpeaks.next.com In article Scott Hess writes: >In article <1991Apr3.220544.22348@cs.ubc.ca> Stuart Ritchie writes: >> About BlastApp: great game. Highly addictive. But one thing that >> worries me is this. I remember reading a disclaimer somewhere saying >> that the game may suffer performance problems on a 030 machine. ... >> I'm really worried about this. Even with a tiny window like BlastApp >> has, is DPS really that much of a bottleneck? Or were there some >> efficiency compromises made by the implementor? Where does the real >> bottleneck lie? >To see what DPS can do, take a look at Stuart (no pun intended, Stuart!). >DPS gives a much larger window of performance possibilities than >many other windowing systems, such as X or QuickDraw. Scott is right: Look at Stuart, or look at BoinkOut. These apps show that DPS can be real fast. Or look at co-Xist, which goes through DPS. It's fast. One of the best things about BlastApp is how quickly it was designed and implemented: Excluding the time it took to create the levels, draw the various objects, and come up with reasonable (well, semi-reasonable) sounds, the whole game took four days to write, half of which was spent designing and the rest implementing & debugging. I've worked on many computer games in my life (none professionally), and not many made to completion: Many years ago, before I knew better, I'd start writing code as soon as I got the idea for a new game and that usually led to an early doom. Later I learned to design before implementing. However I'd spend so much time trying to come up with a reasonable design that I usually would get sick of the whole thing before any reasonable amount of code was written... Thus I was thrilled to see BlastApp get to its current state in only four days. Sure, it could use some more levels, and could be faster --- but that can all be done afterwards. Adding levels or even new types of objects is trivially easy (actually you can add new levels without even recompiling, hint, hint), and many performance optimizations can be made in the way the game draws, in the way different objects interact, etc. There's a lot of room for optimization in the game, and it's all private to the implementation of the various classes --- which means without having to make any changes to the overall structure of the program. After putting four days into creating the thing and some more days designing levels and drawing objects, I decided I was not going to find time to optimize it in the near future so I posted it as is... The bottom line is that a "prototype" such as BlastApp can be created in a short time and be so usable is all due to the power of NeXTstep. Just remember to design first, and design in an object-oriented fashion, and you'll find that you'll be able to create apps with great ease and be able to optimize, tune the UI, or make other changes as necessary later. My two cents! Ali, Ali_Ozer@NeXT.com