ttvd

The <float> rule matches a floating-point constant consisting of an
    integer part, a decimal point, a fraction part, an "e" or "E", and an
    optionally signed integer exponent.  The integer and fraction parts both
    consist of a sequence of one or more digits ("0" through "9").  Either the
    integer part or the fraction parts (not both) may be missing; either the
    decimal point or the "e" (or "E") and the exponent (not both) may be
    missing.  Most grammar rules that allow floating-point values also allow
    integers matching the <int> rule.

Apple ARB compiler will reject 1.E+05 even though this seems valid judging from above description?

ttvd

I hope I'm going to be able to describe what we do there - it's really no magic 
involved - we just wanted something simple.

The decision tree is quite simple structure - leaf nodes are individual 
drawparts (drawpart is a structure that contains vertex array, index array, 
shader, matrices, constants... - the minimum data to render something without 
any higher logic required) and non-leaf nodes pretty much contain 
rules/conditions determining what child node to pick - since we don't want 
to have any virtual calls there, we only have predefined set of conditions 
such as LOD node (based on distance from camera), "switch" node 

ttvd

#define OBJC_NEW_PROPERTIES 1
#define _LP64 1
#define __APPLE_CC__ 6000
#define __APPLE__ 1
#define __ATOMIC_ACQUIRE 2
#define __ATOMIC_ACQ_REL 4
#define __ATOMIC_CONSUME 1
#define __ATOMIC_RELAXED 0
#define __ATOMIC_RELEASE 3
#define __ATOMIC_SEQ_CST 5

ttvd

#define __DBL_MIN_EXP__ (-1021)
#define __pentiumpro__ 1
#define __FLT_MIN__ 1.17549435e-38F
#define __CHAR_BIT__ 8
#define __WCHAR_MAX__ 2147483647
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1

ttvd

Keybase proof

I hereby claim:

• I am ttvd on github.
• I am ttvd (https://keybase.io/ttvd) on keybase.
• I have a public key whose fingerprint is 6AAE 1296 BDE2 797F A278 A2FB F677 B63D E466 628A

To claim this, I am signing this object:

ttvd

defp endianness() when <<1::integer-little-size(4)-unit(8)>> == <<1::integer-native-size(4)-unit(8)>>, do: :endianness_little
defp endianness(), do: :endianness_big

ttvd

ZORG.dylib:
	ZORG.dylib (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 21.0.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
	
	
	install_name_tool -delete_rpath ZORG.dylib ZORG.dylib 
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: 

ttvd

Keybase proof

I hereby claim:

• I am ttvd on github.
• I am ttvd (https://keybase.io/ttvd) on keybase.
• I have a public key whose fingerprint is 09FB 7CFF 4BE3 30E7 A1FC 8692 8277 7B8D 8092 06D5

To claim this, I am signing this object:

ttvd

Core Coding Standard

Coding practices are a source of a lot of arguments among programmers. Coding standards, to some degree, help us to put certain questions to bed and resolve stylistic debates. No coding standard makes everyone happy. (And even their existence is sure to make some unhappy.) What follows are the standards we put together on the Core team, which have become the general coding standard for all programming teams on new code development. We’ve tried to balance the need for creating a common, recognizable and readable code base with not unduly burdening the programmer with minor code formatting concerns.

Table Of Contents

• Why we need Coding Standards
• Context is Important
• Stylistic Standards

• Namespaces

ttvd

Howdy! 

I wrote Red Faction''s Geomod engine...

It does a complete realtime subtractive boolean from the world Geometry. The "hole" that is cut out is a loaded mesh that gets randomly rotated to look different everytime. It could be any shape, we just liked how this one worked. It operates on a face basis, splitting some, deleting some, and adding in new ones. The input is a polygon mesh; the output is a polygon mesh.

The math to to the boolean takes place spread out over a few frames so that it doesn''t impact framerate much.

All of out structures in the game are dynamic to handle this... the code to actually make the whole is only a minor part of the problem. For instance, our AI paths can update to reflect the hole, the rooms and portals update so a hole between two rooms is now a portal, and the collision detection structures for the world use recursive AABB, which get dynamically updated during the Geomod. Even things like slapping bullet decals on the new faces and making sure to remove decals on fa