{"id":635,"date":"2011-10-28T19:00:00","date_gmt":"2011-10-28T18:00:00","guid":{"rendered":"http:\/\/shadowcovenant.com\/blog\/2011\/10\/28\/surgeedimage-bank-editor\/"},"modified":"2011-10-28T19:00:00","modified_gmt":"2011-10-28T18:00:00","slug":"surgeedimage-bank-editor","status":"publish","type":"post","link":"http:\/\/shadowcovenant.com\/blog\/2011\/10\/28\/surgeedimage-bank-editor\/","title":{"rendered":"SurgeED–Image Bank Editor"},"content":{"rendered":"

After a couple of weeks, I\u2019ve finished the Image Bank editor on the SurgeED tool\u2026 Took a bit longer than I was expecting, mainly because I had to add to the editor system the concept of child entities, with all the copy\/delete\/undo\/redo\/explorer issues associated with it\u2026<\/p>\n

But first of all, what\u2019s an image bank (IB) and why do I use them?<\/p>\n

Well, one of the main things you can do to increase performance in any engine (be it 2d or 3d) is to reduce the number of primitive drawing calls\u2026 I\u2019m not talking about actual primitives, but calls to the function that draws them\u2026 That requires a call to the low level system, and that call has a fixed setup time, no matter how many primitives you render in that call\u2026<\/p>\n

So, it\u2019s better to create a single buffer with 1000 primitives (sprites in case of 2d) and draw that, than have 1000 buffers and draw them all\u2026 The performance increase is in several orders of magnitude\u2026 <\/p>\n

This process is called \u201cbatching\u201d\u2026 <\/p>\n

But to draw 1000 primitives in a single draw call, they have to share every render state (which includes all the like render properties, more importantly, the textures).<\/p>\n

So, to draw 1000 primitives, they have to share the same texture, and this is done through creating an atlas, which is a single texture that has loads of images in it. Then, using UV mapping, we can index the separate images and use them in a single draw call to draw different objects\u2026 Below you can see an example of this:<\/p>\n

\"BM_gui\"<\/a><\/p>\n

This is accompanied by a file that describes where each of the individual images is:<\/p>\n

<image_bank name="bm_gui_ib" delete_textures="false" normalized_coords="false" read_textures="true">
    <source>
        <layer type="diffuse">bm_gui<\/layer>
        <images>
            <image name="b_inv_arrow_s" x="703" y="0" sx="32" sy="95" hx="0" hy="0"\/>
            <image name="b_inv_arrow_u" x="639" y="0" sx="32" sy="95" hx="0" hy="0"\/>
            <image name="b_inv_btn" x="191" y="288" sx="61" sy="71" hx="0" hy="0"\/>
            <image name="b_inv_combine" x="795" y="152" sx="184" sy="85" hx="0" hy="0"\/>
            <image name="b_inv_exit_s" x="639" y="320" sx="73" sy="31" hx="0" hy="0"\/>
            <image name="b_inv_exit_u" x="543" y="320" sx="73" sy="31" hx="0" hy="0"\/>
            <image name="b_inv_menu_s02" x="319" y="32" sx="142" sy="25" hx="0" hy="0"\/>
            <image name="b_inv_menu_s03" x="319" y="57" sx="142" sy="23" hx="0" hy="0"\/>
            <image name="b_inv_menu_s04" x="319" y="80" sx="142" sy="24" hx="0" hy="0"\/>
            <image name="b_inv_menu_s05" x="319" y="104" sx="142" sy="24" hx="0" hy="0"\/>
            <image name="b_inv_menu_s06" x="319" y="128" sx="142" sy="24" hx="0" hy="0"\/>
            <image name="b_inv_menu_u01" x="0" y="0" sx="142" sy="32" hx="0" hy="0"\/>
            <image name="b_inv_menu_u02" x="0" y="32" sx="142" sy="25" hx="0" hy="0"\/>
            <image name="b_inv_menu_u03" x="0" y="57" sx="142" sy="23" hx="0" hy="0"\/>
            <image name="b_inv_menu_u04" x="0" y="80" sx="142" sy="24" hx="0" hy="0"\/>
            <image name="b_inv_menu_u05" x="0" y="104" sx="142" sy="24" hx="0" hy="0"\/>
            <image name="b_inv_menu_u06" x="0" y="128" sx="142" sy="24" hx="0" hy="0"\/>
            <image name="b_inv_menu_u07" x="0" y="152" sx="142" sy="33" hx="0" hy="0"\/>
……………<\/font><\/p>\n

The hotspot describes where is the \u201cgrip point\u201d of the image, which is helpful for rotations and just general positioning.<\/p>\n

An image bank then gives \u201cnames\u201d to the images and says to the system where it can go get them (in terms of texture and positioning). A single image bank can use several textures:<\/p>\n

\"afonso0400\"<\/a>\"afonso0401\"<\/a><\/p>\n

This helps with the organization of the image banks\u2026 <\/p>\n

One thing I added in the process of adding an editor for this (more on this later) was the ability of a single image have different layers (like diffuse, normal, etc). This will be helpful to define a decal system later, since I need both textures to create a really good decal, and I didn\u2019t want to create separate systems\u2026<\/p>\n

Basically an image can have multiple layers, the only restriction being that all the layers have to have the same size.<\/p>\n

Up until now, the artists would create these Image Banks by hand, positioning images in a big image and creating a text file by hand, specifying where each element was. This was time consuming and very error-prone, and this was one of the motivations for the image bank editor.<\/p>\n

The way the image bank editor works is very straightforward\u2026 You create an image bank component, and add pages to it\u2026 Each page can have different sizes and support different layers. Then you import images to a specific page (with all layers being a different source DDS image). Then you can move the images around, using the normal tools of the trade (snaps to grid, to other objects, padding support with visual warning where two images are overlapping, etc)\u2026<\/p>\n

When the artist is satisfied with the image bank, he can \u201cGenerate\u201d it and the system will create the atlas and XML file, and it becomes available to all the editor system. The component can then be deleted (it can always be created again from the image bank), or left alone.<\/p>\n

You can also add mountpoints on the images. On the sample above, you can see the character has a sword on his hand, but if we had a character that could yield a sword or an axe (for example), we could add a mountpoint to his hand and in the game run time, attach another object to a specific mountpoint.<\/p>\n

I\u2019m very proud of the editor as a whole, and this component is very cool in action, since I believe it will cut down development time for 2d games a big deal (artists could lose up to 3 or 4 hours creating an atlas by hand, and add 2 more hours or so due to small errors, like a wrong position (easy to spot) or a wrong hotspot (harder to spot)).<\/p>\n

\n
<\/param><\/embed><\/object><\/div>\n<\/div>\n

 <\/p>\n

You can see the editor in action above\u2026 the frame rate is crap, think it is because of the on-the-fly encoding\u2026 This component doesn\u2019t perform as well as I\u2019d want, but it\u2019s easy to understand, considering that each image has to be drawn separately (in its own draw call), because we\u2019re trying to create the image bank that will solve that problem in game\u2026 <\/p>\n

Next stop in my travels in game development land will take me to rebuilding the fonts for Something Fishy, so I can start trying to port the game to tablets.<\/p>\n

Tweet<\/a><\/div>","protected":false},"excerpt":{"rendered":"

After a couple of weeks, I\u2019ve finished the Image Bank editor on the SurgeED tool\u2026 Took a bit longer than I was expecting, mainly because I had to add to the editor system the concept of child entities, with all the copy\/delete\/undo\/redo\/explorer issues associated with it\u2026 But first of all, what\u2019s an image bank (IB) […]<\/p>\n