Crunchy Frog wrote:

> > Well, I can think of two right off hand that should do it.
> >
> > Image Magick and the Gimp.
> >
> > But the question of "why?" comes to mind.
>
> I want to be able to load a single BMP as a set of frames for animation
> in a game.

Well, that was one of the reasons I was thinking was possible. In that
case your constraints are a little sub-optimal.

Since you had mentioned your own display mechanism, I'd suggest the
following:

1) Make it 64x640. Tall, not wide. Then you have the benefit of having the
memory for the one frame structured almost as if it was an individual pic.
Makes it better for several other reasons also. Each frame can be
displayed/manipulated without having to know the total number of frames.
Etc, etc., etc. It also makes it much easier for me to write you a custom
concatenation program if you can't find anything else.

2) BMP for a game? I'd really suggest trying to stay away from BMP if at
all possible. Store things as PNG and just convert to BITMAP as you read
in.

3) If it's a game and it's for a sprite, you'll be much better off if it's
all one single pallete. Or all true-color. If you're designing for 8-bit
display, you'll want to carefully handle the palette allocation.


--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

Jon A. Cruz wrote:
> 
> 
> 1) Make it 64x640. Tall, not wide. Then you have the benefit of having the
> memory for the one frame structured almost as if it was an individual pic.
> Makes it better for several other reasons also. Each frame can be
> displayed/manipulated without having to know the total number of frames.
> Etc, etc., etc. It also makes it much easier for me to write you a custom
> concatenation program if you can't find anything else.

Could you please explain. I don't think I understand your reasoning here.

> 
> 2) BMP for a game? I'd really suggest trying to stay away from BMP if at
> all possible. Store things as PNG and just convert to BITMAP as you read
> in.

Again: why? What would be the advantage of PNG over BMP? It loads much slower.
> 
> 3) If it's a game and it's for a sprite, you'll be much better off if it's
> all one single pallete. Or all true-color. If you're designing for 8-bit
> display, you'll want to carefully handle the palette allocation.
> 
_If_ it has to be 8-bit just stick all images in a 24-bit image and reduce that
to 8-bit. But 8-bit as a standard is becoming a little bit outdated, at least
for games.

On all these topics: it may depend on what platform you're using. I was wildly
assuming that it would be a windows-game where, for instance, BMP is the native
format. 

Regards,

Remco

Post a reply to this message

Remco de Korte <rem### [at] xs4allnl> wrote:
:> 2) BMP for a game? I'd really suggest trying to stay away from BMP if at
:> all possible. Store things as PNG and just convert to BITMAP as you read
:> in.

: Again: why? What would be the advantage of PNG over BMP? It loads much slower.

  Size. Why should you make a 10-Megs game when it could be a 1-Meg game?
  Disk space is cheap, but still limited.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Remco de Korte wrote:
> 
> Jon A. Cruz wrote:
> >
> >
> > 1) Make it 64x640. Tall, not wide. Then you have the benefit of having the
> > memory for the one frame structured almost as if it was an individual pic.
> > Makes it better for several other reasons also. Each frame can be
> > displayed/manipulated without having to know the total number of frames.
> > Etc, etc., etc. It also makes it much easier for me to write you a custom
> > concatenation program if you can't find anything else.
> 
> Could you please explain. I don't think I understand your reasoning here.
> 

The reasoning is that bitmaps are ordered in rows, not columns. When the
X by Y components are stacked vertically, each component is represented
by a single X by Y long byte stream. When they are stacked horisontally,
a component are sliced into Y separate pieces, each X bytes long. Not a
big problem, but why do it the harder way?

Margus

Post a reply to this message

Nieminen Juha wrote:
> 
> Remco de Korte <rem### [at] xs4allnl> wrote:
> :> 2) BMP for a game? I'd really suggest trying to stay away from BMP if at
> :> all possible. Store things as PNG and just convert to BITMAP as you read
> :> in.
> 
> : Again: why? What would be the advantage of PNG over BMP? It loads much slower.
> 
>   Size. Why should you make a 10-Megs game when it could be a 1-Meg game?
>   Disk space is cheap, but still limited.
> 

Ehm, we're talking about a _game_ here. Like those things you can download 28Mb
demo's of. 
Would it really be such an advantage to use PNGs instead of BMPs? I think not.
As a matter of fact I think PNG are seldomly used for that. There are all sorts
of custom formats around where multiple images are stored in one big
blob-data-file but if you want to make it simple on your self in programming a
game on a windows platform BMP is not such a bad choice. If diskspace is a
consideration you might use RLE-compressed bitmaps (if you're colordepth allows
it).
From the games I've seen speed is much more an issue then diskspace. 
Diskspace was an issue when a game had to be crammed onto floppies. That's
(nearly ancient) history by now.
BTW: I'm not saying that I'm in favor of those huge games, there are some really
good games that may even look good (considering...) that take less then 100K.
But then we're not talking Windows games anymore.
I guess when you decide to make a Windows program you've already accepted the
fact that it takes up much more diskspace then really necessary.

