Outpost 2 art

[Exoduz]

Hey guys!

Been lurking around for years, playing outpost 2 offline just goofing around and editing txt files etc.
But... I have been thinking, and wondering, trying to figure out what one would need in order to "update" or remodel/remake the graphics for op2.

My question then would be; What program do i use to open the art of op2 to be able to edit it?
I tried the artwork viewer but that does only viewing and not editing.

Do you just redraw the graphics and put back the bmp file, or do i need to map it of some sort?
Can I maybe open it in photoshop and edit from there?

I would think that a vast number of people have tried redoing artwork, even tried making it into 3D, but I "just" want to update the graphics for a more modern look.

I think it would be fun to play a HD op2 of some sort

Thanks for info and help!

// Exo

[Hooman]

There are tools to extract the game graphics, but I don't believe there are any tools to repack the game graphics. I don't think anyone has ever seriously tried to update the game graphics before. I suppose if someone wanted to make on effort on that front we could look into building the tools. Knowing how to extract should give us most of the info needed to repack.

If you were going to do this, you'd start by extracting the graphics you want to edit. They are natively in BMP format (or at least very similar, and would be extracted as such). You can then edit them in any 3rd party image editing software, such as Photoshop. Once edited, they'd need to be put back into the game graphics. This step is lacking currently. If you were careful, this could be done with a hex editor. Easier if the image size hasn't changed at all. Ideally though, one of the unpacking tools could be modified to repack.

If you had some already edited images to be repacked, that might provide some incentive for someone to get such a tool built.

[leeor_net]

I think it would be fun to play a HD op2 of some sort

I can agree with that. Unfortunately a lot of these older games didn't age very well. OP2 withstands the test of time better than some other games but I would love to see OP2 redone.

[Exoduz]

There are tools to extract the game graphics, but I don't believe there are any tools to repack the game graphics. I don't think anyone has ever seriously tried to update the game graphics before. I suppose if someone wanted to make on effort on that front we could look into building the tools. Knowing how to extract should give us most of the info needed to repack.

If you were going to do this, you'd start by extracting the graphics you want to edit. They are natively in BMP format (or at least very similar, and would be extracted as such). You can then edit them in any 3rd party image editing software, such as Photoshop. Once edited, they'd need to be put back into the game graphics. This step is lacking currently. If you were careful, this could be done with a hex editor. Easier if the image size hasn't changed at all. Ideally though, one of the unpacking tools could be modified to repack.

If you had some already edited images to be repacked, that might provide some incentive for someone to get such a tool built.

I did find a sheet sprite packer program, but it is only for packing the sprites.
I am new to how the mechanics works with sprite packs, but i think that each and every own sprite has to be allocated somehow?
If i extract and create a sprite pack with the same names of each sprite, would op2 be able to load with those sprites?

[Vagabond]

Exoduz,

Welcome to Outpost Universe!

Editing the map tiles and playing them in game can already be done now without any special tooling (except to get the initial well00XX.bmps into a standard format, which we have already done). The game can read them in either the special Outpost 2 format or in a normal BMP format. I'm planning on writing a wiki article in more detail, but haven't taken the time yet to get past a small stub:  http://wiki.outpost2.net/doku.php?id=op2_sdk:editing_map_tilesets.

I think the real problem lies in what image types Outpost 2 can accept. Currently the tilesets are 8bpp BMPs that each use an indexed color palette. So you only get 256 color choices and couldn't really add any colors to a map that do not already exist unless there are unused colors on the palette. I haven't checked if they have used all the colors or not. I haven't tested it yet, but I'm assuming that Outpost 2 wouldn't allow you to load a tile set BMP in 24bpp or 32bpp. This would be easy to test though if you are interested.

If you are interested in working on the in game tiles, let me know and I'll reprioritize putting some more time into the wiki article and answering your questions as best I can. Sounds like you are more interested in the buildings and units though.

