RSS
 

Archive for the ‘SurgeED’ Category

Bah, stupid capture applications…

25 Nov

I did a nifty 10 minute video walking people through the material system of my editor, but the encoding application decided to blow up and corrupt the files… Disappointed smile

Need to find a better way to do this kind of video captures… for fullscreen applications, I have Fraps, which works like a charm, but for “desktop” applications, I don’t have anything good… Any suggestions?

Anyway, this will be the post before the weekend… it still wasn’t this week that we did the “big announcement”, but we’ll do it next week for sure!

Have a nice weekend everyone!

 
4 Comments

Posted in Development, SurgeED, Tools

 

LiveLink

09 Nov

Although I got Uncharted 3 to play, I managed to get some time to add the live-link feature into SurgeEd!

Now, each time I change a shader file (or any of its dependencies), the editor reflects that when the window regain focus. Hopefully I’ll be able to iterate shaders faster, and do some more effect shaders as well.

I still need to add the material edit options, but I’m struggling a bit with it, from a conceptual standpoint.

We are editing objects on the editor, and those objects have (simplifying) a position, orientation and mesh. And the mesh has materials, shared by all the instances of that mesh… We can think of an object as an instance of a mesh. Now, I have to add materials to the object itself, and these materials have to be children of the mesh (with names generated from the object name). Then, every time the mesh of an object changes, the materials have to be deleted and re-added from the mesh materials. There are also other problems associated with the drag/drop/copy/undo/redo systems.

After I solve this, it comes the time for the properties of the material itself, which has a dynamic component, based on the shader selected for the material.

None of this will be simple, but it sounds like a neat system! Open-mouthed smile With both the live-link and the material editing, I’ll be able to work on shaders in a more efficient way!

On another note, found a cool game to spend some time:

 

It’s very cool there’s still new concepts for platformers, and although I’ve seen this concept before in other games, this one uses it very well associated with the ninja concept!

 
No Comments

Posted in Development, Games, Indy, SurgeED

 

SurgeED–Image Bank Editor

28 Oct

After a couple of weeks, I’ve finished the Image Bank editor on the SurgeED tool… 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…

But first of all, what’s an image bank (IB) and why do I use them?

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… I’m not talking about actual primitives, but calls to the function that draws them… 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…

So, it’s 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… The performance increase is in several orders of magnitude…

This process is called “batching”…

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).

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… Below you can see an example of this:

BM_gui

This is accompanied by a file that describes where each of the individual images is:

<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"/>
……………

The hotspot describes where is the “grip point” of the image, which is helpful for rotations and just general positioning.

An image bank then gives “names” 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:

afonso0400afonso0401

This helps with the organization of the image banks…

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’t want to create separate systems…

Basically an image can have multiple layers, the only restriction being that all the layers have to have the same size.

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.

The way the image bank editor works is very straightforward… You create an image bank component, and add pages to it… 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)…

When the artist is satisfied with the image bank, he can “Generate” 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.

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.

I’m 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)).

 

You can see the editor in action above… the frame rate is crap, think it is because of the on-the-fly encoding… This component doesn’t perform as well as I’d want, but it’s easy to understand, considering that each image has to be drawn separately (in its own draw call), because we’re trying to create the image bank that will solve that problem in game…

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.

 
No Comments

Posted in Development, Games, SurgeED, Tools

 

Sub-entities

03 Oct

Some more work on my SurgeEd…

The next step on my editor is the decal system… Although Spellbook already supports decals, I want to make the system better for authoring and for resource management.

At the moment, a decal references a decal sheet, which is a structure that defines UV coordinates on multiple textures (for normal mapped decals, etc), but I want to collapse the decal sheet and the image bank into a single structure, since it’s easier to manage.

To do so, I’ve decided to build into the editor a “Image Bank Editor” component, which will enable me to place images in a series of layered “texture sheets”, and after some consideration, I’ve started building a system with support for sub-entities, that is, entities that can only be bound to a specific entity.

Easier said than done… I did some mistakes in the general construction of the base system which made this much harder, specially on the interaction of the Component Explorer (the tree-like view where you can see all the objects and select them, drag them around, etc) and the main component system.

The base system was pretty easy to get up and running, but creating the right hooks for the Component Explorer to work nicely with the overall structure, including the Undo and Clipboard systems proved a challenge…

Fortunately, I got it working, and the future expansion of the system will allow me to create very interesting things, like object properties that reference an entity in the scene.

Tomorrow I’m heading out to the Netherlands for some work (sadly, I have to have one of those to make a living), and hopefully that will enable me to make some blog posts for the future (so I don’t spend so much time “away” from you, my loyal readers!) Smile

 
No Comments

Posted in Development, Games, SurgeED

 

Win32 Tree Component

16 Sep

For SurgeED, I’ve had to build some tree views:

tree_view

I’m using the Win32 C API to build the GUI, but the TreeView control available didn’t support everything I needed (or supported it in such oblique ways it was too much work). I tried finding a control like this on the Internet, but either they cost money (which I can’t afford), the functionality wasn’t there, or they used MFCs (which I don’t like).

I decided to build my own, on top of the Windows one, and make the code available.

My tree view supports:

  • Multiple selection
  • Drag/drop operation
  • Context sensitive pop-up menu
  • Callbacks for
    • Selection
    • Command (WM_COMMAND message)
    • Drag operation (start/finish)
    • Popup called
    • Sort operation
    • Size change

 

