RSS
 

Archive for the ‘Development’ Category

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!

 

Sound woes…

14 Sep

My artist has been ill these last couple of weeks, and as such I’ve done nothing on “Amoeba” lately… It’s hard staying motivated when working alone on a project (at least for me).

sample01

Anyway, since he’s back I decided I should try and get this game finished (still don’t know what I’ll do about the music and from the commercial perspective)…

The main thing on this project (for me at least) is getting experience on mobile platforms, and to release this on multiple platforms (first on iPhone, Android and PC, then Mac/Linux, and finally WM7), and that part of the plan has been working as intended – although only really experimenting on Android and PC).

As I’ve said before, I’m using Marmalade to be able to build the game using my existing engine, Spellbook. So far, it’s been a pretty decent experience, I’m using Spellbook to build the game itself, and I just have a very thin abstraction layer that wraps Marmalade, but has the same interface as my main deployment platform (DX9+FMOD+DirectInput).

But, alas, finally I’ve found problems, with the sound component. The sound API of Marmalade is very poor (understandable, since it’s not very important in the mobile market), and only supports 16-bit PCM RAW files. This requires you to know the sample rate of all the sounds when you play them out (instead of loading that information from the WAV header or something). Of course, this is not the focus of Marmalade, but since they wasted so much time on the graphics APIs, they could have been as complete in the sound API). They have support for compressed audio, but only for the streaming API.

This is particularly bad for someone like me, that’s been using FMod for ages, and I’m used to just loading samples with one call, and playing them with another…

Anyway, it’s relatively simple to do a WAV or some other uncompressed format loader, but for “Amoeba” I can skip that and use RAW files playing at 22Khz… I’ll have to change this for the PC version (which can use FMod), but for now it’s good enough.

The real problem I’m having is not related to Marmalade, but with the sound system of the Android handhelds… There’s a huge latency between the call to the sound player and the actual sound playing (in some cases, almost one second). Some searches online lead me to believe that this is a problem with Samsung mobiles, but it’s a serious flaw, since even 200 ms lag time in a game can make everything look much worse… I’ve even ran “Angry Birds” on my Samsung S, and although I didn’t notice it before (it’s subtle in the case of that game), there’s a delay present aswell, so I believe it is unavoidable… Going to try it on a Google Nexus phone in some days to see if the problem is exclusive to Samsung’s implementation of Android… if so, I’ll have to rethink sound in the game, since it can become annoying, doing things and getting the sound feedback 200-500 ms later…

On other notes, I’ve also did some memory profiling, trying to see if I have memory leaks or anything, but I found a problem that got me stumped… According to the ARM emulator, I have about 4 Mb allocated (plus another 4 Mb on OpenGL textures), but my task manager on the Android shows about 40 Mb allocated (more precisely, when I close the application, I get about 40 Mb back). I’m not sure if the Android stack pre-allocates some amount of memory, even if I don’t use it, and I maybe can adjust that on the manifest (saving that for later in the project); but I’m very sure that I don’t allocate 40 Mbs of data on my game!

But hey, no memory leaks! Smile

 

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

 

SurgeED

30 Aug

Worked a bit on my editor, fixed some bugs, improved some others…

Main improvement was a bug fix on the shadowmaps for point lights… everything that was behind the light (used the “back” shadowmap – using dual paraboloid shadows here) was being rendered wrong, depending on light orientation (that shouldn’t affect point lights).

Good shadows on point (and hemisphere) lights still depend a lot on the tessellation of the scene (due to the dual paraboloid projection)… I’ll probably add the option for cube-map based shadowmaps, they might be better (albeit way more expensive) for specific cases. The cost might be offset with better batching of solid geometry (create a bunch of vertex buffers with just positions, which is all is needed for shadowmaps), shadow-atlas (eliminate render target switches, but need more complex shader code and the “border” ability on the texel-sample – win the ability of batching shadow-mapped lights and less texture source set-operations) and slower updates on the shadowmaps (update only every 2nd frame or something like that).

The video quality is crap, and the mouse cursor isn’t visible… I was using SnagIt 8 to do the capture, with a DivX codec and 30 FPS capture, but the results were terrible… Hopefully I’ll figure out a better way to do these captures in the future…

 
 

GUI stuff…

29 Aug

I’ve been working on and off on “Amoeba”, mainly focusing on the GUI work (area selection, level selection, etc), and it has been a struggle:

gui_work

First, the “simple” problems: font aliasing was hard to get rid of (and its not completely solved, but on my Android phone you can’t see any major artifacts, specially if you aren’t looking for them).