As for editing the in game unit sprites, I would be curious what image file types are supported by the game. If you designed a new lynx in 24bpp BMP, would the game be able to read it even repacked? I worry that you would be stuck with 8bpp palletized images. This might be harder to test without the repacking tool existing?

-Brett

[Exoduz]

Exoduz,

Welcome to Outpost Universe!

Editing the map tiles and playing them in game can already be done now without any special tooling (except to get the initial well00XX.bmps into a standard format, which we have already done). The game can read them in either the special Outpost 2 format or in a normal BMP format. I'm planning on writing a wiki article in more detail, but haven't taken the time yet to get past a small stub:  http://wiki.outpost2.net/doku.php?id=op2_sdk:editing_map_tilesets.

I think the real problem lies in what image types Outpost 2 can accept. Currently the tilesets are 8bpp BMPs that each use an indexed color palette. So you only get 256 color choices and couldn't really add any colors to a map that do not already exist unless there are unused colors on the palette. I haven't checked if they have used all the colors or not. I haven't tested it yet, but I'm assuming that Outpost 2 wouldn't allow you to load a tile set BMP in 24bpp or 32bpp. This would be easy to test though if you are interested.

If you are interested in working on the in game tiles, let me know and I'll reprioritize putting some more time into the wiki article and answering your questions as best I can. Sounds like you are more interested in the buildings and units though.

As for editing the in game unit sprites, I would be curious what image file types are supported by the game. If you designed a new lynx in 24bpp BMP, would the game be able to read it even repacked? I worry that you would be stuck with 8bpp palletized images. This might be harder to test without the repacking tool existing?

-Brett

Hey and thx!

not really new here but been a lurker
i see what you are aiming for and i understand that it might be a problem for op2 to read any other than 8bpp, and yes, i am aiming firstly for units and buildings
Maybe i can use the art viewer and copy each image of lynx and edit to 24bpp bmp, or maybe even higher bmp res, and upload here, then we could try and see if the game likes it or not.
if the game accepts it, then its go time to edit the rest.

Is there any way to let op2 use jpeg or png etc?

[Sirbomber]

Maybe i can use the art viewer and copy each image of lynx and edit to 24bpp bmp, or maybe even higher bmp res, and upload here, then we could try and see if the game likes it or not.

This is ill-advised.  Though Arklon will probably disagree with me.

EDIT (leeor_net): Removed image link due to photobucket disallowing hot linking.

[Exoduz]

Why is it ill-adviced?
Does the linked image show a try on editing art and failure?
When i get home from work i will try and remake som art and post it, just for fun.
Have to copy and paste from the art viewer though.
We'll se how it goes later tonight

[Hooman]

I think it would be fun to play a HD op2 of some sort

I can agree with that.

leeor_net! 

Outpost 2 uses palettized images. One of the reasons is the way day/night is handled. The game will create several pre-scaled copies of the palette, with different light intensities. When it draws the graphics, it looks up which palette to use based on the day/night light intensity. The actual image itself is not modified, just the palette used to display that image.

Another complication is the player colors drawn on units. This is again done through palette trickery.

I believe the tile sets check the bit depth, so a 24 bit image would fail to load. I think a 16 bit image might load, but assumptions about the use of a palette could cause a crash. For the sprites, I don't believe it stores a bit depth so much as an image type, which has an implied bit depth. Shadow images would have a bit depth of 1. Normal images would have a bit depth of 8.

Total maps colors may exceed 256 colors (8 bits), since each tileset has it's own palette, and a map consists of multiple tilesets. You can break tiles up into tilesets based on common colors, and which tiles can share a palette.

The total colors in one frame of animation may exceed 256 colors (8 bits), due to the game using composite images. A vehicle might consist of separate images for the wheels/tracks, the chasis, the turret, and the shadow(s). Similarly, buildings would have separate images for the dock, the building itself, and the shadow.

The sprite image data is split between OP2_ART.BMP and OP2_ART.PRT (stored in maps.vol). The BMP file is structured like a regular BMP file, but with invalid header fields and is not viewable with normal bitmap editing software. It contains a dummy header, followed by all bitmap data for all game graphics, appended one after another in the file. Since the interpretation of the bitmap data depends on header info, and each image has different header parameters, there is no way to interpret this file with one single header and get sensible data out of it. It is simply the raw bits, interpreted according to external info.

