gfxgangsta

Overall, I would say there is no level of knowledge *required*. You might even learn something new. (i.e. I got started with Unity at a jam). But I think it's important to communicate this to potential teammates. Usually there's a bit of mingling that happens during the first 30-60 minutes of a jam, and you can use that time to find a team in which you fit in.

I really like the idea of a monthly theme.

 

+1 on ByteTroll's request for topics like advanced rendering techniques... sometimes these are covered in different forum posts, but it would be great to see articles.

 

Other theme ideas:

 

-experimental gameplay

-native code for mobile

-a specific OS

-build systems (assets/data/code)

-use of scripting languages

-script language compiler implementation

-scripting integration with game engines

-making a game in a tool not meant for games (like Excel or Powerpoint)

-monetization

-"three-chord song" (many musicians write songs that just use different combinations of the same three chords.. perhaps three simple mechanics could be mixed and matched to make a great game that seems complex, but is really made up of just those three basic elements)

-animation (UV, vertex, skeletal,etc)

-texturing (programmers could chime in with procedural texture generation or articles about packing textures into an atlas)

-specific game genres (racing, shooters, etc)

-postmortem month (what went right/wrong/etc during someone's project)

-hardware (something you tried with Sifteo Cubes or Oculus Rift)

-motion control (gameplay opportunities, filtering motion input, etc)

Do you think it is possible to write an entire android app with either C or C++ (with the exception of the lines required to initialise your native code.

I'm not sure how mature the NDK is at this point (how many features it supports), but you can already implement your Activity class, access sensors and do rendering in native code.

Here's a blog post that shows how to implement a basic native Activity: http://www.altdevblogaday.com/2012/02/28/running-native-code-on-android-part-2/

What problems do you think someone would come across?

Unsupported features, losing access to a useful set of Java UI elements, possibility of getting into trouble with native memory management, etc

Are there any apps that somewhat bizarrely use this approach?

I bet there are a few utility/enterprise apps that use the NDK, but I've only seen games use it.

Is there really any speed benefit? (I would normally expect there to be but apparently there are some weird quirks with how "native" code runs on android)

I would love to measure this at some point. Some algorithms probably benefit more than others. I think there is a speed increase, but it may not be huge. A big reason why people use the NDK is ease of porting (not having to translate to Java from C/C++).

Wouldn't you lose support for x86 and MIPS handsets?

You would have to make separate builds for those architectures. The NDK documentation (http://developer.android.com/tools/sdk/ndk/index.html) mentions x86 and mips are supported (but for API level 9 and greater):

"Removed arch-x86 and arch-mips headers from platforms/android-[3,4,5,8]. Those headers were incomplete, since both X86 and MIPS ABIs are only supported at API 9 or higher."


Also, from http://stackoverflow.com/questions/5089783/producing-optimised-ndk-code-for-multiple-architectures :
It looks like if you specify "APP_ABI := all", it builds for all architectures (NDK7 or greater).

This is an Android.mk makefile taken from the NATIVE_ACTIVITY.HTML help doc:

8/ Create an Android.mk file in the jni/ directory of your project to describe your native module
to the build system. An Android.mk file is essentially a snippet of a GNU Make file. For
example:

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := my_native_module
LOCAL_SRC_FILES := my_native_code.c
include $(BUILD_SHARED_LIBRARY)


To add more .c or .cpp files, you can add them to the LOCAL_SRC_FILES section like so:

LOCAL_SRC_FILES := my_native_code.c my_native_code_2.c my_native_code_3.c my_native_code_N.c


OR like so:

LOCAL_SRC_FILES := my_native_code.c \
my_native_code_2.c \
my_native_code_3.c \
my_native_code_N.c




There's also the "wildcard" keyword so you can avoid listing all the files manually:

http://stackoverflow.com/questions/8350878/using-makes-wildcard-function-in-android-mk


Hope this helps!

Your problem is this line:

if (d3d = NULL)

...

it's assigning your d3d pointer to NULL, instead of comparing... what you want is :

if (d3d == NULL)

...

Can you post the code for directionalLightEffect and combineFinalEffect?

And as for "but I believe things which are within the 0.0 to 1.0 range don't have to be normalized, since that's basically what normalizing does"...


Normalizing causes a vector to become unit length. Even if the individual XYZ are in the 0.0 to 1.0 range, that doesn't mean the vector's length == 1.

I assume the QuadRenderer works correctly. Shouldn't the light direction vector be normalized?

I found the following resource particularly useful, but you would have to convert to OpenGL and use shaders:

http://www.riemers.net/eng/Tutorials/XNA/Csharp/Series4/The_water_technique.php

The explanation is pretty good though