Mike Acton

Posts

July 23, 11:19 PM

By Mike Acton and Daughter (Thanks: Ed Bartley)

You know those little icons on clothes tags? I sat down with Daughter and we worked out their meanings.

 

See: https://plus.google.com/105595823502776413734/posts/RUs5PQEPXgU

See also: http://www.textileaffairs.com/c-common.htm

 

 

Clothes suitable for a king

Clothes suitable for a Cyclops king

Clothes suitable for a human king

Clothes suitable for a mutant fish king

Clothes suitable for human king with glasses

Clothes suitable for human king with eyebrow issues

Clothes suitable for insect king

You can wear these clothes after you decapitate the king.

You can wear these clothes after you decapitate the king and deliver the head to me on a silver platter.

You can wear these clothes only after you steal the crown right off the king’s head.

Clothes suitable only for kings that secretly fight crime in the night while hiding their identity under a mask.

Knowledge of trigonometry required to wear these clothes.

These clothes can be rendered most efficiently using triangle strips.

Be careful of attracting mice while wearing these clothes.

Special outfit for use only when pressing the big, red button.

Clothes suitable for DJs only.

Clothes suitable for human peeping through windows.

Clothes suitable for mutant fish peeping through windows.

Clothes suitable for ninja peeping through windows.

Clothes suitable for television news anchors.

Clothes suitable for eating TV tray dinner in front of TV news.

Clothes suitable for hipters that refuse to own TVs.

Clothes not suitable for washing windows.

Clothes so small they fit in an envelope. (Warning to fathers.)

Clothes susceptible to blowing around and exposing self when standing over air vent.

 Clothes suited for characters in arcade games; expect mocking.

Clothes suitable for Justin Bieber.

Bow ties are not cool.

‘A’ These clothes only suitable for attractive people.

 These clothes attract Cyclops spies (looking around corners)

These clothes attract human spies (looking around corners) <- Thanks, Ed.

These clothes only suitable for Toy Story aliens.

These clothes not suitable for big, fat people with small, skinny legs.

’A’ These clothes only suitable for not-attractive people.

These clothes only suitable for watching the Hudsucker Proxy.

These clothes suitable only for students with 4.0 average.

These clothes suitable for students that just don’t give a damn.

These clothes suitable for parents that insist on putting those bumper stickers on their car about their kid being something of the month at their local school.

Clothes suitable for right-handed person while speaking on cell phone.

Clothes suitable for right-handed graduate.

Clothes suitable for left-handed person while speaking on cell phone.

Clothes suitable for left-handed graduate.

Clothes suitable for people who neither own a cell phone nor have graduated.

 

 

 

Permalink | Leave a comment  »

November 10, 10:24 AM

Lately I've been thinking about some my personal biases and how they can get in the way of what I really want to accomplish. More specifically, how they might have been inhibiting me from giving my best at the things I'm most passionate about: Like games, game development, engine development, programming, personal growth, and my team. I also can't help but wonder how they impact my relationships with friends and family, and in particular as a parent to my wonderful daughter.

