nicked on 12/6/2011 at 12:24
My side-scrolling shooter is coming along nicely. I have a little devlog here:
(
http://create-games.com/project.asp?view=main&id=2107) http://create-games.com/project.asp?view=main&id=2107 (mainly for myself, to maintain pace!)
I'm not programming anything though, I'm using Multimedia Fusion 2. :cool:
Myagi on 12/6/2011 at 13:44
Quote Posted by zombe
why the hell is this necessary!?
In the "*x << (void const*)x;" case it finds an operator for the matching type "void const*" with "A& operator<<(void const *x) { return *this; }" and uses that.
In the "*x << (void*)x;" case there is no matching "void*" operator so it uses "template<class C> A& operator<<(C const & x);" to instantiate a function with "void*" as C, this results in following function instance:
A& A:: operator<<(void* const & x) { x.notVoid(); return *this; }
and "notVoid" is not a member function of type "void*". The compiler error message might have hinted that it was using the templated operator ;) Maybe you meant to write "{ notVoid(); return *this; }"?
Quote Posted by zombe
in my real-case the function is small enough, so the duplicity does not bother me
Considering the nature of that function and inline expansion, you could have 100 versions of it without it taking a single byte more (in a Release build).
zombe on 13/6/2011 at 06:56
Quote Posted by nicked
My side-scrolling shooter is coming along nicely.
Wow, is all that pixel-art done by you & co? I'm terrible at pixel art :(
Quote Posted by Myagi
In the "*x << (void*)x;" case there is no matching "void*" operator so it uses "template<class C> A& operator<<(C const & x);" to instantiate a function with "void*" as C, this results in following function instance
Yes. Instead of implicit conversion from "void *" to "void const *" - it goes after the template. Even if i remove the non-templated version and add "void const * const &" template specialization - it refuses to take the specialization and instantiates one from the non-specialized template instead x_x. Very annoying (reasonable, but very-very annoying).
Btw, the function should NEVER accept pointers, but afaik there is no way to tell it that - or is there? (~ i know that i can require the opposite in specialization, ie C must-be-pointer, but how do i tell it that it cannot be pointer?)
edit: actually, how did that work? ... *goes googling*
edit2: ah, that kind of partial specialization seems to only work with class templates and not function templates => useless for this problem.
Quote Posted by Myagi
and "notVoid" is not a member function of type "void*". The compiler error message might have hinted that it was using the templated operator ;) Maybe you meant to write "{ notVoid(); return *this; }"?
No. "x." was intentional to catch the wrong call at compile time (ie. check it is "notVoid").
Quote Posted by Myagi
Considering the nature of that function and inline expansion, you could have 100 versions of it without it taking a single byte more (in a Release build).
The real case has obviously much more stuff in it and is pretty much guaranteed not to inline due of excessive instruction count. It is just that the code there that causes the resulting sizable amount of instructions is relatively short in its source form - so, easy to keep the duplicate is sync (obviously, i will move the code to some separate private demoronizer-function later - so, the call to that is all i have to synchronize). It is just irritating that i have to do all that nonsense.
Myagi on 13/6/2011 at 13:08
Quote Posted by zombe
The real case has obviously much more stuff in it and is pretty much guaranteed not to inline due of excessive instruction count. It is just that the code there that causes the resulting sizable amount of instructions is relatively short in its source form - so, easy to keep the duplicate is sync (obviously, i will move the code to some separate private demoronizer-function later - so, the call to that is all i have to synchronize). It is just irritating that i have to do all that nonsense.
What about a compromise like
Code:
template<class C> A& operator<<(C const & x);
A& operator<<(void const *x) { return *this; }
A& operator<<(void *x) { return *this << (const void*)x; }
Inline expansion will make sure that the end result (execution wise) is identical to what you initially wanted to happen, it just requires adding en extra line of code while still having the benefit of only needing to maintain the complex function once.
I'm still a bit unclear of exactly what real-world "effect" you're after, but maybe two versions of the template would do what you want?
Code:
template<class C> A& operator<<(C const & x);
template<class C> A& operator<<(C const *x);
nicked on 13/6/2011 at 16:34
Quote Posted by zombe
Wow, is all that pixel-art done by you & co? I'm terrible at pixel art :(
Yup, except a couple of the overhead-view background textures, which are freebie textures. Also, some of it's scanned-in hand-drawn art not hand-placed pixels.
zombe on 13/6/2011 at 20:39
Quote Posted by Myagi
What about a compromise like
Way better compromise than my demoronizer-function idea! Completely missed that option x_x (oh, and you forgot "const &").
Quote Posted by Myagi
I'm still a bit unclear of exactly what real-world "effect" you're after, but maybe two versions of the template would do what you want?
It must accept a bunch of classes (by reference - never by pointer as that will cause problems [besides a few exceptions - all are descendants of one base class]) + a few basic types (the main reason why i use template) + void* (the only acceptable pointer / special case).
So, pointer related template is of no use - in fact, i would like (but it really is not terribly important) to make if fail when i accidentally give it any kind of pointers (besides void*). I think that it is impossible - while the template allows to select "void*" out of it without conversions (SomeClass* => void*), i can not select the pointer types out of the remaining cases. Only partial class specialization can do that (ie. the "template<class T> class Something<T *> ..." stuff), not function templates sadly.
Quote Posted by nicked
Yup, except a couple of the overhead-view background textures, which are freebie textures. Also, some of it's scanned-in hand-drawn art not hand-placed pixels.
Yeah, i was referring to the foreground. Thous three screenshots of yours exceed my grand total of efforts from the last ... ~15-20 years x_x ... yeah, i have avoid doing that kind of stuff as much as i can. Have not done any pixely stuff in the last 10-15y tho (went to 3D/OpenGl land *) - maybe it is a bit easier with today's tools :/
Hm, what tools DO you people actually use? Eldron? ...?
*) before that: used also a lot of customized characters for graphics in text mode / the incredibly confusing but damn fast mode-x / plain geometry.
Myagi on 13/6/2011 at 23:28
Quote Posted by zombe
So, pointer related template is of no use - in fact, i would like (but it really is not terribly important) to make if fail when i accidentally give it any kind of pointers (besides void*).
I think this template configuration will give you compiler errors if you supply it with any pointers except void. The trick, cast a void*
to "C", that should fail to compile for anything but a void*.
Code:
template<class C> A& A::operator<<(C const & x) { x.notVoid(); return *this; }
template<class C> A& A::operator<<(C const * x) { void *dummy; static_cast<C>(dummy); return *this; }
template<class C> A& A::operator<<(C * x) { void *dummy; static_cast<C>(dummy); return *this; }
(Allthough if the problem is solved without templates then that's fine, i'm just throwing some ideas out there.)
Renzatic on 14/6/2011 at 03:19
Quote Posted by Judith
As for the trees and foliage in general, they're pretty tough to make in high-poly versions, let alone in low-poly.
High poly isn't so bad, because you have an infinite amount of goof around room to make things look good. It might take a big investment of time, but you're not constrained by anything. On the other hand, doing low poly is a pain in the ass mainly because you have to line up all those 2D alpha planes, which takes forever, then make sure the finished product looks good from all angles.
I now understand why most people prefer doing summer themes, or stick to pine trees exclusively when they're doing something in winter. You can disguise the sparsity of your model with a barrage of leaves. With low poly skeletal trees, you have to have the right textures, and lay them out precisely to get things looking good.
Quote:
If I were you, I'd download something like SpeedTree demo and use their model previews to model something similar. Also the season setting you picked isn't making this any easier, good snowy/icy textures and materials are pain in the ass, requiring extra time to make.
Yeah, I just recently got the UDK again simply to play around with Speedtree. Sucks I can't export the models directly, but I can copy the end results easily enough.
And no, doing a melting snow winter theme has been a pain in the ass. At least I have the added advantage of only working with diffuse textures, and not having to worry about normals, specs, and all that good stuff. Still, painting the snow on, and making sure it lays across all the appropriate surfaces consistently without being too overwhelming hasn't been a cakewalk. It's really hard to paint snow like that.
Man. Glowy bits. Extra texture layers. I kinda wish I went with a more modern engine sometimes, if just for the little atmospheric perks you can throw around everywhere. Oh well. Working with NWN is teaching me constraint, at least. Which is something I've always needed to learn.
And speaking of which, I've finally got most of my house finished. I've had to cut quite a few corners to give each wall on the main frame of the house it's own unique surface, so I can bake in AO. It looks good right now, but I'm worried I might lose too much detail when I scale the UV sheets down from 2048x.
(
http://dl.dropbox.com/u/3018396/House_1.jpg) Side Front Shot
(
http://dl.dropbox.com/u/3018396/House_2.jpg) Back Shot
I just need to add the doors, some throwaway details, then start working on the dried up kudzu hanging off the porch and other miscellaneous foliage. I want to have a really big bush growing wild in the corner of the house, for instance.
nicked on 14/6/2011 at 05:43
Most of my pixel stuff I do in Photoshop, even though it's grossly overpowered, because I'm used to the keyboard shortcuts. Plus I can cheat with layers! Judging from the much better looking stuff Eldron's been turning out, I'd say he (she?) has no need to cheat!