Mazzel!

Remco

Post a reply to this message

Margus Ramst wrote:
> 
> Remco de Korte wrote:
> >
> > Jon A. Cruz wrote:
> > >
> > >
> > > 1) Make it 64x640. Tall, not wide. Then you have the benefit of having the
> > > memory for the one frame structured almost as if it was an individual pic.
> > > Makes it better for several other reasons also. Each frame can be
> > > displayed/manipulated without having to know the total number of frames.
> > > Etc, etc., etc. It also makes it much easier for me to write you a custom
> > > concatenation program if you can't find anything else.
> >
> > Could you please explain. I don't think I understand your reasoning here.
> >
> 
> The reasoning is that bitmaps are ordered in rows, not columns. When the
> X by Y components are stacked vertically, each component is represented
> by a single X by Y long byte stream. When they are stacked horisontally,
> a component are sliced into Y separate pieces, each X bytes long. Not a
> big problem, but why do it the harder way?
> 
> Margus

That is a reasonable explanation.
The way I think this will work the whole image will be loaded into memory with
one single statement and then it's not really relevant anymore though. Besides,
it may be easier in low level programming environments but on most programming
platforms it doesn't really make much difference.
But I see your point.

Ciao!

Remco

Post a reply to this message

Remco de Korte <rem### [at] xs4allnl> wrote:
: Ehm, we're talking about a _game_ here. Like those things you can download 28Mb
: demo's of. 
: Would it really be such an advantage to use PNGs instead of BMPs? I think not.
: As a matter of fact I think PNG are seldomly used for that. There are all sorts
: of custom formats around where multiple images are stored in one big
: blob-data-file but if you want to make it simple on your self in programming a
: game on a windows platform BMP is not such a bad choice.

  I quote myself: "Disk space is cheap but still limited".
  This means that with current hard disks the size of one game doesn't matter
at all. It could be 10 kilobytes or 1 Gigabyte. Big deal.
  The problem is that you seldom play just one game and use just one program.
Usually you have many of them on your disk. If everyone of them took 1
Gigabyte, you will certainly complain. A 16 Gigabytes hard disk would be
full quite soon.
  It's good to think that your program is not the only program the end user
will be using. Saving storage space for the other programs is polite, IMHO.


: If diskspace is a
: consideration you might use RLE-compressed bitmaps

  RLE doesn't pack very well.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Hi Remco de Korte, you recently wrote in povray.windows:

> That is a reasonable explanation.
> The way I think this will work the whole image will be loaded into memory with
> one single statement and then it's not really relevant anymore though. 
If the image is vertical, blitting from it will be better because the
bitmap is in contiguous memory, i.e. the CPU cache will do a much
better job of getting data, it could make it quite a good deal faster.

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

Remco de Korte wrote:

> Jon A. Cruz wrote:
> >
> > 2) BMP for a game? I'd really suggest trying to stay away from BMP if at
> > all possible. Store things as PNG and just convert to BITMAP as you read
> > in.
>
> Again: why? What would be the advantage of PNG over BMP? It loads much slower.
> >

"It loads much slower". That sounds like a start at premature optimization, which
is the root of all evil. :-)

How much is "much slower". Tests should be made. I'm guessing on the order of
perhaps a second at the extreme. Depends on your system. Disk speed is going to be
a bottleneck anyway, and modern processors get quite fast. The main point would be
to test it in context and see how it works overall.

Another thing to consider is when will this apply?  Usually this slight slowdown
would occur once at the begining of the program or level. While a splash screen is
being displayed. Balance that with having the equivalent of keeping all your
images ZIPped on disk the entire time the user has the game installed but is not
playing it.

Also by taking that hit on speed at one point during startup you also buy the
addition of transparency by color or by alpha channel, etc.


Anothing thing that had been mentioned was RLE BMP files. Problem is that RLE
compression really sucks for most things (that's my professional opinion from
having worked with RLE a lot :-)  Also, using it will make the BMP's incompatible
with a lot of programs. But at least it's not quite as bad as "right-side-up"
BMP files.

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

On Tue, 07 Sep 1999 14:19:01 GMT, Lutz Kretzschmar wrote:
>Hi Remco de Korte, you recently wrote in povray.windows:
>
>> That is a reasonable explanation.
>> The way I think this will work the whole image will be loaded into memory with
>> one single statement and then it's not really relevant anymore though. 
>If the image is vertical, blitting from it will be better because the
>bitmap is in contiguous memory, i.e. the CPU cache will do a much
>better job of getting data, it could make it quite a good deal faster.

Though if you're lucky, the bitmap is located in an unused chunk of video 
memory and the CPU doesn't even have to get involved in the blitting 
operation.  Yes, I've been writing video device drivers lately, why do you
ask?  Is it the missing hair or the wild look in the eyes?

Post a reply to this message