The PRT file contains the info needed to interpret the bitmap data. It starts with an array of palettes. Then it contains an array of header information (width, height, bit depth, palette index), with offsets into the BMP file for the chunk of data each header describes. It also contains an array of animation info, where each animation has an array of frames, and each frame references several component images, as described above.


This is the nature of the images you would be editing. The game only understand this format. It would likely by done by extracting and editing numbered images. When those images are re-inserted, they would be composed into frames, which would be placed in animation sequences.

The easiest starter project would be to change just the images without modifying width, height, bit depth, or how frames or animation sequences are composed. That could even be done by careful copy/paste with a hex editor. You could copy the bitmap data (excluding the header) from an extracted edited bitmap, back into OP2_ART.BMP, without needing to modify OP2_ART.PRT, assuming you figured out the right size and offsets for the copy/paste. The image extraction software might be able to help figure out the paste offset.

More advanced editing will mean re-writing the PRT data. Do-able, but some tooling would need to be developed to make that easy.


@Sirbomber: lol
Looks like some bad re-pack offsets

[Exoduz]

Would there be a way to change op2 to read other  types of palettes with higher bit depth?
Or do we need the whole op2 source code for that?
Or can we use a higher bit with modifying the prt file only?

[Vagabond]

Getting the source code for the game isn't really an option although not for lack of trying. You can check out a lot of older posts on the subject.

Modifying the existing code with Ollydbg to accept larger palette sizes would perhaps be possible. This would be well beyond my experience though to discuss knowledgeably.

I know that older rpg games could switch color palettes when drawing different versions of the same enemy. This way you could have a bad guy appear in several color themes without having to redraw him. Saving space and time. I wonder if anyone still designs  sprites this way? It is similar to what Outpost 2 does with drawing different colors for player units.

Isome modern indie games still use palettes when making sprites. They typically do it to develop a specific color feel for the game or give the game a retro feel.

@Exoduz, do you have any experience drawing sprites with indexed color palettes or  desire to learn how?

@Hooman, I appreciate the thorough research on the topic!

[Exoduz]

@vagabond I dont really have the experience for indexed color palettes, i do however desire to learn since i like drawing and refurbishing images and drawings.
But I guess it would not take so long time to learn about indexing color palettes?
Do you know yourself?
I am going to try to offer some time today at refurbishing one of the sprites of a convec or a structure just to give you an example of what my idea would look like.
If we could make the prt to use 16-bit highcolor for example then we could have a palette consisting of 65535 variations of red green and blue.
But, if we go 16-bit palette, how many pixels can we have per inch?
And how big can we size it?
Also, could we go even bigger on the bit scale, to 24 or 32 bit?

[Vagabond]

Exoduz,

I just checked and Gimp only supports color palettes up to 256 colors on size (8bpp). I'm not sure it is really an option to use greater than 256 colors in a palette.

Unfortunately, I don't have real experience in graphics arts besides doing some small work on Gimp and Inkscape. My wife has some skill so a while back we researched pixel art together. I really like the feel of graphics from the late super Nintendo era. We looked up how people reproduced the look and learned about indexed color palettes but never really applied it.

I would still be interested in seeing what you come up with if you do up some graphics either in 8bpp indexed palettes or 24/32 bpp true color.

I think the modern way to apply the night time gradual darkness of tiles and units in Outpost 2 would be to use a graphics shader that applied a color change mathematically as opposed to switching out color palettes. Not sure if a graphics shader would be able to paste the 7 different colors on to the buildings/units. Of course a moot point for the current code base for Outpost 2.

[Hooman]

I think we're worrying too much about problems we don't yet have.

Would there be a way to change op2 to read other  types of palettes with higher bit depth?
Or do we need the whole op2 source code for that?
Or can we use a higher bit with modifying the prt file only?

