So for one of my projects I was dissatisfied with the fact that a QLabel whose horizontal size policy is Qt::Ignored will have its text clipped instead of having an ellipsis at the end (or somewhere in there). I whipped together a simple extension to QLabel that puts an ellipsis at the end based on the current size of the label. It's not complete in general (e.g., doesn't really support multiple lines), but for me it gets the job done. Feel free to use this code for whatever purpose you please (i.e., it's in the public domain).
elidedlabel.hpp
elidedlabel.cpp
Expressing Qt Love
The more I use Qt, the more I love it. Whenever I talk to people I'm always expressing my joy about how simple it is to do things with Qt. Whenever I do something new, no matter how small, I'm excitedly telling and showing friends what I've done. For example, recently I had the requirement that I wanted to be able to save images displayed by QGraphicsPixmapItem to a file. In a matter of a couple of minutes I extended QObject and QGraphicsPixmapItem, wrote an override for the contextMenuEvent to display a "Save Image" menu, and a simple slot to show a "Save File" dialog. Now all the images I'm showing on my QGraphicsView can be optionally saved to a file at the user's request.
A really simple thing, but that's because it was done in Qt! If it weren't for the existence of Qt I would probably still be using Java and Swing.
A really simple thing, but that's because it was done in Qt! If it weren't for the existence of Qt I would probably still be using Java and Swing.
A New Look
Well, the score editor project my friend and I have been working on has taken a bit of a regression. In particular, we decided to switch to Qt and C++ because Swing just wasn't doing it for us. It just lacked in a native feel, particularly on the Mac.
So there's nothing much new here, but by using QGraphicsView we have been able to really do some neat stuff. In particular, printing was a breeze but also exporting PDFs and supporting zoom. We also decided to display the score in pages instead of one long, unified page. I think it gives it a more professional feel, and also shows you exactly how it will look when printed. Anyways, a screen shot showing the zooming out, and also a new splash screen that yours truly put together. Not too shabby, but it still needs a bit more pizazz.
So there's nothing much new here, but by using QGraphicsView we have been able to really do some neat stuff. In particular, printing was a breeze but also exporting PDFs and supporting zoom. We also decided to display the score in pages instead of one long, unified page. I think it gives it a more professional feel, and also shows you exactly how it will look when printed. Anyways, a screen shot showing the zooming out, and also a new splash screen that yours truly put together. Not too shabby, but it still needs a bit more pizazz.
Sleep is lovely
So the last week hasn't been particularly productive. I've managed to get my GPU splatter almost completely working minus one little thing that will be annoying to handle. I think I'm going to put it off to the side and get to work on calibrating the camera array we have in the lab. Camera calibration is not particularly fun, but oh well, it must be done.
I've been refactoring my game engine code lately to abstract the physics-related code so that I avoid having to deal with Bullet directly. I've also started working towards my first game. I'm currently happy with the codebase I have, so diving into a game will really show me whether or not my design decisions were good or bad. If the latter, then I get a chance to refactor and learn from my mistakes.
Another thing I've decided is that the "experimental" C++0x stuff in GCC is awesome, and I've been modifying my code to use some of the useful stuff it offers. Initializer lists really made certain parts of my code look much nicer because I get to avoid dealing with boost::array and/or std::vector when dealing with static data. Whenever appropriate, I plan on taking advantage of the new auto keyword to make code shorter and more concise; No longer will I have to write things like std::vector<sometype>::const_iterator (or even have to typedef them!). There's a bunch of other small things that are cool too, like "raw" strings, smart pointers, variadic templates, rvalue references + move semantics, a null pointer constant, fixes for the "double bracket" issue with templated types, a foreach loop, and so on!
Perhaps one of the things I'm super excited for, though, are the lambda functions. Alas, I have to wait for GCC 4.5 to enter the world of stable releases before I can use them. Nevertheless, I installed the prerelease to play around with them some. I think a lot of these C++0x features are really going to make C++ code far more concise, almost like [some things] in Python. Here's my attempt at writing a simple "list comprehension" that writes the squares of the numbers from 1 to 10:
I don't know about any of you, but I think that's about as concise as one is going to get in a language like C++. I'm looking forward to playing around with these lambdas for my simple event processing functions that are registered with my engine's windowing system. All I ask is that the C++0x standard doesn't change dramatically between now and its official "release".
Anyways, I actually pulled an all-nighter last night (no reason in particular), hence the title of this post. Off I go to enjoy some amazing sleep.
I've been refactoring my game engine code lately to abstract the physics-related code so that I avoid having to deal with Bullet directly. I've also started working towards my first game. I'm currently happy with the codebase I have, so diving into a game will really show me whether or not my design decisions were good or bad. If the latter, then I get a chance to refactor and learn from my mistakes.
Another thing I've decided is that the "experimental" C++0x stuff in GCC is awesome, and I've been modifying my code to use some of the useful stuff it offers. Initializer lists really made certain parts of my code look much nicer because I get to avoid dealing with boost::array and/or std::vector when dealing with static data. Whenever appropriate, I plan on taking advantage of the new auto keyword to make code shorter and more concise; No longer will I have to write things like std::vector<sometype>::const_iterator (or even have to typedef them!). There's a bunch of other small things that are cool too, like "raw" strings, smart pointers, variadic templates, rvalue references + move semantics, a null pointer constant, fixes for the "double bracket" issue with templated types, a foreach loop, and so on!
Perhaps one of the things I'm super excited for, though, are the lambda functions. Alas, I have to wait for GCC 4.5 to enter the world of stable releases before I can use them. Nevertheless, I installed the prerelease to play around with them some. I think a lot of these C++0x features are really going to make C++ code far more concise, almost like [some things] in Python. Here's my attempt at writing a simple "list comprehension" that writes the squares of the numbers from 1 to 10:
#include <iostream>
#include <algorithm>
#include <iterator>
int main(int argc, char *argv[]) {
int i = 1;
int data[10] = {};
std::generate(
data, data + 10,
[&i]() -> int { return (i * i++); });
std::copy(
data, data + 10,
std::ostream_iterator<int>(std::cout, " "));
std::cout << std::endl;
return 0;
}I don't know about any of you, but I think that's about as concise as one is going to get in a language like C++. I'm looking forward to playing around with these lambdas for my simple event processing functions that are registered with my engine's windowing system. All I ask is that the C++0x standard doesn't change dramatically between now and its official "release".
Anyways, I actually pulled an all-nighter last night (no reason in particular), hence the title of this post. Off I go to enjoy some amazing sleep.
FIZZICKS!!!!
I haven't done a whole lot with my game engine stuff over the past week (been focusing on implementing GPU splatting for my research), but I decided to capture a video today. It's a little low quality, but it shows off the basics. For the most part, there's enough functionality in there to start working on a game, but I want to make the code simpler and easier to work with. Anyways, here's the video:
Currently I'm using Bullet for Physics, CEGUI for the in-game GUI, DevIL for loading images, OpenGL for rendering and a whole lot of boost to make my life easier. The windowing (Cocoa, Carbon, X11 or Win32) is my own. Eventually I might do the same for the image loading and in-game GUI so that there are less dependencies, but for now I don't really care too much about that. I'm planning out a simple game to make eventually, so look forward to that in the future. Perhaps not the very near future, but quite possibly by the end of the year.
Currently I'm using Bullet for Physics, CEGUI for the in-game GUI, DevIL for loading images, OpenGL for rendering and a whole lot of boost to make my life easier. The windowing (Cocoa, Carbon, X11 or Win32) is my own. Eventually I might do the same for the image loading and in-game GUI so that there are less dependencies, but for now I don't really care too much about that. I'm planning out a simple game to make eventually, so look forward to that in the future. Perhaps not the very near future, but quite possibly by the end of the year.
Modeling 101
Okay, this is far from me giving you a 101 class on modeling, because when it comes to drawing/modeling/things of that nature I suck pretty bad. Nevertheless, I amazed myself at how quickly I could whip up a "stick man" model with a basic skeleton using Blender.
He's in a sitting pose, waving I think. Yeah, I have skills *cough*. Anyways, other than a crash here and there, Blender is a pretty decent piece of software. Some of the keyboard shortcuts are non-intuitive but once you get them down you'll be unstoppable.
That screenshots also shows off my integration of CEGUI into my WIP. I struggled with two issues that I'll share with people. The first issue was that you need to have the OpenGL viewport set up correctly when initializing CEGUI. Unfortunately my initialization was occurring before I called glViewport, but that was easily resolved. The second thing was that having any VBOs/VAOs bound messes up CEGUI (for now). Be sure to release any bound buffers/arrays before rendering things.
CEGUI is a pretty hefty library, but it looks to be incredibly robust and still actively developed. I loved how I could manually inject input events into the CEGUI system, which meant easy integration into my own windowing system. I noticed that some other systems used existing input libraries or hooked into something like GLUT or SDL. I also love the ability to use describe things in XML. I think CEGUI and I will get along quite fine until I decide to write my own UI system.
There was a bit of messing around getting things to link properly, but I managed to get everything working in the end. I'll finish off by pointing out qmake. I use it for my Makefile generation and I absolutely love it, mainly because it's incredibly simple. CMake is another option if you happen to be looking for one.
He's in a sitting pose, waving I think. Yeah, I have skills *cough*. Anyways, other than a crash here and there, Blender is a pretty decent piece of software. Some of the keyboard shortcuts are non-intuitive but once you get them down you'll be unstoppable.
That screenshots also shows off my integration of CEGUI into my WIP. I struggled with two issues that I'll share with people. The first issue was that you need to have the OpenGL viewport set up correctly when initializing CEGUI. Unfortunately my initialization was occurring before I called glViewport, but that was easily resolved. The second thing was that having any VBOs/VAOs bound messes up CEGUI (for now). Be sure to release any bound buffers/arrays before rendering things.
CEGUI is a pretty hefty library, but it looks to be incredibly robust and still actively developed. I loved how I could manually inject input events into the CEGUI system, which meant easy integration into my own windowing system. I noticed that some other systems used existing input libraries or hooked into something like GLUT or SDL. I also love the ability to use describe things in XML. I think CEGUI and I will get along quite fine until I decide to write my own UI system.
There was a bit of messing around getting things to link properly, but I managed to get everything working in the end. I'll finish off by pointing out qmake. I use it for my Makefile generation and I absolutely love it, mainly because it's incredibly simple. CMake is another option if you happen to be looking for one.
We got monkeys!
Yep, we do have monkeys. Blender monkeys, to be exact. I whipped up a simple loader for Wavefront OBJ models. Only loads the basic geometry now, so I have to work on the material stuff. One problem is my lack of a shader that does more advanced illumination, so that's something I have to work on. The two screenshots I've posted only do per-pixel lighting with Lambertian reflectance. I also want to make it so that my OBJ loader doesn't reproduce verticies with the same position + normal + texture coordinates.
I have also gotten things working with Cocoa. I do the event loop myself to make things easier, but it's all good. Full screen mode works in Cocoa too, but not in X11/Win32 because I haven't had the chance to do so yet. And with Cocoa I'm briefly gonna bring up the PIMPL pattern and how I made use of it.
The PIMPL pattern is a way of hiding an implementation from translation units other than the translation unit that implements some class. This is possible because you can have a class member that is a pointer to a type that has only been forward declared.
So why did I need this? Well I needed to store Objective-C pointers (i.e., NSWindow *) in my Window class. The problem here is that everything works wonderfully in Objective-C files, but everyone else chokes when including Window.h because they get confused by the Objective-C code in <Cocoa/Cocoa.h>. I couldn't really forward declare these Objective-C classes either, because again I have the same problem: Objective-C in a C++ file just doesn't work (as far as I know?). Enter the PIMPL. I forward declare a struct that will hold these Objective-C pointers and define that struct in my Objective-C implementation of the Window class. Problem solved, whahay!
I have also gotten things working with Cocoa. I do the event loop myself to make things easier, but it's all good. Full screen mode works in Cocoa too, but not in X11/Win32 because I haven't had the chance to do so yet. And with Cocoa I'm briefly gonna bring up the PIMPL pattern and how I made use of it.
The PIMPL pattern is a way of hiding an implementation from translation units other than the translation unit that implements some class. This is possible because you can have a class member that is a pointer to a type that has only been forward declared.
So why did I need this? Well I needed to store Objective-C pointers (i.e., NSWindow *) in my Window class. The problem here is that everything works wonderfully in Objective-C files, but everyone else chokes when including Window.h because they get confused by the Objective-C code in <Cocoa/Cocoa.h>. I couldn't really forward declare these Objective-C classes either, because again I have the same problem: Objective-C in a C++ file just doesn't work (as far as I know?). Enter the PIMPL. I forward declare a struct that will hold these Objective-C pointers and define that struct in my Objective-C implementation of the Window class. Problem solved, whahay!
Game Design
So, one thing that I've been working on over the past week is reviving my "game engine" that I started working on a couple of years ago. It's not far, but I'm currently happy with the way things are going:
Pretty simple, I know. Shows off some basic texturing and per-pixel lighting, but that's about all I got for now. Currently this is all done in OpenGL, but I've abstracted many of the concepts in such a way so that I could easily swap in a DirectX renderer. This is done at compile-time though, so that I avoid dealing with dynamic libraries.
It's pretty easy to get something up and running too. I just extend an application class, which takes care of some nitty gritty details for me (e.g., the game loop). With the help of some compile-time polymorphism, I just override three methods: initialize, update, and render. Also, input handling (keyboard + mouse) is currently implemented using mappings to boost::functions. These mappings are registered at runtime, generally in the initialize method one specifies.
There's plenty of work to be done, but I think it's a good start. Some things I need to work on:
Of course, there's a lot more than that -- Terrain LoD, Character Animations, GUI Rendering, Game Logic, Physics, etc -- but it's a start!
Pretty simple, I know. Shows off some basic texturing and per-pixel lighting, but that's about all I got for now. Currently this is all done in OpenGL, but I've abstracted many of the concepts in such a way so that I could easily swap in a DirectX renderer. This is done at compile-time though, so that I avoid dealing with dynamic libraries.
It's pretty easy to get something up and running too. I just extend an application class, which takes care of some nitty gritty details for me (e.g., the game loop). With the help of some compile-time polymorphism, I just override three methods: initialize, update, and render. Also, input handling (keyboard + mouse) is currently implemented using mappings to boost::functions. These mappings are registered at runtime, generally in the initialize method one specifies.
There's plenty of work to be done, but I think it's a good start. Some things I need to work on:
- Resource Management. Currently all resource management is done through boost:shared_ptr. In other words, there isn't really any "management" happening. I need some form of a manager that can load various assets, caching things as necessary to help with efficiency.
- Higher-level Primitives. Currently I send triangle primitives to the renderer, which is a little too low level for my liking. I'd like to pick a set of base primitives that are at a higher-level (e.g., triangular mesh, model, terrain)
- Deferred Rendering. I've always wanted to take a stab at implementing deferred rendering. I'd just love to play around with shaders in general and getting some fancy stuff on the go.
Of course, there's a lot more than that -- Terrain LoD, Character Animations, GUI Rendering, Game Logic, Physics, etc -- but it's a start!
Current Work
I thought that since I haven't posted in awhile, I'd put something new up to let everyone know what's been up for the past few months.
Well first, posts have been delayed because up until mid-December I was busy finishing the last of my courses required for my M.Sc. After that, I spent holidays both relaxing and working on my first paper. The paper focuses on improving stereo matching for underwater environments. In particular, the paper builds a physical-based foundation for epipolar geometry in an underwater stereo system, one in which cameras are placed in waterproof housings. We have results on synthetic data which shows that naive approach of traditional stereo by itself is inferior to our own approach, especially for cameras with wide angle lenses.
I think I've put together a pretty good paper (along with plenty of revisions and invaluable feedback from my supervisors), so here's hoping to getting accepted for ICPR 2010! If our paper gets accepted I'll be off to Istanbul in late August to present it. I'll be sure to keep everyone updated on this. If it does go somewhere, I expect several more publications will stem from this work, hopefully in a first-tier conference and maybe even a big journal!
The score editing software that my friend and I were working on has been put on the back burner temporarily. I am mostly focused on school and he is busy with his job so, for now, it's hard to find the time and the focus necessary to move the project along. Hopefully it'll pick up eventually, and if it does, I'll be sure to keep everyone updated on its progress.
Well first, posts have been delayed because up until mid-December I was busy finishing the last of my courses required for my M.Sc. After that, I spent holidays both relaxing and working on my first paper. The paper focuses on improving stereo matching for underwater environments. In particular, the paper builds a physical-based foundation for epipolar geometry in an underwater stereo system, one in which cameras are placed in waterproof housings. We have results on synthetic data which shows that naive approach of traditional stereo by itself is inferior to our own approach, especially for cameras with wide angle lenses.
I think I've put together a pretty good paper (along with plenty of revisions and invaluable feedback from my supervisors), so here's hoping to getting accepted for ICPR 2010! If our paper gets accepted I'll be off to Istanbul in late August to present it. I'll be sure to keep everyone updated on this. If it does go somewhere, I expect several more publications will stem from this work, hopefully in a first-tier conference and maybe even a big journal!
The score editing software that my friend and I were working on has been put on the back burner temporarily. I am mostly focused on school and he is busy with his job so, for now, it's hard to find the time and the focus necessary to move the project along. Hopefully it'll pick up eventually, and if it does, I'll be sure to keep everyone updated on its progress.
Subscribe to:
Posts (Atom)