I'll share some of them with you here. Some are obvious, some might be silly, but it wasn't until I stepped back a bit that I could really see them for what they were. In no particular order:

  1. "Professional" Bias : Or what I'm also thinking of as "The Boring Bias." I have a deep love for games and how they can motivate us, give us room to create, pull us together as people, ignite our passions and provide a platform for fascinating ideas and technology and have fun, real joy, doing it. But I see myself all too often looking elsewhere when I want to accomplish those very same things in the context of development. When I look at management type stuff like Gallup studies, or books like "Good to Great" or methodologies like Agile I can see a commonality: They're all so freaking boring! Nothing has been able to motivate, inspire and bring together millions of people or all different cultures and backgrounds to build things and make things and share experiences together like games - and that's something I know something about! I'm now super excited to figure out how I can apply my own models of games to a lot more problems. And just have more fun in the process.
  2. Education Bias : This is peculiarity of game development. Edutainment has been such god-awful crap for so long that just being associated with anything that might be considered "learning" is often avoided, at least overtly. And this bias has often caused me to forget that fundamentally, games are *about* learning. It's the one true universal language on this planet. We not only share game playing with other humans, we share it across species. Seriously, for the folks that say math is the universal language - I can't imagine doing math with a dog, but I can certainly imagine playing a game of fetch pretty easily. It's how a lot of of us higher Earth creatures learn best. And the very best games teach us deep and fundamental lessons that we can take with us our whole lives. Come on, how long have we been collectively studying chess or go? And if we look at games like WoW or even more recently FarmVille, we're talking about games that represent the some of largest live human experiments in economics and psychology the world has ever seen - the world is learning a lot from that. So I need to remind myself to ask what I can learn, what lessons I'm sharing, or what I'm experimenting with in everything I do.
  3. Programmer Bias : Pretty much universally every single time I've said or thought, "you need a programmer to do that bit, really" I've been eventually proven wrong. I have this model in my mind of programmers: something like a mix of problem-solving, math and logical/analytical thinking skills with a bit of OCD thrown in. And I'm definitely biased to think of problems in those terms. But the truth is that everyone has these same skills at different levels, they just need the right tools (or games!) and the right information to leverage what they can do and know. Not everyone can do everything of course, and someone has to write those tools in the first place, but everyone *can* do way more than they're usually given credit for (especially by me.) In games, artists construct models out of triangles, which can certainly be seen as a form of programming (which is fundamentally just doing something that converts data from one form to another.) But we also see artists building shaders and animators building complex rigs which by any measure is exactly the same kind of thing. The examples are endless. I can imagine some alternative history where some "programmers" got together and said "Only programmers can make music! It requires complex math and deep analysis of the structure to get it right!" - when of course we can see that a whole lot of people who only know three cords and definitely don't deeply understand the structure or math behind music can create real works of art that resonate with millions of people. Now when I think to myself that only a programmer could do something, I need to think instead about what kind of engine would allow someone like Britney Spears to do it instead. (Which of course now, I realize the irony of using her as the example here after I write it. Which just goes to show how insidious it is.)
  4. Negativity Bias : Part and parcel with having analytical work and being fascinated with models of completion (like programming!) is being over-critical. It's a crucial part of the process, of course. You make things better by looking at what problems exist and how they can be solved. It's when I take this too far that it becomes a real issue. It's when I forget that I'm looking for areas to *improve* and idea and not reasons to *kill* an idea that it gets in the way of creativity and shuts things down too early. It's easy to forget, especially in retrospect, that pretty much every good idea, and certainly every great idea, has holes in it. Sometimes big gaping ones. You just don't have all the answers up front. Especially when you're trying something new. You're not supposed to! Otherwise, it wouldn't be new! I have to imagine all the people that have changed the world, and all the (much larger number of) people that told them how it wouldn't work and think about which side of that equation I want to be on. For Pete's sake, I was one of the people that said "Sony doesn't know shit about games, I don't see how they can compete with Nintendo and Sega" when I first heard about the original Playstation project. This doesn't mean every idea *is* a good idea, of course. Or is practical. Or affordable. Or performant. Or whatever. But I does mean that I have to help build an idea up first and see how far it can go assuming it *can* meet the criteria for success. And explore it a lot further before deciding it's definitely not going to work.
  5. Expert Bias : There are some areas that I consider myself an expert in. Which really just means these are topics I've dedicated huge amounts of time, energy and study to. They are topics that fascinate me and that I can apply to what I love doing. The bias is not that I consider myself an expert at some level (admittedly there's always someone out there that seems to know more than I do) - at best, it's just factual, at worst it's hubris. The bias is that I get so lost in these subjects that I fail to see the, what are often extremely obvious, connections. e.g. How I can apply what I do to other fields, or how I can apply expert knowledge from other fields to what I do. Recently, in talking to a couple of the engine programmers on my team at Insomniac, I mentioned how I thought their Super Power as more generalist programmers was to bring disparate ideas together. To see the connections between unrelated systems and build something new and better out of the parts. It's something I need to work harder on. I need to remind myself to occasionally step back and look at fresh and new topics, ideas and areas of study and see what *else* I can learn. I can probably use some work on the hubris thing too. But whatever. Not today. :)
  6. Business Bias or Art Bias : I take turns with these in seemingly equal amounts. "It's about the business!" (Generally meaning sales, etc.) "It's about the art!" (Generally meaning a desire to express what's important to me as a creator.) It's neither one, exclusively of course. Famously recently Bobby Kotick of Activision pissed off a lot of people, both developers and players, when he said making games was exclusively about the money and really shouldn't be any fun. That's not only the road to soulless garbage in my opinion, it's simply and provably wrong. And Activision is quite lucky to have a lot of dedicated developers that bring their love and passion to development (and thus have made some great titles) regardless of what their CEO says to the company shareholders. On the flip side, it's not just about "the art" either. If I push toward some extreme end of experimental development, I'm very likely to exclude a huge majority of the potential audience. And it's that wider potential audience that (1) pays the bills, (2) gives me more people to connect with on some level, which is important to me and (3) gives me the opportunity, over time, to experiment with the ideas that I'm so interested in. It's why I love pop entertainment so much - it's a blending of business and art in a way that's both artistically compelling and sustainable. I just need to remind myself sometimes to have patience. There's lots of room for experimentation in a pop art, but you have to take the audience with you along the way. Take a look at music, punk and rap and rock-and-roll before them have completely transformed pop music. It just took some time and pressure. You know, like in Shawshank Redemption. 
  7. Proximity Bias : This is one I find the strangest, but see it in myself all the time. I often take the opinion of someone completely outside of my social circle more seriously than someone I'm very close to. Even if the opinion is exactly the same! Perhaps I go to some conference like GDC or talk with some people from different development studio or just read something from some random guy on the internet and I think "Wow! That's a great idea. I want to use that." But then when I take that idea back and share it, I might have people tell me, "Goddammit, Mike! I've been telling you that for a couple of years now!" It almost certainly has to do with the internal psychological model of the people I know have in my head and I become blind to things that don't match that model. And the more I work with someone, or the longer I'm friends with them, the deeper entrenched that model becomes and the more blind I get. Even worse of course is when I bring the experience I have with the person as unfair and unrelated baggage and partially (at least subconsciously) judge the idea on that too. I need to remind myself when I hear an idea or any kind of feedback really, to imagine it in a much more neutral context to try and break this model of where it's coming from in my head.
  8. Film Bias : This is another peculiarity of games. It's this idea that the film industry is the sort of big-brother to the video game industry and we often look to them as a model of how to do things or what we want to do. Well screw that! This one in particular pisses me off a lot when I see it in others and so very much more when I see it in myself. It's not that there's nothing to learn from film or the great studios, because there is (Pixar comes to mind and Ed Catmull in particular is a sort of personal hero of mine.) It's that games in particular have something fundamentally deep and different to bring to the world and that's what we need to explore! I love that I get to be a part of these moments in games because there is so much for us to explore and learn. It's my view that years from now video games are going to have such a profound impact on the way we live our lives that we're not even going to be able to imagine why we thought we'd want to be more like Hollywood and their lot. I need to remind myself that we have our own destiny and I get to be a part of that!
  9. Productivity Bias : This is actually where this whole thing started. I was thinking that it's so easy for me personally to get lost in what I'm doing. In projects and tasks and milestones and bugs. In making sure that things are getting correctly and on time. It's so easy to forget why I'm doing this. It's so easy to lose the passion and sheer love of the work and the things I can bring to the world under the onslaught of everyday stuff. There's no question that the stuff needs to get done, but all the work that I've ever done that I thought was really good (or even great) came from an emotional core. It's because I believed, deeply, that it was important and that I could make some kind of impact (however small) on the world. I need to remember to take a step back more often and remind myself of why I'm here and how I can make a difference. Really, just to keep inspiring myself so that I can always do my best.
  10. Success Bias : Man, this one sucks balls. When I'm successful at something, I want to keep doing more of that. On the surface, that seems fine, of course. But at some point it gets in the way of failure. I can find myself avoiding things that are different than that or that don't have the same chance of success. I can easily forget that in any way in which I've been successful, it's absolutely only because I failed in so many ways before that first. I know that I have to try lots of new things and fail at most of them to create anything really good. But it's so easy for me to forget. I need remember to ask myself every single day, how have I failed today? Because if I haven't failed, then I certainly haven't been trying hard enough. 
  11. Completion Bias - I'm adding this one because I realized that it was this that was actually getting in the way of me writing this little article in the first place. I know this is the reason why I don't post to my blog or work on various hobby projects as often as I want to. I have a strong tendency to want to complete something. What "complete" means is fairly arbitrary, but if I don't feel like I can do something real justice I don't want to do it. I'm sure this has something to do with the old adage my dad pounded in my head as a youth. That "if something is worth doing, it's worth doing right." And I'm for sure obsessed with that. As I wrote this I asked myself questions like: "Have I written enough on these topics?" or "Have I missed anything important?" or "Did I make that point well enough?" or "Are there some better ways of categorizing these biases?" or "Is there some way I could more generalize this point?" or "Should I go back and rewrite this whole thing?" - And I needed to tell myself that what I wrote probably is imperfect in many ways but I have my entire lifetime to improve it and at the very least, trying to articulate these imperfect thoughts in some way will at least give me a good start.
I don't know if you know anyone that shares my biases. Or if you can think of others of your own to share. But I'd really like to hear about it.

Mike.

Permalink | Leave a comment  »

August 06, 05:12 PM

Usability is not random.pdf Download this file

Looking for early feedback on my (still unfinished) Usability is Not Random presentation. All thoughts/comments/suggestions appreciated!

 

Mike.

 

PS: The above looks best if you select the "Slides" option on the bottom-left. Also, if it's taking too long to load in, you can click the "download" link and get the PDF directly.

 

 

Permalink | Leave a comment  »

August 03, 09:06 PM

Lately we've been using JSON as our text-based interchange format of choice internally. While most of our tools are internal and save this data in a way that's invisible to the user, we still do work with a lot of external tools. For better or worse one of those tools is Excel.  Giac Veltri (Engine Programmer) has put together a JSON exporter for Excel and short presentation that give a bit of background on the plugin. This plugin might not do exactly what you want, but it could be a good place to start if you're also looking to export JSON from Excel.

 

Included here are Giac's Excel plugins for Excel 2007 (xlam) and Excel 97-2003 (xla) and sample data and the generated JSON.

 

Have fun!

 

Updated link to Json plugin! (15 Aug 2010)


ExcelJsonSample.zip Download this file

JSON Exporter for Microsoft Excel.pdf Download this file

Permalink | Leave a comment  »

March 12, 04:08 PM

I was inspired by this link that @jurgenappelo sent out this morning:

Last night, once again I noticed that there were a lot of people hanging around here at GDC in groups of people that they work with (or go to school with) every day. GDC and events like this are great opportunities to meet new people and catch up with old friends too! There are also a lot of other things you can do to make GDC a better experience and give a little bit back to those around you.

Here’s my list of 10* little things you can do at GDC to make it just that much better

*There’re only 10 things because I’m too lazy to make a list of 50 things. (I actually was going to make 20 things when I sat down to write this, but I got to ten and changed the number because damn, that took longer than I thought it would.)

1.      Compliment someone else’s game. Social media has changed the way we interact among ourselves and with other game players. A few voices can make a huge impact. Take a little time to walk around the expo, find a game that you’re excited about (that you didn’t make) and let people know about it. With just a quick tweet or facebook update you might be able to get some people interested in a game that might’ve never heard of it otherwise. And a lot of the small, indie games depend on word of mouth and you might be able to make a big difference.

2.      Be genuine. Have your own voice and say what you think. For example, if you meet someone that you admire, but you disagree with a choice that they’ve made in one of their games, go ahead and let them know. Don’t be a jackass, but gamedevs want (and need!) to hear constructive criticism, and the most constructive feedback comes from our peers that know the constraints of real development. Tell people what games you liked and didn’t like and don’t worry too much about who might be standing right behind you with a grimace or frown on their face. Don’t be afraid to say what you think.

3.      Listen and learn. This is what we’re all here to do in the end. Pay attention in the sessions. Take notes. But don’t just write down the slides – you can get those later. Write down the ideas that the speaker inspires in you, or the things you want to try when you get back home. Every session represents some hard earned lessons and we’re really doing ourselves a disservice if we don’t learn the most we can from those lessons so that we don’t have to pay the same price to avoid them. The same is true of individuals you talk with – there’s a lot of organizational knowledge here in the industry, stuff that isn’t written down and really just shared from person to person – ask questions of everyone you talk to and try to learn something. In just a few days I know I’ve learned a lot of good lessons from a lot of people and that is going to make a difference when I get back to work.

4.      Work on a presentation, panel or roundtable. Get inspired by what other people are presenting this year and think up some ideas for what you can present next year. The submission deadline is sometime in the summer, so now’s a good time to think about it. I’ve had quite a few people tell me that they “just don’t have anything useful to say” – That’s total bunk! It doesn’t matter how long you’ve been doing this or what your job is, you’re being constantly challenged in this industry and you learn hard lessons every year. Those lessons and discoveries are exactly the kind of thing that would interest everyone else. Not only that, but every one of us is standing here on the shoulders of giants and there is no good excuse for not returning that favor. If you’re uncomfortable standing in front of an audience, find some other way to give back – write an article, create a how-to or make a little video showing of a technique you use. If you really, truly have no lessons to share and nothing to give back then either you are in the wrong industry and you should leave or you are in a job that doesn’t challenge you to be better - in which case, I’ll point out that Insomniac is hiring! :)

