Outpost 2 Sprite Sheets

[leeor_net]

I have a feeling this has been talked about at length but evidently I'm a search retard. Can't find anything. So here goes.

I wanted to tinker around with an idea that uses some of the Outpost 2 art assets... but it would appear that none of the art assets have been pulled from the game and saved into common image formats. No sprite sheets, nothing.

I looked at the OP2artviewer programmer (references here) but whatever files it saves are unreadable. I could just use the reader and take screenshots and copy it that way but that's a tedious process and I'm not looking for tedious, I'm looking for simple.

To that end, has anybody already done the work of extracting the OP2 art assets and compiling them into sprite sheets already? If not is anybody interested in doing that?

[Hooman]

By sprite sheets I assume you mean a column of frames all within the same image?

It would be good to have something like that for units. I've thought about it before, but never did it. Perhaps the code from the graphics viewer can somehow be combined with the list of animation indexes for various units. I can see a few potential uses for such images.

I believe Outpost 2 uses varying frame sizes and offsets. It also combines multiple images into a single frame. You'd have to account for those varying sizes and offsets if you wanted a consistent column of frames. That shouldn't be too difficult to deal with.

I like the idea but don't currently have time to commit to it.

[Vagabond]

Leeor,

Check out the Outpost 2 Art Viewer by Cynex if you have not already. It can spit all the game assets as either images or frames into a folder with predictable names. Output is bitmap with several different color depth options using the Batch Save command. Only thing is it doesn't place them all on a sheet. http://forum.outpost2.net/index.php/topic,1635.msg32189.html#msg32189

There is a program called SpriteSheetPacker built by Nick Gravelyn that I have appreciated using in the past. It can be found here: https://spritesheetpacker.codeplex.com/. It is written in C# and the source code and compiled executable are both available.

SpriteSheetPacker can take the output individual sprites and compile the sheet in PNG, JPG, or BMP. It also can create a text file listing the rectangle on the sheet that each sprite takes up. See the attached 2 files for a quick example I made by pulling the cargo truck and robo dozer frames using the Outpost 2 Art Viewer and the Sprite Sheet Packer.

[leeor_net]

Woot thanks! I thought I was using Cynex's viewer, evidently I wasn't.

[Hooman]

Efficiency note: A single column of frames will have the best paging and caching behaviour. A row of frames would have the worst. A square image of frames would probably perform similarly to a row of frames.

If you use a column, where each row of pixels is stored adjacent in memory, than all rows in a single frame are adjacent. This should improve cache performance, and keep each image on a single page of memory if possible, or straddle adjacent pages of memory.

If you store a row of frames, then a row of pixels will straddle many frames, and so you can end up loading unneeded data into the cache. It also means you'll likely have to touch more memory pages. For a wide enough image, it could be a new page of memory for each row of pixels.

[leeor_net]

Since I'm using the GPU and GPU memory I tend to work with what works best for those - power of two textures so I'll stick with square textures and simply pull from that.

Also, that seems like an unnecessary optimization. We're talking about modern computers here, not dinosaurs from the 90's. A few page hits aren't going to slow down a program that much. If, when instrumented and run through a profiler that shows that it's a bottleneck, fine, optimizations can be made then. But, since I'm using a GPU to manage and render graphics, I'll refer to the above.

[Hooman]

I hadn't really considered GPUs. I believe the caching is still quite relevant for the CPU. Computer's aren't so memory constrained, so the paging is probably less of an issue in terms of affecting the working set size, but it may still have an appreciable impact on memory bandwidth. Despite memory being random access, sequential access still produces much higher performance. That applies whether the memory is being accessed by a CPU or a GPU.

This is similar to how it's much faster to draw by scanlines than to draw by columns. Theoretically it does the same thing, but due to optimizations for sequential memory access, it produces a huge difference in performance.

[leeor_net]

When you upload the texture to the GPU, that's it. The GPU handles everything from there.

Plus there are texture size limitations on the GPU. While you may still have the same NUMBER of pixels in a linear format vs. a square format, the GPU can only handle so much. Well... it depends on the GPU. ATI/AMD GPU's have much lower limits than nVidia.

Anyway... moot point me thinks.

[Hooman]

I think perhaps we're not on the same page.

[leeor_net]

Bahahaha... programming puns!

I'm going to go drown myself now.