Then the complex problems: different screen resolutions/orientations. I want “Amoeba” to work on all devices I can possibly put it on, and that means different resolutions and orientations. We got 480×800, 1024×768, 640×960 and many more… And these means different aspect ratios, which just add more confusion to the problem.

The game itself is easy to adjust to the resolution (I have a virtual resolution system coupled with some “margins” disguised with some GUI elements), but if I do the same on the GUI, it looks amateurish, and that’s a definitely no-no on indy game development…

I could program a kind of interchangeable file with the positions of the elements (or use structures in C++, whatever), but even that is hard to tweak, because of dynamic scaling, and I have to consider ALL the possible resolutions. But this might be a solution in the future; I’ve already decided that all my next mobile games will only support one orientation anyway, since it’s too much work supporting multiple ones…

So, getting the GUI working on different resolutions/orientations/aspect ratios has been a though fight… and it’s only half the battle…

Then we have the code problem, where we hook behaviors… what happens when I left click and drag the mouse (equivalent to taping the screen and dragging my finger on it)? What’s the reaction…

On this project, I initially had all the code in C++ in the animation loop of the screen, but it was becoming unmanageable. Every change implied going through loads of conditions to get to the right place, and half the time I’d just get it wrong anyway… Confused smile I decided to scrap that and go for scripted GUI. While it’s not much better, it’s easier to control a GUI with LUA co-routines, specially transitions between “pages” of GUI. It’s still not optimal, but a bit better…

Working on this (and on my previous experiences with GUI elements), I got thinking… I hate GUI work, but mainly because it seems to be much less organic than the rest of my code (at least the end result). Why is that?

One reason I can think of is that “I HATE GUI WORK”, so I do sloppier code to try to get it over with… the other possible reason is lack of planning of the GUI and its elements. Finally, the lack of a really defined GUI framework on Spellbook might hinder me aswell…

Basically, I see 7 different ways of creating a GUI/GUI logic:

  1. All GUI elements on a particular game are a separate C++ object that can handle itself. This was the approach I used on “Blitz and Massive” and it worked very well, from a code organization point of view. This was further facilitated due to the fact that most of the “end result” of the GUI actions were script calls.
  2. We have a generalized object system (with sprites, text, aggregate objects, etc) and we instance it in C++. Control is done by using the animation pump that reacts to specific events. This results in long, hard-to-manage code, and loads of “temporary” variables to handle the state of the system.
  3. Same as last, but using scripting to instance the objects and registering events. Events trigger script calls that change the system. The “temporary” variables are more contained and can be handled locally by the scripting. Problem is that a language like Lua has great facilities for co-routines (superior to all languages I’ve ever seen!), but it’s terrible for flow control (because of syntax… seriously, on the 21st century, someone still requires the “THEN” keywork for an “IF” clause!?!?)
  4. Same as 2), but use a more sophisticated event system for the event handling, instead of the animation pump.
  5. Use a GUI middleware (from native stuff like Win32 or iOS stuff (not cross-platform), to more “game-like” alternatives like Scaleform (expensive) or “web-like” like Webkit/Awesomium (I hate web-technologies and don’t want to have 2 scripting languages involved in a single project)).
  6. Roll your own GUI middleware (a giant enterprise by itself!)
  7. Hire a gnome to do it!

 

I see pros and cons in all of these, but I think that most of my problems can be addressed with taking the time to think about the GUI, to plan it appropriately, like I do with the rest of the game components…In the meantime…. I REALLY HATE GUI WORK!

 
 

Starting up…

20 Aug

Theme is “Escape”, hum? Didn’t see that one coming… Smile

Already have an idea, involving some insanity (escaping your own mind) and whatnot…

Anyway, time to check out the blog, eat breakfast and start cranking some code!

Good luck everyone!

Ah, obligatory deskphoto:

desk

 

Contamination!

01 Aug

Amoeba_Contamination

Have been working a bit more on the Amoeba game, and most of the game code is done… still missing the game flow components (splash->main menu->level select->play->game over, etc), but I need some art for it, that’s being taken care of…

Had the time to implement some experimental gameplay mechanics, to make levels be a bit more different from each other… In the screenshot above, you can see the “Contaminate” mechanic… instead of the cells flying off the screen when we do a mistake, they hang around on a contaminated state… From there, I have two different mechanics when the contaminated cell touches other cells: either it destroys them, or it infects them.

Contaminated cells can be destroyed, either my clicking on them a certain amount of times, or by laying a trail on top of them (which is slower, but affects multiple cells).

Just this addition really improves the gameplay of the level, specially if we consider the “greed” factor: the reward for getting loads of cells together before dumping them into the collector is very large, so the “greed” instinct comes online and ultimately dooms the player.

