soledad penadés

repeat 4[fd 100 rt 90]

We have finished this demonstration a year and some months late but… who cares? Now featuring Mac Os X version (as well as the win32 one), as well as a new scene and lots of improvements here and there. Grab Blue Tuesday final version!

If you just can't see it, try the video version :) (Quicktime file, H264 compression, 400×300 pixels) - although nothing compares with the 1024×768 pixels size of the realtime version. Should you have a decent opengl card, go for the first one…

I hope you have a very great and blue tuesday :)

I was just wondering… what will be the size of the data types on this computer? (Must recognize I hadn't done any research before wondering, then I would have discovered that mac's follow IEEE754 standard, as windowss -or that they say-).

So there we go with it:

#include  using namespace std;

int main (int argc, char * const argv[]) {

// insert code here...

cout << "Type sizes" << endl;

cout << "BOOL " << sizeof(bool) << endl;

cout << "CHAR " << sizeof(char) << endl;

cout << "INT " << sizeof(int) << endl;

cout << "FLOAT " << sizeof(float) << endl;

cout << "DOUBLE " << sizeof(double) << endl;

cout << "INT* " << sizeof(int*) << endl;

return 0;

}

And what does it return?

Type sizes BOOL 4 CHAR 1 INT 4 FLOAT 4 DOUBLE 8 INT* 4

Bool types use 4 bytes!?! WTF?!

Usually computer science students tend to think that the Compilers subject is useless and will never have any application in their lives. I mostly agree with them. We usually finish doing crap works in where the hardest development tasks are thinking a base class tree (which will very probably have to be changed due to client requirements), so there's no space for applying our Wonderful Knowledge about Compilers.

Luckily I have more ideas in mind than doing typical applications; even more, I was thinking about one feature that I want to have on my no-engine and I suddenly realized that I needed to have a little parser on it. Thanks God! All of those (supposedly) wasted hours in the laboratory trying to code an stupid Pascal compiler (in Pascal!) have been justified three years after! Isn't it great? I was looking at the expression grammar of that documentation and then I saw everything so clear and structured!!

Cool!

When I showed shine the not-engine for demos that I had been developing, I can imagine his "ARGH" face. An ugly mixture of C and C++ code, with lots of things like

#ifdef _DEBUG

OutputDebugString("blabla");

#endif

instead of developing a logger object which always proves to be more efficient, powerful and useful (as you can for example configure it to output to a console or to a text file).

And those past days we have been discussing and thinking about a way of materializing the ideas which are rounding our minds. Most of those ideas were already implemented in the latest demo we did (vslpx), but they would need a bit more of polishing. Other ideas could be also taken from the structure that shine used on neon v2.

Finally we have here a good constraint: all the development should be system independent - and I am being really serious about this. We need to be really strict on this point because I want my demos to run on mac. So there's no place for directx, windows includes or win32 api functions, either mac os api functions. Luckily I'm going to use opengl (that's the only graphics framework that I have managed to understand), so we don't lose too much about directX, but I need to be very careful about little details as the endianess of the machine running the demo, the system file path separator (whether it is "\", as in windows, or "/" on *nixes, ":" on mac's -sometimes only-) and things like that…

All of these points bring me to a clear conclussion: I MUST learn C++!

What I have seen is that lots of the feature lacks in my programs come from the fact that I don't really know how to do things efficiently, so I finish doing workarounds which can work for one case, but they end in an spaghetti-code cascade most of the times :-S

Fortunately we can count on a good book by Bruce Eckel: Thinking in C++. You can download an HMTL version with source code for free. (Actually there are links to other books like Thinking in Java and Thinking in patterns).

Reading the introduction chapter it describes perfectly my scenario:

"I clawed my way into C++ from exactly the same position I expect many of the readers of this book are in: as a programmer with a very no-nonsense, nuts-and-bolts attitude about programming"

So let's expect this book to help me (and you, if that's your willing) improve my coding skills :-)

Yesterday I decided to compile my current project in windows. I didn't know if it was going to bring me too much trouble, as it was the first time I developed in one platform (mac) and then compiled for another (windows). So I turned on my old laptop, opened visual C and created a new Win32 Console application (as here in the mac version I'm creating a simple binary which you can execute from a terminal window).

I downloaded fmod's pack for having the .lib and the .dll, and then I realized that the graphics framework I was using, glfw, didn't provide a precompiled .lib or .dll, so I had to compile it. Luckily, there was a makefile for visual C so I didn't had to figure anything (I am quite bad trying to do build scripts).
Once I discovered that I didn't had the appropiate enviroment variables set up for using visual c from command line, I remembered there was a .bat file called vcvars.bat or something like that, which prepares all the paths and routes so you can start running nmake without any problem. So, I executed that makefile.vc and I got my glfw dll and lib, next step was adding the .lib to the project and trying to compile.
But I had forgotten to add two important libraries: opengl32.lib and glu32.lib, which are the equivalent to mac's OpenGL.framework. So I added them and then it compiled perfectly without no errors!
Demo ran smoothly and as expected… no need to change anything in the code (as all the window initialization is done via glfw's functions, and fmod is multiplatform).
Only difference is that for windows I use dll's so the final executable size is smaller, while in the mac version everything gets statically linked and thus the size of the exe is way bigger (let's say ~750 kb for mac, ~150 for windows). But I prefer to have it statically for demos… that way there's no possibility of forgetting a dll when submitting for a compo! :D