Naked pointers in high-level code are just another code smell that often, but not always, indicate that the Dependency Inversion Principle is being violated.

http://en.wikipedia.org/wiki/Dependency_inversion_principle

Today I learned something new! Thanks for that.

This is a long shot, but here goes. I recently dug up an ancient gm6 project of mine from--get this--December 31, 2005 through January 1, 2006. Yes, that's how I spent that New Year's eve.

The "game" is actually a soundboard and contains a bunch of soundbites from one of my favorite movies, painstakingly recorded with fancy sndrec32 technology. I've long since lost the original wav files, but the audio is embedded somehow in game.gb1, game.gm6, and game.exe (which, incidentally, no longer runs, but I recall being able to before I ditched Vista).

So, is there any tool or procedure that'll let me rescue all those nuggets of dialogue? I suspect not, but it never hurts to ask

I try to use cutesy wordplay or portmanteaus (e.g. chroma + math + thud = chromathud), but I typically use Muz's word association to get there.

It sounds like your fighting game runs the gamut of potential styles.

Fight + Gamut.

Go!

Not JS, but here's what I did in Chromathud, FWIW:
https://github.com/Cheezmeister/Chromathud/blob/master/Chromathud/Chromathud/Gameplay/Field.cs#L396

Basic idea is to have a N+1'th hidden row that shifts upward when it becomes visible. Horizontal collapsing I can't really speak to, but gut feeling agrees with other comments, i.e. your life will be easier if you treat columns as first-class citizens, because they (unlike rows) always stick together.

jgrams nailed it. tl;dr, the problem is that your thrust is in a different direction from your velocity, but you were adding them together as scalars. But if a bug leads to better gameplay mechanics, it's not really a bug at all, is it?

Man, I'm tweaking my dotfiles. It's the coder equivalent to masturbation, I need to get in gear already.

Just you wait until the big one tells the little one to `#define C 0` because it "makes stuff faster", stifling chortles all the while. Then we'll see who goes C->razy.

I've only mucked with "boring" ADK GUI apps so I can't speak to libGDX etc. but my experience has been, the API and tools were once solid and well-designed, but they have not aged well. At all. Token backwards compatibility has led to a mess of abandoned APIs, half-baked ideas and "deprecated" features that actually just won't work for half your customers. Linux has shitty drivers, and Windows has shitty CLI and automation support (through no fault of the ADK, but there are some things you can't do outside of CLI). I *frequently* spend an entire day cursing at ADB trying to connect to a real device. Sometimes it just decides to stop working and I need to re-scour the internet for clues on getting my specific setup to work. Eclipse is great at making Java suck less, but it's still Java.

My brief fling with Win Phone dev was more of the same, different flavor. XML nested 10 levels deep with wack-ass names 40 characters long. I hear iOS dev is more pleasant, but I'm not touching that with a 10 foot pole.

I think the NDK is where it's at. All that glue code terrifies me, though.

Thus commences day 2: a day full of infinite possibilities and ultimate intrigue. If you see a shy-looking fool in yellow pants, say hi so I don't have to! I don't bite, I'll probably just yawn at you.

Yeah the IGDA parties are generally pretty tame, but (IME) that means it's easier to start/maintain a conversation, so it all depends on how you want to balance your networking with your fun.

If you <3 music and/or just want to party your face off, the DNA Lounge is stellar. The lineup looks a little sparse this year, but if nothing else there's Virt.

Has anyone heard of jams happening outside of the indie hostel?

It turns out this part involves zero effort as well. I was expecting to throw down a few dozen lines of handwritten JS to call into my setup and update routines (in which case I'd also compile int main() out of the build so that it wouldn't get in the way), but even that wasn't necessary, as the framework provides a hook that'll call your main update routine for you.

https://github.com/kripken/emscripten/wiki/Emscripten-browser-environment#implementing-an-asynchronous-main-loop-in-cc

The only sort-of downside to this is that you're limited to a void (*)(), i.e. your function can't take any arguments or return anything. Hardly the end of the world, but it did force me to define a wrapper that just discards the result of the real update(). Sometimes I do miss lambdas.

Code:

