In short: go component-based. Narrower interfaces, more orthogonality, easy to change behavior at runtime.
evidence:
In short: go component-based. Narrower interfaces, more orthogonality, easy to change behavior at runtime.
evidence:
http://blog.zincroe.com/2009/05/how-to-add-box2d-to-an-iphone-xcode-project/
Get that error while calling DataContext.SubmitChanges()?
That’s because the SET clause of the generated SQL statement for the update is empty, like this:
UPDATE [dbo].[Food] SET WHERE ([id] = @p0) AND ([Name] = @p1) AND ([Kcal] = @p2) AND ([Carbs] = @p3) AND ([Fat] = @p4) AND ([Protein] = @p5) AND ([Creator] = @p6) -- @p0: Input Int (Size = 0; Prec = 0; Scale = 0) [205] -- @p1: Input NVarChar (Size = 20; Prec = 0; Scale = 0) [UR Fettes Schnitzale] -- @p2: Input Int (Size = 0; Prec = 0; Scale = 0) [600] -- @p3: Input Float (Size = 0; Prec = 0; Scale = 0) [40] -- @p4: Input Float (Size = 0; Prec = 0; Scale = 0) [99] -- @p5: Input Float (Size = 0; Prec = 0; Scale = 0) [0,150000005960464] -- @p6: Input Int (Size = 0; Prec = 0; Scale = 0) [240]
And that’s because… Linq2Sql’s DataContext’s entity identity tracking gets very confused when you override GetHashcode() and Equals() methods in your Entity Classes. Seriously. <sarcasm>But why would you want to do that anyway?</sarcasm>
Quoting from here:
“… the combination of GetHashCode() + Equals() forms the entity’s concept of identity. If you make it based on field values (other than PK) then the identity changes as you change the fields. This is bad if L2S must lookup other info in a dictionary based on the entity’s identity, and especially if L2S needs to find an entity in its identity cache!
Advice: don’t change the identity of an entity. L2S expects it to be based on the object’s natural (address based) identity.“
In Java or .NET, if you override equals(), you also have to override GetHashCode(). The rules:
1) if two objects are equal, their hashcodes must be equal too.
2) if two objects have the same hashcode, they need not be equal (since it could just be an accidental hashcode-collision)
3) If the object in question is ever to be used in hash container, it must not change its hashcode during its lifetime. If it does change its hashcode, e.g. after having been added to a hashed collection, it could never be found again since the hash container would look in the wrong bin! And yes, this conflicts with 1) and 2) above – even microsoft didn’t get this right in every place of the .net framework. You can even get away with a sloppy implementation that doesn’t take these rules into account, if you won’t ever use hash containers.
The safest way to go is to make all fields which contribute to hash code calculation immutable .Or make the entire object immutable (which has many more benefits, automatic thread-safety and better sharing of objects among them)
For further info:
http://stackoverflow.com/questions/462451/gethashcode-guidelines-in-c
Aside from Remote Desktop-ing into the VM, you can enjoy resolutions beyond 1600×1200 by getting the Virtual PC 2007 hotfix pack:
This took me an embarassingly long time to find out:
If you’re looking for an example on how to use it, here you go:
http://d.hatena.ne.jp/nakamura001/20081208/1228729579
It doesn’t work in the simulator, in a very silent way, i.e. I got no warning, no error, nothing, just no texture was drawn.
Also:
So it’s not an option for me, it would have been a nice way to increase drawing performance though I guess.
Last night I looked for some cheap performance improvements in OGL ES, and after stumbling over this article I was expecting a quick win… Turns out it took me about 2 FULL HOURS to google the correct way to change the pixel format. I use Xcode’s OpenGL ES Program Template, but it works the same for everything OGL ES1.1 on iPhone. Having it taken me that much precious time, I figured I’d write it down for myself and maybe for others with the same problem:
Set the drawableProperties property of your CAEAGLLayer instance like this:
eaglLayer.drawableProperties = [NSDictionary dictionaryWithObjectsAndKeys:
[NSNumber numberWithBool:NO], kEAGLDrawablePropertyRetainedBacking, kEAGLColorFormatRGBA8, kEAGLDrawablePropertyColorFormat, nil];
This sets the default format of RGBA8. As of now you seem to have only one other choice: kEAGLColorFormatRGB565
And that means 16bit color depth and omitting the alpha channel. As I understand it, that breaks Alpha Blending, so it may not be a viable option for everyone… It wasn’t for me because I do massive blending with the alpha channel for my sprite engine. Maybe you could make it work using Alpha Testing, although excessive use of alpha testing seems to be discouraged by PowerVR people and some developers for performance reasons.