  
Welcome to Ventspace! Most posts here are delayed copies of posts from the real Ventspace.
| Friday, September 28, 2007 |
  All Glory To The Hypnotoad | 
Posted - 9/28/2007 11:52:09 AM | 
| |
| Wednesday, September 26, 2007 |
| The Problems of Data Hiding | |
Posted - 9/26/2007 3:20:37 PM | Back to the technical stuff for now. I start at Day 1 on Monday, so you can probably guess what vein the posts for next week will be in.
The Problems of Data Hiding
I was reminded of this yesterday, when I was asked to reconsider sealing a bunch of SlimDX classes. (SlimDX objects were all previously sealed if there was no further inheritance in the codebase.) I looked at a couple MSDN things I was pointed to, and decided to unseal, with no particular objections or concerns. There was no particular reason to seal the classes in the first place, except for a vague idea of "well, these are the most inherited classes that show up in DX". It's worth noting that you can safely inherit DirectX classes and COM classes in general if you are careful about it, despite what I may or may not have said some years ago.
Sealing classes is basically a form of data hiding; it prevents people from accessing your protected members. Most people are familiar with scope limitations (private, protected, internal, package, etc) as a technique for data hiding. There are other techniques as well, like interfaces that selectively expose members via function calls (C APIs, COM, and other interop systems work like this). Sometimes you can provide a public version of the object that simply doesn't tell the user what's inside it. (This one is quite common in C.)
So what is data hiding? Why do we use it? Most people are aware that it relates to encapsulation, somehow. Some people think it is encapsulation. (Those are the people who end up with pass-through getters and setters for no reason other than that it provides 'encapsulation'.) I disagree with that view. Encapsulation is not information hiding. As for the why, most people will tell you that you do it so that people can't mess up your internal data and therefore break your code. The problem is that doesn't work. Breaking through the barrier is usually pretty easy, and I know how to do it with minimal effort in C, C++, and .NET. And if this is the case, why would you disallow reading of the internal data?
It should be clear at this point that data hiding isn't about preventing people from modifying internal values, it's just about discouraging it and suggesting going through the proper interfaces. There was a question posed in the forums recently about how you would implement private in C. (Someone please find this thread and post it in comments.) The answer is not clever syntactical tricks. It's much simpler than that.struct SomeData
{
int publicValue1;
float publicValue2;
int m_privateValue1;
float m_privateValue2;
};
What about encapsulation, then? The point of encapsulation is to hide implementation details -- details which might change. A 3D vector will always have X, Y, and Z members, so there's no meaningful encapsulation for one. If you make the members private and give it get and set functions, you're just wasting your time and creating more code to maintain. It's data hiding, but it's not encapsulation! Data hiding merely provides a support mechanism which can be used to assist with encapsulation. Sadly, it seems that most introductory texts and courses don't explain this or even suggest it.
So why were we sealing classes? To provide encapsulation? The composition of most SlimDX classes is a pointer to a DX object and nothing more. That will never change. Hiding that stuff away is not useful, and in fact we're in the process of exposing that to the world via a CLS-friendly IntPtr member. The tricky part, then, is knowing what should actually be encapsulated. This is a tough one, and there's a couple questions to look at:
* What could a client possibly want this data for?
* Is there any harm in letting the client have this data?
* Is it likely that this data will vanish or change substantially in the future?
* Is this going to pollute reflection tools like Intellisense and property grids? (This last one is very new-age.)
Sadly, there's no definitive answer. Personally, I tend to favor not encapsulating. My reasoning is that failing to expose something is far more problematic than exposing it unnecessarily for most users, and hostile or abusive client code WILL get its hands on your data if it's decided to. (Just read Raymond Chen's blog for a while if you want confirmation of that.) Take a look at .NET's System.Collections.Generic.List<T>. It's a straightforward resizable array. The mistake they made was to not expose the internal array directly, at least as a read-only property. The only danger in doing so is that you could skip the bounds check of the list size, and you'd only be subject to the capacity limitation. But who cares? It's not like that's even dangerous. And if someone wants your internal array, it's reasonable to assume they have a good reason. For example, they might want to pin it and submit it to SlimDX for use as buffer contents. People do this anyway; it's just that they end up using reflection to penetrate the scope shield and access it anyway. So what was accomplished by the data hiding here? Nothing at all. Not only that, MS can't even change the internal name of the member anymore.
In short, please take a moment to think about why you're hiding your class data, and if it's really doing any good, or just making everyone's life harder. Think about it real hard if you're using the 'friend' keyword in C++. You might just be wasting your time.
| |
| Friday, September 21, 2007 |
| The Pain of Buying a Car | |
Posted - 9/21/2007 3:29:10 PM | Before I get started, I have one thing to say about Dev-C++. If you're using it, knock it off. It's a worthless piece of software that wasn't any good when it was being actively developed, let alone now when it's been dead for two years. If you're programming on Windows, take the time to learn Visual Studio, or get the hell out of our industry, because clearly you're not cut out for it. I have no sympathy for the guys who think that it's too bloated or too complicated or any of that.
The Pain of Buying a Car
I received my offer from Day 1 on the 12th -- that was a week and a half ago, on Wednesday. I decided to accept later that night. The next step from there was buying a car, which I finally did on Tuesday. The interim period was a rather painful one, since I had a whole bunch of problems to look at:
1) What car do I get?
2) New or used?
3) If new, lease or buy?
Selecting a car was quite difficult. I'm saving a large amount of my paycheck for going back to school eventually, so there were some serious limitations in how much I could afford to pay per month for my car. On top of that, I'm only 20 and my insurance is shockingly expensive as a result. I basically needed the following things from the car of choice:
1) Fast. Now I'm not racing or even going to track days, but I want a car that is responsive and lively. It needs to be ready to pick up the pace at a moment's notice.
2) Lots of cargo space. I'm a rather mobile person at the moment and I'm moving stuff around constantly. I need space to put stuff. This is where the 300ZX got invalidated as a choice, sadly.
3) Reliable. I can't be fixing my car all the time, especially since that's not a budgetable expense. Anything except new and certified used got invalidated here. I also rejected every American car brand here, which left the Japanese manufacturers.
4) Rims, not hubcaps. This is a dumb one, but seriously, I hate hubcaps.
5) Stylish. I had to be able to look at the car and not feel disgusted or embarassed. Scion got rejected with extreme prejudice. Volvo was disqualified as well.
I eventually decided that leasing a new car was the best way to go. I also figured that a compact sport hatchback was the best compromise. The remaining choices in that arena were:
1) Mazda3 and Mazdaspeed3
2) VW Rabbit/Golf/GTI
3) Audi A3
4) BMW 3 series wagon
5) Toyota Matrix
6) Honda Fit
The Honda Fit is boxy looking and woefully underpowered. The Matrix is strange looking, and underpowered as well -- Toyota discontinued the performance XRS model and the other two trims have no spine. The Audi and BMW are both way too expensive, not to mention boring looking and generally not worth the money. The Rabbit/Golf/GTI is also pretty boring, and far too small (two door instead of four). That leaves the Mazdas. I really wanted the Mazdaspeed 3, which is a performance tuned version of the regular 3. It was too expensive though, and demand is high enough that you can't even get a discount off sticker price. That's how I ended up settling on the Mazda3 hatchback.
That's only half the story. After having decided what car to buy, I needed to actually find and buy it. I can be pretty picky about colors; I originally wanted the red one and would settle for the blue, and that was it. I backed off later, especially upon discovering that the silver looks quite good in person. Both 2007 and 2008 models are out on dealer lots right now, and bizarrely the 2007s aren't any cheaper. (The 07 and 08 are identical, but an 07 is obviously worth less.) Then there's the huge headache of actually negotiating a price. Reading various articles, mainly on Edmunds, I realized that the trick here was to use the internet. The internet always wins, you see.
When salesmen sell a car, they get a commission off that sale. There's considerable incentive to jack up the price however they can. The internet sales departments, however, are more interested in sheer volume, and so they will happily give you the car at only a slight charge over invoice. The practical upshot of all this is as long as you're not too picky about things like the color of the car, or factory-only options like a sunroof, you can simply fire off requests for price quotes to half a dozen dealerships and cherry pick the one who makes you the happiest. Better yet, you can attempt to use the quoets to play dealers off each other. (We tried this, but it didn't work. Mazda3s are popular, so they don't really need to play that game.) You can completely skip the whole haggling and dueling process like this, and not only that, you're practically guaranteed a better price than you could get just by walking in.
So when it came time to actually buying the car, there was no fighting over price. We took some time to look at the three different actual cars that were available, in three different colors and with varying trim levels and options. There was some more time spent hacking out the details of the lease, and a whole bunch of waiting while insurance and credit were straightened out. It could have been much worse, though. I was really glad that the price had been set (and set at quite a favorable value) right from the start.
Anyway, maybe some of you will find that helpful. I especially suggest reading everything at Edmunds about buying cars, as they have a lot of useful information.
| |
| Wednesday, September 19, 2007 |
| Here In My Car | |
Posted - 9/19/2007 6:07:02 PM | Buying a car is a rather stressful experience, but I think it would've been much worse without the internet at hand. Once again, the internet triumphs over all. I'll talk all about it later.
Alternate titles for this entry included "Can Has Car?", "Zoom Zoom", and "I Got Three Stars On The Way Home".
Here In My Car
I feel safest of all
I can lock all my doors
It's the only way to live
In cars
So I finally have my car. It's a "Sunlight Silver" 2008 Mazda3 Hatchback, s Touring. I took some photos so you can see what it looks like. Here's me drifting in Tokyo:
And here's me drifting in Hong Kong:
And here's a photo I took on a foggy day in Cloud City on Bespin:
Now, I know some of you are going to whine, like "those cars aren't drifting", or "the license plates are different and illegal in each photo", or "Cloud City is a fictional place". Well, you can just keep that to yourself. I don't have to explain myself to you.
It has a 2.3L four cylinder engine that puts out 156 bhp and 150 lbf·ft. The engine is mated to a five speed automatic transmission that includes a manual paddle shifting mode. It's no racecar, but there's enough power under the hood to get it to 60 mph from standstill in 8.1 seconds using the manual mode. That figure is according to Car and Driver. It's a front wheel drive car, but torque steer isn't really an issue. It rides on 17 inch wheels, and I haven't checked what the stock tires are yet. The brakes in particular are quite aggressive. A new Corvette can stop from 70 mph in about 166 feet; this Mazda can do it in 168 feet. It also does the Edmunds slalom faster than a WRX STi (and with a hell of a lot less body roll, if you watch videos).
Physically, it's almost identical in width and length to a Subaru Impreza wagon, which makes it very much a compact car. The styling is really nice, although it took me a little while to appreciate its looks. It's much sharper and more aggressive than a Golf or really any other hatchback I can think of. The interior is amazing, as far as I'm concerned. The audio system sounds great, and has an auxiliary input, so my Zune connects in nicely. The steering wheel feels great in my hands, as does the shifter. And just look at the dash:
There's plenty of reviews out there that discuss more about the car, so go read them if you're interested. I suggest Edmunds and Car and Driver. All I can say is, they're right. Mazda (and Volvo, who were responsible for the safety equipment in this car) did an amazing job -- this car, in this price segment (I paid 19K USD and change), is nothing short of incredible.
| |
| Sunday, September 16, 2007 |
| What I'm Currently Studying | |
Posted - 9/16/2007 4:05:55 PM | It's not clear to me how many people know this, but I've decided to take an indeterminate amount of time (most likely 2 years) off of school and pursue career goals. There are any number of reasons, but they are not the subject of this entry.
I've accepted an offer with Day 1 Studios, near Baltimore. My understanding is that I'll be a junior developer on their next gen core tech. Sounds pretty awesome, and they're cool guys. I'm also getting a car, now that I have money and a job. Thank god. I've been waiting for months, desperately wanting a vehicle. I can't afford anything that good, but I think the final selection is quite nice. I am a car enthusiast, after all; I wasn't about to settle for a five year old Civic. Exactly what it is will be secret till I bring it home.
What I'm Currently Studying
Since I have a job now, I have a lot to catch up on. I believe that I am anywhere from one to two years out of date when it comes to graphics programming techniques, particularly shader techniques. I need to bring myself back up to date if I'm going to be doing next gen work. I'm also moving back to C++ outright. A little annoying perhaps, but necessary even for my hobby work. (Amongst other things, I need a new demo should job searching come up again.) This journal post is just to give an overview of what I'm going to be looking at over the coming months. It should serve as a useful guide for those of you who are interested in taking a similar job.
First, I wrote an article some time back discussing how to handle shader constants in an automatic way, using .NET 2.0. If you haven't seen it already, I recommend it; it's one of the best bits of work I've ever done. Now, I originally meant to do research on adding lazy evaluation and referenced (rather than locally contained) data to the implementation. With my change in focus, however, I currently have a new bit of work to do. You see, I believe that I can replicate this system in C++, with nearly identical usage for people using the code to handle shader constants. Not only that, the implementation will be mostly platform independent; all it will take to port is modifying two or three extremely small functions and probably looking up your platform docs for the bytecode to a NOP. The implementation will not share the elegant brilliance of the .NET version. In fact, it will be certifiable voodoo. However, it will work, and it will accomplish the same exact goals with similar maintenance effort once it's done. It will also be accessible to a much wider audience, notably the professional audience. I'm looking forward to that.
Second, I have some books to buy. Day 1 will reimburse half the price of any book I buy that is related to my work. With that in mind, I am going to buy all of the books in the Shader X and GPU Gems series, as well as a few other misc books in the same vein. (Game Programming Gems and AI Game Programming Wisdom are likely.) Over the coming months, my goal is to internalize all of the information contained in these books. Shouldn't be too hard; I figure a month per book is a good relaxed pace, and quicker on the older books and the Game Programming and AI series. By this time next year, I can easily be completely up to date at that point with everything that an experienced game/graphics programmer should know.
Third, there's lots of extra reading to do. I need to become comfortable with everything Tom Forsyth has written, ever. I'm also planning to take an extended trip into shadow mapping technology. My current estimate is that the shadow stuff is about 20 papers to read, most of which are useless techniques and therefore can be skimmed and ditched quickly. I also need to catch up on about 3 years of GDC and SIGGRAPH papers that are relevant to me, along with anything else ATI or NVIDIA have published in about the same timespan. I'm especially interested in ambient occlusion, spherical harmonics, and subsurface scattering.
Lastly -- and this is the daunting one -- I need to study GPU based RTRT and (conceptual?) integration with a traditional raster pipeline. And before you all get excited, no, I don't think real time ray tracing has any kind of future as a replacement for rasterization. That idea is absurd, although I'll reserve extended discussion of that matter for another time. However, a number of effects are very akward to rasterize, and I've been curious recently if we can borrow techniques or tricks from the RTRT community in order to solve certain problems. This is not a first; parallax mapping is a fairly good example of the whole idea, although it's a little different. I'm not sure where this will lead, or if it will lead anywhere at all. In any case, my value as a developer has always been the sheer breadth and diversity of my knowledge, and I've managed to use that to great effect in the past. I do honestly believe that I can make some progress here.
It should come as no surprise that I want to buy an E-ink PDF reader as soon as I can justify the expense and a model less silly than the Sony Reader appears. (Does it need 4 sets of controls to turn the page on it? Does it really?) There's lots to do, and all that while I'm doing actual next gen work. I don't mind, though. For one thing, I really enjoy this sort of thing. Second, right now I'm a junior developer at a game company, and that's just not good enough. It's passable for the moment, but I'm aiming much bigger than that. I'm 20 years old now, and have a year left in my degree which I'm deferring. The goal is to make tech director and buy a Vette by 25. Seems like a reasonable target to me.
| |
| Saturday, September 8, 2007 |
| Reinventing the Wheel | |
Posted - 9/8/2007 8:26:04 PM | Here's another entry that fell off the Obvious Train. Sorry guys.
Reinventing the Wheel
One of the more common sayings in programming is, "don't reinvent the wheel". For a lot of situations -- arguably the majority -- this is completely appropriate advice. However, every so often, it is in fact necessary to reinvent the wheel. The problem is, what kind of wheel are you going to turn out?
 
