Does anyone know of or where I can obtain a bif editor. I would like to edit the game sprites, but can't find anything for bif files.
Does anyone know of or where I can obtain a bif editor. I would like to edit the game sprites, but can't find anything for bif files.
- A conclusion is simply the place where someone got tired of thinking.
- The only thing we learn from history is that we learn nothing from history.
never mind
- A conclusion is simply the place where someone got tired of thinking.
- The only thing we learn from history is that we learn nothing from history.
did you find one.? if so please direct me to it
i am still trying to find that elusive geisha movie
------------------
Chaos is born from order.
Cowardice is born from bravery.
Weakness is born from strength.
-Sun Tzu
Chaos is born from order.
Cowardice is born from bravery.
Weakness is born from strength.
-Sun Tzu
Hell - you guys never seen our Giant Mods/Maps section??? It's all there...
------------------
Honour to Clan Kenchikuka.
I'm from Malta, but I'm not a Malteser.
Visit my resource site here!
Konnichiwa,
RSW san has made a much better BifReader. It allows you to edit per pixel. Note: when you open a BIFFile you'll see 1 image, there can be more. 100Mons.Bif for example (Campmap dir) has 100 images. You can browse through them by using the Framelist.
Thanks to Tm for the colorpalet fix.
This tool and the tool to edit LBM files is available for download in the tools section: http://www.totalwar.org/maps/Tools.shtml
------------------
Ja mata
Toda MizuTosaInu
Daimyo Takiyama Shi
http://www.takiyama.cjb.net
Ja mata
TosaInu
bump.
Wanted to make sure all you modders noticed this. It was kinda overshadowed by the news that we could record battles. This new version of the bif editor allows us to change the images to whatever we want. I demand at least three nifty mods on my desktop by next Monday. (One being the kensai sprite is replaced by Mr. T. -I pity the fools that dis my bushido!)
Tm
Wee-hoo! We'll see what we can get together. I just hope I can use the stuff I had done earlier.
-- B)
I've tried it out and it is indeed pretty cool! It made me realize how much work went into all those sprites though, radically changing just one unit could take a really long time for an amateur like me.
------------------
All quotes are terrrible!
All quotes are terrrible!
Quote radically changing just one unit could take a really long time for an amateur like me.[/QUOTE]
No excuses! I want those mods on monday!
Actually, if you see any problems with the application interface or shogun fails to recognize the
new bif files post your results here. RSW indicated to me that he still had some doubts it could handle all the different bif formats properly and I did see some minor interface things that could be fixed...
Good job Tm, I had stopped paying attention until now.
Thanks T but really I'm only the middleman in this case. Real life is keeping me from the glory. You know, always the bridesmaid...
Hi, I have been following the progress with modding bifs for a while know, and I am very happy that it is finaly possible to edit the sprites but as Klen pointed out:
Quote radically changing just one unit could take a really long time for an amateur like me.
[/QUOTE]
I think it would be a great step foreward if we were able to import/export from .bmp.
This would enable modders to build and animate sprites in Programs like Poser, 3dsMAX or other 3d Progs, and export the animation sequences to individual bitmaps. These could then be imported back into bifs, just like the game designers created the sprites.
From a programmers point of view I think import/export would be easier to implement than copy and paste.
You would "only" have to read a bitmap pixel by pixel and change the color code in the corresponding bif-frame, just like you now change it in the pixel where the mouseclick occures.
Export would likewise generate 1 bitmap image for every bif-frame in the file.
Sadly I dont have enough time to help out with programming, but if you need a betatester to test a future release of the bifreader I would be happy to help out.
Thanks for the offer Omegamann and welcome to the org! We(Scott, RSW, and I) are looking into increasing the functionality of the current bif editor to help out the modders. Progress has already been made but some more work is still needed. We've discussed the possibility of converting these files to a common format that would allow us to edit them using commercial editors but it seems to be easier said than done. This alternate format needs to be able to support transparent pixels and multiple frames of information. So far, it's just been easier to do these conversions manually rather than convert them to some other more convienent medium using a conversion program or a photoshop plugin. Currently, the bif image in the editor is displayed using a bitmap and the transparent color is represented as a bright green. It would be relatively easy to save this as a bitmap but taking an existing bitmap (something that has been modified with a different editor), and extracting the color and data information to build up a bif file would be the hard part.
I am unfamiliar with poser and 3dsm; will they allow the user to save a list of bitmaps and then display them one at a time as if they were frames in a animation?
Tm
Coming at it from another angle, another standard file format that uses animation and transparency - the common .GIF
Then modders could use something like ImageReady or any commercial internet-graphics-editor. Build the animations as animated gifs, then run them through the biffer.
Easy for me to say - I'm not a programmer!
I'm starting to rework some old ideas, and will try to run some tests to make sure they're compatible. More updates as I have time for...
-- B)
I've done a little research into gif files. This would seem the perfect interface with the exception that they require a license fee whenever you develop something with their format. They are very strict about this. I remember reading in the google newsgroups how a guy wanted to write some free software that made use of the gif format as charity for homeless blind children with aids. They refused to allow him to work with their format without the fee. Now whenever I think about the gif format I think about those homeless blind children with aids and how they weren't good(wretched) enough to get away with it.
I dont think we need gifs or another complicated file format that supports transparency and animation.
Wouldnt it be much simpler to save each viewport in the bifeditor as one bitmap file and name them according to their framenumber?
These bitmaps could be edited and then be imported back individualy to replace/overwrite the corresponding frame.
Transparency would be a distinct color in the images palette.
OmegaMann has a point there. Many graphic mod tools just use a certain color to be the transparent color (like an ugly purple.) The importer would look for this color (which is done by simply reading the palette index for each pixel, something you have to do anyway) and replace it with transparency info when it goes in the BIF file. Since the BIF file needs to be a form of run-length-encoded, it is unavoidable to have to work with the files at byte by byte level anyway. The encoding used in the BIFs are not standard RLE.
An uncompressed BMP would work best in this situation because they use a very simple structure.
Also...an IFF/LBM file is capabale of storing animation and transparency, although it is not the easiest format to work with. Try finding a program to support IFF/LBM animation editing...good luck. Deluxe Paint and Disney Animation Studio were the only programs I know of that could (both no longer availible.)
However, as I forgot to mention in my email to TM, I think the best way is to rip each frame out individually as an uncompressed bitmap. If organized by folder, they can be plugged back into a BIF by importing fairly easily. I didn't have time to reply to you TM, but I was going to say exactly what Omegaman said about the "special color as transparent" idea. If anyone is familiar with Transmogrifier for The Sims, it is done exactly this way.
Scott
Looks like we are thinking along the same lines Scott.
And its not just the Sims tool that uses this kind of import/export.
I worked with tools for Age of Empires/Kings, Baldurs Gate, and the Close Combat series that did just the same thing.
Im very exited by the possibillity to efficiently create mods with different unit graphix, hope it will become reallity soon.
sounds to me like the next step then is a bif to bmp converter, yes?
K.
------------------
The only absolute is that there are no absolutes.
Yes, i guess .bmp shoul be enough. There are a lot of tools like ACDsee were you can convert images to and from .bmp format.
The color palette could pose a problem though.
Does Shogun use a global palette for unit graphics or does each bif contain its own palette?
Each bif has it's own color palette that applies to all the frames in that image.
I've modified RSW's bifreader source to export the frames as bitmaps but it will take awhile to do the opposite; convert a series of bitmaps into different frames of a bif file with a common palette.
I can release this version of the code but I don't know of how much worth it will be until we can figure out a way to import these bitmap files as multiple frames of a singe bif. This seems to be the hard part -unless Scott has some specific ideas on how to handle this?
Well...let's look at the problems that need to be resolved here:
1. We need to preserve the same palette for all frames so that there is only one palette going into the BIF
2. The Bitmaps need to be standardized and must remain standardized. For example, we need the BMP to remain uncompressed and we need to be sure to keep the magic transparent color.
I will answer these in reverse order, because the second problem has a short answer.
The second one is a user issue that can only be adressed with education. Someone willing to seriously mod will just need to take the time to understand the rules. I am not a fan of simplicity at the sacrifice of control. I would rather read a 42 page manual for the BIF editor than have only one choice of drawing program.
The first issue can be adressed a few different ways. Firstly, as stated above..with simple education. Obviously all frames need to use the same palette, the artist will need to set up his palette to use all the colors he will need for the various frames right off the bat. This is the simplest approach programatcally. By using the palette loading and saving feature of Paintshop Pro or Adobe Photoshop. A PAL file is a 768 byte file that stores 256 colors in three byte pieces. One byte for red, one byte for green, and one byte for blue. Extremely simple to work with. By drawing your first frame as you want it and then saving the palette, you can load that palette up when creating your next frame and the colors and thier indices will remain the same. If you realize as you get further into the animation that you need another color, you can simply add that color, save the palette again, then load up the previous frames and the new palette and save them again. The second option is to have a palette optimization tool programmed into the BIF importer. This would be rather difficult to implement, but basically, it would take all the palettes and find all exact match colors and prioritize them to the global palette. Then find similar colors and decide which one to ultimately use based on how often it is used, and further down the scale to trying to squeeze in completely unique colors. Then it would have to watch and convert all indices based on this new palette. This is not only difficult to program, it will also add *ALOT* of time to the importing function. I vote for option number 1.
Now, it is important to note here that it is not the best idea to convert from the BMP to another format and then back again because pixels and other data have a way of changing between formats. For example...once you save an image as a JPEG, you will not regain those lost pixels when you g to BMP again. Also, the palettes will have changed. The reason for this is because your original information needs to change to fit a different format. Even though the picture looks the same to your eyes, alot has changed behind the scenes. This complicates the programming end of the deal and causes unforseen errors, since it is nearly impossible to think of every stupid thing a person might try to do. Once the BIF editor creates the BMP, you should work with that BMP as it is and save it over the original. Or, if creating a BIF from scratch, to pay extrmemely close attention to the rules. This ensures (not 100%, depending on the program doing the saving and your attention to the options in that program for the file format while saving) that the file will gain very minimal, if any corruption.
The best way to convert the BMP back to BIF with the fastest and simplest programming method is straight uncompressed pixel data. The everything is just a simple (LOL) matter of math. Math is finite and predictable. The importer would read the image pixel by pixel and cross-reference it to the color palette in the BMP (or the created, seperate PAL file; even better!) and do the encoding.
Example for the logic of just one pixel:
10 Read Pixel
20 look up referenced color
30 Is the next pixel the same color? If yes, then loop and store count of yes answers. Else go to 40
40 Is this color the magic transparent color? If yes, then change the palette index to 00 else go to 50
50 Assemble the pixel row:
Number of sequential pixels using a color
Color
jump to next unique color and loop above
Count number of bytes used by this row
60 save row, advance the correct number of bytes and go to 10
This is probably a little flawed (if only I could make a flow chart in this post...)
The order of the importing proccess will be to create header, then the palette, then the pixel data. As I asserted above, the rows will need to be pre-proccessed because the number of bytes per row will only be known at the end of the row. Once you proccess the row of pixels in the bitmap, count the number of bytes needed for the BIF and just advance that many bytes in the BIF to begin adding the next row. Of course, this would probably be faster to assemble the entire BIF in memory first, and then just dump it to a file, but I have not been able to master this method in my own programming yet.
Scott
(Sorry in advance for any cloudy thoughts...very late on my side of the big blue marble. Just ask for clarification.)
ok, i'm not even going to try and follow all the technical bits and points here, but i am curious and we do know a few things here. we know that CA used something to make these bif images. we dont know what that was. i'm also going to assume that the reason for converting the current bif's to some other format is so that we can use other programs that handle that format, like psp or photoshop or something else. we have a bif editor that works. the question that comes to mind now is, would it be easier to convert images to other formats and use other programs to edit or expand the current bif editor into something more workable that could do more editing tasks?
CA is using something to make their images. did they make their own bif editor? did they use a commercial bif editor? did they make their images in some other format and then convert them to bif's? if they did this last one, is this a program they made or did they use an existing program? do we need a 'two way street' here or could we use something that makes the images in a regular paint program and then convert them to bif's but not be able to convert back to that prior format?
also, could someone explain the bif format? what's the general layout and structure and what's included where?
K.
------------------
The only absolute is that there are no absolutes.
I can't answer the CA questions. I'm not sure anyone but CA can answer them but I can respond to your last question -I want to know where we stand first.
Just how far can we go in describing their application file format? RSW has successfully reverse engineered their bif format -is it ok to post those details in a public forum? I believe the daimyo tried to get some response from CA concerning this but I never heard of any official response.
I certainly would like to get this information out in the open, I think it would help the whole community, but if I do so will CA goons come out and break my kneecaps? Is there any offical position concerning mods?
Tm
OK, I wont say that I can answer the questions concerning CA, but I know enough about programming and game creation that I can imagine how CA created the .bif files or more precisely the unit graphics in S:TW.
First the units are moddled and animated in a 3D Programm.
After that the animation is viewed from the 8 different perspectives and snapshots are taken for each animation frame.
These snapshots are saved in a image file format and resized to the size we later see in the game.
These images are then compiled into the bif frames and files we install.
The last step could be because of memory considerations or simply to make it harder to mod these files.
Anyway if the bif to image import/export function is completed we would be able to create units in a similar way, although we would still need modders that have 3D moddeling and animation know how (and programs).
Well, I waited a week for some response during which time I purchased some kneepads. If anyone objects to the dissemination of this information let me know and I'll remove it.
The BIF file format as far as we know it.
The first 256 words are the color table in little endian format. The colors are stored in 5-6-5 RGB format or 6-5-5 format (That is 5 bits of red, 6 bits of green, and 5 bits of blue). The first word of the table is the transparent color and the last word of the color table determines the color mode as either 5-6-5 or 6-5-5. Image data consists of a series of bytes that point into this color table.
The color table is followed by the header information -a series of double words that gives information concerning the image. This header information gives the image height, width, and the number of frames in the image.
This header is followed by the image data itself. This data consists of rows of bytes stored in a compressed format. When uncompressed, it creates an array of numbers that is image_width characters wide and (image_height * num_of_frames) high. These are offsets into the color table for each pixel.
For example, if an uncompressed line of data looked like this:
FF 01 00 00 00 00 00 00 01 FF
we display it by painting a pixel with the color at position FF in the color table
followed by a pixel the color of offset 01
followed by 6 pixels the color of offset 00 (transparent)
followed by color 01
followed by color FF
RSW did a good job on his bifreader application in that there is detailed information on portions of the image when the mouse is dragged over a certain position. For example, put the mouse over the last color in the color table and you can see the current color mode.
At the last moment I went through and removed much of the detail -drop me an email if you want more.
Tm
Posting Permissions
Reply With Quote
Bookmarks