Renzatic on 11/6/2011 at 07:27
Man. Look at you. Getting all fancy with your pans and zooms. Looks good, by the way. :thumb:
Work on my NWN tileset continues slowly and surely. Not nearly as fast as I'd like, of course. But I'm too ponderous to really speed things along.
(
http://dl.dropbox.com/u/3018396/Stillwater.jpg) It's gonna be a very monochromatic little town. Red and fluhhhhhh seems to be about the extent of my palette.
So I've got 3 mostly but not quite done buildings in, along with a few dirt road tiles, some ground tiles, and...two trees. Mostly what I've learned from all of this is that I suck at doing trees pretty badly. I can never make them look realistic enough to satisfy my raging anal retentive tendencies. And doing skeletal winter trees with a low poly count is that much harder.
And I gotta say, it seems to be veering more and more towards Southern Gothic and less and less towards the old Victorian style I was originally aiming for.
zombe on 11/6/2011 at 09:37
My free codding time is mostly spent with the minecraft modpack (wow, been out for over half a year with ongoing extension/support!) ... anyway - i bet most of you who have spent some considerable time in minecraft lands already know that. So, not news :/ ... hm ... ah, to the point.
Well, started coding in c++ again, after quite some time, intending to make something gamey - but mostly just to re-learn stuff.
Got some peculiar errors a few hours ago that i fail to solve - yet. The compile time errors show up when i target x86 (i pretty much always have targeted x64 since 64bit win showed up) - never with x64 and i can not find any configuration differences between the two. Maybe some of you have an idea how to find out what the hell is going on.
1) all the interlocked intrinsic functions (like: "_InterlockedIncrement") give me "identifier not found" ... ? (windows.h included with LEAN_AND_MEAN)
2) "void *operator new( size_t n )" stuff gives "error C2373: 'operator new' : redefinition; different type modifiers \n predefined C++ types (compiler internal)(23) : see declaration of 'operator new'". delete gives similar error.
wut?
edit: ok, #2 solved - that insufferable dork demanded _cdecl for some retarded reason. (needless to say - i am very unhappy with that. any idea how to beat some sense into it?)
Al_B on 11/6/2011 at 10:02
At the back of my mind I think I've seen this type of issue before due to precompiled headers problems. It might be worth trying turning off the use of them for at least one source file and see if that clears up the problem with that file (not sure how large your project is).
zombe on 11/6/2011 at 10:16
Adding "#include <intrin.h>" solved it ... but why do i need to do that? windows.h was supposed to add them :/ ... *confused*. And why none of the problems show up with x64 target?
edit: wait, what the h* ... (
http://msdn.microsoft.com/en-us/library/2ddez55b.aspx) ... i could have sworn it told windows.h.
edit2: ah, probably sleep deprivation induced confusion with this: (
http://msdn.microsoft.com/en-us/library/ms683614%28v=vs.85%29.aspx)
edit3: i LOL'd (ie. that is NOT terribly useful):
Quote:
Windows 95, Windows NT 3.51 and earlier: If the result of the operation is zero, the return value is zero. If the result of the operation is less than zero, the return value is negative, but it is not necessarily equal to the result. If the result of the operation is greater than zero, the return value is positive, but it is not necessarily equal to the result.
Judith on 11/6/2011 at 11:23
Quote Posted by Renzatic
Man. Look at you. Getting all fancy with your pans and zooms. Looks good, by the way. :thumb:
Work on my NWN tileset continues slowly and surely. Not nearly as fast as I'd like, of course. But I'm too ponderous to really speed things along.
(
http://dl.dropbox.com/u/3018396/Stillwater.jpg) It's gonna be a very monochromatic little town. Red and fluhhhhhh seems to be about the extent of my palette.
So I've got 3 mostly but not quite done buildings in, along with a few dirt road tiles, some ground tiles, and...two trees. Mostly what I've learned from all of this is that I suck at doing trees pretty badly. I can never make them look realistic enough to satisfy my raging anal retentive tendencies. And doing skeletal winter trees with a low poly count is that much harder.
And I gotta say, it seems to be veering more and more towards Southern Gothic and less and less towards the old Victorian style I was originally aiming for.
Thanks, those buildings look awesome :) As for the trees and foliage in general, they're pretty tough to make in high-poly versions, let alone in low-poly. I 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.
Anyway, here comes the next one. This time fiddling with some emissive and alpha blending stuff, and some mirrored UVs as well.
(
http://img15.imageshack.us/img15/4407/lantern01sheet.jpg)
Inline Image:
http://img15.imageshack.us/img15/4407/lantern01sheet.th.jpgAlso, now I know why most of my normals appear inverted at some light angles. I forget that green channel has to be flipped, duh...
Yakoob on 11/6/2011 at 13:09
Quote Posted by zombe
Adding "#include <intrin.h>" solved it ... but why do i need to do that? windows.h was supposed to add them :/ ... *confused*.
"windows.h included with LEAN_AND_MEAN"
zombe on 11/6/2011 at 21:19
Quote Posted by Yakoob
"windows.h included with LEAN_AND_MEAN"
Except that:
* It only removes the useless garbage that you never need anyway - even with VS_EXTRALEAN (or whatever it was called) it is hard to find anything missing.
* with 64x "windows.h included with LEAN_AND_MEAN" - and no problems.
* it was not supposed to be added by windows.h to begin with x_x.
zombe on 12/6/2011 at 06:23
Since some of you know c++ ... i got another mystery:
Code:
class A {
public:
void notVoid() const {}
template<class C> A& operator<<(C const & x);
A& operator<<(void const *x) { return *this; }
};
template<class C> A& A::operator<<(C const & x) { x.notVoid(); return *this; }
Will result:
Code:
A *x = new A();
*x << *x;
*x << (void const*)x; // this is ok
*x << (void*)x; // this fails O_o
I can fix it by adding two specializations instead of the non-templated version:
Code:
template<> A& A::operator<<(void const * const & x) { return *this; }
template<> A& A::operator<<(void * const & x) { return *this; }
Which is fine as in my real-case the function is small enough, so the duplicity does not bother me - but why the hell is this necessary!?
Eldron on 12/6/2011 at 07:19
Quote Posted by Judith
Thanks, those buildings look awesome :) As for the trees and foliage in general, they're pretty tough to make in high-poly versions, let alone in low-poly. I 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.
The secret to making trees and such for high-end content is to not make any highpolies :)
One does textures and generate the normalmaps through other faster means.
