Disqus - Latest Comments for snake5

Re: #AltDevBlogADay » Matrices, Rotation, Scale and Drifting

snake5 — Tue, 03 Jul 2012 10:21:57 -0000

Couldn't the usage of different cache lines from a SoA layout like this - ({position,rotation,scale} array, {matrix} array) - help with the performance problems?

Also, what can a scene node represent? Is it any bone in a scene or just the whole character or something else?

Re: #AltDevBlogADay » Matrices, Rotation, Scale and Drifting

snake5 — Tue, 03 Jul 2012 09:11:08 -0000

By "editable" I didn't mean the editor, just that they will be used the same way they're used in an editor.

Re: #AltDevBlogADay » Matrices, Rotation, Scale and Drifting

snake5 — Tue, 03 Jul 2012 08:42:08 -0000

Why are you storing editable transform data as a matrix? Seems somewhat counter-intuitive since it's much easier to work on position, rotation and scale separately and update the matrix only when any of those are changed.

Re: #AltDevBlogADay » Comparing Floating Point Numbers, 2012 Edition

snake5 — Wed, 22 Feb 2012 02:44:50 -0000

There's nothing quite like trying to debug a precision problem in CSG code in the morning. Epsilons do indeed suck and it seems like you have found the answers to the problems I've had before. Thanks for the awesome series of posts.

Re: Skin Shading in Unity3d « #AltDevBlogADay

snake5 — Sat, 31 Dec 2011 02:03:37 -0000

If I had access to my collection of movies, I'd show you something - SSS is a lot stronger with refracted light (opposite to viewing direction). EDIT: looks like Wikipedia has a good example: http://upload.wikimedia.org...
Here I see SSS on the nose which also isn't really the right place for that - there's a bone or two immediately under the skin.
Also, the color used on the light-shadow transitions isn't the right one - with my almost-perfectly-white cell phone light, I get something a bit closer to orange with my fingers. For the record, the color of my skin is just as white as that of your test model.
And finally, in terms of specular, you need more fresnel there. Skin's fresnel data is quite close to that of asphalt. At the moment what you have there is the specular that my working desk would produce.

It's amazing how things can be discovered just by putting one's hand between one's eyes and the monitor... :)

Re: Awful Lot Of Heterosexuals Around Here. « #AltDevBlogADay

snake5 — Thu, 15 Dec 2011 12:52:01 -0000

Someone has probably said something like this here but I'll try:

1. I don't care what kinds of characters I see in the game as long as they're not different than the game world. Sorry, but I'm having a hard time imagining an LGBT adventure game hero. Feel free to throw concepts at me to help me share your opinions.

2. The relation between people of different sexualities makes everything just fair. Not every third game is about gay people and not every third person in the world is gay. In any case, everything's getting better than it was before.

3. The only way people could currently buy this is the introduction of the concept through other, familiar concepts. As many have pointed out in IMDb's forums of various gay movies, one of the gay characters are often more feminine than the other and that's what makes it OK (understandable) for most people. Don't forget that heteros aren't gay and they will never really know what it means to be one.

Re: Awful Lot Of Heterosexuals Around Here. « #AltDevBlogADay

snake5 — Thu, 15 Dec 2011 12:23:33 -0000

Sam Fisher and Harry Mason both (and perhaps more of them) have kids. How would you spin that with gay characters?

Re: No One Cares About Your Cool Game Idea « #AltDevBlogADay

snake5 — Sun, 04 Dec 2011 03:26:16 -0000

I have to agree - this is a great post - even though the theme is heard a bit too often lately, I did still read and enjoy reading it.

Here's perhaps some of my gross inability to quickly get a job speaking but I'll let it out anyway: most of these 'idea people' (those who don't think about the practical side at all) don't really want to be game developers, a huge part of them don't even really want to see their idea become a real game; they're often just people who aren't satisfied with whatever the market offers at the moment and they want more of something or.. what they really want is power to influence something. So if they can't get to the same conclusion after so many warnings already, they're not cut out to be game developers, at least - not yet.

Re: IEEE 754 multiplication and addition « #AltDevBlogADay

snake5 — Thu, 01 Dec 2011 07:24:17 -0000

Spotted something odd in the first piece of code:
- declaration and initialization of zFrac is missing;
- (line 25) assuming it's also u32, "zFrac & 0xFFFFFFFF" wouldn't do anything special i.e. it would just be the same as "zFrac".

Re: http://altdevblogaday.com/2011/11/29/review-scores-%e2%80%93-they-are-bad-so-let%e2%80%99s-fix-them-%e2%80%93-ok/

snake5 — Tue, 29 Nov 2011 00:12:17 -0000

They're supposed to give the harshest possible opinion. Many years ago, it was exactly what critics did and how they got the name - they criticised. Now all they do is generate biased hype. Why biased? Because a game that most thinking users rate lower than 6/10 gets a 10/10. And for what? In the case of GTA4 and Gamespot, the score was generated from minigames (which most experienced gamers didn't really enjoy, by the way).