5.      Be a mentor. There are a lot of students here. Even for those that are themselves students, there are those that are just starting out and haven’t gone through the same program you have or researched the same things you have. Take the time to talk to someone that you might be able to help. Encourage them to ask you questions and answer them as honestly as you can. Share some good stories about embarrassing things you’ve done or painful moments you’ve endured and offer some advice for how they can avoid the same traps.

6.      Venture outside of your comfort zone. Go to sessions that aren’t in your area of expertise. Talk to people that aren’t doing the same discipline. There are a lot of surprising lessons that can be applied to your work if you take the time to look around. It’s also critically important that we all try to understand the challenges that we each face and appreciate the goals and visions for how we can all best contribute to the games we’re making. Personally, I’ve spent a lot of this week in art and design sessions and I can tell you definitively that those sessions made a difference to me.

7.      Introduce people and talk to strangers. Put together a quick meetup or a coffee and gather a few people that haven’t met before and introduce them. We don’t work in a vacuum and it’s important that we make connections with others so that we can learn from them. Help others do the same whenever you can. If you’re standing in a group of folks and you see a couple of obviously shy folk standing around with badges, invite them in to your conversation and ask them what they think. It’s easy and people appreciate it when you include them. I know I do.

8.      Give speaker feedback. Seriously, it’s really helpful. Take a moment and fill out the form in any session you’re in and tell the speaker what you think. Imagine if you were up there – wouldn’t you want to know what everyone really thought about your presentation? Wouldn’t you want some feedback so that you could improve in the future?

