More pages: 1
2
Framework4
Wednesday, January 7, 2009 | Permalink
Over the holidays I began some work on a new framework. I'm building it around DX11; however, I'm still making it reasonably platform independent and I plan to put OpenGL 3.0 and Linux support in there at some point too. So far I haven't done much, but at least I have a window and DX11 device up and running. Yay!
There are a few changes I'm making to the overall structure of the code. One is of course to separate the rendering context from the device in order to be able to take advantage of DX11 deferred contexts, AFA command buffers. Another change I'm making is to try to resolve more stuff on link time rather than at runtime. In previous frameworks I've had base classes with virtual functions that subclasses implemented. For instance D3D10Renderer and OpenGLRenderer inheriting from Renderer. However, since I'm always using one or the other and never both in the same app it adds unnecessary overhead. Not that this overhead was ever a problem, but it just feels better to do it right.
So instead I'll create a common interface, and just add the right implementation to each project.
Another change is that I'll use a better coding style. As a self-learned coder I've been using many odd coding practices throughout the years. Slowly I've adapted to common industry conventions, but Framework3 was still based on a lot of old coding style preferences which I never bothered to change, because I'd rather be consistent than mix conventions. With the clean break with Framework4 I'll now be using "m_" on member variables and "{" will be on its own line etc.
Jay
Thursday, January 8, 2009
The industry doesn't always know what it's talking about wrt coding conventions. At least you'll only be arguing with yourself :-)
Gr�gory
Friday, January 9, 2009
i can't wait to have a look at a new demo using framework4
Seth
Saturday, January 10, 2009
Unordered access views rock!
orange
Monday, January 12, 2009
I look forward to Framework4, OpenGL3 renderer, as well as pleasure to learn from you to make proper use of const
yosh64
Wednesday, January 14, 2009
Just don't go by the convention to limit lines to 85 characters (I think that was it), which I think was so your code appears correctly in a terminal, we had todo this at uni in our assignments, and was quite a pain, hehe.
Hmm, well do this if ya want, but I'm not a fan, hehe.
Also, I actually prefer to have curly brackets { on the same line, and not on a new line. Hmm, although originally I used to always put them on a new line, at least for functions and classes, but I just think it's a waste of space now days, hehe.
Ohh, I've seen some people go even further than using an m_ prefix for member variables, that is they have a prefix for each data type, alike m_bWhatever for boolean, m_vWhatever for a vector and so on.
Hmm, a friend of mine doesn't like any of this prefix stuff, and I think when they have a function with a parameter/variable named the same as a member of the class then I think they add an underscore _ to the function parameter/variable name.
Anyhows that's enough rambling from me, hehe.
Humus
Wednesday, January 14, 2009
Sticking to 80 chars per line made sense back in the days when people used DOS editors. I tend to take a little care and not write too long lines, that's all. Not strict rule, just a little common sense.
As for prefixes, m_ is useful because you can easily see whether you're modifying the class or local variables. Besides you avoid any name clashes. But things like hungarian notation is useless these days IMHO, because any reasonable editor will show the type if you just hover over the variable with the cursor.
Mo
Friday, January 23, 2009
Drop the m! Keep the underscore! Viva la revolution!
Gr�gory
Thursday, February 5, 2009
btw, are you far from publishing a demo using it?
More pages: 1
2