#ifdef EMSCRIPTEN
        emscripten_set_main_loop(js_update, FPS, false);
        return NORMAL_EXIT; // Yield control to the browser
#endif
Uint32 nextFrame = SDL_GetTicks() + 1000 / FPS;
for (;;)
{
if ((result = update()) != NO_EXIT) break;

int pauseSecs = nextFrame - SDL_GetTicks();
if (pauseSecs > 0)
{
cdebug << "Waiting " << pauseSecs << " ms...\n";
SDL_Delay(pauseSecs);
}
nextFrame += 1000 / FPS;
} // end main loop

And that's all there is to it! Check out the result at http://cheez.lt3.us .

Meanwhile, time to screw around with PhoneGap and see if I can squeeze > 5FPS out of this thing. Tata

[Getting Started]

Today was a fun day. I decided to give [emscripten](https://en.wikipedia.org/wiki/Emscripten) a go, and got a taste of the particularly potent trio of CMake, SDL, and emscripten. These tools are quite powerful in their own right, but they're also not too fancy to play nice together, and when they do, the results are pretty encouraging. I thought I'd share my experience, and a couple of the (minor) obstacles that popped up. Hoping you find this useful and/or informative


Getting Started

Bootstrapping is pretty simple, following the instructions [here](https://github.com/kripken/emscripten/wiki/Tutorial). Emscripten isn't the easiest tool ever to get rolling, but it's darn close. It's a bit immature to deploy in a single command...no aptitude, pacman or yum here Instead you're going to grab the latest from github, along with its main dependencies--python, clang, and nodejs, which SHOULD live in your package manager of choice.

Run `./emcc` once to configure paths. This is mostly automatic, but you may need to intervene if it can't find something.

Run `./emcc` again to verify the paths you set up. I tried to sneak by without installing nodejs and was duly reprimanded at this step. Once this is done, we're ready to go.

Using Emscripten

I built a couple of the test files as advised, and all seemed to work well. `emcc` claims to be a "drop-in replacement" for `gcc`, which is quite a bold statement, but I couldn't prove it wrong, and I have little interest in trying. Building single files really is as simple as `emcc hello.cpp -o hello.js`. You'll get a huge, honkin' output file (understandably so), which you can then run locally with something like `node hello.js`.

After I got past my initial excitement at the ease of use, I felt a chill run down my spine. What happens when we graduate to larger projects with several source files? JS doesn't have any concept of linking, so surely things are about to get ugly.

Fortunately, not the case. In fact, they've got it all figured out - https://github.com/kripken/emscripten/wiki/Building-Projects


There's surprisingly little magic that goes on here. The tools are just python wrappers around shell commands. For example, the following is what powers `emmake`, where args is the command line you pass in:

Code:

    681   def make(args, stdout=None, stderr=None, env=None):                                                             
    682     if env is None:                                                                                               
    683       env = Building.get_building_env()                                                                           
    684     if not args:                                                                                                 
    685       print >> sys.stderr, 'Error: Executable to run not specified.'                                             
    686       sys.exit(1)                                                                                                 
    687     #args += ['VERBOSE=1']                                                                                       
    688     try:                                                                                                         
    689       process = Popen(args, stdout=stdout, stderr=stderr, env=env)                                               
    690       process.communicate()                                                                                       
    691     except Exception, e:                                                                                         
    692       print >> sys.stderr, 'Error: Exception thrown when invoking Popen in make with args: "%s"!' % ' '.join(args)
    693       raise                                                                                                       
    694     if process.returncode is not 0:                                                                               
    695       raise subprocess.CalledProcessError(cmd=args, returncode=process.returncode)                               

Firing Things Up

Not only can you use your existing Makefile, you can likely use your existing Makefile *generator*. For me, this is CMake, so my first attempt looked like this

Code:

    bobvi% emconfigure 'cmake ..'
    Error: Exception thrown when invoking Popen in configure with args: "cmake .. -DCMAKE_TOOLCHAIN_FILE=/tmp/tmpsYw1ki.cmaketoolchain.txt"!
    Traceback (most recent call last):
    File "/home/cheezmeister/stuff/code/python/emscripten/emconfigure", line 24, in <module>
    shared.Building.configure(sys.argv[1:])
    File "/home/cheezmeister/stuff/code/python/emscripten/tools/shared.py", line 671, in configure
    process = Popen(args, stdout=stdout, stderr=stderr, env=env)
    File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
    errread, errwrite)
    File "/usr/lib/python2.7/subprocess.py", line 1308, in _execute_child
    raise child_exception_
    OSError: [Errno 2] No such file or directory
    bobvi%

Oh no! emmake doesn't process the command line you give it, so zsh wound up choking on those single quotes. Let's try again.

Code:

    bobvi% emconfigure cmake ..
    -- The C compiler identification is Clang 3.2.0
    -- The CXX compiler identification is Clang 3.2.0
    -- Check for working C compiler: /home/cheezmeister/stuff/code/python/emscripten//emcc
    -- Check for working C compiler: /home/cheezmeister/stuff/code/python/emscripten//emcc -- works
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Check for working CXX compiler: /home/cheezmeister/stuff/code/python/emscripten//em++
    -- Check for working CXX compiler: /home/cheezmeister/stuff/code/python/emscripten//em++ -- works
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Looking for include file pthread.h
    -- Looking for include file pthread.h - found
    -- Looking for pthread_create
    -- Looking for pthread_create - not found
    -- Looking for pthread_create in pthreads
    -- Looking for pthread_create in pthreads - not found
    -- Looking for pthread_create in pthread
    -- Looking for pthread_create in pthread - found
    -- Found Threads: TRUE 
    CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (message):
      Could NOT find SDL (missing: SDL_LIBRARY) (found version "1.2.15")
    Call Stack (most recent call first):
      /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:291 (_FPHSA_FAILURE_MESSAGE)
      /usr/share/cmake-2.8/Modules/FindSDL.cmake:176 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
      CMakeLists.txt:36 (find_package)
   
   
    -- Configuring incomplete, errors occurred!

Getting there. But what's this about SDL? CMake wants to locate it, but emscripten doesn't provide it. Nuts! This had me stumped for longer than it should have, if I had properly rtfm'd. "Building Projects" states: *Built-in support exists for libc, libc++ and SDL, and for those you do not even need to add -lSDL or such - they will just work. But for other libraries, you need to build and link them.* In other words, it's even easier than you thought it was.

Makes perfect sense. As soon as I zapped the find_package(SDL) and related lines from `CMakeLists.txt`, things were back on track. Of course, I don't want to have to put them back in for regular native builds because I'm lazy, so I just added an option for it:

   

Code:

option(USE_EMSCRIPTEN "Set this true if deploying to JS with emscripten" OFF)

My build command now looks like this

Code:

    bobvi% emconfigure cmake -DUSE_EMSCRIPTEN=TRUE ..
    -- The C compiler identification is Clang 3.2.0
    -- The CXX compiler identification is Clang 3.2.0
    -- Check for working C compiler: /home/cheezmeister/stuff/code/python/emscripten//emcc
    -- Check for working C compiler: /home/cheezmeister/stuff/code/python/emscripten//emcc -- works
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Check for working CXX compiler: /home/cheezmeister/stuff/code/python/emscripten//em++
    -- Check for working CXX compiler: /home/cheezmeister/stuff/code/python/emscripten//em++ -- works
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Could NOT find PortAudio (missing:  PORTAUDIO_LIBRARIES PORTAUDIO_INCLUDE_DIR)
    -- Could NOT find JNI (missing:  JAVA_AWT_LIBRARY JAVA_JVM_LIBRARY)
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /home/cheezmeister/stuff/code/c/nextris-js/js
   

Cool! No dice with portaudio out of the box, but I can deal with that later. Let's try building!

Code:

    bobvi% emmake make         
    [ 10%] Building CXX object CMakeFiles/nextris.dir/src/game.cpp.o
    emcc: warning: -I or -L of an absolute path encountered. If this is to a local system header/library, it may cause problems (local system files make sense for compiling natively on your system, but not necessarily to JavaScript)
    /home/cheezmeister/stuff/code/c/nextris-js/src/game.cpp:75:7: error: use of undeclared identifier 'SDL_GetKeyState'; did you mean 'SDL_GetKeyName'?
            ks = SDL_GetKeyState(NULL);

Dagnabbit, I'm still using SDL 1.2. In SDL 2.0, and thus emscripten, that function was renamed to SDL_GetKeyboardState, but otherwise it behaves the same, so it's an easy fix. I suppose it's time for me to migrate anyway. After replacing that call, behold, it builds!

Code:

    bobvi% emmake make         
    Scanning dependencies of target nextris
    [ 10%] Building CXX object CMakeFiles/nextris.dir/src/main.cpp.o
    emcc: warning: -I or -L of an absolute path encountered. If this is to a local system header/library, it may cause problems (local system files make sense for compiling natively on your system, but not necessarily to JavaScript)
    ...
    [100%] Building CXX object CMakeFiles/nextris.dir/src/display.cpp.o
    emcc: warning: -I or -L of an absolute path encountered. If this is to a local system header/library, it may cause problems (local system files make sense for compiling natively on your system, but not necessarily to JavaScript)
    Linking CXX executable nextris-1.1.0.js
    Warning: .ll contains floating-point values with more than 64 bits. Faking values for them. If they are used, this will almost certainly break horribly!
    [100%] Built target nextris
    bobvi%

Awesome! Notice how I got a js file as my output. That comes from changing the name of the CMake target to have a js extension, which causes the final emcc call to generate JS rather than bitcode.

As a side note, those warnings were benign in my case. Run a `emmake make VERBOSE=1` to check what flags are causing them and whether you can safely ignore them.

So...let's try it, I guess? It came as no big surprise that I couldn't blindly run the game from the terminal:

Code:

    bobvi% node nextris-1.1.0.js
   
    /home/cheezmeister/stuff/code/c/nextris-js/js/nextris-1.1.0.js:155847
          throw e;
                ^
    ReferenceError: document is not defined
        at _SDL_Init (/home/cheezmeister/stuff/code/c/nextris-js/js/nextris-1.1.0.js:2438:9)
        at __ZN4Game3runEv (/home/cheezmeister/stuff/code/c/nextris-js/js/nextris-1.1.0.js:13663:14)
        at __Z11nextris_runv (/home/cheezmeister/stuff/code/c/nextris-js/js/nextris-1.1.0.js:13619:14)
        at Object._main (/home/cheezmeister/stuff/code/c/nextris-js/js/nextris-1.1.0.js:4341:10)
        at Object.callMain (/home/cheezmeister/stuff/code/c/nextris-js/js/nextris-1.1.0.js:155839:26)
        at doRun (/home/cheezmeister/stuff/code/c/nextris-js/js/nextris-1.1.0.js:155878:20)
        at run (/home/cheezmeister/stuff/code/c/nextris-js/js/nextris-1.1.0.js:155901:12)
        at Object.<anonymous> (/home/cheezmeister/stuff/code/c/nextris-js/js/nextris-1.1.0.js:155917:1)
        at Module._compile (module.js:456:26)
        at Object.Module._extensions..js (module.js:474:10)

   
Sure, it wants some DOM-age to bond to. I tried sticking it in a web page, with this slightly more primising error :

Code:

    [20:26:29.175] TypeError: Module.canvas is undefined

OK. How do I define the canvas? I can stick a canvas in my HTML, sure, but how do I let the framework know it exists? On a whim, I tried something silly like this:

Code:

      9 <canvas>
     10 <script type="text/javascript" src="nextris-1.1.0.js"></script>
     11 </canvas>

No such luck Alright, it's back to the manual, there must be something I [missed](https://github.com/kripken/emscripten/wiki/Tutorial#generating-html)...

Well then. In that case, I'm just one extension change away from letting the framework do everything for me. i.e., spit out a canvas and the requisite boilerplate to tie it into the emscripten module. Let's give it a go. I got some far more satisfying results this time around

Code:

Linking CXX executable nextris-1.1.0.html
/usr/bin/cmake -E cmake_link_script CMakeFiles/nextris.dir/link.txt --verbose=1
/home/cheezmeister/stuff/code/python/emscripten/em++   -g    CMakeFiles/nextris.dir/src/main.cpp.o CMakeFiles/nextris.dir/src/block.cpp.o CMakeFiles/nextris.dir/src/score.cpp.o CMakeFiles/nextris.dir/src/game.cpp.o CMakeFiles/nextris.dir/src/debug.cpp.o CMakeFiles/nextris.dir/src/field.cpp.o CMakeFiles/nextris.dir/src/utils.cpp.o CMakeFiles/nextris.dir/src/audio.cpp.o CMakeFiles/nextris.dir/src/controls.cpp.o CMakeFiles/nextris.dir/src/display.cpp.o  -o nextris-1.1.0.html -rdynamic
Warning: .ll contains floating-point values with more than 64 bits. Faking values for them. If they are used, this will almost certainly break horribly!
make[2]: Leaving directory `/home/cheezmeister/stuff/code/c/nextris-js/js'
/usr/bin/cmake -E cmake_progress_report /home/cheezmeister/stuff/code/c/nextris-js/js/CMakeFiles  1 2 3 4 5 6 7 8 9 10
[100%] Built target nextris
make[1]: Leaving directory `/home/cheezmeister/stuff/code/c/nextris-js/js'
/usr/bin/cmake -E cmake_progress_start /home/cheezmeister/stuff/code/c/nextris-js/js/CMakeFiles 0

Open this in your favorite browser, you'll be good to go. Just don't try to view the source from Firefox, or it'll choke on some 20,000 lines of asm.js and die a horrific death.

But I have one issue left:

Code:

    [20:53:14.613] uncaught exception: SDL_Delay called! Potential infinite loop, quitting. _SDL_Delay@file:///home/cheezmeister/stuff/code/c/nextris-js/js/nextris-1.1.0.html:2598
    __Z6updateP11SDL_Surface@file:///home/cheezmeister/stuff/code/c/nextris-js/js/nextris-1.1.0.html:13895
    __ZN4Game3runEv@file:///home/cheezmeister/stuff/code/c/nextris-js/js/nextris-1.1.0.html:13787
    __Z11nextris_runv@file:///home/cheezmeister/stuff/code/c/nextris-js/js/nextris-1.1.0.html:13710
    _main@file:///home/cheezmeister/stuff/code/c/nextris-js/js/nextris-1.1.0.html:4432
    callMain@file:///home/cheezmeister/stuff/code/c/nextris-js/js/nextris-1.1.0.html:155930
    doRun@file:///home/cheezmeister/stuff/code/c/nextris-js/js/nextris-1.1.0.html:155969
    @file:///home/cheezmeister/stuff/code/c/nextris-js/js/nextris-1.1.0.html:155988

   
So, SDL_Delay is off-limits, too. As the tail end of [this post](https://hacks.mozilla.org/2012/04/porting-me-my-shadow-to-the-web-c-to-javascriptcanvas-via-emscripten/) explains, our main loop needs to be async, which makes sense if it's to be running in a browser. Up until now, I was able to get away with a fixed timestep, but now it looks like I'll be taking a break for a wee bit o' refactorin'. But for now, sleep. More on this story as it develops.

Party, party? What party? We jammin'?

Do they let outside guests upstairs to chill? I was too late to premium indie room this year, and it makes me sad

And I use doubles too, so a simple templated thing could be better. Or maybe an openGL style API with an "f" or "d" suffix to the function call. E.g., Tweenf, Tweend, Tweeni, ..


That last one made me giggle. I don't think I'd be able to use that API with a straight face :x

Panning commonly uses an "equal-power" or "constant-power" crossfade defined by the sin and cos of the pan value (times pi/2), rather than a linear fade. This is because linear weakens the output at the center values. There are reasons to use both kinds of fade though.

That...explains why my panning sounds so crappy. Kudos to you sir!

Merlin's butt, was that the Lich?

Groan...

Man, I like this idea! One week is short enough to force you to keep the scope under control, but gives some wiggle room in case Life Happens (tm).

May I play along?

I happen to have written a tutorial on them.

That's a pretty solid guide, nice job!

What exactly does your buddy mean by "use quadratics"?

Are we talking straight-up

Code:

height = At^2 + Bt + C

, or some fancier technique I'm not familiar with?