Recent Posts

Pages: 1 2 [3] 4 5 ... 10
Outpost 2 Programming & Development / Re: Outpost 2 art
« Last post by Hooman on June 26, 2017, 10:40:41 AM »
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.
Outpost 2 Programming & Development / Outpost 2 art
« Last post by Exoduz on June 26, 2017, 08:11:23 AM »
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
I've updated the text file describing the saved game and map file formats. It was missing a section in the header of saved game files. I also filled out some details on the meaning of the previously unknown fields.

Code: [Select]
Offset  Size    Description
------  ----    -----------
0x0     0x19    "OUTPOST 2.00 SAVED GAME", 0x1A, 0 - String must match exactly or else load error
0x19    0x1086C fileDialogData
0x10885 0xD7A0  sheetData[0x73]  (array of 0x73 (115) UnitTypeInfo objects, each loading 0x1E0 bytes of data)
        Note: Technically each object loads data through a virtual function call, so each object could load a different amount of data. However, there are no overrides, so they all call the same base class function, and hence all load the same data.
          4       int requiredTechNum
          0x1DC   struct[] unitTypeInfo.playerInfo[]
0x1E025 ...     From here, the format matches that of .map files
Projects / Re: OP2MapImager Development
« Last post by Hooman on June 26, 2017, 02:28:12 AM »
Since there is both a and grnwld01.bmp (tile set), without file overwrite protection, it is entirely possible to make some interesting mistakes. Fortunately, the stock tilesets don't suffer from it.

That's one of the reason why I suggested appending an output parameter, such as the scale factor:

People would have to go out of their way to have a problem, which I think is good enough.

Project organization can be a pain. Maybe just move the main method out into a Main.cpp, and let the rest implicitly be library like code. It might not be separated out into a library, but someone could easily cannibalise the project or make such changes if they wanted to.
OutpostHD / Re: OutpostHD - An Outpost Redesign
« Last post by Hooman on June 26, 2017, 01:17:03 AM »
Thanks, removing one of the equal signs solved that problem.

I needed to install the SDL2 dependency (using Ubuntu):
Code: [Select]
sudo apt install libsdl2-dev

I also needed to add the "-std=c++11" flag to CFLAGS in the Makefile:
Code: [Select]
-CFLAGS         =       -g -Wall -I./API/NAS2D/include `sdl-config --cflags`
+CFLAGS         =       -std=c++11 -g -Wall -I./API/NAS2D/include `sdl-config --cflags`
That removed a ton of errors and warnings about "nullptr".

I see a few errors about "sLevels", as stated above. I renamed the occurrences to "sLevel" just to see if it would compile. No other compile errors, though lots of warnings about non-void functions having no return statement (they are dummy stubs), and a few typedefs being locally defined but unused.

And of course the error stated above was still present:
Code: [Select]
make: *** No rule to make target 'API/NAS2D/lib/libnas2d.a', needed by 'bin/OPHD'.  Stop.
Tested with GCC:
Code: [Select]
#error OS not supported

Code: [Select]
cppError.cpp:5:2: error: #error OS not supported
 #error OS not supported
You're right, the math doesn't seem to work out. Looks like an error in the description of the file format.  :-[
OutpostHD / Re: OutpostHD - An Outpost Redesign
« Last post by lhark on June 25, 2017, 08:59:25 PM »
Ok, that's weird, I can only reproduce half of your problem. On the last line it complains about a missing library and is right about it : leeor_net forgot to include it with the rest of my patch.

If you want, you can compile the missing library yourself leeor_net accepted my pull request for

As for the other problems, I can only that my shell scripting wasn't fully POSIX compliant :/

Maybe try the following fix on line 24 of the Makefile

-   if [ "$${dirs#*ui_builder/}" == "$$dirs" ]; \
+   if [ "$${dirs#*ui_builder/}" = "$$dirs" ]; \

Also, leeor_net, you should have a look at line 436 in src/States/GameState.cpp, I think you have a bug : the string sLevel becomes SLevels at one point without any new declaration.
I ended up using HXD to determine the offset of 0x1E025 for loading the map data from the save file. You can basically search for the width and height of the map which appears near the beginning of the map portion.

I cannot get the math to work to get 0x1E025 from the structure sizes listed in the file snippet earlier in the thread.

If someone has time to break it down for me for my own knowledge on the subject, it would be appreciated.
Projects / Re: OP2MapImager Development
« Last post by Vagabond on June 25, 2017, 12:42:59 PM »
As alluded in the other post, OP2MapImager can now take renders of save files. It is a bit silly though since it doesn't include any of the building or units, just the background terrain. So you could just take a picture of the underlying map and get the same results. There could be a fun project involved in parsing out all the information in a saved file and rendering it so you could capture a huge battle or share a high def render of your utopian colony layout. I think this will remain outside the scope of the project for me though.

I finished implementing standardized switch statements. Still some testing to work through though.

When appending numbers to filenames to avoid overwriting, maybe append the scale factor, or final dimensions. That's the only real input the should change the output, other than actually modifying the source map or tilesets. Considering the nature of the transformation, you probably don't need to worry too much about protecting from overwrites.

Since there is both a and grnwld01.bmp (tile set), without file overwrite protection, it is entirely possible to make some interesting mistakes. Fortunately, the stock tilesets don't suffer from it.

I'd like to finalize the big picture of the project. Currently, there are 2 projects, OP2Utility and OP2MapImager. OP2MapImager is the actual console application. OP2Utility contains XFile (eventual cross platform file system support) and MapData struct.

OP2MapImager Reusability Concerns

Is anyone possibly considering reusing parts of this code in other projects? If so, what would they/you prefer structure wise from my end.

Option A would be moving the render code over to OP2Utility so anyone could call it and render a map from another project. However, it will carry the dependency to FreeImage into the dependency project, when everything else in the library does not require FreeImage.

Option B would be a third library project that just contains the FreeImage dependency and render code. This way other projects could reference OP2Utility and not worry about FreeImage, or you could reference both library projects if needed. The downside is you now have to hook in yet another library project.

Option C would be to leave all the render code in the console application. I think you could just call the console application in quiet mode from another application to render a map.

Anyways, I'm willing to work any of the three ideas, just curious if there are opinions to weigh in on before I dive in coding.

Render of a save file, MesaMissions (a scenario I've been working off and on for a while)
Pages: 1 2 [3] 4 5 ... 10