One of these wheels is a lot more sophisticated than the other. Just because a wheel needs to be reinvented doesn't mean you have any business doing the work. When this question comes up, most people's focal point is whether or not the wheel needs to be reinvented at all. Sometimes it does. But is the person who would be doing the reinvention actually sufficiently competent to make a nice wheel? The answer is rarely "yes".
Take STL containers. Are they always good enough? Of course not. They have certain goals in mind, and if those goals are not similar to your own goals, they may be very inappropriate for you. But if you decide to reinvent those containers, there's a very real danger that you'll do such a poor job that you were better off with the prewritten version. You don't need to be "better" than the people who wrote the standard library, but you do need to be good enough to meet your goals more effectively than those containers can. That's not always easy, and many of the people who are convinced they must do so are exactly the people who have no business doing it.
So how do you know if you're competent enough to make a better or more appropriate wheel? If you need to ask, the answer is no. If you're looking to create your own quality wheel, it follows that you know a thing or two about wheels. That familiarity with wheels should already give you the ability to judge if you can make a better one. If not, you simply can't. (I'm ignoring the situation where the original wheel was done by a completely incompetent moron, which happens.) So to those of you who want to know if the standard library (regardless of language or platform) is good enough, the answer is yes, it is. Now it's probably a very good experience to make a few wheels yourself anyway. They'll come out crappy, but that's how you learn. But don't for a second think that you can jump right in and create a better one.
Oh, and one last comment to those of you who design wheels. Please don't screw it up, like on the Civic Hybrid:
It makes it a lot harder on us when we have to explain why people shouldn't do their own wheels.
| |
|
| S | M | T | W | T | F | S | | | | | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9 | 10 | 11 | 12 | 13 | 14 | 15 | | 17 | 18 | | 20 | | 22 | 23 | 24 | 25 | | 27 | | 29 | 30 | | | | | | |
OPTIONS
Track this Journal
ARCHIVES
October, 2009
September, 2009
August, 2009
July, 2009
June, 2009
October, 2008
June, 2008
May, 2008
April, 2008
March, 2008
February, 2008
January, 2008
December, 2007
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
February, 2007
|