There are other mechanics, like cells that mutate, or normal cells that infect others, but I still need to do some experiments to see how they work in a real game level.

Also worked on some powerups/powerdowns from a code standpoint, which also add something to the gameplay (like attractors, which make all cells that aren’t of the same color as the one we have be attracted to the finger, which makes it harder to navigate in the game field).

All of these are making the game become more complex and complete, which I guess is a good thing, but it kind of spoils the initial purpose of building a simple game to experiment with publishing/deploying of a game in this kind of mobile platforms…

Anyway, now I’m in a phase where I need some art to carry on, and I’m almost going for vacations, which will make updates to the blog a bit on the minimal side… Smile

 
 

Amoeba

22 Jul

The video below shows the game I’ve been working on my spare time with a friend. The working title is Amoeba, and it is being developed with Spellbook running over Marmalade.

Progress has been nice and steady, considering I’ve worked a total of 4 or 5 hours on it, not counting the basic porting time for Spellbook.

 

We deliberately chose a simple game to develop, since we wanted to tackle loads of stuff at the same time (developing for mobiles, distribution, marketing, etc) and we didn’t want to have to worry about the game development as well…

As it is, the game is about using your finger to “grab” unicellular organisms of the same color. If you collect enough, you’ll get a “Breakthrough” that allows you to advance to the next level. If you grab an organism of a different color of the one you’re currently grabbing, they’ll nullify each other and the risk of “Infection” is greater.

Not groundbreaking, but I’m hoping to achieve other objectives than perfect game design with this one:

  • Finish a game for mobile devices
  • Getting it into the market
  • Marketing it

 

Some challenges so far were to adjust the game to different device orientations and to different aspect ratios, both of which are already up and running…

Next steps include some basic GUI work and level progression… After that, level design and sound, and finally polish and menu stuff…

The video above is running in the ARM emulator that comes with Marmalade, but the game runs exactly the same in my Samsung Galaxy S (an Android phone).

 
 

One-Button Arthur

19 Jul

Another awesome one-button game: One-Button Arthur.

It’s from the same creator of One-Button Bob, it runs about the same length and it’s super-fun… Smile

I’m feeling a huge urge to do a one-button game for mobiles, specially if I can make it data-driven enough so that my friends can help me with level design…

For now, it’s just a pipe dream… Smile

Been working on the mobile stuff, particularly orientation of the device… under Marmalade, it’s a bit complicated, since I already have a virtual resolution system that seems to clash a bit with their own, and I’ve been finding it difficult to find the orientation of the device from the low-level stuff… think I’ll have to use the resolution change event to find out the current resolution and extrapolate orientation from there…

Also found out that my cellphone (a Samsung Galaxy S) doesn’t detect the orientation change when it is upside down (which shouldn’t be a problem, to be honest).

I’ll start working on my current game in the next few days, starting with some background elements and interaction with the player’s finger…

 
 

Textures working

15 Jul

Worked a bit on the port of Spellbook to the Marmalade framework, got textures working:

Textures

That’s on the emulator (couldn’t take a decent photograph on my Samsung Galaxy S)…

Was quite complicated getting this to work, actually…

1) Had to build a DDS loader… Although it currently only supports R8G8B8A8, R8G8B8 and A8 formats, it can be easily extended in the future (specially when I understand some more about OpenGL, since OGL ES 1.0 only supports RGB, RGBA and LUMINANCE textures). Thankfully, I did half the work some time before when I did an iPhone application.

2) After I got this working, I only had a white square on the screen, where my sprite should be… After loads of mucking around in all the wrong places, I found out on a forum the solution: I had mipmapping enabled when I did the glTexImage2D to load the texture, so the function was still waiting for the rest of the data (for the mipmaps), and I wasn’t giving it any… so the texture creation process wasn’t finished and hence the white square…

3) Channel ordering:

Red_Blue_Channel_Switch_OpenGL

Might have trouble seeing it, but the red and blue channel is switched… OpenGL stores the information differently from DirectX, which might be a problem in the future, when I want to do cross platform dynamic texture updating.

Anyway, the sprite you’re seeing is animated. It was generated with IBGen, a tool I built that grabs a 3d model and its animations and export a sprite sheet, an image bank and animation data to be used in 2d games. Below you can see an example of a sprite sheet:

afonso0400

The packing system isn’t very good yet, but it serves my purposes…

Still don’t know what my next step is, but probably a better reaction to different orientations of the mobile (currently the graphics get drawn offscreen, etc, because Marmalade is reacting to it itself, which makes for weird effects).