Thinking in C++
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 :-)
Jcl
20050729
As a matter of fact, you just -cannot- code anything without having to worry about APIs (be them graphic APIs like DX or OGL, or system-wide stuff).
You merely put wrappers around these.
While OpenGL will allow you to make code more portable, it's not 100% portable either and you'll need to set up stuff differently for *nix, mac, or windows.
I'd rather go to make a completely wrapped up graphics engine, and just make different renderers for different platforms (they could be DX for Win, GL for Mac and Unix, etc.)
Same thing goes for the rest… you make a -for example- file managing "library", in which you can plug (either via real plugin architecture, or just by compiling different files on different platforms) while the "usage" of that library keeps being the same.
For the most part, if coding a demoengine, you won't need to use filepaths, and it's rather uncommon having to worry about endianess if you are not using assembler, or raw access to files. C++ compilers and their corresponding libraries are good enough to do it for you (as i said, unless you are reading stuff byte by byte, which is rather uncommon nowadays).
Anyway, have fun with it, and if you need anything, just ask for it :)
sole
20050730
The point where I need to be careful about endianess is when reading binary resources. Luckily I think I know how to do it; I was discussing it with shine and he confirmed my thoughts: each time I read something which is more than 1 byte long, I have to check whether it is right or not. So that would apply for int's, float's, etc…