P.S. If something is constantly inaccurate, it is also, by definition, broken.

Re: http://altdevblogaday.com/2011/11/12/ill-just-refactor-that/

snake5 — Sat, 12 Nov 2011 12:04:34 -0000

I find myself not using the word most of the time and I think it's for a good reason - "refactor" now seems to simply be an euphemism of "rewrite", thought up to keep the executives from having a no-progress nervous breakdown.
But the word without these new meanings would just die - just think how often cleaning up bits and pieces of code is considered something special, not as something coders just do (as a normal part of their job). And changing variable/function/type names for clarity? Probably never, until the word showed up...

Re: http://altdevblogaday.com/2011/11/06/our-responsibility-towards-training-the-next-creatives/

snake5 — Sun, 06 Nov 2011 14:44:35 -0000

Just like you, I have found out that the only way to become better at what I do is to acknowledge that what I've done just isn't good enough. Even if it is, at least for me being above average (ain't that a popular term? >_>) or to be anything else, I still need to accept it's not enough and move on. This actually goes a bit further than just listening to some truthful opinions but I figured that since I don't have really that many opinions to listen to, I might as well shift my own in the direction of progress.

Anyway, this post was very interesting to read for me, particularly because I haven't thought much about being at the saturation point, even though I find way too many worse-than-mediocre programmers getting jobs everywhere. But truth bombs are always a good idea. I can only wish I had more of them.

Re: http://altdevblogaday.com/2011/10/31/type-names-matter/

snake5 — Tue, 01 Nov 2011 13:32:59 -0000

I used the word "like" to imply that such changes as "string" -> "name" are nowhere near making the code more readable. Quite the opposite for some, in fact.

Unreadable code, in my opinion, would not only be code that uses near-obfuscated type names but also a heavy lump of OO code that has more internal two-way dependencies than a state-of-the-art skyscraper. It would also be code that uses hideous naming conventions like Systems Hungarian, or useless m_, g_ prefixes - anything that distracts from the real meaning of code.

But I would consider a "typedef std::vector< std::string > StrVec;" very readable, even though it's abbreviated and doesn't fit the STL interface naming convention.

Those are all my preferences. Mostly different from what most programmers consider to be good. Therefore I still think the word "like" is very appropriate.

Re: http://altdevblogaday.com/2011/10/31/type-names-matter/

snake5 — Tue, 01 Nov 2011 08:55:10 -0000

I think that for solo projects "know your audience" actually suggests that code should be written only for that one programmer and no one else. That no "if it goes viral" or "future team members" should be considered.

Otherwise it would make no sense - who would I really be writing the code for? What if my project gets picked as the best in an open-source GD contest? Should I write type names for whoever might look at the code later? What if I'm an OO-maniac that inspires hate in Linux software developers, should I rewrite everything in C-like code? What if the long, simple versions of my typedefs could occupy more than 1/4 of length of a line and I initially chose to use half-acronym typedefs that take less than 1/10?

Please don't get me wrong, I'm all for readable code. I just didn't agree with the part where you suggested that code must be written so that other people like it (unless they sell it, of course).

Re: http://altdevblogaday.com/2011/10/30/c-events/

snake5 — Mon, 31 Oct 2011 12:19:08 -0000

I'm afraid I can't remember any case/moment where writing/reading to the same variable from different threads has been impossible. Modifying the data of another thread makes it simple to trigger events on that thread. Doesn't require any special systems, just set some variables and forget. The other thread finds out they've been updated and reacts accordingly as soon as it's possible.
Sure, there are some rules for that to work but I don't see how [ab]using heavy systems makes anything easier: the message data still needs to be stored, sent and received, and time needs to be taken to do something that doesn't matter too.

Re: http://altdevblogaday.com/2011/10/30/c-events/

snake5 — Sun, 30 Oct 2011 09:25:26 -0000

It is somewhat hard for me to see the point of this. What needs does this fulfill?
"Event" in programming is simply a fancy name for "something that is called when something happens", in other words, a simple function that has some context (data, scope...) attached to it.

And well, I don't see any problems writing a function call or using function/class pointers. Sure, one might like to have something "stronger" for UI callbacks but I doubt they would ever require 1000 LOC to implement the add, remove and trigger functions, especially with a STL set.

P.S. Let's cut up one of your own examples: collision callbacks.
The usual case is:
Number of callers: 1
Number of receivers: 1
Number of events: 1-3 (add/remove/persist, most important is the first one)
Event receiver alive as long as the object is alive.
User data capacity for each collision object: 1 pointer.
Automatic memory management: none, all non-POD types in user data must be handled manually.
Therefore it's much easier to just pass the pointer to a collision object owner interface that can be used as a base class by the real owner, thus enabling unrestricted access to all of the data/functions of the owner. The pointer is detected in the physics engine callback override and it's handled appropriately. Registering and managing receivers is not required, so there's no need to make the design more complex than it has to be. Additionally, this approach allows any other physics-related object query the owner of each collision object processed.

Re: http://altdevblogaday.com/2011/10/28/dont-be-that-guy-but-how/

snake5 — Sat, 29 Oct 2011 00:51:22 -0000

I think "That Guy" just needs to know his audience. If there's none, there might be no point in trying to grab the attention of the people.

There's also one thing about help which might be of interest for you: "helping" implies that you're doing whatever the other person wants, not what you consider to be best for him. That is a huge difference which older people usually respect by not doing anything unless asked. It's not about being understandable if the people obviously do not care about improving their skills. And that seems more likely to be the case with amateur video makers whose most satisfying achievements without doubt would be making a video and uploading it. They would have to constantly destroy their achievements to move on and improve their skills - there's not many people that are ready to do that.

And putting other people's interests before yours seems completely like the wrong way to go. Now here's why:
1) People are selfish so by doing that you'll effectively give away all the time that you have - just like funding something that promises nothing returned;
2) People are not going to take you seriously unless you have achieved something; (I know, you're probably thinking about my achievements as you read the comment..)
3) People generally do not know what exactly it is that they want so unless you're sure that what you do helps, you're probably wasting your time;
4) If you're one of those who just like to help, you can make a blog for yourself and write tutorials about stuff in the style of "to whom it may concern";
5) There are 7 billion people on our planet, which ones do you really consider to be more important that yourself?