9.      Know your limits. GDC is a fun atmosphere and there are a lot of parties. If you’re tired go to bed. If you’re drunk, stop drinking. It’s all fun and games until I get someone else’s puke on me. We all want to be able to talk to each other and have a good time, but you stop being interesting when you’ve obviously exceeded your limit. Although a video of you might get some hits on youtube.

10.   Share ideas. We can’t always share the projects that we’re working on and there is a lot of confidential information that is important that we keep secret, but that’s pretty finite. Share your thoughts and your ideas for making things better. Share your thoughts on the industry as a whole, some improvements to an algorithm or some game design concept. Whatever you can. That’s precisely why we’re here. Don’t be overprotective of your ideas. Sharing them and talking about them makes them better.

On a slight tangent, earlier this week I sat in on some of the indie game talks. In particular I noticed that there was this definite “them vs. us” feeling. My message to all of us (whether or not we call ourselves indie) is to remember that we all make our games with love and we all share a passion for making great games. So let’s not forget that we’re in this together and take opportunities like GDC to make everything a little bit better. Our shared goal should be to make all games better, because that’s better for the players and it’s better for all of us.

Mike.

PS: Please come to my presentation on Saturday morning at 9am! I’m going to be sharing some lessons that I’ve learned and that I’m passionate about related to how we’re fundamentally approaching programming wrong.  Even if you’re not a programmer, it might be helpful to get a perspective on some coding challenges. And I’d really be interested in feedback from people from all disciplines. Also, I’m not above a little bribery:

Permalink | Leave a comment  »

March 06, 04:03 PM

Here are the initial details for our GDC tweetups #gdcdrink and #gdcherf

Everyone is welcome. We are always looking for fresh meat... er, new friends!

No need to RSVP at this point. Just come by and we'll squeeze you in.

#gdcherf - Cigar smoking, drinking, sharing stories, general bitching.

#gdcdrink - Same as above, but for our non-smoking friends.


Let me know if you have any questions. You can email me at macton at gmail. (Shoot me a mail if you're coming and you want my cell number.)

Mike.

PS: If any party poopers decide to change your mind at the last minute, go ahead and come by! I'm sure that we'll be able to squeeze in one more.

Permalink | Leave a comment  »

August 13, 04:48 AM

Data used for different purposes (i.e. different and exclusive most-common transforms/operations) will have a different form. Data should be designed to fit the transformations and constraints being applied for the problem. Two different problems imply two different data designs.

This is intuitive at a high level. Text is clearly not the best format for reading and executing an instruction stream, however it is a good format for editing and describing one. That's why we write code in text and yet it's compiled (transformed) in to something more suitable for the exclusive use (reading and executing). Even short-cycle interpreted languages are simply less monolithic versions of the same logic (e.g. small sections of modified text are transformed in to another format, like a VM code or JIT native code.) This is done because these are exclusive and independent uses of the same essential data (instruction description/stream) and different formats are better suited to the different uses, and different parts of the data are often exclusively relevant to one transform or the other.

At a high-level, the same pattern is applied to the game (e.g. data from maya, intended for general-purpose editing, is converted to a runtime format, which is intended for game rendering, which has different goals, transformations and constraints.)

You can imagine many more examples that fit this essential pattern:

Let me repeat this point: Two different problems imply two different data designs. This is a fundamental of good data design.
 
However, Object-Oriented Design (OOD) and Object-Oriented Programming (OOP) have perpetuated this misguided belief that there is an ideal abstract data form where all transformations are given equal weight*.

THIS IS GARBAGE.
  • It doesn't match the reality of what's happening.
  • It's not intuitive at all. (Mostly because it doesn't match any reality.)
  • It's harmful (by pretty much any metric - memory, performance, complexity, etc.)

The idea that all transforms are essentially equal, and a data format is an opaque abstraction that provides the union of all information needed for all transformations equally, is just wrong. Nothing could be further from the truth, but the value of each transform, both independently and in exclusive groups, and the impact on the data design is not considered in traditional OOD. See also: Three big lies

* It doesn't matter whether or not this pattern or belief is inherent in OOD. The fact is that it is most commonly applied this way in practice. And you know it.

Take for example, this bit of code:

