Mail Archives: djgpp/1998/02/01/19:16:30
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 <sager+@andrew.cmu.edu> wrote in article
<sop9SG_00YUq09XYI0 AT andrew DOT cmu DOT edu>...
> 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.
>
>
- Raw text -