Its friday morning, I'm at work and not fully awake yet, so bear with me if I talking nonsense, as I'm known to do.. Making a game is like baking a cake, only you know the ingredients but you don't remember or don't have a complete recipe. You know what you want it to taste like but you don't know how much sugar is enough and if three eggs is too much..

So you mix it up and see how it goes.. Maybe you have tried baking bread before so you know the basics - hopefully.. It might turn out right but there's a little too much of something you can't quite put your finger on, so you go back a little, start over and see what happens next.

After a few attempts you end up with something that has potential and you start to get really excited.. start to get a feel for how much flavour you need and start fine tuning it.. then some wiseguy says: 'I bet cinnamon would go well with this..?' and another guy says: 'Yeah, I love cinnamon!'.. So you mix again, and see where it ends.. It might not work, or it might be just what you missed..

I think I've taken this stupid analogy as far as I can now, I hope I haven't embarrased myself too much already - and I might add that I've never baked a cake, but I don't mind eating them..

I just added the following file "WERendererD3D9ProgramDataTypeHelper.h" to our engine. that is pretty sick if u ask me, but as much as i hate it, I am too paranoid to rename it to anything shorter ... snif ... and its not the only one.

I don't like going to the cinema. People are too noisy. They talk. They chew their popcorn and sweets too loudly and make noises with their candy wrappings. You don't always get a nice seat, and sometimes you have to fight for an armrest. So I spent a lot of money on a very nice tv and sound system, so I can watch movies at home and still get a bit of that cinema-feeling (minus loud people).

The only problem is, we can't turn the volume up at night because my kids asleep, and the neighbours would probably complain also.. Another thing is when you're at the cinema you sit down to watch a movie and you don't get up until its finished - but at home you can just pause the DVD, make a cup of tea etc. - and you end up seeing the movie in small bites.. So, you end up not getting any value out of the nice surround sound setup at all - and the movie experience is gone also..

Anyway, I'm a bit embarrased about whining over this when I know people are starving and dying all over the world, and I'll just say what I wanted to say when I started to write this blog entry: The fact that I don't go to the cinema anymore, means that I'm a bit late to see new movies - I wait until I can rent them on DVD.. - and I've just recently watched "Kiss kiss bang bang", "V for Vendetta", and "Inside man".. - and I think they're so great I thought it worthwhile to write it here - go rent them now if you haven't seen them! =)

- I hope I haven't bored you to death by now, and that you'll excuse my self-indulgent whine.. =/

yes, I am sick of inconsistent support for variable argument functions, and the annoying fact that in many cases u need 2 version of variable argument fucntions (one with (...) and another with (va_list)).

I only ever needed var arg functions for string operations, parsing and logging. so again I got rid of using (...) once and for all ( ? ).

The results look like this:

Thats as comfortable as i was able to make it, and i like it ... u can of course also setup a dynamic P_EL array at runtime.

Ok, Im done with finalizing strings in the engine, yes yes we had working strings since the beginning, but everything always evolves, and code does as well, we started off with simple 'char*' strings, so no internationalization (badly needed for WOF), the next version support UNICODE 'wchar_t*' which i assumed was the end of all string things... but it seems using only the documentation of 'so called' 'unicode equivalents' of simple 'char*'string functions never mentions that in fact a 'real' UTF16 char is variable width!!! Short Look at sample headaches/documentation pitfalls

so back to the design table (hopefully for the last time for strings).

in the end i decided to go for UTF-8, has all the advantages I need, and in thie way I can also easily move text files and binary files (containing text) happily between OS's no problems at all.

it works quite well, I also added some goodies for 'OS' independence, Strings can be converted (or not when not needed but still transparently) to a 'NativeString' which is used to pass to native functions like windows functions which have ANSI/Unicode variants and so on .... this makes the whole OS dependence nicer (it is already nice and hidden away in nice 'Native' Intrface classes, but now Strings can be passed in and out nicely).

The functions are not optimized, but they will only be heavilu used at loading time and should not be used in performance critical parts anyway (comparing strings? NONO).

Bonus: Another thing I like is that the string code is now more general becuase it doesnt treat each 'char' as a 'glyph' so now switching formats (which most probably wont happen anyway) would be more or less painless, specially since I already needed to write conversion between ANSI-UTF8-UTF16 to support char*, wchar_t* and the internally used UTF8.

Bonus: no more const static char* kBla = "bla" thrown here and there, these now become const static CtString kBla("bla"), this is converted of course into the internal UTF8 format, well probably not a big difference but I like it more...