Even with the source, this could be a difficult change. It's unlikely we would change the graphic types accepted by the game. Though sometimes people get creative and come up with interesting ways to do things. And who knows, maybe there is sufficient support and we just don't realize it.

Palettes are generally for 8 bit images (or smaller), and 8 bits means 256 colors. If you have more bits per pixel, say 16 bits per pixel, it's easier to just encode the color information in the pixel data, rather than an index into a palette. It's very hard to tell the difference between 16 bit color and higher.

Honestly though, I don't think the use of palettes is really all that restrictive.

The palettes are referenced per image, not the whole screen. Even if you were trying to exhaust a palette by making every pixel of an image a unique color, you'd still need at least a 16x16 pixel image to exhaust 256 colors.

Realistically though, images are not random data. Sprites typically have transparent pixels, so that cuts down on actual real pixels and colors used. On top of that, you probably do want to reuse colors to maintain a certain theme. Further, the limitation is per image, not per frame which is composed of many images. You can use one palette for a vehicle's wheels, and another palette for the chasis, and another palette for the turret. Are you going to exhaust that in a typical 32x32 pixel unit graphic?

To take things further, if you really wanted, you could break an image into two, just to use separate palettes and get more colors. The use of transparency could even let you use overlapping images, where the pixels from a certain palette are in one images, and the rest are transparent, while another image is overlayed with the pixels from another palette, and transparent for the rest.

Though you probably don't want to get too carried away with creating new palettes.

Next question: Is there a limit to the number of palettes you can use?
Honestly, I don't quite remember, though I wouldn't be surprised if there was a static limit. The game used 9 palettes in the PRT if I remember correctly. There might be a static buffer limit on that. Though that would be easier to patch than using 16 bit color everywhere.

FYI: 9 palettes * 256 colors/palette = 2304 colors


As for practical editing, just edit in whatever bit depth is comfortable for you to use. The images can be post-processed to get them into a desired form. That might mean merging colors that are close to keep the images below the palette limit, or spliting the images up to use more palettes. Chances are, for graphics the size of a unit, you can likely keep the color count to within 256 and still have a pretty good looking image.

In short, if you can make better looking graphics, I'm sure someone can come up with a way to use them.

[Exoduz]

Ok, I will have to check back on the images for later since as you might have read I am concentrating on coding.
But with that said i do have ideas in my head for how the graphic could look.
And by the look of it, if you check with the art viewer you can clearly see that a vehicle is made up of several other images, taken together and made frames of.
by other images i mean wheels, top, body for ex.
it was well over 100000 images in total in the op2 art when extracted.
though when extracted the tranceparency went lost and shows up as either orange or black depending on if you choose 8 bit or 16 bit or 32 bit.
I did however find a rather cool python script which depixels pixel images which can be implemented into games.
there are videos of the creator of said pyhton code running it with super mario etc.
its called depixelizing pixel art, and link for it is here; https://github.com/jerith/depixel

also, there is a sprite packer, called sprite sheet packer http://amakaseev.github.io/sprite-sheet-packer/

[Hooman]

Random thought: Good 2D art skills is probably a more rare and valuable skill around here. I don't think we have anyone really doing much with 2D art.

What were you planning with the depixelizer? Converting the graphics to a vector format such as SVG, fixing it up a bit, and then re-rendering it at a higher resolution? I don't know how easy that would be considering going from low res to high res means creating data that simply isn't there in the source image. But then, that's the manual fixup stage.

I don't believe a typical sprite sheet packer would be too useful for Outpost 2. That's just not how the game stores the graphics. The Outpost 2 format is more like a column of irregularly shaped images; a stack of rectangles of varying size. A typical sprite sheet packer tries to layout images onto a 2D canvas, which possibly wasted space due to different sized images being placed next to each other. Outpost 2 is actually more efficient at how it stores graphics than the typical sprite sheet. It's not just that it avoids wasted space, but also it has much better memory linearity, which can speed up access and drawing, as well as reduce the working set size for memory. Having a single column of images, rather than a row of images will actually improve memory access times. Unfortunately, the format used by Outpost 2 suffers from a certain lack of tooling. It's just not easy to view the images all at once, or work with the data with standard tools.

