Humus - Comments

More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 59 60 61 62 63 64 65 66 67 68 69 ... 71 ... 81 ... 91 ... 101 ... 111 ... 121 ... 131 ... 141 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 365

Query FailedYury
Friday, June 18, 2010

Does it really works? Consider the following example:

CLASS_BEGIN();
u8 byte0;
u8 byte1;
u8 byte2;
u8 byte3;
CLASS_END();

MyClass::MyClass()
: byte0(0)
, byte1(0)
// oops, missed one
, byte3(0)
{
CLASS_VERIFY();
}

Verification function will do a lookup for 0xBAADCODE, but won't find since three of four bytes were changed. In the same time one variable wasn't initialized at all.

Yes, byte2 will have deterministic value, though it will vary from build to build as class description changes.

Will F
Friday, June 18, 2010

Ugh, never mind; I fail at reading comprehension

Will F
Friday, June 18, 2010

Neat technique, but one question: what do CLASS_BEGIN() and CLASS_END() expand to? I'm not clear how you'd convert those macros to a range of variables to initialize without adding new members to the class (which seems like an undesirable side effect)

fmoreira
Saturday, June 12, 2010

I've just installed it and I noticed that it now comes with those step-by-step introductory tutorials to D3D11. Although not architectural-wise it's very useful for those who want a bottom-up learning path!

Rob L.
Monday, June 7, 2010

My (mid 20, single ;^) ) rather limited experience as a professional game programmer is, that we would work overtime because we wanted to show we get things done. I haven't been explicitly told to do it, only asked. (I know that what sounds like a question sometimes isn't one, but that hasn't been the case here.)

Yes, the schedules have always been invalidated (mostly) due to technical issues and initial delays due to extended legal work, that haven't really been compensated in revised schedules; and yes, we knew we wouldn't achieve much working through two weeks straight (only on some occasions, it has been seven days more often), but at least we managed to get milestones done until the deadlines. We would then get "compensation days" off, one day for every weekend day of work.
Oh, yes, there has also been overtime food. That always reduces stress a little.

Things changed towards the end of production, though:
We would absolutely always work overtime - I guess ten hours a day was the average for at least three months (programmers only) - and there wouldn't bee any possibilities to take days off. That really "destroyed" most of us.

The product was finished on time, but most people needed at least a month off of work, finally taking their well deserved vacation. Speaking of which, some of us didn't make any vacation worth mentioning besides "compensation days" over the course of one and a half years!
Some have started looking into other industries for more regular work time, which is unfortunate, but also probably the best for them.

Well, what does that mean for me? "Overtime is a failure of the management" sounds about right, save for the few "nerds" that just get emotionally invested and want to get everything done, no matter what.
I really have to stop getting in love with the things I'm working on. ;^p

Seriously, it's very demanding, but isn't it worth it in the end? :^)

Best regards,

Rob

Reader
Sunday, June 6, 2010

> 720p? 540p with 2xAA for the win!
> (Yeah, I'm looking at you, Gears...)

What are you talking about? Every Gears of War game has been 720p with 2x MSAA. Maybe you are thinking of Halo?

David
Thursday, June 3, 2010

I am not actually convinced that it is the number of hours which is tiring(in any industry). More what is stressed during the time at work.

For example when working in the software industry, at the end of the day I would be mentally, but not physically tired. The inverse would often be true when working in the bar/catering industry due to a lot of running around etc(although this generally involved more than 7.5 hour days 6 days per week etc...).

Thatcher Ulrich
Thursday, June 3, 2010

Hm, I think this article is mostly misinformation. The in.position.z in your shader is NOT what is written to the depth buffer, and therefore I think the screenshot is misleading. The hardware normally computes in.position.z/in.position.w and writes that to the depth buffer. Both z and w are linear in camera space, but z/w is definitely not linear in camera space and it's definitely not linear in screen space either.

I'd be curious to see the screenshot if you try computing in.position.z/in.position.w.

I agree about reversing the depth when using floating-point depth, but not when using fixed-point depth.

Here's a pretty good article which covers these issues and AFAIK is accurate: http://www.gamasutra.com/blogs/BranoKemen/20091231/3972/Floating_Point_Depth_Buffers.php

Summary: the ideal thing to use for depth is actually a function of log(camera_z) but that can be approximated using the reversed floating point z buffer.


General
	News 3D Pictures Textures Articles Cool stuff
Other
	FAQ About Humus
Other 3D sites
	OpenGL.org GameDev.net Beyond3D Rage3D
Programming info
	OpenGL extension registry NeHe