Example, I have 10 BMP files that I rendered using POV. They are
explod01.bmp through explod10.bmp, each 64x64 pixels. I want to create a
bmp that is 640x64 containing all of the images so i can load them as
one file to use in my own display mechanism.

I understand that if the images are 256 color that some color averaging
will need to be done, but my primary interest is just to physically
place the images side by side.

Post a reply to this message

You can do this in any decent paint program, but I doubt there is an app that
does it automatically...
It would be nearly trivial to program such an app, though. If you can't do it
yourself, perhaps bugging some programmer type would help :)

Margus

Crunchy Frog wrote:
> 
> Example, I have 10 BMP files that I rendered using POV. They are
> explod01.bmp through explod10.bmp, each 64x64 pixels. I want to create a
> bmp that is 640x64 containing all of the images so i can load them as
> one file to use in my own display mechanism.
> 
> I understand that if the images are 256 color that some color averaging
> will need to be done, but my primary interest is just to physically
> place the images side by side.

Post a reply to this message

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.

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

Margus Ramst wrote:

> You can do this in any decent paint program, but I doubt there is an app that
> does it automatically...
> It would be nearly trivial to program such an app, though. If you can't do it
> yourself, perhaps bugging some programmer type would help :)
>
> Margus
>
> Crunchy Frog wrote:
> >
> > Example, I have 10 BMP files that I rendered using POV. They are
> > explod01.bmp through explod10.bmp, each 64x64 pixels. I want to create a
> > bmp that is 640x64 containing all of the images so i can load them as
> > one file to use in my own display mechanism.
> >
> > I understand that if the images are 256 color that some color averaging
> > will need to be done, but my primary interest is just to physically
> > place the images side by side.

Post a reply to this message

Attachments:
Download 'us-ascii' (2 KB)

Ah, is that it? Well, you could apply them as image_maps on boxes and
use an orthograhic camera. I will try to come up with a macro if you
think you can't handle it yourself.


Peter Popov
ICQ: 15002700

Post a reply to this message

Crunchy Frog wrote:
> 
> Example, I have 10 BMP files that I rendered using POV. They are
> explod01.bmp through explod10.bmp, each 64x64 pixels. I want to create a
> bmp that is 640x64 containing all of the images so i can load them as
> one file to use in my own display mechanism.
> 
> I understand that if the images are 256 color that some color averaging
> will need to be done, but my primary interest is just to physically
> place the images side by side.

I have a program that does exactly that.
If necessary you can also cut of some margins.
It's not perfect because I just cooked it up for my own use but if you like I
can send it to you. 

Remco

NB Windows only, sorry...

Post a reply to this message

> 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.

Post a reply to this message

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.

Which is precisely why I stick all frames on a strip as well.

Remco

Post a reply to this message

On Mon, 06 Sep 1999 14:35:18 -0400, Crunchy Frog
<cru### [at] montypythoncouk> wrote:

>Example, I have 10 BMP files that I rendered using POV. They are
>explod01.bmp through explod10.bmp, each 64x64 pixels. I want to create a
>bmp that is 640x64 containing all of the images so i can load them as
>one file to use in my own display mechanism.
>
>I understand that if the images are 256 color that some color averaging
>will need to be done, but my primary interest is just to physically
>place the images side by side.

The netpbm utilities, if you can find a copy for Windows, might do the
trick.  Specifically, there's a program called "pnmcat" that takes two
or more input images and concatenates them together in a specified
way.  It'd take a little thought to get it right, but it would work.
If you can't find a copy for Windows, bug me and I'll see what I can
do about compiling it.  Note that they're command-line utilities,
though - no GUI or even graphics of any kind - so they might not be
your cup of tea.

Post a reply to this message

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