Jump to content
Double Fine Action Forums
Sign in to follow this  
DF Oliver

Programming Update #6: All Hail the Bug Overlords I

Recommended Posts

3D programming sure can have some weird effects. For the first picture with nothing but lumberjack faces and no eyes (that should be in a modern art exhibit by the way)- why did the software just pick the last available texture? Programs aren't supposed to have random behavior like that- usually if a program encounters something it doesn't recognize it'll just display an error icon as a placeholder or nothing at all..

Share this post


Link to post
Share on other sites

I'm one of those people that complained about the animation quality during the last update, and I have to say it's really improved. Ignoring the head glitches, the animation for the body in the 'Feeling a bit disconnected today' video is great!

Share this post


Link to post
Share on other sites
3D programming sure can have some weird effects. For the first picture with nothing but lumberjack faces and no eyes (that should be in a modern art exhibit by the way)- why did the software just pick the last available texture? Programs aren't supposed to have random behavior like that- usually if a program encounters something it doesn't recognize it'll just display an error icon as a placeholder or nothing at all..

It actually isn't random behavior, because that is what OpenGL does. If glBindTexture fails it simply uses the previously applied texture.

I do agree with you though. Moai seems to be designed to keep working when stuff fails (unless it's a critical error). This is nice in one way, because you can keep working on something and fix the issue later it also can make it difficult to find out what actually went wrong (because very few systems complain).

Share this post


Link to post
Share on other sites

Very funny update! I really enjoy seeing bugs in games and in animated movies.

But this was also pretty informative because you explained what cause the problems.

Keep up the awesome work!

Share this post


Link to post
Share on other sites

Thanks for the great post again :)! Always enjoy bugs, except when I have to fix them :D!

Share this post


Link to post
Share on other sites

the rubber band walk has got to be used - for a completely stand alone or mini game trip fest of confusion!

Share this post


Link to post
Share on other sites

It's really cool that you guys share things like this.

I knew that with the documentary we'd get an insight into what it was to make a game (warts and all :D ), but with these updates, these forum posts are really turning into a fairly decent game development resource and case study for aspiring developers.

Share this post


Link to post
Share on other sites

Haha :) Visual bugs are funny. Most of the coding I've done the past years have been the non-visual kind - the bugs you get there are never quite that funny ;-)

Share this post


Link to post
Share on other sites

somehow, that reminds me of my bachelors thesis, where i tried to stream animations (defined in a more human-friendly way - not really - through some params in an XML file) to UT2004 and execute them through an interface for bone adjustments provided in unrealscript. the whole idea was stupid, the results were "ok" but the bugs were absolutely hilarious as well.

"oh, i havent seen THAT in kamasutra"

Share this post


Link to post
Share on other sites

yes. yes! YES! These updates are delicious. These updates.......they please the Cello. The Cello loves the updates. Please give cello more updates. Cello needs the updates! UUUUUUUPDAAAAAAAAATESSSSSSS

Share this post


Link to post
Share on other sites

I wonder if any bugs you identify are so awesome that they are built upon and incorporated into the final product? I know developers do occasionally slip these things in (one example is Dog shaking his head when Alyx says "You DID do the math, right?" in HL2:Ep1).

I mean, Lumberjack Forest and Red Dreams of Texture Packing Land could be fun levels to include into the game. Also, I feel an urge to ride a Buzzard-Mailbox!

Share this post


Link to post
Share on other sites

Love it. :) Other people's bugs are always more entertaining than your own; besides, none of my projects involve lumberjacks, rubber or otherwise.

Share this post


Link to post
Share on other sites

This is cool. What is your debugging method, as a CS major it is cool to understand how others debug.

Share this post


Link to post
Share on other sites
The rubber band one is super creepy.

you havent seen half of what can happen in such situations :).

Share this post


Link to post
Share on other sites
This is cool. What is your debugging method, as a CS major it is cool to understand how others debug.

Excellent question Borzen.

