Implementing GIF images??

[Will]

I thought about how cool it would be to make animated gif explosions and muzzle flashes or even bullets. So my question is , would this be possible and would it affect the gameplay since bitmaps are used because they are able to load quicker than some other formats.

DISCUS

[bja888]

gifs loop, it wont know when to stop playing it

[Avarax]

still it would be great i.e. for fires or grass moving in slight wind as scenerys for maps.

[BUKKAKE]

gifs loop, it wont know when to stop playing it

actually gifs can be made to loop between 1 and 65535 times, or forever. most programs just loop them forever regardless of this setting though.

[aqua]

I think that would be great!!!

[papercut]

Maybe. It's not needed but it won't hurt anything at all.

[bja888]

gifs loop, it wont know when to stop playing it

actually gifs can be made to loop between 1 and 65535 times, or forever. most programs just loop them forever regardless of this setting though.

Your not getting it. If there are 20 files it will play the animation though 20 frames then stop. If there is one file then it wont know when to dump the memory that is used to play the animation. All animations will have to be a specific length even if you have it play only once.

[Nfsjunkie91]

gifs loop, it wont know when to stop playing it

actually gifs can be made to loop between 1 and 65535 times, or forever. most programs just loop them forever regardless of this setting though.

Your not getting it. If there are 20 files it will play the animation though 20 frames then stop. If there is one file then it wont know when to dump the memory that is used to play the animation. All animations will have to be a specific length even if you have it play only once.

There'd only be one file, with x number of frames. I'm not sure of how well this would work, because I think something similar to DirectShow has to be used to play .gifs, rather than just a standard image loader.

[Will]

Would that slow down the game or what?

I saw its use primarily with bullets , nades and the like. Maybe map scenery and interface too. Actually I would definately like to see that in the maps . But it's never gonna happen anyways. (unless MM recodes soldat and release it as 2.0)

[Keron Cyst]

How would it be used with bullets & grenades? I see the feature (which has been suggested many times before, and each I support) being used primarily as in looping scenery, like grass waving in the wind or minor smoke-emitting torches; larger .GIFs of actual, other soldaten recorded from demos fighting in the background could be used for WWII scenes, etc.

[Toumaz]

Would that slow down the game or what?

I'm not too sure it would slow down the actual game noticeably, but it would for sure crank the RAM.

[Mistercharles]

Isn't GIF a filetype that can't really be used for commercial purposes? Plus, I think MM said that Delphi + GIF don't mix.

[jrgp]

GIF is used all the time in commercial purposes.
It originaly was invented in the very late 80's.

and next time, use the search function
http://forums.soldat.pl/index.php?topic=783.0

[Pyroguy]

Yes, this has been suggested before a few times. There is a lot of wrong things being said about GIFs and BMPs... I've spent some time as a programmer and know a few things about GIFs and BMPs.

Both a GIF and a BMP are pure data files. They contain no "code" or commands that are intended to be run, just graphical data. Both have a specific format, basically, a set of rules (not included in the actual image files) that different programs use to convert the data in the file to something it can use on screen and converting something on screen to data it can store in the file type correctly.

BMP's format has very little in the way of "rules"; it stores only the pixel width, pixel height, and each pixel in the image, based on a starting pixel (I believe it is top left, but I'm not sure) and then continuing pixels based on the width/height. It also has some info about bit settings for valid colors, but that gets really complicated and doesn't help this explanation.

GIF's format has a lot more in it in terms of "rules"; it stores info such as the number of frames, the width and height, repeat length, and bit information. It also supports transparency. GIF is useful for image animations and also in the fact that images can be "compressed" in GIFs; patterns of pixels can be recorded and repeated throughout the image to save space.

The major difference between the two is that, while BMPs generally have a larger size due to lack of some form of compression in the format, they are the fastest to render because they can be pulled directly from the file and put onto the screen with little effort of the processor. GIFs, while usually smaller, allow for animations; but they require a lot more processor power to draw, especially with multiple frames or large image dimensions.

That said, both need the program that is drawing them to have a sort of "reader" in the code; and MM doesn't really want to program in a GIF reader, because a BMP reader is much easier to code and makes the game run faster; plus, image size doesn't really matter for a 640x480 game.

[echo_trail]

gifs loop, it wont know when to stop playing it

actually gifs can be made to loop between 1 and 65535 times, or forever. most programs just loop them forever regardless of this setting though.

Is that why you sometimes get that bug saying you have 65535 kills and 65535 deaths? Some kinda .gif flaw?

Anyway, I support this idea if it could be worked out without ruining the programming. Soldat's fine as it is, and adding features to it is only a cool factor if we don't change the core.

[Nfsjunkie91]

gifs loop, it wont know when to stop playing it

actually gifs can be made to loop between 1 and 65535 times, or forever. most programs just loop them forever regardless of this setting though.

Is that why you sometimes get that bug saying you have 65535 kills and 65535 deaths? Some kinda .gif flaw?

Anyway, I support this idea if it could be worked out without ruining the programming. Soldat's fine as it is, and adding features to it is only a cool factor if we don't change the core.

65535 is the highest 16 bit number, I think. Not just Gif files use that number as a max, but so do ports (0-65535) so it's not a .gif problem at all. Unfortunately, adding gifs would require a different image loader, as I previously stated, so I doubt Michal'd go out of his way to do it.

[Wraithlike]

I think it would be cool, but maybe it would need a frame limit, like 200-300, to keep people from making things that take really long times to load and then cause massive slowdown.

[cooz]

I think it would be cool, but maybe it would need a frame limit, like 200-300, to keep people from making things that take really long times to load and then cause massive slowdown.

or maybe file size limit would be good solution too

[Will]

Another question. Would it be possible to code Soldat to load multiple BMP's into the game and create an illusion of GIF animation , but it's actually just multiple BMP's.
The actual data about how many times it will cycle through bitmaps could be stored in somekind of .ini file and the values could be like this:

[AK-74-Bullet]
ImageLoop=0             ; infinite
ImageFrames=5          ; how many different BMP's would be used for this bull
FrameInterval=7         ; time before changing the image to the next (measuredinticks)


the bitmaps could be named ak74-bullet , ak74-bullet2  and so on


I'm just cuorious about this and I have no hopes about this being implemented at all , I ust wanna know if this would be a good idea

[Zamorak]

gifs loop, it wont know when to stop playing it

actually gifs can be made to loop between 1 and 65535 times, or forever. most programs just loop them forever regardless of this setting though.

Is that why you sometimes get that bug saying you have 65535 kills and 65535 deaths? Some kinda .gif flaw?

Anyway, I support this idea if it could be worked out without ruining the programming. Soldat's fine as it is, and adding features to it is only a cool factor if we don't change the core.

No, thats because kills are an unsigned 16-bit integer data type, 16-bit unsigned only goes from 0 to 65,535