Ryan_001

Unfortunately programming is one of those endeavours where making mistakes is almost a requirement for learning.  Its also one where the vast majority of people aren't at your skill level (ie. in the general populace/school/ect...) and you will mostly find peers either online or at the workplace.  Sadly neither of those 2 places are conducive to making mistakes.  Discussing the pros/cons and hashing over problems should be the norm, but sadly its not.  I post as little as possible online, simply because everything's an argument, nothing's a discussion.  You can post a great response and/or answer (or in your case tutorial) but one little minor mistake that means nothing to the larger picture and you'll be roasted.

 

The only 2 places I've known online (in regards to programming) that had people nice enough that I feel I can post freely is TigSource.com and an indie-gaming facebook page.  The rest I mostly just lurk around on, its not worth the therapy attempting otherwise.

So a while back I saw Andrei Alexandrescu's talk on ranges vs iterators and was inspired.  So I rewrote a portion of the STL to use ranges to see if what he was saying was correct and how things worked out.  I've finished a bunch of range traits and functions, a vector and list container, and have been working through the usual standard algorithms (find, search, unique, ect...) and came across a weird problem.  Before I get to the question though a quick review of how I implemented ranges.

 

Working with ranges is closer to working with the raw containers than iterators interface-wise.  You have Empty() to test if there are elements in the range.  PopFront() and PopBack() remove the first/last element from the range.  Front() and Back() are used to access the first/last element.  There's also a Slice() function which allows me to take a subrange of the range.  One thing to note is that ranges cannot be 'enlarged'.

 

In the D programming language there's a function called findSplit() http://dlang.org/phobos/std_algorithm.html#findSplit which I was trying to implement.  With iterators this is a simple single pass algorithm regardless of the iterator type (ie. the iterators can be forward, bidirectional, random, any way it works easily).  With ranges I can implement the algorithm with random ranges (ie. the type of range that one would get from a vector) as the Slice() function is constant time for random ranges.  Slice() is linear for bidirectional ranges (the type of range used to traverse a list), which makes the findSplit() algorithm take essentially multiple passes (which for such an essential algorithm is unacceptable).

 

I can't think of any way to do this algorithm cleanly and efficiently with ranges, but it seems Andrei succeeded.  Am I missing something?  Or is this a fundamental problem with ranges?  Any thoughts/ideas are welcome.

I found myself using 4D arrays before.  What I did was pass a 'stride' vector around.  So say u have a 40x30x20x10 4D array, the 4D stride vector would be: { 1, 40, 40*30, 40*30*20 }.  Sometimes you want to pad to align rows or what-have-you and that can easily be adjusted for in the stride.  You can even use the stride to convert from indices to byte offsets, if you're working with raw data.  Then to convert a 4D index and a stride to a 1D offset you simple do the dot product, something like dot(index,stride).  Obviously this could easily be extrapolated to N dimensions, under the hood there's nothing special or tricky going on, but by pairing a stride vector with all the arrays it makes it very easy to work with.

I find I use protected variables from time to time.  Most of the time they are const variables initialized once, so there's no need to worry about invalid state, or messing things up, ect...  In theory they could be made public but why clutter the public interface?  The other time is for small/specific classes that I have no intention of anyone else inheriting from, and then its mostly for convenience.  Off the top of my head I can't think of any time I've absolutely required them, but none-the-less I'm quite glad they're there.

I'm gonna have to take back what I said about VS2012.  After having used it for a few days now on a larger project, intellistupid and syntax hilighting on it are broken.  Even the smallest change in your source code and it has to re-parse, even if its something as simple as deleting a comment.  Since the hilighting is tied to the intellistupid you change anything and all your text reverts back to black/white with nothing but keywords hilighted.  Even simple macros or templates cause it to get completely lost, causing red squiglies everywhere.  The code will compile fine, but intellistupid still can't figure it out.  Even when everything's seemingly fine it'll still just randomly turn itself off for no particular reason.  It still can't tell the difference between a declaration and a definition.  Moving around in large-ish code bases (TBH its not even that large) is now a complete PITA.

VS2010 wasn't great, but it wasn't THIS bad.  My productivity has definitely decreased having moved to VS2012.  I'm seriously contemplating reverting back.

I was asked for my color theme in a private message, and since I can't figure out how to attach files (is it even possible?) I figured here is the next best spot.

Somehow I just can't come to terms with the new UI.

I mean, Microsoft has never been about visual design but this is just bad, MENU BAR, Y U SCREAM AT ME!?...

Guess I'll just have to adapt, will give it a few more tries.

There's an easy reg edit to solve that: http://stackoverflow.com/questions/10859173/how-to-disable-all-caps-menu-titles-in-visual-studio-2012-rc

I posted a screenshot of what I came up with.  I have a multi-monitor setup so the solution explorer, output, properties, ect... are on other monitors.  That way I can have 2 code windows up on the same screen.  Being able to see both the header and cpp file at the same time is really nice.

Also while playing around with the colors I made myself some notes.  I'm not sure of the accuracy of them, or their conciseness, but I found they helped me when setting up my own custom color theme.  I really think somewhere on MSDN they should explain not only all the items but also their relationship to one another.  Anyways I pasted them in the quote below, the tabs didn't quite make the copy/past, but ah well...