You can download the files here. They probably don’t work “out of the box”, some helper functions are missing, and probably some includes need to be removed. Anyway, it should be easy enough to extrapolate what’s missing.

Some usage instructions (check .h file for the public interface):

  • To initialize (register the window class – you have to create a define called SURGE_TREE_VIEW with the name you want the class to have internally), you have to call “scc_register_tree_view()”. To unregister, call “scc_unregister_tree_view()”
  • To create a tree view, either use a custom control (with the class set to whatever the name was), or something like:

 

HWND tree= CreateWindow(SURGE_TREE_VIEW,window_name,window_flags,
                        x,y,width,height,parent_window,NULL,instance,0L);

  • To enable/disable multiple selection, call “scc_set_tree_view_multiselect(tree,true/false)”
  • To set a callback function, use “scc_set_tree_view_*_callback”
  • To add nodes, you have to use "scc_add_node”. This takes as a parameter an object of type SurgeTreeNode (more on this later). This will add the node at the top level of the Tree View. To add elements as sub-nodes, use the “add_node” function on the SurgeTreeNode you want to be parent of this one.
  • The SurgeTreeNode is the base class of all the nodes in the tree. You should subclass it for “type of nodes”. For example, on the Component Explorer of SurgeED, I have loads of classes (“Project”, “Component Group”, “Component”, “Group” and “Entity”). All of these can have different options on the pop-up menu, have different behaviors on drag, etc.
    • add_node: Adds a subnode to this node
    • remove: Remove a subnode from this node
    • expand: Expands/contracts this node
    • toggle_expand: Expands the node if it is contracted, and vice-versa
    • select: Selects this node (and the nodes below, if the second parameter is set to “true”). Note that for this to work correctly, when you select a node, all the nodes below it are unselected (or else we could have some weird behaviors on the drags), although they are still highlighted (like they are selected because someone up the chain is selected)
    • toggle_select: Selects this node if it is unselected, and vice-versa
    • update_label: Forces a refresh on the label of the node
    • set_bold: Sets the label on this node to bold
    • (Virtual) get_label: Returns the label of the node
    • (Virtual) evt_select_change: This function is called whenever this node is selected
    • (Virtual) is_draggable: Should return true if this node can be dragged. Only if all nodes in the current selection can be dragged can the operation be executed.
    • (Virtual) try_drag: Should return true if this node can be dragged to the given target node
    • (Virtual) can_accept: Should return true if this node can accept all the given nodes as sub-nodes
    • (Virtual) notify_drag: This function gets call for each node that is dragged onto the target node, when the drag operation is completed (don’t have to do anything to change the structure of the tree itself, the nodes will be moved to the correct place)
    • (Virtual) get_menu_options: fetches a list of strings with the names of the options to show up on the pop-up menu. Only the options that are shared by all the selected nodes show up.
    • (Virtual) handle_menu_option: Gets called for all selected nodes when an option is selected.

 

For the record, you can use this code in any way you want (commercial and non-commercial), a heads-up and thank you would be nice.

I’m not responsible for any damages and bugs! Smile

Anyway, if you have any questions, just shoot them here or email me…

Hope this is helpful!

 
No Comments

Posted in Development, SurgeED

 

The hiatus

12 Sep

Hey all!

I’ve been neglecting (again) my blog… but I got good reasons! Smile

One was my birthday, which implies a lot of partying… My wife got me a neat video camera (I’ve been lusting for one for ages!), a Cannon Legria:

l_09822270

It has nice quality… maybe on my next Ludum Dare 48 hour compo I’ll manage to use some rotoscoping or live video to make the game sprites… Smile

Anyway, after that excuse runs out, I’ve been having too much fun playing around with my editor! I can only work on it on my spare time (when I also write this blog), so when I get into the zone I tend to not deviate from it.

From a practical standpoint, just added some options to the light system (soft shadows, through PCF) and moved the light creation to the a new “Instance entities” tab on the toolbar. It makes sense, since there’s nothing different on the creation of the light and the other entities. This way the GUI becomes more organized (and more akin to 3d Studio Max, aswell).

Most of the changes in the editor was the updating of resources. Now it is possible to reimport some assets and have them replace the existing ones, which is really cool!). Was thinking on live update (modify the resource files themselves and have the system update), but decided against it. The editor is built on the idea of being a self-contained “project”: it has its own directory structure, naming schemes, etc, so I don’t want the artists/level designers to be able to change things around… too much potential for disaster, in my opinion… I rather have them export the assets to some temporary directory somewhere on their hard drive, and explicitly import the assets into the project. It requires an extra step (or two, since the system asks the user if he really wants to update the assets), but I think its not a big deal. Anyway, if we see the benefit in this, I can add an option for a live-link, which are files that get imported automatically as soon as they’re modified (without asking anything, etc). Also want to add live update of textures (since that’s a different resource type, we can afford to break the coherency of the system for that, since they get copied to the project itself).

The editor is coming along nicely, its already considerably powerful and it works pretty well (still has the occasional crash, but since the system auto saves almost continuously, it doesn’t cost the artist anything). Next step on the development map on it is helper objects (with object linking/sub-objects and sub-classing working properly). I’ll make a video then (a better one than the last, with narration!).

Anyway, I’ll do an effort to be more regular at updating the blog… Smile

 
No Comments

Posted in Development, Games, SurgeED, Tools