[Exoduz]

I had the idea to make it cleaner and smoother, but keep the feel of op2, something like they did with starcraft HD if you have taken a look at that!
The depixelizer was thought to maybe be another way of refurbishing the look of op2, just dont know what would be easier.
If it is as you say not like the regular Sprite sheets, then i guess you would have to extract every single image/frame and edit them one by one and then somehow (working with the same palette) inject each image again retaining the way they built the op2 art sheet.
That would be an immence and huge time consuming job, and it would probably be faster and easier to just code op2.5 and update it with a new game engine and make new sprites, or even making op2 with 3D models.

[Vagabond]

That would be an immence and huge time consuming job, and it would probably be faster and easier to just code op2.5 and update it with a new game engine and make new sprites, or even making op2 with 3D models.

I would have to disagree with this. The edits Hooman is describing are a lot easier than creating a new game from scratch, unfortunately.


I could probably write the first half of the software using FreeImage for pixel manipulation right now.

1. Pull all the sprites into memory.
2. Iterate through the sprites to find the widest sprite width and the total height of all the sprites.
3. Create a new BMP with the width and height in step 2.
4. Create an array of containing a structure with image data
    * image width
    * image height
    * image palette
    * image position on sprite sheet
    * image name
5. Strip indexed color palette from image and paste image onto sprite sheet.
6. . . .

Past this, someone would then need to write the code to translate this data into the .prt and .bmp file, which would probably be a bit beyond my skill alone.

I'm a little unsure about the shadows being 1bpp though? FreeImage probably would not appreciate preserving a 1bpp image in an 8bpp image. So, maybe it would have to be handled more peacemeal than creating one large image first and then converting it?

All that being said, I think you should take a stab at redesigning something in game and see what you come up with.

-Brett

[Hooman]

Remember the original OP2 project had something like 20 artists. Remaking everything from scratch is a huge project.


Don't worry so much about the format right now. We can adapt stuff if we need to. If someone put in the time for the art, I'm sure we could put some code together to use it.


As for code project ideas, one I've had a the back of my mind was a sprite sheet extractor. Something that would extract sprite sheets for individual units. I figure each unit independently would be more manageable, and perhaps more useful, than a single sprite sheet for all game graphics.

Mind you, I was only considering an extractor, not something to re-integrated edited graphics. My idea was simply to extract simple unit animations, and perhaps use them to spruce up the website, or make them available for more general use in other projects. Maybe it would encourage more people to work on mini games, or game remakes if they had access to such resources.

[Exoduz]

Ok, well, I have as said before started coding right now and getting forward on that, learning arrays, while and loops etc.
But i will take the time to soon start working on my art idea!
Regarding images and sizes etc, if i make a image of whatever format(jpeg TIFF png) and in whatever size i want, it doesnt matter right now?
I am guessing you convert it later on?

[Hooman]

Yes. Focus on doing quality work on the image itself. That's the hard part. The format conversion is just a technical detail at the end.

[White Claw]

...The format conversion is just a technical detail at the end.

That sounds like the kiss of death.

I wish I had more 2D skills. For another project, I had created 3D models and used those to generate the requisite 2D images from various angles. I thought about doing something like that for an OP-style remake, but that project isn't moving anywhere at the moment.

Good luck on the coding. Though if you have artistic talent, I'd be interested in seeing that too.

[leeor_net]

This is ill-advised.

That is the kiss of death right there. You see these words and you know you're immediately heading into the real of Undefined Behavior^TM and usually involves horrible crashing, plague and the election of Trump.

[Arklon]

Here's the images Sirbomber tried posting:

This is ill-advised.  Though Arklon will probably disagree with me.

Of course I disagree, this is most definitely the way to go to import graphics into OP2. It's so good that it even improves the stock graphics just by doing nothing but re-importing them.