• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Vincent_M

Loading Uncompressed Textures

10 posts in this topic

My new engine editor allows me to tweak my textures' properties such as filtering, wrap modes, max size on a per-platform basis so my artists can make high-res textures, optional mipmap generation, etc... I will also allow the user determine which format the texture data will be stored as (32-bit RGBA, 16-bit RGBA_5551/RGB_565, 8-bit alpha, etc, PVRTC 2/4-bit via provided compress tools, etc). Then, I'll write its properties and its pixel data to my own custom texture format. The textures are loaded in-editor using the FreeImage library. Would this be a good way to go about it, or should I consider compression encoding non-PRVTC textures? This would require extra data pools to stream in temporary compressed data so it can be uncompressed leading to longer load times than a single freed(). Textures can get big quickly, for example: a single 1024x1024 texture takes up 4MB of disk space if stored uncompressed plus its small header data. I could get around that by putting all my files into zip archives. Does a custom file format sound like a good idea?

 

My texture system extends beyond typical 2D textures as well. For example, I'll have a cube-map editor that'll put all my cube maps together into a single "atlas" of sorts. I'll also have a 3D texture editor and 1D texture support. The idea is that the data is serialized into file formats that my engine can readily load up quickly with only a handful of fread() calls. They're large cuz I'm banking on uncompressed texture support (except for PVRTC), but possible. Of course, loading zips from an APK on Android will prove annoying as I'll have to copy all of my zips from the APK (which is a zip archive) into a cached directory.

 

0

Share this post


Link to post
Share on other sites
It's not uncommon for games to have two build modes with one for the final shipping game executable and one for developers (and content creators) where the former can only load a small handful of useful types (PNG for UI, DXTC for textures, for example) and the latter can load anything.

In yet other engines, there's a separate tool for conversion of images and the like and the game will (in editor mode) invoke that utility on demand when asked to load unconverted resources or when a resource setting is changed.

Yet other engines just have separate game builds and editor builds.
1

Share this post


Link to post
Share on other sites

 

 

1) As a general purpose engine, supporting more image types is generally a good idea. The typical workflow for artists is to use photoshop images (psd files) for their work and export textures as one of the compressed formats supported by cards, such as DXT1 or DXT5 or whatever. These formats are usually supported directly by the card so no further processing is necessary.  Some people are tempted to support jpeg and gif and similar formats; those are great for the Internet or places where size is more important than fidelity, not so much in games. Uncompressed raw images are something of a last resort used for compatibility when all else has failed.

You bring up a good point about DXT1/5, etc. I've always stored my textures as a png, then used an image library to load my data. The thing is, I'm starting to think the release version of my game doesn't need a code base as extensive as FreeImage on mobile/embedded platforms just to load images when it should have some sort of serialized, unified pipeline. The format would match the data structures' format in-game so loading will be simple.

 

 

 

It's not uncommon for games to have two build modes with one for the final shipping game executable and one for developers (and content creators) where the former can only load a small handful of useful types (PNG for UI, DXTC for textures, for example) and the latter can load anything.

In yet other engines, there's a separate tool for conversion of images and the like and the game will (in editor mode) invoke that utility on demand when asked to load unconverted resources or when a resource setting is changed.

Yet other engines just have separate game builds and editor builds.

This is along the lines of what I'd like to go with. For example, the users would import their textures into the editor, and the Inspector would provide it with image format options based on its deployment platform. For example, if it's iOS, you could compress for PVRTC 2 or 4-bit by selecting it from the format combo box, and the PVRTC command line tool would run in the background a deployment-time (as needed) to spit out new info.

0

Share this post


Link to post
Share on other sites

 

The typical workflow for artists is to use photoshop images (psd files) for their work and export textures as one of the compressed formats supported by cards, such as DXT1 or DXT5 or whatever.

This is a very bad idea. Don't let your artists produce or export to the final format. Ever.

It will all start innocent, the artists commit the DXT compressed textures and you are happy. Then you realize, that all textures are compressed as DXT5 instead of DXT1, even those without an alpha channel, because DXT5 has twice the bitrate and thus MUST HAVE twice the quality. You ask them to remedy the mistake but going through all the textures in the repo and reexporting them manually is too much work and apparently too error prone.
At this point, you can forget any efforts to get an automatic export running, because the DXT compressed versions, and the (presumably) source material somehow got out of sync. And there are multiple copies of the source material and noone really knows which ones are to most recent ones.

And then you consider to change the way the textures are compressed, or even the compression format, but your only viable source material are the already lossy DXT1/5 compressed textures.
 

 

It depends on your workflow and the discipline that is kept in the office.

 

Everywhere I've been the art budget was fixed in stone in advance. The maximum size of each model, both meshes and textures, is specified and is included in the acceptance criteria. If a single asset is over budget it is well known because it shows up on the feature dashboard that shows all the metrics of all the assets; it needs to be approved by the art lead, the art director, the feature designer, the tech lead, and the project manager.  When it happens it is usually just "this is an important model" followed by "yup", "yup", "yup", "go ahead". 

 

Since the asset sizes show up in several metrics and are reviewed daily, it would be fairly hard for an artist to slip in a 4MB dxt file without at least one person noticing. 

 

If your art process is such that nothing gets reviewed and there is not accountability, sure, I'll agree it is a bad thing.  But that is bad because of a (lack of) policy and a lack of discipline.

2

Share this post


Link to post
Share on other sites
Another strike against having art export DXT files themselves is that there are a few new DXT formats that most art tools can't even read, let along write, but which are important for getting better compression or fewer artifacts out of your files (Example: BC5, BC6, and BC7). Heck, your artist is not going to want to sit there for several minutes with their machine completely tied up (as in your mouse is unresponsive) just to compress a single BC7 file. Edited by SmkViper
0

Share this post


Link to post
Share on other sites

Ok, so it sounds like using engine-processed data would be a better way to go than using typical image formats such as png or jpeg because you miss out on hardware compression, load times could be higher and extra memory will be needed for temporary memory pools. One thing though: I wouldn't see us hardware-compressing algorithmic textures, such as normal maps, since its data needs to be as accurate as possible.

0

Share this post


Link to post
Share on other sites

Ok, so it sounds like using engine-processed data would be a better way to go than using typical image formats such as png or jpeg because you miss out on hardware compression, load times could be higher and extra memory will be needed for temporary memory pools. One thing though: I wouldn't see us hardware-compressing algorithmic textures, such as normal maps, since its data needs to be as accurate as possible.


BC5 is specifically designed to compress normal maps with a minimal amount of artifacting. It is able to avoid the obvious blockiness at lower resolutions you get with older DXT formats while being smaller because it only stores two channels.
0

Share this post


Link to post
Share on other sites
^As well as that, the old school solution was to throw out the Z channel of your normal maps (because you can reconstruct it from the other two), and then putting the X/Y channels into the Green and Alpha channels of a DXT5 (with nothing in Red/Blue).
This gives better quality than naively using RGB, because DXT5 compresses RGB and Alpha data seperately, so by using G and A, you make sure there's no cross-talk during compression. The alternative to achieve the same memory savings is to reduce the resolution by half in both width and height (1/4 the pixels).

If you're targeting hardware without much memory, then compression or low resolution is a requirement. We used config files in our build system to swap between the two to compare quality, and also we let the artists specify a choice per asset if required.
2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0