dwilliamson

// Marching Cubes Edge/Triangle LUT Generator

// From Transvoxel paper http://transvoxel.org/Lengyel-VoxelTerrain.pdf
// We have ambiguous case when a cube has an ambiguous face
// An ambiguous face has two diagonally opposing corners that are inside and the other two are outside
// This can be tesellated two different ways and when you place this face up against another cube, can introduce holes
// In Lengyel's paper, his ambiguous cases are 2, 6, 7, 8,  9, and 10.
// These map to cases                          3, 7, 8, 12, 10 and 13
// Key observation is that in MC ambiguous cases always arise due to the inclusion of the inverses

dwilliamson

//
// Lookup Tables for Transvoxel's Modified Marching Cubes
//
// Unlike the original paper (Marching Cubes: A High Resolution 3D Surface Construction Algorithm), these tables guarantee
// a closed mesh "whose connected components are continuous and free of holes."
//
// Rotations are prioritised over inversions so that 3 of the 6 cases containing ambiguous faces are never added. 3 extra
// cases are added as a post-process, overriding inverses through custom-build rotations to eliminate the rest.
//
// Uses the exact same co-ordinate system as https://gist.github.com/dwilliamson/c041e3454a713e58baf6e4f8e5fffecd

dwilliamson

//
// Lookup Tables for Marching Cubes
//
// These tables differ from the original paper (Marching Cubes: A High Resolution 3D Surface Construction Algorithm)
//
// The co-ordinate system has the more convenient properties:
//
//    i = cube index [0, 7]
//    x = (i & 1) >> 0
//    y = (i & 2) >> 1

dwilliamson

Documenting a tiny fraction of the Character Physics/Locomotion/Animation of Advent Shadow for PSP (2004).

The first thing I will say before I start this is; if you can get hold of a guy that can both code and animate stick them in the guts of the implementation and you'll get something that surpasses anything a paired programmer/animator can achieve. Have them responsible for implementing rough first-pass animations and writing the code that drives the animation engine. They might be responsible for final animations here and there, it really depends on your setup. However as far as the code goes, keep them purely on the gameplay side and away from the core technology - you don't want to over-burden them. If you have to use a separate programmer/animator, these guys have to be good. This is not easy stuff and both guys need to be artistic - if you have a programmer who looks at a bunch of moves to implement as a tasklist to be ticked off whenever something is in the game, that's not good enough. The sam

dwilliamson

#pragma once


// This allows windows.h to be included first, overriding this header file, but be careful
// not to do this everywhere as compile-times suffer.
#ifndef _WINDOWS_


#define _WIN32_WINNT 0x0601 // _WIN32_WINNT_WIN7

dwilliamson

#include <TinyCRT/TinyCRT.h>
#include <TinyCRT/TinyWindows.h>

namespace
{
    constexpr uint64_t time100NSecsPerSec = 10000000;

    uint64_t FileTimeToU64(FILETIME ft)
    {

dwilliamson

// -------------------------------------------------------------------------------------------------------------------------------
// Opaque Object Containers: Provide RAII/Move semantics for opaque pointers.
// -------------------------------------------------------------------------------------------------------------------------------

// Opaque handles must implement the commented out types/functions
template <typename Type>
struct ctrOpaqueTypeTraits
{
    // using Type = OpaqueType;
    // static constexpr auto New = Type_New;

dwilliamson

uint32_t NextPow2(uint32_t v)
{
    v--;
    v |= (v >> 1);
    v |= (v >> 2);
    v |= (v >> 4);
    v |= (v >> 8);
    v |= (v >> 16);
    v++;

dwilliamson

DerivePointerAlignment: false
PointerAlignment: Left

dwilliamson

template <typename Type>
struct uptr
{
    uptr() = default;

    uptr(Type* ptr)
        : ptr(ptr)
    {
    }