Thursday, August 14, 2014

Fixed Timestep with Interpolation

I'm kind of glad to see someone else has come up with the exact same solution I have for my game engine's time step.

Daniel Borgman:  Fixed Time Step With Interpolation

To quickly sum up how you would do fixed time step with interpolation:
  1. You determine how many times you want your logic to run per second.
  2. Use an accumulator (time bank) to save how much time has passed.
  3. Run your logic when you have enough time saved up to make a withdraw.
  4. Keep running the logic over and over until you can't make a withdraw anymore.
  5. Run your rendering code every time you get a chance but pass in a delta of the time elapsed since you last ran your logic code, and interpolate your graphics with the delta.
The downside with fixed time step & interpolation is that your graphics are always going to be delayed, but all of your animations will be as smooth as the fps.

You can decide to only render after a set of updates has happened, but this will result in a more 'choppy' fps. 

Another article that goes into more detail about fixed time steps:

Tuesday, May 13, 2014

Current State of Compiling an IOS App on Windows

After spending all my free time researching yesterday.

  1. I've determined that its you can at the moment: compile a IOS app and sign the IPA on a windows computer.
  2. It also seems like its possible to have autocomplete and obj-c syntax highlighting using Codelite (or VIM, if you're into that...) though I'm not entirely sure how well it mixes with the toolchain since that uses Cygwin.  (Perhaps you can write a plugin for Xamarin?)
  3. And remote debugging is possible but difficult to set up. That is, if you want break points. If you don't need breakpoints, you can use:

Sunday, May 4, 2014

Making Your Code Object Oriented

self.categoryLabel.backgroundColor = [self.schoolSubject colorForBackground];
self.categoryLabel.textColor = [self.schoolSubject colorForText];

//Object Oriented based programming
[self.schoolSubject customizeLabel:self.categoryLabel];

This is just a simple example of treating your classes less like data and more like objects. You always want to tell your object to *do* stuff.

In the above example, what I want to do is customize a label based on the model. Sooner or later, specs and designs change. Maybe I only want to set the background color. Using the first 2 lines in the above example, you will have to change each place where it is used. If we used the last line, we would only have to change the code in one place.

Now, this is great and all, but one danger you want to avoid is over architecting. If I only used the above code in 1 part of the entire app/game then the first 2 lines would be perfectly fine.  (The last line wouldn't be considered bad either in this example.) However, I used that code in about 5 other places that I forgot about and which resulted in inconsistencies throughout the app.

One of the most important things to being a fast and productive programming is making sure your code is DRY (don't repeat yourself). This is just one small way to do that.