Mail Archives: djgpp/1998/02/04/04:16:44
On 3 Feb 1998 20:46:00 -0700, Smith A. Cat <imbe AT primenet DOT com> wrote:
> You should NOT use the DOS binary in Win95 except when rebooting into DOS
> mode.
Any reason why?
--
Take a look in Hagbard's World: | w3ng - The WWW Norton Guide reader.
http://www.acemake.com/hagbard/ | ng2html - The NG to HTML converter.
http://www.hagbard.demon.co.uk/ | eg - Norton Guide reader for Linux.
Free software, including........| dgscan - DGROUP scanner for Clipper.
ve enough
ram. You say 400 images would load with 32 meg of ram... Each image is
180x160. Ok, if I'm loading up 200 images per fighter, yeah 400 then
or 32 meg of ram would make it run better. I guess I could also give
the user of loading one fighter up to memory, and possibly have common
moves be ther too...
Oh on another note, I can't get Allegro to be nice with WIN95. Under
certain circumstances that I haven't had a chance to fully experiment
with, Win95 crashes under programs that I normally can run under dos.
I think it may have to do with the sound card, but there may be more
complications, does anyone have any similar experiences?
Exerpted:
>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
>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)n.
Its not slow to render the ppl in real time. It would just be more difficult,
and not something that I want to think about for it would push the release date
back a couple months which isn't feasable for me. Given 3-d art rendered on the
fly makes throw moves easier, and your point about the memory/speed thing...
>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.
True, I was thinking of going 320x 240, it makes alot of extra work go away
when changing palettes. And I don't want too many backgrounds, for they're
the biggest cause of slow down in the game...
>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.
I was thinking of doing the standard sprite animation technique so long as the
background wasn't moving. Dirty rectangle code is too difficult for me
to understand
I think since I've never been exposed to it.
- Raw text -