Archive for 'work'OpenGL pbuffers suck!Aaargh! Well, the blog title is about as much as I wanted to say on this topic. …this is just me venting out, during the process of chasing a video memory leak for 4 days already. It involves p-buffers, depth textures, shared OpenGL contexts and other delicious things. Still didn’t find the cause, but I’m getting close. Pbuffer my a**. We’d better write softwareIt’s better for the world that we write software and not teach dancing… …OTEE crew playing dance minigame in WarioWare: Smooth Moves. The game is awesome - you get lots of fun and look stupid at the same time! Now that’s what I call a good API (stb_image)The other day at work I needed a command line tool to compare some images (whether they mostly match, used in unit/functional tests). For unknown reason I could not get ImageMagick’s compare to work like I wanted, so I just wrote my own. I used stb_image library from Sean Barrett - and it just rocks! Here’s the code to load a PNG image from file: int width, height, bpp; unsigned char* rgb = stbi_load( "myimage.png", &width, &height, &bpp, 3 ); // rgb is now three bytes per pixel, width*height size. Or NULL if load failed. // Do something with it... stbi_image_free( rgb ); That’s it! Basically a single line to load the image (and of course the library has similar functions to load from a block of memory, etc.). And the whole “library” is a single file - just add to your project and there it is. In comparison, loading a PNG file using de-facto libpng takes more than 100 lines of code (and some time to read the docs). Small is beautiful. …and the way we do graphics related unit/functional/compatibility testing deserves a separate article. Sometime in the future! Quote of the monthAt work the other day:
A day in the life…Ok, as mcpunky asked to say something in more detail, I have no choice but to log a day of my work. Bear with me.10:30 - I come to work. Peter is already here and wants to show me the shader-related project he’s working on. It is becoming really cool by now, we discuss the projects, shaders, lighting, BRDFs and all the other stuff that graphics programmers always talk about.
11:35 - Checkout new bugs reported to me. This day we have three of them. Some shaders don’t display correctly for one user on his laptop; checking it, replied asking for log files now. Webplayer crashed on win2000. Checkout the crash dump, it’s in Mono initialization; flag the bug for later review on actual win2000. One more: windows build loses the very first keystroke. Launch Visual Studio, build debug player. By 12:10 I have this bug found, fixed and checked (was an error in handling lost DirectInput devices). Commit into svn, merge into Unity 1.5.1 branch as well.
12:40 - Nicholas comes to discuss our strategy for handling per-vertex lighting with custom shaders of Peter’s project. Fixed function T&L and custom shaders that don’t care about vertices or pixels just don’t merge well together. Maybe we’ll have to reimplement the fixed-function vertex pipeline equivalent in vertex shader(s). Might be hard to get right, especially on some lower hardware. 13:05 - Lunchtime! At this time of year it’s almost mandatory to eat outside. So nice. After lunch I watch a demo deities by mfx for some inspiration. Ah, I so want to do that. 13:45 - Joe comes in, shows some cool stuff one customer is working on. We discuss some glow filter issues. 14:00 - Philosophical talk about our unit/functional testing strategy. We do quite some functional tests now, and a tiny amount of unit tests. I’d like to try some unit tests on shader parser (which I’ll have to refactor someday soon, and without unit tests I’m scared). Agreed that unittests are probably a good thing if you strike the right balance (now THAT was a surprise, huh?). Will try. 14:30 - Checkout a whitepaper from ATI about fixed function emulation in HLSL, playing with their shader. Instruction counts are scary! Talk with Nich about glow improvements, he has some good tips. 15:15 - Put a GeForce into my PC - will try to figure out why in some cases graphics looks too dark on them. 15:25 - Again comes Nicholas, more talk about this shader thingy, regular additive pixel passes vs. ambient passes vs. vertex lighting and how the actual end user should not care about these details. We found a nice solution it seems; this way shader authoring seems intuitive (or at least much more intuitive than the other alternatives we considered). 15:50 - Back to darkness-on-geforces issue. On the way I found out that motion blur filter no longer works on a PC! Reverting to older versions from svn to find out where I did introduce it. Ok, that was a stupid typo by me from several days ago, fixed. 16:35 - David opens a shoe box - and surprise surprise - there’s a cake and cookies inside! Good stuff. Me loves anything that’s sweet. 16:45 - The darkness-on-geforces is only the motion blur filter going wrong. That’s good. Debugging with glIntercept, something’s wrong with blur accumulation texture. 17:10 - D’oh! The motion blur had a pretty crappy implementation; was trying to render into the texture while using itself as the input. Obviously the results can be undefined, which just happened on geforces. Rewriting the filter to do it properly. Testing it, integrating into standard assets. 17:45 - Discuss our (i.e. company) roadmap and which parts of it can be announced publicly :) Then the talk went downhill about memory management, fragmentation, per frame allocations, porting Mono to some exotic architectures, whether porting runtime to Direct3D or kind-of-OpenGL-but-not-quite would be easier (my take is that porting to D3D would be easier) etc. Did something else which I don’t quite remember because we couldn’t have talked for an hour, right?
19:30 - I actually leave home, it’s some 20 minutes away on a bike. The plan is to eat lots of grapes and watch a movie tonight. What turned out is that I read some papers and then did the plan. Overtall, it has been a day with quite much talks. Not exactly the day where you feel “hey, I’ve done a lot of stuff today”, but not bad either. Will be ok for blog purposes I guess. On work and clean codeIt’s been like 6 months of me working on Unity. So far so good. We’ve done a big new release recently, so after some pre-release insanity we’re a bit more relaxed. I guess not for very long though, we have more stuff planned than we can handle :)
It sure feels nice to work on an actual software product. I think it’s probably the first time in my carreer that I know people are using my work and I do care about that. Having worked on projects before, it’s very different - a project just comes and goes, and once it’s finished you never think about it again. And most of the time you don’t care about “the clients” that much either. Working on a product is much more rewarding (especially if the users seem to like it). Another interesting here is that we are a very small software shop. So everyone has to be a one-man-army (the others certainly are, not sure about myself). Design, program, fix bugs, decide on features, do support, write docs and even do html tweaks for the website. Of course, it could be Jack of all trades, master of none (*), but somehow I feel that we are managing pretty well. And I like to be involved in various aspects of making a product. (*) though wikipedia says that the full saying is Jack of all trades, master of none, though ofttimes better than master of one - which looks like a positive thing to me. Back to some shader programmingThere is something magic in programming shaders. Like, when you edit one of our standard shaders and save, say, nine instructions in it - the feeling is really good. Maybe because, well, it’s a standard shader - so that means everyone’s graphics will actually render faster. Nice!
Maybe it’s because shaders are such a short piece of code, without too complex dependencies… I’m sure anyone who knows graphics hardware will corect me here, but let’s oversimplify and pretend that shaders actually execute in a simple way… So when you make a shader shorter, you pretty much know it’s going to be faster. When you make it “look better”, it almost certainly will look better. Try doing that in your regular big codebase - by optimizing something you may break something else; and in general you have no clue what to optimize unless you do your profiling homework. So, my take is that shaders are much simpler, so the joys of looking at assembly output actually make sense. So, yeah, I’m back to some shader programming. Why doesn’t this feature exist?Found this quote from Raymond Chen today (here):
So brilliant. The holy grail of shadowsIt just occurred to me: it seems that noone has ever made a shadowing system that does shadows from anything onto anything, with zero artifacts, with no corner cases, always looking good, running fast and on any sensible hardware.
Hm… sounds like a challenge! ;) Back to reading. Switched jobs - (almost) back in this crazy industrySwitched to the new job recently. So here I am, sitting in OTEE office in Copenhagen, working on Unity game development tool. Not exactly game development, but quite related. So far so good, will see how it goes. If you haven’t yet - take a look at Unity, it is good and will only get better.
|