class AlignedBox
{
public:
  Vector3 minimum;
  Vector3 maximum;
  bool seeded; <-- Take a moment: What do you think this is for?

...

That field exists because these transformations (methods) have been included in this class:
Vector3 Test(Vector3 vertex);void Merge(const AlignedBox& box);void Merge(const Vector3& position);

You can see, for example from the Test method below that these transformations are designed to edit the AlignedBox. And that the "seeded" value is used simply as a test to see if an initial point has already been transformed by the method into extents of the box.

Vector3 AlignedBox::Test(Vector3 vertex)
{
if (!seeded)
{
seeded = true;
minimum = vertex;
maximum = vertex;
return vertex;
}

if (vertex.x > maximum.x)
maximum.x = vertex.x;

if (vertex.x < minimum.x)
minimum.x = vertex.x;

if (vertex.y > maximum.y)
maximum.y = vertex.y;

if (vertex.y < minimum.y)
minimum.y = vertex.y;

if (vertex.z > maximum.z)
maximum.z = vertex.z;

if (vertex.z < minimum.z)
minimum.z = vertex.z;

return vertex;
}

Now without getting in to the data field seeded itself, at whether or not it's actually necessary (it's not at all - you can almost certainly know in context whether or not you're creating a new AlignedBox. Not only that, it implies that points are being added arbitrary and individually with no consideration of their data design. Which in turn implies that the data design of the parent, or calling system is poor.)

Note another set of methods that exist in this class:

bool IntersectsSphere( const Vector3& pos, const f32 radius ) const;
bool IntersectsBox( const AlignedBox& box ) const;

Clearly these two sets of transformations are independent. The pattern should also be familiar (see diagram above). The data is "edited" by the Test and Merge methods, and is later transformed by the Intersects* methods. Certainly we may expect the AlignedBox to be edited again in the future, but in the same way that we expect code to be re-edited. These are exclusive and independent data transformations, and as such, we should expect their solutions (data forms) to be different, depending on their most common uses.

In fact if you looked at the data usage for the Intersects* methods in the system, you would very likely be able to reduce the most common pattern in to cases like the following:

And the data design you would create for solving this problem would be very different from the design you would create for solving the editing problem above. As it is with text and code.

Most people do intuitively know there is something wrong with this design. Although they may not know what. Take the Intersects* methods again, for example.

This function is completely defined in the cpp file, in that it actually does the transformation/test.
bool AlignedBox::IntersectsSphere( const Vector3& pos, const f32 radius ) const;

However, can you guess what Sphere::IntersectsAlignedBox looks like? How to handle these kinds of cases invariably leads to a confused OOD. Why? Because the model makes no sense. The fact of the matter is that these methods do not belong in this class because this is not the class of data that they act upon. The only "class" that these transformations belong to are a class of data that match their transformation patterns (which may look like the image above, or whatever the most common context they're applied in the application happens to look like.)

But note, even in the above case you would be careful not to over-generalize the data pattern, or you would simply end up switching on every pair of data types possible in the input streams. You need to analyze the data itself to see which pairs are likely combinations and should be handled as such. It's exceedingly unlikely that all pairs are equally likely and that no similar pairs are ready to be transformed within the same latency window.

In a similar way, AlignedBox also includes the following methods:

void GetVertices(V_Vector3& vertices) const;
static void GetWireframe(const V_Vector3& vertices, V_Vector3& lineList, bool clear = true);
static void GetTriangulated(const V_Vector3& vertices, V_Vector3& triangleList, bool clear = true);

Which belong to an entirely different class of transformations! To which you would need to ask similar questions - How are the transformations applied? When are they applied? What are the latency constraints? What is the necessary throughput? etc.

While it may be said that I "cherry-picked" a particularly poorly designed example to pick on, the flaws themselves and the lack of consideration for data flow and design, are very typical. And there is a lot you can infer about the system as a whole by just looking at the data design of a single part.

Mike.

Permalink | Leave a comment  »

August 05, 03:36 AM

Recently I've been doing some presentations as well as just general sketches of some things I've been thinking about regarding optimization, concurrency and data design. I've been posting them on Twitter to gather feedback from my pals there. A couple have caused a little controversy, but remember that all of them are given in the simple spirit of sharing ideas among peers. And don't forget it's all in good fun!

Permalink | Leave a comment  »

July 11, 04:03 AM

We have a lot of manga. Picked up here and there over the years. I don't know how many. Hundreds, certainly. So my daughter decided that this summer she's going to make a project of re-reading (or in some cases reading skipped books) every manga we have in the house. And classifying them! ("Love it", "It's okay" and "Junk") - so far good progress. Everything on the table there is what she's read so far. Only four more shelves of books to go! Oh and guess what her reward for such diligence is going to be? You're right! More manga!   (Yes, she reads lots of regular books too. Don't give me any crap about comics.)

Permalink | Leave a comment  »

July 11, 03:48 AM

Local store was closing down a while back. They said everything in the store was on sale. So I bought some socks. And I liked one of the signs they used to show which area you're shopping in. I wanted to buy that. They said "everything." It's not confusing. I know what everything means. Plus, they're closing down - what the hell are they going to need those signs for anyway? The hardest bit was negotiating a price. As if either one of us knew anything. I didn't know how much the sign was worth to me. The clerk certainly didn't know how much to value it. $40? Sure, sounds good to me. Write it up! Now I know where "Home" is.

Permalink | Leave a comment  »

June 27, 11:46 AM

Special treat for Alexandra: I wonder if vampires still have to get permission to cross the threshold of the Romanian embassy, or if they get some kind of free pass.

Permalink | Leave a comment  »

June 27, 10:55 AM

Seriously. I can't imagine being able to plan around not having any earthquakes. Ever. Forever. I mean, I don't even put heavy stuff on top shelves because earthquakes may cause them to fall and break something or someone. No hurricanes or tornadoes, either right? Man, it seems like the only disaster the French need to worry about are military ones (Sorry guys! I had to. Forced at gunpoint by English friends who couldn't take my new perspective on the French.)

Permalink | Leave a comment  »

June 27, 09:52 AM

Tomatoes. They really looked good too. I was tempted to just take them, since I figure someone must've accidentally left them behind. But I didn't - wouldn't want to piss off the god of transportation - my car has almost 200K miles on it, and I want to keep going. Plus, I think the offering was an apology for neglecting the street signs. Though you can see his image on the street. Watching.

Permalink | Leave a comment  »

June 27, 09:25 AM

The last few days of weather in Paris have been terrible. Humidity. Rain. Cloud-cover. Today though (my only vacation/free day), was perfect. Sunny and dry. I think I may have a sunburn from my nap in the park. :)

Permalink | Leave a comment  »

June 27, 09:07 AM

Eight hour walk through Paris and I only saw one handwritten sign (and I was looking for them!). It's a lost art.

Permalink | Leave a comment  »

June 26, 11:30 PM

The impact and value of handwritten signs interests me. Not to mention the necessity (in this case).

Permalink | Leave a comment  »

Profile

Mike Acton is Engine Director at Insomniac Games and runs CellPerformance.com
Computer Games | Greater Los Angeles Area, US

Summary

As engine director at Insomniac Games, Mike leads one of the best engine teams ever assembled in the gaming industry. When he’s not searching for new ways to optimize Insomniac’s engine, he dreams up new ways to help the development community and tries, with varying degrees of success, to contribute as much as possible to CellPerformance.com. Mike makes regular appearances as a speaker at SCEA development conferences, Game Developers Conference and other events, extolling the virtues of understanding the data and hardware first along with programming for performance. Mike’s hobbies include designing new hardware on FGPAs and debating all challengers via Twitter (@Mike_Acton). He lives in Burbank with his teenage daughter.

Mike believes strongly that it is important give back to the community. None of us could have done our jobs well without relying on the work of others and those giants that came before us, and we all have a duty to return that favor.

Experience

  • Jan 2007 - Present
    Engine Director / Insomniac Games
  • May 2005 - Nov 2006
    Sr. Architect / Highmoon Studios
    Discovering the secrets of the Cell BE processor and the Playstation 3.
  • Apr 2004 - Mar 2005
    Lead FX Programmer / Sammy Studios
    Worked closely with the FX art staff to create custom tools, realtime editing and previewing on the target platform and some very cool special effects.
  • Jun 2003 - Jan 2004
    Lead Programmer / FINE
    Worked on the LIME PS2 title. Developed all tools including art converters and a unique scripting language. Developed all console code including graphics engine, scripting engine, streaming engine and game code. Developed the title from start to gold master in record time.
  • Jan 2002 - Jun 2003
    Engine Programmer / Yukes co, ltd.
    Worked on developing a new PS2 graphics engine.
  • Mar 2000 - Jan 2002
    Technical Director / Engine Programmer / VBlank, inc.
    Mostly engine programming, plus designed the toolset and formats and co-developed the tools.
  • Jan 1999 - Mar 2000
    Lead Programmer / Engine Programmer / Bluesky Software
    I wrote and completed the PSX engine (arbitrary portals, no convexity design restrictions, using arbitrary geometry and all the pipeline tools (lightwave for geometry, image converters, etc)
  • 1996 - Jun 1998
    Lead Programmer / Engine Programmer / Sony Interactive Studios America
    Involved in every aspect of the development. Including character animation engine, camera logic, AI and virtual control systems, tools, etc.

Additional Information

Posts

November 21, 04:04 AM
I favorited a YouTube video: Biography of the creation of NeXT, the Apple we know today.
November 12, 02:53 PM
I favorited a YouTube video: In this video, we take a look at two Canon DSLRs - the 7D and the 5D Mark II. If you've got either one of the triple digit-D or double digit-D DSLRs from Canon, which of the two makes the ideal body to upgrade to? We take them out to compare some ...
November 05, 09:37 PM
I liked a YouTube video: Just a little something from me about the site.
October 27, 03:05 PM

October 27, 04:56 PM

I'd been having some trouble displaying text in sixty second shooter. There's some stuff Google's working on that's still in development that worked well but I don't want to rely on it. A couple versions of Chrome ago, using browser text on top of the native client stuff seemed to hash my framerate - but either it was my imagination or they fixed it. Browser text is pretty decent now, particularly if your game isn't CPU bound - you can check it out by playing the game with the about:flags framerate counter enabled and turning the "browser text" option on and off.

But searching websites for how to arrange text left me with no clue how to make it look "videogamey" - but eventually, with some advice from Gregg Tavares and others, I found what I was looking for, and here it is.

For a lot of this, jsfiddle.net was awesome for just mucking around with a decent iteration loop. 

You can check this all out in the field, by the way, by going to the game sixtysecondshootertest.appspot.com and choosing 'view source' - (you can also see how I did the game's audio.)

I'm a rank amateur at this stuff, so if you know better ways, I'd love to hear them.

Web Fonts

Web fonts are cool. My wife picked out 'Comfortaa' for sixty second shooter. It does seem to add a second or two to the load time, which is a problem, but I'll work that out someday - the game really needs a loading bar.

Overlaying Text

I just wanted to overlay text on top of the game area, for a start. Could HTML even do that? I wondered. The old HTML I knew was only good for arranging witihin a single layer. Overlap wasn't its thing.

Eventually I tracked down the "position: absolute;" style in CSS. It's just what I needed - there's even a z-index if I want to control the order things are displayed, though I didn't seem to need it. It feels good just knowing its there.

For example, to put the player's score and whatever other useful in-game information in the upper-left hand corner...

Controlling Visibility

Here's another little tidbit: when I wanted to hide an element with javascript, the first thing a Google search told me was to set its style.display to 'None'.  One problem with that is it bashes whatever information was in the style.display before, whether it was 'inline' or '-webkit-box' or what. A better answer, with Chrome anyway, is to use 'style.visibility', setting it either to 'visible' or 'hidden'. This also keeps the element in the flow - other widgets won't move when it disappears. To wit.

Creating Elements On The Fly

I wanted the points you earned for shooting badguys to pop up when you hit them - the way to do that was to use the CreateElement javascript function. At first I kept track of them in a dictionary, but then discovered I could use the setAttribute() and getElementsByClassName() functions which allowed me to attach data to them and track them. Sorry, no jsfiddle for this one, check the game code.

Sometimes these would stick off the screen, and ugly scroll bars would pop in. Using overflow: hidden on them wouldn't fix it - so I used overflow: hidden on the entire page. Which will mess people up with screensizes smaller than 1024x768, but according to my stat reporting nobody's running that small ... so far.

Resizing The Game To Fit The Window

And that was all I needed, up until I wanted the game to resize with the window. Up until now I'd been doing everything in absolute pixels.

First, resizing the window is pretty easy: use the javascript onresize. (With native client, when you resize the embedded native client element, it calls DidChangeView on the instance. From there I resized my post-processing buffers as necessary.)

The hard part was putting text in the right place - particularly centered text. One way is to use absolute: position, left: 50%, text-align: center, width: arbitrarypx, margin-left: -onehalfarbitrarypx. (Resize that window to see it in action.)

But some of my text, I didn't just want to center it absolutely - I wanted it centered in the middle of the larger, left-hand pane. And it had all sorts of tabley stuff and radio button lists and doodads inside it. This was the biggest pain. This was where I broke out the new flex box stuff which is differently supported in different browsers ... on the bright side, since I'm only supporting Chrome, I only had to use -webkit-box. On the dark side, I discovered interesting things like it's hard to combine flex box with absolute position - look what happens (Chrome/webkit only) if you flex box a list at the bottom of the screen. (My solution for the lower nav bar was to use display: inline and lots of padding-right - they don't spread out exactly the way I wanted but whatev.)

For the box-centered-in-a-pane, I ended up faking it with padding. There's got to be a better way:

A Book

I learned almost everything I know about CSS from CSS: The Missing Manual... and a lot of Googling.

 

September 24, 09:49 AM

2ch’s latest efforts to make the unmoe moe has seen them manage to moefy the entire national borders of the UK, on the basis that she “looks like a girl worried about the size of her breasts.”











Other nations have been subjected to the same technique, with Chinese efforts in this area proving particularly successful, even if there is some evident disagreement over if and how to incorporate Taiwan…








This is not, however, a recent innovation:






See also the advent of Oniko for an outstanding example of more conventional moe anthropomorphisation.

September 24, 08:26 PM
He marcado un vídeo como favorito en YouTube.: Music video by Amy Winehouse performing Just Friends. (C) 2008 Universal Music International Division, a division of Universal Music GmbH
September 24, 08:25 PM
He marcado un vídeo como favorito en YouTube.: Music video by Amy Winehouse performing You Know I'm No Good. (C) 2006 Universal Island Records Ltd. A Universal Music Company.
September 06, 01:13 PM

A few months ago I’ve written an article named Where the top of the stack is on x86, which aimed to clear some misunderstandings regarding stack usage on the x86 architecture. The article concluded with a useful diagram presenting the stack frame layout of a typical function call.

In this article I will examine the stack frame layout of the newer 64-bit version of the x86 architecture, x64 [1]. The focus will be on Linux and other OSes following the official System V AMD64 ABI (available from here). Windows uses a somewhat different ABI, and I will mention it briefly in the end.

I have no intention of detailing the complete x64 calling convention here. For that, you will literally have to read the whole AMD64 ABI.

Registers galore

x86 has just 8 general-purpose registers available (eax, ebx, ecx, edx, ebp, esp, esi, edi). x64 extended them to 64 bits (prefix "r" instead of "e") and added another 8 (r8, r9, r10, r11, r12, r13, r14, r15). Since some of x86’s registers have special implicit meanings and aren’t really used as general-purpose (most notably ebp and esp), the effective increase is even larger than it seems.

There’s a reason I’m mentioning this in an article focused on stack frames. The relatively large amount of available registers influenced some important design decisions for the ABI, such as passing many arguments in registers, thus rendering the stack less useful than before [2].

Argument passing

I’m going to simplify the discussion here on purpose and focus on integer/pointer arguments [3]. According to the ABI, the first 6 integer or pointer arguments to a function are passed in registers. The first is placed in rdi, the second in rsi, the third in rdx, and then rcx, r8 and r9. Only the 7th argument and onwards are passed on the stack.

The stack frame

With the above in mind, let’s see how the stack frame for this C function looks:

long myfunc(long a, long b, long c, long d,
            long e, long f, long g, long h)
{
    long xx = a * b * c * d * e * f * g * h;
    long yy = a + b + c + d + e + f + g + h;
    long zz = utilfunc(xx, yy, xx % yy);
    return zz + 20;
}

This is the stack frame:

So the first 6 arguments are passed via registers. But other than that, this doesn’t look very different from what happens on x86 [4], except this strange "red zone". What is that all about?

The red zone

First I’ll quote the formal definition from the AMD64 ABI:

The 128-byte area beyond the location pointed to by %rsp is considered to be reserved and shall not be modified by signal or interrupt handlers. Therefore, functions may use this area for temporary data that is not needed across function calls. In particular, leaf functions may use this area for their entire stack frame, rather than adjusting the stack pointer in the prologue and epilogue. This area is known as the red zone.

Put simply, the red zone is an optimization. Code can assume that the 128 bytes below rsp will not be asynchronously clobbered by signals or interrupt handlers, and thus can use it for scratch data, without explicitly moving the stack pointer. The last sentence is where the optimization lays – decrementing rsp and restoring it are two instructions that can be saved when using the red zone for data.

However, keep in mind that the red zone will be clobbered by function calls, so it’s usually most useful in leaf functions (functions that call no other functions).

Recall how myfunc in the code sample above calls another function named utilfunc. This was done on purpose, to make myfunc non-leaf and thus prevent the compiler from applying the red zone optimization. Looking at the code of utilfunc:

long utilfunc(long a, long b, long c)
{
    long xx = a + 2;
    long yy = b + 3;
    long zz = c + 4;
    long sum = xx + yy + zz;

    return xx * yy * zz + sum;
}

This is indeed a leaf function. Let’s see how its stack frame looks when compiled with gcc:

Since utilfunc only has 3 arguments, calling it requires no stack usage since all the arguments fit into registers. In addition, since it’s a leaf function, gcc chooses to use the red zone for all its local variables. Thus, esp needs not be decremented (and later restored) to allocate space for this data.

Preserving the base pointer

The base pointer rbp (and its predecessor ebp on x86), being a stable "anchor" to the beginning of the stack frame throughout the execution of a function, is very convenient for manual assembly coding and for debugging [5]. However, some time ago it was noticed that compiler-generated code doesn’t really need it (the compiler can easily keep track of offsets from rsp), and the DWARF debugging format provides means (CFI) to access stack frames without the base pointer.

This is why some compilers started omitting the base pointer for aggressive optimizations, thus shortening the function prologue and epilogue, and providing an additional register for general-purpose use (which, recall, is quite useful on x86 with its limited set of GPRs).

gcc keeps the base pointer by default on x86, but allows the optimization with the -fomit-frame-pointer compilation flag. How recommended it is to use this flag is a debated issue – you may do some googling if this interests you.

Anyhow, one other "novelty" the AMD64 ABI introduced is making the base pointer explicitly optional, stating:

The conventional use of %rbp as a frame pointer for the stack frame may be avoided by using %rsp (the stack pointer) to index into the stack frame. This technique saves two instructions in the prologue and epilogue and makes one additional general-purpose register (%rbp) available.

gcc adheres to this recommendation and by default omits the frame pointer on x64, when compiling with optimizations. It gives an option to preserve it by providing the -fno-omit-frame-pointer flag. For clarity’s sake, the stack frames showed above were produced without omitting the frame pointer.

The Windows x64 ABI

Windows on x64 implements an ABI of its own, which is somewhat different from the AMD64 ABI. I will only discuss the Windows x64 ABI briefly, mentioning how its stack frame layout differs from AMD64. These are the main differences:

  1. Only 4 integer/pointer arguments are passed in registers (rcx, rdx, r8, r9).
  2. There is no concept of "red zone" whatsoever. In fact, the ABI explicitly states that the area beyond rsp is considered volatile and unsafe to use. The OS, debuggers or interrupt handlers may overwrite this area.
  3. Instead, a "register parameter area" [6] is provided by the caller in each stack frame. When a function is called, the last thing allocated on the stack before the return address is space for at least 4 registers (8 bytes each). This area is available for the callee’s use without explicitly allocating it. It’s useful for variable argument functions as well as for debugging (providing known locations for parameters, while registers may be reused for other purposes). Although the area was originally conceived for spilling the 4 arguments passed in registers, these days the compiler uses it for other optimization purposes as well (for example, if the function needs less than 32 bytes of stack space for its local variables, this area may be used without touching rsp).

Another important change that was made in the Windows x64 ABI is the cleanup of calling conventions. No more cdecl/stdcall/fastcall/thiscall/register/safecall madness – just a single "x64 calling convention". Cheers to that!

For more information on this and other aspects of the Windows x64 ABI, here are some good links:

[1] This architecture goes by many names. Originated by AMD and dubbed AMD64, it was later implemented by Intel, which called it IA-32e, then EM64T and finally Intel 64. It’s also being called x86-64. But I like the name x64 – it’s nice and short.
[2] There are calling conventions for x86 that also dictate passing some of the arguments in registers. The best known is probably fastcall. Unfortunately, it’s not consistent across platforms.
[3] The ABI also defines passing floating-point arguments via the xmm registers. The idea is pretty much the same as for integers, however, and IMHO including floating-point arguments in the article will needlessly complicate it.
[4] I’m cheating a bit here. Any compiler worth its salt (and certainly gcc) will use registers for local variables as well, especially on x64 where registers are plentiful. But if there are a lot of local variables (or they’re large, like arrays or structs), they will go on the stack anyway.
[5] Since inside a function rbp always points at the previous stack frame, it forms a kind of linked list of stack frames which the debugger can use to access the execution stack trace at any given time (in core dumps as well).
[6] Also called "home space" sometimes.

Related posts:

  1. Where the top of the stack is on x86 I’ve noticed more than once that some programmers are confused...
September 18, 10:39 PM
I favorited a YouTube video: http://iamlights.com LIGHTS' official music video for "Toes" off of the forthcoming album Siberia out everywhere 10/4/11. Siberia is available to preorder here: http://bit.ly/siberiapack For more LIGHTS: http://Facebook.com/LIGHTS http://Twit...
September 18, 04:12 AM
I favorited a YouTube video: littleBits is a system of electronic parts for play and prototyping. Designed for children, artists, or anyone shy about soldering, littleBits make electronics easy, fun, fast and accessible. Ayah Bdeir talks about her simple and intriguing system...
September 18, 04:11 AM
I favorited a YouTube video: Anil Dash shares his observations and insights into the development of the Maker movement He sees it as a kind of political movement that is apolitical in nature but also radical and inclusive. This conversation with Anil and Dale Dougherty, fo...
August 02, 01:20 PM


nevver:

No More Problems in Poohville

August 03, 12:16 PM

Made by scientist Paul Vallett for his Electron Cafe blog, this funny cartoon is essentially about the differences between how science happens in the movies, and how science happens in real life.

On the one hand, I like it a lot, because the speed and ease of movie science does lead people to expect major breakthroughs to happen quickly, and makes them less critical of the sort of PR and journalism that tries to paint every new paper as a game-changer. In fact, you could probably make a case for movie science being one of the drivers that helps to create that bad PR and journalism to begin with. If decades of film and television have trained people to expect easy "Eureka!" moments, maybe they're likely to have less interest in nuanced results, or the fact that not all published science is correct. Unrealistic expectations matter.

On the other hand, well-done fiction is bound by reasonable constraints. There's not time for a "and then they do real science" montage in every movie. To a certain extent, I think this particular complaint might be a bit like wondering why nobody in Star Wars ever stops to pee.

Via JA Tetro



July 26, 04:12 PM

Your favorite NFL receiver would be proud.



July 29, 08:44 AM


A Redditor called “i_luv_ur_mom” posted this math teacher’s amusement, an equation that draws a lovely Bat-signal.

Do you like Batman? Do you like math? My math teacher is REALLY cool



July 30, 07:00 PM


Submitted by: Unknown

July 29, 04:17 AM
I favorited a YouTube video: 25 years ago he revolutionised the animation industry. A Day In The Life of John Lasseter
July 27, 03:52 AM

World population is estimated to be 6.9 billion people, and while that is a lot of people, it suddenly doesn't seem like that much in these maps by Tim De Chant of Per Square Mile. Simply imagine that the world lived with the same density of a real city, and see how much area they take up. If we all lived like they do in San Francisco (space-wise), we'd take up just under 398k square miles, or rather, only four states. Same density as New York? We'd all fit in Texas.

[Per Square Mile]

Hello. My name is Mike Acton. You can email me at macton@gmail.com

I'm the Engine Director at Insomniac Games. In these links you'll find my personal opinions about programming, family, and other random stuff.

Check out: CellPerformance.com

Are you a junior programmer or student? Want feedback on your ideas from a #gamedev? Send me a link. I'll queue you for the hotseat.

Coming soon: Macton's Tech Hotseat

abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz