Monday, August 16, 2010

Adding Users In Leopard

How to add a user from the command line in Leopard (since it's apparently too much for Apple to include useradd-esque scripts).


dscl localhost -create /Local/Default/Users/zack
dscl localhost -create /Local/Default/Users/zack UserShell /bin/zsh
dscl localhost -create /Local/Default/Users/zack RealName "Zack"
dscl localhost -create /Local/Default/Users/zack UniqueID 502
dscl localhost -create /Local/Default/Users/zack PrimaryGroupID 1000
dscl localhost -create /Local/Default/Users/zack NFSHomeDirectory /Users/zack
dscl localhost -passwd /Local/Default/Users/zack changeme


Also to look at what UIDs already exist...


dscl localhost -list /Local/Default/Users UniqueID


Scripting this is trivial but I am lazy. ;)

Friday, April 30, 2010

Metallica vector art wallpaper

Couldn't find a good Metallica wallpaper so I went and made one using Inkscape and Gimp, and the And Justice For All cover.

1680x1050


Will provide other sizes upon request. I also made a version without the gradient although it doesn't look as cool so I'm not going to post it.

Thursday, April 29, 2010

Boost + Graphviz

BGL is a template library which (I think) means that everything is just a bunch of header files. The Graphviz stuff apparently needs to be compiled though, and while I installed all of the Boost stuff through my package manager (Fedora 12) apparently I did not get this Boost/Graphviz stuff.

Here are the steps I went to build libbgl-viz.so, which can be linked to in order to run the graphviz examples. This is probably all documented somewhere but I could not find very clear instructions anywhere. Also it's worth noting that if you build a dynamic library you will probably have to distribute it with your application as you can't rely on it being in the Boost distribution (because it's not)!

1) Download boost-1.4 source.

2) Go to boost/libs/graph/src.

3) g++ -c *.cpp -I../../../ -Wno-deprecated -fPIC

4) g++ -shared -o libbgl-viz.so *.o

5) Next steps are optional if you do not want to install system-wide.

6) sudo chown root:root libbgl-viz.so

7) sudo mv libbgl-viz.so /usr/lib/

8) Try building some of the examples, you will need to link with boost_graph, libbgl-viz, and boost_regex. If you get any errors try playing with the order.

9) Go party!

Monday, January 11, 2010

Cameras, lights, and balls!

Another bunch of little updates.

* Mostly finished the virtual camera system. It supports multiple cameras with 5 and 6 degrees of freedom. Basically 5DOF = translational degrees of freedom along the XYZ axes and two additional degrees of rotational freedom (pitch and yaw). This is your typical FPS camera.
6DOF is all of that plus roll, more useful for flight sim-type games. The only thing I really think I have left to add is support for strafing. Also I think it would be kind of neat to have a wrapper around gluLookAt() that creates a camera and sets the proper orientation, because a lot of the examples I am looking at use it.

Camera example, mouse controlled flying 5DOF camera through a field of cubes.


* Enabled MSAA (multisample anti-aliasing) by default. Added support for backface culling.

* Renamed all function from the format dX to dgX to avoid conflicts with the physics library I am looking to use (ODE).

* Restructured source/include directories so that it is much more organised. Also I wrote a new configure script that should work better than the old one, supports folders in source directory, etc.

* Added some memory allocation macros.

* Mostly implemented a virtual light system (inspired by Mark Kilgard's multilight example). Still need to add support for shadows, spotlights, and materials.

Port of Kilgard's multilight example to Dagger3D.


* Brought one of my old experiments back to life. Basically it is a 2D box, you press the space bar and balls get dropped with semi-random initial velocities. Gravity affects the balls and they can bounce off each other. Difficult to do efficiently (I did not).

Semi-animated screenshot of bouncing ball experiment.


Starting work on a simple GUI system that will probably only include some very basic stuff, mainly buttons, text, and maybe some very very simple input fields.

Also looking into writing a resource => header file compiler, so that you can include (for example) a texture or font inside an executable.

Ahhhh I totally need to go to bed now...

Wednesday, December 30, 2009

Fancy text & documentation!

First order of business is that the API documentation for the SVN version of Dagger3D is now online. For a good overview of everything, check out the dagger3d header. A few files are still missing documentation, but expect that to change in the next few days!

Second item is that I got a little carried away playing with the font code. Basically I added inline colours and real tab support. Read about it here, see screenshot below.


Source for example in screenshot.

Also today I received in the mail six grand boxes of gingersnap tea.

Thursday, August 20, 2009

Performance comparison of TGA and PNG

I've been doing a little research into the TGA and PNG formats. Dagger currently supports both, something I'd like to change as it is completely unnecessary.

Both support RGBA and are lossless which are pretty much my only requirements.

TGA is simple to load, but the files are usually two to three times larger than the equivalent image saved as a PNG. PNG on the other hand is a compressed format so the files are pretty small, but loading is much more complex and I've resorted to using a PNG library that is several times larger than Dagger...

There is no reason to support two different formats with essentially the same feature set, therefore I would like to cut one of them out of Dagger. The problem so far has been deciding which one.

I can live with TGA's large file sizes, what I'm mainly concerned about is loading performance. I originally thought that loading compressed images would be faster because disk IO is slow. To test this I wrote a quick benchmark that loads a 512x512x24 image 100 (I also tried 1000 but the results were mostly the same) times and then takes the average load time for each format. It turns out that in all of my tests loading a TGA is 2.5-3.5 times faster than loading the equivalent PNG.

The code and the images can be found here. Make sure that you configure & compile Dagger with.
./configure DEFS=-DD_TEXTURE_DISABLE
make
The test was performed several times on both 32bit and 64bit machines (Fedora 11).

TGA loading was performed by Dagger, PNG loading was performed by whatever version of libpng ships with Fedora.

Edit: After changing my loader to use GL_BGR(A) instead of manually swapping pixel components, TGA loading is now roughly 12 times faster than PNG loading. Wow.

Late edit: Not sure how scientific this was. Increasing the number of times I loaded a texture showed that eventually PNG beats TGA. Unsure what exactly this means, but I'm probably going to go with PNG afterall seeing as how for the time being some kind of image compression is still important.