From: "John Luebs" Newsgroups: comp.os.msdos.djgpp Subject: Re: Allegro Optimizations Date: 1 Feb 1998 23:02:11 GMT Organization: Luebs & Son Photo Lines: 75 Message-ID: <01bd2f64$d2c801c0$8913c6cf@comp> References: <6b0q66$3la AT nnrp3 DOT farm DOT idt DOT net> NNTP-Posting-Host: sa4-p9.dreamscape.com To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk whew the 1500 images hurts!! Anyway, there is no way to run at 27fps if you don't load any of the images onto disk. I doubt you need all 1500 images at the same time! Lets say you needed 400 images, well in DOS with 32MB of RAM (which is the standard, even 16MB would do) that would work. Yet I doubt you need 400 at the same time, but if you do, you need at least 16MB of RAM and probably could not run Win 95, as it will not swap itself out (for many good reasons). You need to load all images that you need at run-time in memory, at least virtual. So just allocate as much memory as you need. If the person does not have enough memory, then just trust the VMM. Each fighter has 750 images!! Wow, to tell you the truth this is overkill and it is impossible to do this with anything less than 64MB. Even though the fighters are 3D, are you sure you need 750 images each?? It might be possible to do this if you can make each fighter 300 images each. This still requires 20MB!! I find it interesting that when you come to a fork in the road when making games one option always requires more memory, and the other more CPU power. This is a great example. I would think, that with this kind of 3D work you would want to actually render the fighters in real-time. Yes, it may sound slow, but it isn't. Trust me, if quake can run at this resolution (640x480) at 23fps on a P166, then you can get a game like this going at 27fps on a P166. (Quake has a lot more to do!! Including executing that clunky p-code) Now the scrollable backgrounds, each one eats 2.7MB. However if you do it, you will want to try to allocate as much as possible in video memory. Another thing to consider using, is a 320x240 "resolution" so you quarter the size needed. Our eyes pay less attention to a grainy background. I would try implementing a "dirty" update procedure, so you only erase and update if a rectangle has been made dirty. This usually requires a linked list and some "implementation" but is well worth it. John Luebs James W Sager Iii wrote in article ... > I was wondering if anyone is good with speeding > things up. > I'm writing a street fighter/ mortal kombat clone... > > I want to display images VERY fast. > > Lets just say I need to display on the screen each refresh: > *one scrollable 3x3 screens wide background. -In memory > *two 180x160 fighters --On disk(total of 1500+ images so loading into > memory is not a viable option) > *one status bar 640x48 -In memory > *two projectiles 90x80 -On disk, but loads into memory when using them. > *5 small images 25x25 -in memory > > Is it possible for me to get that going at about 27 frames per second or more > on a 166mhz? > > > Also, if that is do able, I'd really like to do the following: > *two or more scrollable and moving ackgrounds, anywhere from 3x3 screens > and lower a piece.(one or more is used for layering, like clouds moving > in the background) > *three 180x160 fighters. > *One status bar > *6 projectiles 90x80 > *15 small images 25x25 in memory > > Yeah, that looks pretty much impossible, but I'm curious. Maybe my technique > of just blitting them all onto one off screen bit map and then blitting that > to the main screen is inefficient. I'd like to hear suggestions. Theres > nothing I fear more than having all my 3-d artists make tons of images, > me to code up the fighter maker and the game, only to realize its > impossible. > >