Showing posts with label dev. Show all posts
Showing posts with label dev. Show all posts

Monday, May 2, 2011

Ubuntu 11.04 and the Unity desktop



So the new Ubuntu has been released for a couple of days now long enough for people to get a taste on what they like, dislike and what needs to be improved in unity before they consider it a polished desktop experience.

Personally I think Unity has a lot of potential, but that doesn't mean that it is the bees knees in its current state. There are just a few little gripes I have with the desktop and although I am impressed with the amount of work they have done thus far it is still far from a finished product.


  • Unity configuration tool, currently the closes thing that we have for configuration for the unity desktop is the unity plug-in settings in the compiz configuration manager in which you will need to install in order to get access to it.
  • A non net-book/tablet styled applications menu, although the current way of getting to your applications works and I understand that it was designed for the more casual/new user who would have the few applications that they would use regularly in their dock. What about the power users? Users who would have an array of different applications they would use on any given day, there needs to be a menu layout similar to the 'applications', 'places', 'system' menu that we've all known and loved.
  • Click minimize, this one is quite logical, now that the unity dock has also functions as the window lists when you click on the launcher icon that belongs to the said program it should minimize the application window. This is because this is the standard behavior that everyone will expect myself included.
  • Always display the applications menu in the global menu, I'm not at all phased by the decision to have the Mac styled global menus however having the menu hidden till mouse over is unconventional and should be an option to enable instead of the default behavior.
  • Always visible dock, there are many reason for this first one people may want to always see the dock which is a given preference. But more importantly for people using it on tables and touch interfaces how are they meant to get it back without troubles?

  • A proper workspace switcher, the current method is only optimized for touch interfaces where they would have difficultly tapping the individual squares to each corresponding workspace. But the users whom have it installed on their desktop, laptop and even net-books this method is slow and en-cumbersome for something that we are so used to 'click the square switch!'


So my final thoughts on the unity desktop is that it is a good start and something that I can see a future in, so I can't wait to see how unity matures by the time the next long term release comes out.

Friday, December 17, 2010

My New Desktop (Fluxbox)


I've tried a few times to create a fully minimal desktop that uses as little resources as possible whilst still appealing to my tastes. And I have to say I'm quite happy with my current setup, I don't think I've ever had a system this responsive and fast before. X3 login takes roughly 2-3 seconds

Fluxbox (window manager and desktop environment) occupies  2.2MiB of RAM
Conky (displays time and system information) occupies  1MiB of RAM
Tint2 (panel) occupies  768KiB of RAM

Need less to say thats not all the system is running for instance I run a few services like samba, bluetooth and networkmanger, xorg of cause so my system sits at around 100MiB of RAM may be a little more or less.

when I get my configuration 100% how I want I'll probably post my config.

Sunday, November 28, 2010

Exporting to sauerbraten, using blender and the SMD format

For those of whom have traversed the Internet for free games you probably have at least heard of Sauerbraten http://sauerbraten.org/, which is the successor to the original Assault Cube http://assault.cubers.net/ which still is a pretty fun game to play. Anyway moving along as you might of heard from one of my other posts namely (and only) on my previous post you may of heard that I'm partaking in making of a game and for the mean time the cube II engine has taken our fancy to be the engine that we will build off.  Since I'm currently the only programmer/technical dev on the team it was up to me to get the environment setup. Because we plan to do all our modeling in blender more specific the development builds so 2.5 which has broken a few plug-ins that was needed for us to able to continue production. Namely the md3 exporter and i think the there was a md5 exporter as well which was mainly used in the original Sauerbraten game. Luckily for us the cube II engine supports a wide variety of formats for the models http://sauerbraten.org/docs/models.html in which i was quite delighted to see. So in the search to find a compatible export plug in for one of the supported formats other then obj which can only be used for static models so no animation nor rigging can be applied. I eventually came across the smd format, which you may of may not heard of but you would of defiantly heard of the games that uses it, its the format that valve games use, such as Half Life and Team Fortress. In general i was quite happy to see this this means that we would be able to use these models in the source engine as well, Gary's mod anyone?

Well anyway lets get back on topic, I discovered a smd import/export plug in that is compatible with blender 2.5.

here is the the projects page: https://code.google.com/p/blender-smd/

the smd format support in sauerbraten is from what i can tell is fully fleshed out and has all the same options as its support for MD5 which what i was originally going for. So lets take a look on the steps involved in exporting to a SMD and then the process of configuring and setting it up so that it is ready to be used in the cube II engine.


Step 1
First of we need to download and install the blender-smd plugin. go to https://code.google.com/p/blender-smd/ and download the latest version of the plugin(io_smd_tools). Then extract the zip folder to any temporary path. Open up blender and click "File" >> "User Preferences" (shortcut Ctrl + Alt U) to get into blender's application settings. Then navigate to the "Add-Ons" then click install select the extracted file from the download earlier. Once you go the plugin file selected click "Install Add-On". Then in the Import/Export section "Import/Export SMD Tools" and check it to enable the plug in. Remember to click "Save As Default" at the end so that this plug in is enabled by default each time you open up blender.






    Step 2
    Now its time for the easy part which is making model and exporting it, there is a few things that you will need to keep in mind in regarded to exporting you models in SMD for the cube II engine. The main thing you need to keep in mind is that name of the material you use for the model. Though the actual settings i believe don't get transported into the export, this is so when it comes to adding the color, normal(bump), spec maps that you know the name of the material to apply it to. When it comes to actually exporting the model you will find the SMD tools menu in the scene menu in the buttons panels, its a simple process of selecting the output folder for the project and the models that you wish to export.
     



    Step 3 
    Now move the model, and a copy of the textures you wish to apply to it in the game to sauerbraten's <base>/packages/model/<model's folder> so that the engine can find it when you call it. and now we need to create a file called "smd.cfg" inside the model's folder so that we configure the model for the game. here is an example of the "smd.cfg" and what it might look like.

    example configureation
    smdload crate02.smd // model no. 0
    smdskin crate02 skin.png

    mdlscale 1500
    end of example configuration

    The first line "smdload crate02.smd" tells  the cube II engine where the model file is located. the second line "smdskin crate02 skin.png" instructs the engine to apply the objects texture map or "skin" as it is referred too to the material. (note: "crate02" is the name of the material inside "crate02.smd" remember if you did not name the material in blender then "smdskin Material skin.png" would be what you would have to enter.)
    Lastly the "mdlscale 1500" this line is needed because blender units may look large in blender but the cube  II engine to treats 1 blender unit as like 1 inch in size the 1500 actually tells it to scale the object 1500% of it original size.

    (this is just a very basic configuration if you want to set things like the normal map (bump map) Look to the model documentation you may notice that the SMD section is not explained but that only because all the SMD options are identical to MD5 the only difference is that "md5" in all the commands is replaced with "smd" "md5load" = "smdload" etc.)


    Step 4
    now all that i s left is to import the model in the game engine to do so, in the command shell in the cube II engine whilst editing a map. Simply type "mmodel <model'd folder path>" eg. model's folder is in <base>/packages/models/crate02 then the command will be "mmodel crate02" to import the model. and the rest you should already know if you've messed around in the cube II map editor.