TODO

DONE:
- link with generated cpp files output
- convert minimal demo to use new network layer
- get basic singleplayer demo working
- get anti-aliasing working
- convert to sublime edit
- convert into "shared", "client", "server" directories for code (a good way to split...)
- don't include "client" headers/libs into shared (!!)
- add "lib" target to network makefile
- link to network lib
- make sure network lib gets built
- add to git
- capture uncompressed TGA images
- capture compressed TGA images
- record input to some binary format (append struct to file...)
- "make video" plays back recorded output, disables VSYNC and outputs TGA files
- process the TGA files into a video
- switch screen resolution to 1280x720 (this is the resolution of the screens at GDC...)
- record video at this resolution and see how it looks in keynote
- raw MOV file playing back in keynote is jittery (presumably IO bound)
- exports from quicktime pro 7 are low resolution and export @ 30Hz =p
- exporting 1280*800 and converting to m4v via hand brake gives good results
- change demo to output exactly at 1280x720 letterboxed (black above/below)
- write TGA files at 1280x720 resolution skipping past first 40 lines
- verify exact fit in keynote post handbrake
- ndl headers should be generated separately for the dep to precompiled
- this will fix the problem with network library getting built on clean =p
- there are problems with dependency checking that are annoying
- adjust the lockstep demo so that input to the second simulation goes in to a queue
- variable number of frames to hold in the queue before releasing
- 1,2,3,4,5,6 changes number of frames the second simulation is behind
- need to be able to dynamically adjust ahead/behind as well!
- get the non-deterministic mode working again
- get interpolation/extrapolation demo back
- point sampling demo
- linear interpolation demo
- extrapolation demo
- need to get the authority red color solid in interpolation demo
- render should be a global object passed TO the demo, not owned by
- letterboxing should be applied post render by demo.cpp
- clear display should respect letterboxing on switching demos

TODO:
- show prioritized updates (slow down into slow motion and flash as each cube is updated)
- demonstrate quantization jitter (both for position + 0.5f, and for quaternion using shit technique 8.8.8.8) ==> quantize on both sides
- perhaps instead of splitscreen, we could show the cubes overlaid (ghosted) to show the diff

DEMO VISUALS:
1. singleplayer demo (done)
2. deterministic lockstep: synced via input but drifts into error (done)
3. deterministic lockstep: in sync and delayed by 1.5 secs (done)
4. interpolation: point sampling (done)
5. interpolation: linear interpolation (done)
6. interpolation: linear extrapolation, ballistic extrapolation (done)
7. push/pull: highlight prioritized sends with flash (done)

PLANNING:

1. show demo, explain how it works. one million cubes. activation etc. blow. katarami.
2. send input across. describe input. sent across in packets. every packet arrives. lockstep discussion.
3. goes out of sync... --> slightly different delta times --> floating point determinism discussion.
4. interpolation --> describe packet, object ids. interpolation. linear error, additional latency, etc.
5. extrapolation --> poor prediction. eventually, would rewrite an approximation of the sim in the remote view.
6. run simulation on both sides ---> prioritization. push/pull/serialize. *smoothing*, error reduction.
7. serialize function, bit packer etc.
8. low hanging fruit. object id, reduce to n bits. be smart about local player cube (always first cube), saves 2 bytes per-packet.
9. at rest optimization. 1 bit at rest. if at rest, assume zero lin/ang vel. (subtle point: at rest flag is synced hard)
10. quaternion optimization: smallest 3. compare with naive 8.8.8.8 (show drift)
11. position compression. store nearest 1m quantize. encode xz positions relative to origin. bound z in range
12. quantize on both sides. gives best quality extrapolation and alerts you when something is going wrong.
13. bound and quantize linear and angular velocity.
14. show that we can now be within 64kbit/sec bounds. now switch to optimizing # of objects per-packet
15. prioritization. higher priority for red objects (moving)
16. reliability system. confirm position of at rest objects. don't send them. if moved (red), unconfirm them.
17. frequency optimizations: apply to position z, mostly in this range, sometimes above. very application specific
18. linear velocity. split apart linear velocity into a direction (unit) and a size -- encode size with variable bits (manual huffman)
19. angular velocity. same treatment. combine lin/ang velocity for "slow moving" objects
20. delta encoding. we have a reliability system, try a different strategy -- what about encoding objects relative to prior
    position?

HOUSEKEEPING:
- need to fix the at rest problem! make it so that objects have some minimum force before they will
  come back from rest. this probably means i need to get the amount of force applied to an at rest
  object from the solver somehow? how to do this?
- get tests working again (ideally, link network tests in with engine tests and run in one go...)
- find a way to get truetype font rendering to textures working
- identify cool libraries used by "Carbon Studios" and see if any of them
  can be used in my project, eg. hashing functions (MD5) would be cool for det check.
- add hash query functions to game, simulation, activation system etc. hash the entire state and verify
  that the game is deterministic on playback. recording inputs and save the hashes. compare hashes on frames
  during playback to verify deterministic.

cool things to share:
- how objects are identified over the network (object id)
- how serialization function, variable encoding for data
- smallest three quaternion compression
- priority bubbling up
- unit vector compression technique (need to recover source code!)
- want to explore delta encoding, eg. encoding relative to previous position
  (this is the *ultimate* encoding for reducing position/orientation bw...)
- bandwidth stats from sony to justify 64kbit/sec
- explain how packet header overhead works, how much payload etc.
- fake a lag switch to induce packet loss and show how it behaves (show recovering in pieces, lerps etc.)
- want to explain that when i push an object if it is at rest, i force it to be at rest. don't want to "disturb" other objects
  or have a desynced at rest state between machines. hand coded at rest update.
- latency cost for interpolation
- problems with packet loss => extrapolation

key points:
- i want to record video for the talk instead of running a live demo = less stress, better presentation post-GDC
- do not talk about something if there is not a cool video or visual diagram to explain it
- the entire talk must be visual
- source code examples can come from sublime edit 2

side points:
- interpolation works great for motion that has high jerk. eg. player motion,
  because you cannot really predict something when it depends entirely on user input (FPS)
  valve games use interpolation exclusively. cost is added 100ms latency
- if you have a racing game, extrapolating linearly (dead reckoning) works well, because car
  motion is predictable, you cannot stop on a dime
- for a tumbling rotating ridid body, motion is a function of input, but changes slowly, like
  a car, extrap using physics sim is best bet. linear extrap or ballistic is poor.

ideas:
- if cubes are pushed below the cube then they can be destroyed/removed/eaten, especially if you land on them *splat*
- idea: resolve problematic cases where the small cubes look bad by removing them
- holding Z+SPACE = slide mode (pull towards ground, slide out like a hockey puck, but with some friction...)
- space while in a large katamari ball = explosion
- implement super-slowmo pause and unpause. this would be particularly good for showing diagrams over the video
  (vs. just hard pausing in and showing diagrams...)
- get better visual quality by writing a pixel shader (per-pixel lighting will look less flat)
- fix the at rest jitter by requiring a certain force threshold to wake an object from rest (if white)
- integrate FMOD and get some sounds going, increase the pitch of the sounds the longer the cube grows
- try to approxmimate ambient self-occulision while in the katamari to get better lighting
- highlight recently acquired red cubes with some "blip" highlight color
- experiment with different colors. i particularly like the contrast of sky blue, white and yellow.
- the only thing stopping me from using other shapes is my silhouette code which is specific
  to cubes. if the silhoutte code was rewritten using a vertex shader (extrude degenerate)
  then I could easy support other shapes like cylinders, spheres, trimesh etc...