If I'm trying to track down a non-visual issue then the Visual Studio (or XCode) debugger is your friend. For graphical issues it's a bit more tricky. Even though gDebugger is a good tool it isn't quite as good as Pix. These visual debuggers allow you to inspect the state of the GPU, so let's say you want to find out why something looks funky then you can see which texture it uses. Even with that knowledge you still need to deduct how the GPU got into that state though, so you are back to the VS debugger to find the offending state change.

Oliver.

Share this post


Link to post
Share on other sites

This is nifty; I didn't expect you guys to keep us updated on the bugs you find and fix, but it's really interesting to read. That moment of clarify when you realize what's gone terribly wrong is always a good feeling, so it's cool that I can get that here without actually having to go through and figure out what screwed up.

Share this post


Link to post
Share on other sites

I've never been so familiar with the debug process of the frontier of Moai or a Double Fine project and I feel quite privileged.

Thanks Oliver and all at Double Fine. Also, thanks again 2PP.

Share this post


Link to post
Share on other sites

Thanks for the explanations, Oliver!

In the same spirit as the movie Ed Wood I think the game looks perfect as is. Compile and ship it now. DFA Done!

Share this post


Link to post
Share on other sites

Loved this update. Got a bunch of weird stares from people at work because of my giggling fit.

Share this post


Link to post
Share on other sites

Ahh bugs, joys :D

You should totally "leak" that last video to the non-backing public. Pretend like you dont notice the character's odd walk cycle :P

Share this post


Link to post
Share on other sites
Ahh bugs, joys :D

You should totally "leak" that last video to the non-backing public. Pretend like you dont notice the character's odd walk cycle :P

I agree with this. Name the video "final lumberjack walking animation."

Share this post


Link to post
Share on other sites
This is cool. What is your debugging method, as a CS major it is cool to understand how others debug.

Excellent question Borzen.

If I'm trying to track down a non-visual issue then the Visual Studio (or XCode) debugger is your friend. For graphical issues it's a bit more tricky. Even though gDebugger is a good tool it isn't quite as good as Pix. These visual debuggers allow you to inspect the state of the GPU, so let's say you want to find out why something looks funky then you can see which texture it uses. Even with that knowledge you still need to deduct how the GPU got into that state though, so you are back to the VS debugger to find the offending state change.

Oliver.

Are you using the stand alone version 5.8 of gDEBugger or version 6.2 from AMD that is available as a VS Studio plugin? I haven't got VS Pro to check, since I'm only using the express edition & it isn't supported, but I'd assume it's easier to debug using the plugin version, although AMD's newer versions may only be available for AMD cards (which is a shame) since it lists a requirement as "The latest AMD Catalyst driver".

Using the GL_GREMEDY_string_marker extension to place log messages into the debug build can be quite handy for understanding the function call history too, but I wish there were an option to store the call stack at every OpenGL call, so you could see where each call was made, rather than only the call stack for the very last function call when it is paused.

Share this post


Link to post
Share on other sites

Are you using the stand alone version 5.8 of gDEBugger or version 6.2 from AMD that is available as a VS Studio plugin? I haven't got VS Pro to check, since I'm only using the express edition & it isn't supported, but I'd assume it's easier to debug using the plugin version, although AMD's newer versions may only be available for AMD cards (which is a shame) since it lists a requirement as "The latest AMD Catalyst driver".

Using the GL_GREMEDY_string_marker extension to place log messages into the debug build can be quite handy for understanding the function call history too, but I wish there were an option to store the call stack at every OpenGL call, so you could see where each call was made, rather than only the call stack for the very last function call when it is paused.

Thanks for the tip Dan. I have a NVIDIA graphics card right now, but I'll give the VS integration a try on a different machine. The markers are definitely helpful, without them debugging that stuff would be a nightmare. :-)

Share this post


Link to post
Share on other sites

This is fun but not very useful.

I still want to see the whole A.I. process (I know we're not at that point yet).

Share this post


Link to post
Share on other sites

Hey, I saw nothing wrong with that video. He just has a lot of swagger is all...

Share this post


Link to post
Share on other sites
Sign in to follow this  

×
×
  • Create New...