Re: http://altdevblogaday.com/2011/10/27/game-design-b-minus-should-try-harder/

snake5 — Fri, 28 Oct 2011 01:33:58 -0000

While I agree with most of that, I can easily understand why repetitive tasks are often there in the first place - if the controls of the game are polished enough to be extremely easy to use (which is the case with most AAA games), gamers will act OCD-like about the included content - killing enemies, smashing boxes etc. - they will want to do all of it, just because it's so simple and satisfying.

What I've often noticed though is that game design often isn't the real problem. Games have physics, mission scripting, all kinds of switch objects etc. If that kind of stuff is in the game code but not in the levels, it makes more sense to blame whoever wrote the story or designed the levels. If AC were a completely mission-objective-oriented game instead of a bean-counting sandbox, or set in an imaginary world, the possibilities for the adventure would probably be endless.

Re: A blob array « #AltDevBlogADay

snake5 — Tue, 25 Oct 2011 12:19:21 -0000

This is the way I see it: http://img684.imageshack.us...
As I said, it looks like your implementation can make at most two cache misses when looking up size/capacity while std::vector would make at most only one. Otherwise, everything seems to be just about the same. It seems to me that you don't think pointers are data that needs to be looked up.

Re: A blob array « #AltDevBlogADay

snake5 — Tue, 25 Oct 2011 10:40:57 -0000

What are the benefits of using this data structure over std::vector (or anything similar to it)? I mean, seriously. Serialization is just as simple with any container, storage isn't any more compact than what the best implementation of std::vector could give (object count, capacity, pointer and data for both). It also requires reading basic info (size, capacity) from a memory location that could easily be far from cached data. I can easily imagine internal data management being more cryptic due to pointer conversions too. And std::vector also supports using the stack as storage space for your data.

Re: Debugging hard to reproduce bugs « #AltDevBlogADay

snake5 — Sat, 22 Oct 2011 08:32:42 -0000

Ah, well then it would help to know more about the memory usage in your projects (including the memory management libraries that you use) and your development environment.

Re: Debugging hard to reproduce bugs « #AltDevBlogADay

snake5 — Sat, 22 Oct 2011 07:06:22 -0000

My argument is that the tool can more often fail to help with memory corruption bugs. So often that it would make no sense to use it for such bugs.

By the way, if the garbage collection / smart pointer bug was triggered by high memory usage, would it not mean that:
- the bug would be extremely simple to reproduce;
- it's not really a memory corruption bug?

Re: Debugging hard to reproduce bugs « #AltDevBlogADay

snake5 — Sat, 22 Oct 2011 02:13:33 -0000

Those were not just hard bugs he was talking about, but those were crashes and memory corruption. If he said that such a system can be used for, let's say, AI debugging, or finding out why the player character doesn't sometimes jump when it is supposed to, I would definitely agree with him. I think we can also agree that such bugs can sometimes be hard to fix. But if we're talking about memory corruption, which is usually caused by all kinds of bad pointers / array indices, recording random seeds and input could easily do nothing to help.

Re: Debugging hard to reproduce bugs « #AltDevBlogADay

snake5 — Fri, 21 Oct 2011 19:12:47 -0000

I wasn't talking about deterministic game logic, that's also not what the post is about.
Fully deterministic behavior = doesn't ever differ in any way (data layout in heap, CPU cache state, thread timing etc.).

Re: Debugging hard to reproduce bugs « #AltDevBlogADay

snake5 — Fri, 21 Oct 2011 14:56:52 -0000

Just as tricky as implementing the ability to save the game at any moment. Simple serialization of data + entity/pointer dictionary. With full serialization of dynamic objects, it becomes bulletproof but has a potential to be extremely slow.