Bonus: In code there were places where temp string are passed around a lot specially while loading, a 'BuffString' was used for this which until now simply typedef'd to a normal string, but now i added StringMemAllocator supports, so now u have real Buffer strings (when u want them) which reuse memory and save a lot of free/alloc calls.

As for string length including/excluding the ending NULL character, I decided to include it, after all is IS a character in the string, be it special or not. and i added a 'bool lengthIncludesEndingNULL()' function which shoud be used when manipulating strings with no assumptions. String code doesnt have to be super fast, only super usable, at least for the projects in-sight.

Another indirect bonus is that we use tinyXML (currently) which supports UTF8 and we couldnt use this support (for player names per example) until now.

Google Maps Link

Part 1

Constant references, instead of passing by value is it worth it (for 32 bit and smaller data types of course) ? tough to say, in most cases it surely isnt slower than passing by value, or maybe it is when the value u are passing is smaller than a reference (pointer) ? like passing a char is 1 byte but a const reference to a char is 4 byte (on 32 bit system). I really need to time it, but i guess it laso depends on compiler/processor. but for now i seem to be passing values by const& wherever possible in my code and cant seem to be able to stop, the only thing is function calls become too long ...

Part X

overflow, I started using bytes as indexes in a part of the code to save space, dont know if its really worth it, but i think it is, the problem now is letting the code warn u with overflow, so u start hacking checks using temporary variables and casts to see if the value changed sign/overflowed and the like, wont go into details, but i wonder why there isnt any overflow support in c/c++ itself, pretty annoying if u ask me ...

Every now and then I rememeber that I decided at some point not to use STL for WOF, and then I start to think about how 'unproffersional' that is and start hearing voices telling me to switch to STL.
In fact I think my 1st use of STL was in 2001, sitting in my office, searching for a library that would give me good strings/containers and the like. When i first found STL and started reading about it I was pretty impressed really...
but enough about history ...

there are countless forum discussions and threads discussing code reuse and 'reinventing the wheel'

from coders hanging anybody not using STL
to coders beinbg shocked that DOOM3 doesnt use STL
to longer ...     discussions

but today i decided to change a bit of code that handles string parsing, and instead of using plain old C sscanf and friends, to use the new gr8 genius C++ iostream while this is not 'exactly' STL but its related ...

anyway, i was happily recoding this 'evil' 'unprofessional' C style code, and scanning string using >> and all that fun stuff, its fun cause it also supports locales and much much more thing i dont know about (im not sure this is a good thing though)

but my dreams came to an end when after succesfully scanning floats, my code sudeenly refused to scan old simple integers.

and i m saying my code because of course its my code thats doing sthg wrong, and surely not 'std' so i spent 1 hour looking at all those very improbable causes in my code, until i gave up, and in an evil split second of unprofessional thinking, I typed this in google:
iostream problem reading int comma
which found nice matches, and after the usual journey in google I found:
link
link
link

and so on ...
all these troubles for reading an int? yes of course I could fix it, there are workarounds, there are other STL libraries to use, and regression tests to make sure they work.

but all i needed is to read an int, I think i had code to do this 10 years ago when i still had no internet and was a total noob and was proud of a function that converts strings to integers, and even floats! :P
sure std has locales and this is why this messes up, but maybe this is not how i want to use locales, i dont need a cannon to kill a fly, sure STL is tons of code that can do anything, but the things i need from STL i coded for WOF in a couple of days and worked reliably with no problems until today.
so I dont want to be switching STL libraries for my code to work, I dont want to have headaches every time somebody changes something somewhere, I dont want to work around libraries that theoretically are 'pieces of coding art' until u need to do something practical with them.

just found this:
STL Guru Interview

I understand all this! honest! I DO have a BE in Computer and Communications Engineering, and its gr8, artistic! nice and kewl, takes it all to a new level! but there was sthg wrong with the implementation i just used reading an int ...

yes it is, but the same goes for code reuse and over-engineered floating in their own heaven of pure theory libraries ...

I actually could write much much better comments about them, but im tired and i have better things to do like workgin on WOF.
One point I still want to make is the horrible naming convention of iostream: its really chaotic and unintuitive, but i guess iostream is allowed to do this, to do things u would be hanged for if u did urself. (pubimbue, snextc, sbumpc), maybe to support 8 bit operating systems, but this is really not my problem ... I wont expand on this either although I would like to.
so as a conclusion, i ll stick to my own wheels until the next time i have STL voices in my head.
and just for the record, i do use other libraries so its really not a 'i dont use anything i didnt write syndrome'

end of bla bla ...