In order of precedence (as you move down 'groups' each subsequent group will replace, or overwrite the previous ones)
Any time 'automatic' is used as a color, the color of the next lowest precedence is used.

[group 0, lowest precedence]:
Plain Text - default text when nothing else applies
  - usually what is used when 'Automatic' is used

[group 1]:
Comment   - comments
Identifier  - any name (variable, class, enum, label, typedef, template parameter, function parameter, ect...)
   - the C++ specific ones take precedence
Keyword   - any keyword in any language
Literal   - any literal (include strings, numbers, headers, ect...)
Operator  - punctuation, symbols, ect... (+, -, comma, braces, ect...)
Preprocessor Keyword - #include, #define, ect...

[group 2]:
Number  - any number literal (5, 0.6f, ect...)
String  - any string literal ("bob", includes headers like <iostream>)
URL Hyperlink - used when it detects a comment is a hyperlink

[group 3]:
C/C++ User Keywords - no idea
   - the documentation seems to says its for macro's, but it doesn't seem to work
C++ Class Templates - the class name of a class which has templates
   - example in: template <typename T> class Bob {}; - BOB would be the 'Class Template'
   - does not apply to normal class names
   - example in: class Bob2 {}; - Bob2 is NOT a 'Class template'
C++ Enumerators  - the items within an enumeration
   - example in: enum Bob { one, two }; - one and two are enumerators
C++ Events  - not sure
C++ Fields  - member variables
   - example in: class Bob { int a,b; }; - a and b are fields
   - does not apply to static member variables
   - does not apply to member functions
C++ Function Templates - the function name of a function template
   - example in: template <typename T> void Func () {} - the Func would be the 'Function Template'
   - does not apply to normal function names
   - does not apply to template member functions
C++ Functions  - non-template function names
C++ Labels  - goto/jump labels
C++ Local Variables - any variable defined within a function
   - includes nested local variables (ie. variables defined inside a lmbda function)
C++ Macros  - the name of a macro definitions
   - example in: #define BOB - BOB would be the 'User Keyword'
   - includes both normal macros and function macros
C++ Member Functions - member functions
   - includes template member functions
C++ Namespaces  - namespaces, nothing special here
C++ Parameters  - function parameters
   - does not apply to template parameters
C++ Properties  - not a clue
C++ Static Fields - static member variables
C++ Static Member Functions - static member functions
C++ User Types  - user defined types (not all)
   - class names, typedef's, typename and class template parameters
   - does not include template class definitions, but includes their usage
   - does not include functions
C++ variables  - global variables

[group 4]:
Highlight Current Line (Active)  - colors background of current line, when editor has focus
Highlight Current Line (Inactive) - colors background of current line, when menus or other windows have focus

[group 5, higest precedence]:
Selected Text   - background color of selected text
- doesn't seem to completely replace background, seems to 'tint' it in some cases, not sure how this works exactly
Brace Matching (Highlight) - doesn't seem to work
Brace Matching (Rectangle) - brace matching background color
- only applies to {} and () but not <>
Highlighter Reference  - colors background of similar identifiers
Excluded Code   - does nothing
- by default the editor will 'darken' the excluded code (make it look more like the background)
- changing this value seems to have no effect on the default action

My big issue is that the order items are initlialized in the initializer list is not the same order as they are listed.  Which for dependent items can really lead to some hard to track down bugs.

Ah, but should initialisation be in the initialiser list order, or the order you declared them in the class declaration?

FWIW many coding standards suggest keeping your initialiser lists in the same order as your member declarations for exactly this reason.

Their order in the class definition is either for readability/clarity, or compactness/cache coherency.  No one orders their variables in intialization order, at least, no one outside of C++.  Not to mention dependencies can change based on the constructor that is chosen.  If the order of initialization occurs in order of the intialization list, then at least you have some control in regards to dependencies.  Course IMO the best solution is just to use intializtion lists when absolutely necessary, use standard C++ code the rest of the time.

Most modern compilers will optimize the trivial stuff.  So I only stick important things (large items, parent classes, references, ect...) in the initializer list, as I really don't like them.  My big issue is that the order items are initlialized in the initializer list is not the same order as they are listed.  Which for dependent items can really lead to some hard to track down bugs.

I did a voxel engine a while back for a TIGSource competition:

The entire thing is done using ray casting/tracing in a pixel shader, and ran fine on my 9800 gtx.  Unless your voxels are large, translating them into polygons can be memory intensive.  Also voxels are only memory intensive if you plan on working with them in an uncompressed form.  I went with a tile system reminiscent of old-school 2d games (which is pretty much just artist directed VQ compression), and stored both the map and tiles in about 64 megs (4k 16x16x16 tiles, and a 256x256x256 map).  I could've squeezed it into much less but I didn't feel the need.

The real drawback IMO of voxels is animation.  Much like old school 2d sprites, you need to hand animate every frame.  Where-as a polygonal models can have a near infinite frames of animation, and even have dynamically generated animation, voxels are much more restrictive in this area.