Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

Norman Barrows

Member Since 04 Apr 2012
Offline Last Active Yesterday, 07:21 PM

Topics I've Started

should i release my code?

08 June 2015 - 12:24 PM

now that i'm finishing up my skinned mesh code, i'm seriously considering releasing it.


i know that if i has something like it when i started on this skinned mesh adventure it could have probably saved a week or two of R&D. and i find it hard to believe that given the large number of people that have played with skinned meshes in dx9, nobody has ever put the stuff together into a neat little package. 


and really, the proper was to release it seems to be release all my gamedev code, IE:


the Z3D game library

the Zaudio labrary

the various other Z libraries (GUI components, fonts, rigid body modeling/animation editor, etc).

skinned mesh and other code of interest from Caveman 3.0 (some library APIs have yet to be moved from the game to the Z3D libraries).

sample code and sample programs that use the libraries.

the CScript macro processor and cscript source code for all of the above.


the code is largely directx code, which is why i'm asking in this forum.



* it could help others

* feedback might lead to better code



* dx9 based - but many folks still use dx9 or dx9 based libraries. i do have the beginnings of a dx11 version going.

* procedural code and PODs, but can easily be changed to classes.

* limited documentation currently available, but the code is pretty high on readability, pretty well commented, and there's lots of sample code available.

* use of arrays to implement memory pools. can be easily converted to use vectors.



any other cons or gotchas to consider?


what might be a good "as is" type license to use?


all things considered, should i do it, or would it be a waste of time?


if i do, what's a good way? dropbox, and links on my website and in my dev journal here?


NEGATIVE SCALE - the eyes follow you!

08 June 2015 - 10:49 AM

so i'm working on my skinned mesh test routine.


i'm drawing 100 instances of a skinned mesh, with multiple animations of different lengths with interchangeable hair meshes and interchangeable textures for body, hair, clothes, and eyes.


i was just now using the game's built-in matrix editor to determine the offset matrices for the eyes and hair mesh with respect to the head bone.


got everything adjusted and coded in. works fine.


the only thing...


the eyes are FOLLOWING me!


like a painting in a museum, where the eyes follow you no matter where you walk around the room.


even the meshes with heads that are turning as part of their animation. the eyes seem to continue to look at you while the head turns.


and just like the effect in a museum painting, its kinda creepy!


what's going on here?


i'm not rotating the eyeballs around y at all! i have't added vision tracking yet. the eyes just constantly aim straight ahead and down 13 degrees.


but they sure look like they're following you.


have i entered the uncanny valley?


i've never seen anything like this before, except in a painting.


its this a good thing or a bad thing? or does it matter?

skinned mesh triangle count

02 June 2015 - 10:30 AM

if i'm shooting for about 100 skinned meshes onscreen at once, what sort of triangle count should i be looking at? less than 20K per character? , less than 10K? 5K? 2K? 1500?


this is my first time doing skinned meshes, i'm not sure how low i have to go on the poly budget.

should WndProc process WM_QUIT?

02 June 2015 - 09:13 AM

two questions:


1. should WndProc process WM_QUIT?


some sources seem to indicate yes, others, no.


i currently do not.


for WM_DESTROY i call postquitmessage(0), which apparently sends a WM_QUIT to windows to unhook the wndproc.


for WM_CLOSE i use the default processing of DefWndProc, so i don't process it myself, just pass it on. DefWndProc in turn apparently sends me back a WM_DESTROY, which i then process.


but i've also heard that once i process WM_DESTROY and postquitmessage, that i should then wait until i get a WM_QUIT back before i actually terminate.



2. when i do determine inside wndproc that i should terminate, due to a WM_DESTROY (or possibly WM_QUIT) being received, whats the best way to tell the app to quit, given that i could be anywhere in the code that i run the windows message pump? since WndProc is a callback, the only way i see is to set some sort of "time to die" flag in WndProc, then check it in the main loop (perhaps at the end of an update cycle), and terminate if its set to true. but that seems to imply use of a global variable, IE some ram dedicated to data exchange between the app and callback.


is this why its a good idea to have just one message pump loop, and then have the whole rest of the program, which runs when the loop isn't busy? and if you get a message to terminate, you just postquitmessage, exit the windows pump loop, then terminate? the natural flow control of the code precludes the need for a flag?

skinned meshes with interchangable heads

26 May 2015 - 09:53 PM

whats the easiest way to implement skinned meshes with interchangeable heads in dx9?


separate head and body meshes, with multiple head meshes, all rigged to the same skeleton, then use whichever head mesh you want when drawing?