What are you making?

Quote:

---

Originally 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.

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/440...01sheet.th.jpg

Also, now I know why most of my normals appear inverted at some light angles. I forget that green channel has to be flipped, duh...

Quote:

---

Originally 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"

Quote:

---

Originally 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.

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!?

Quote:

---

Originally 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.

Currently deciding between whether to do a side scrolling shooter (ala R-Type, 1942 etc) or a platformer. Got a basic level editor done after following some SDL tutorials and then modifying it to suit my tastes. So now just the matter of deciding.

I'd wanted to know how to do moving tiles which I now know how to do, and it was pretty much what I'd assume was the way to do it, which was a surprise.

My side-scrolling shooter is coming along nicely. I have a little devlog here:

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:

Quote:

---

Originally 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:

---

Originally 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).

Quote:

---

Originally 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:

---

Originally 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:

---

Originally 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:

---

Originally 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.

Quote:

---

Originally 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);

---

Quote:

---

Originally 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.

Quote:

---

Originally 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:

---

Originally 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&lt;class T> class Something&lt;T *> ..." stuff), not function templates sadly.

Quote:

---

Originally 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.

Quote:

---

Originally 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&lt;C&gt;(dummy); return *this; }
template<class C> A& A::operator<<(C * x) { void *dummy; static_cast&lt;C&gt;(dummy); return *this; }

---

(Allthough if the problem is solved without templates then that's fine, i'm just throwing some ideas out there.)

Quote:

---

Originally 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.

Quote:

---

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/440...01sheet.th.jpg

---

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.

Side Front Shot
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.

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!

Eldron might be the the undisputed king of pixel artery, but I've still gotta give you props for your style.

I dunno why, but I got such a huge kick out of that shot.

Heh, yeah he's pretty funny. What I spent most time on was trying to get a consistent look to all the enemies in the game, so that most of the bad guys have something in common and can be seen to be allies.

It's not much, and it's not my own project, but I'm taking this scripting class in college and we have to make space invaders. So far I've got a half working ship (can move but can't shoot), and some other code for blocks but having some trouble with it. Got a bit of ways to go. I'm using Unity for this project. I'll make it be known that I'm not really into programming, and I'm a noob with javascript; the only programming i did before was for a previous course, fundamentals of programming where we used C++.

Quote:

---

Originally Posted by Renzatic

Side Front Shot
Back Shot

---

Btw, what is the total texel count for that model? Looks very detailed. Also, how many individual textures?

Quote:

---

Originally Posted by sNeaksieGarrett

It's not much, and it's not my own project, but I'm taking this scripting class in college and we have to make space invaders. So far I've got a half working ship (can move but can't shoot), and some other code for blocks but having some trouble with it. Got a bit of ways to go. I'm using Unity for this project. I'll make it be known that I'm not really into programming, and I'm a noob with javascript; the only programming i did before was for a previous course, fundamentals of programming where we used C++.

---

I worked on a remake of Space Invaders (one of the best starting game coding efforts I'd recommend to anyone to teach themselves the basics of game coding / game design) across last year and into this year. Though I did mine in c++ not unity. Getting the enemy movement working right took me a while to get looking right.

Getting only the bottom most enemy per column to shoot took me ages to figure out also.

Quote:

---

Originally Posted by zombe

Btw, what is the total texel count for that model? Looks very detailed. Also, how many individual textures?

---

Texel size? I have no idea. But it's 3 2048x UV sheets. One for the main frame, upper windows, and posts, one for the roof, and one for the porch, lower windows, and the back extension. I could have fit it all on one or two 1024x UV sheets, but since I'm baking AO into everything, I have to give almost every surface it's own unique coordinates.

So 3 uncompressed TGA files comes out to 36 meg of textures. I'm not sure how that'll translate into texel usage, but I don't think it's a 1:1 conversion to video memory. The 1024x textures are only 9 meg, and it doesn't look half bad at that size, but it does muddy it up a bit, and loses some of the finer details.

I'm making some simple info apps for Android. It's hilarious fun.

no, no it isnt:(

While moving my old stuff over to the new framework i hit a snag: the LZO lib i used is GPL infected :( ... damnit ... for doing my own stuff it did not matter, but now i have to (or rather: prefer to assume i need to be free of GPL infection at some point) protect myself against that kind of thing. Which means LZO is useless (its commercial form is not an option at the present time). :(

So, any recommendations for replacement that has similar goals / performance characteristics?
PS. If sacrifices need to be made then i prefer to do them at the compression time.

FastLZ (MIT licence) comes to mind. LibLZF (BSD licence) also sounds interesting if high compress ratio is not your ultimate goal.

Also, Google just released snappy (BSD licence), and its benchmark results are intriguing. This one is C++ (with C bindings).

EDIT: Actually, snappy looks pretty much awesome.

Alrighty ... getting them all - will report results whenever i get some tests going.