Posted on Programming

Trigger vibration on Android from Heaps/Hashlink

I wanted to trigger vibrations in Hexlock – so I did, and here’s how! I am not saying this is the best, correct, or even a good way to go about it. It’s just what I did. Maybe it will help.

I added a static function to my Main class, the idea being that it would do nothing unless I was compiling for Android. (I added -D android to my compile-to-c.hxml for just this purpose). There may already be a hlNative one, but who knows at this point. I didn’t see one, and adding -D android was easy enough.

#if android
@:hlNative("Java_io_heaps_android_HeapsActivity")
#end
public static function vibrate(i:Int) : Void { }

When compiling to C code for Hashlink, calls to that function (Main.vibrate(i)) get replaced with Java_io_heaps_android_HeapsActivity_vibrate(i), which I defined in my jni.c1 file.

JNIEXPORT void JNICALL Java_io_heaps_android_HeapsActivity_vibrate(int duration) {
    (*jvm)->AttachCurrentThread(jvm, &thisEnv, 0); 
    jclass cls = (*thisEnv)->FindClass(thisEnv, "io/heaps/android/HeapsActivity");
    jmethodID method = (*thisEnv)->GetStaticMethodID(thisEnv, cls, "vibrate", "(I)V");

    __android_log_print(ANDROID_LOG_DEBUG, "JNI.c", "Vibrating: %d", duration);

    if (method > 0)
        (*thisEnv)->CallStaticVoidMethod(thisEnv, cls, method, duration);
}

You’re probably wondering where thisEnv comes from, and if you are I can help! I modified my startHL() function to be:

JNIEnv* thisEnv; // I want access to these from other functions
JavaVM  *jvm;
  
 
JNIEXPORT int JNICALL Java_io_heaps_android_HeapsActivity_startHL(JNIEnv* env, jclass cls) {
    thisEnv=env; // Store the JNIEnv for later use
    (*env)->GetJavaVM(env, &jvm); // Also the JVM
     return main(0, NULL);
}

As you can see from two functions back, the code assumes there is a vibrate() function in io.heaps.android.HeapsActivity, and there is, because I added one.

    static public void vibrate(int duration) {
        Log.d("HeapsActivity.java", "static vibration call");
        Vibrator v = (Vibrator)instance.getSystemService(Context.VIBRATOR_SERVICE);
        v.vibrate((long)duration);
    }

And now it vibrates! You can find out more about the files I’m referencing (including a Git repo hosting them) here.

Posted on Programming

Presenting Hexlock, a really fun game™

Hexlock, a simple counting-based puzzle game, now available for your Android device.

Select a level, defeat it, and repeat.

There are twenty-one levels in total, each represented by a different tile on the level select screen, and you can play them in whichever order you like.

In each level, you start by clicking the middle tile. From there, just form a path from neighbour to neighbour until the two numbers at the top match up. Once they do, you’ve won!

The hex tiles each have a value, represented in hexadecimal. The goal is in binary. All you need to do is form a path such that the hex values add up to the binary goal. You can do that by adding and converting between bases in your head, or, you know, just click around until it unlocks.

Once you’ve defeated a level, how well you did will be reflected in that level’s tile on the level select screen. Grey if you have yet to complete the level; green if you scored par or under; blue if you scored under 2 par; orange for less than 3 par; or red if your path was longer than 3 par.

Only your highest score for each level will be saved, and if you ever want to review that path, long press the hexagon for that level in the level select.

Controls

  • Clicking on the most recently selected hexagon will unselect it.
  • Press and hold (long press) the middle tile to reset your current level.
  • Press and hold (long press) a level to load your highest scoring path.
  • Press the back button on your phone, or escape or backspace on a keyboard to return to the level select menu.

Download it today in the Google Play store!

RATED 5 TO 6 HEXAGONS BY REVIEWERS EVERYWHERE1

Or, if you don’t have an android device, you can play the web version here.

1. This is not true; very few people rate things in hexagons these days

Posted on Programming

Dead by Daylight – filterable perks

Dead by Daylight has added so many new characters and perks since I made my original perk search tool – but worry not! I’ve created an updated version, powered by Logipar and based on data from the fandom wiki. Complete with scripts to help me easily integrate additional perks, as they’re added.

As always with Logipar, you can filter using logical operators like and, or, and not. Parentheses welcome.

You can query a field directly (character, description, name) using : to match if the field contains a value, or = to match if the field is a value. Or just type in regular text to check if it’s contained in any of the fields.

For example, character:ace will match Ace Visconti and Ghost Face. Whereas, character=ace will only match Ace.

You can finally search for rummage to remember that the perk is actually called appraisal. Now if only they would add something similar to the game itself.

Dead by Daylight, now with filterable perks. Available on GigglingCorpse. Give it a try today at https://gigglingcorpse.com/dev/deadbydaylight

Or, you know, below:

Posted on Programming

Hello World; Heaps on Android

Hello, and welcome.

As there’s no way for you to reasonably know, I built a puzzle game recently – in Haxe, using Heaps which I had only used once before, for a website that required a 3D can. Which may seem strange, but I assure you it made sense at the time. Anyway, Heaps seemed fairly nice, so I figured I should try it again.

But I wanted it to be an Android app.

Which is okay, because Heaps works on Android. It says it right there on the website! Unfortunately, there’s not much info on it beyond that, and compiling Heaps for Android turned out rather less straight forward than I had hoped.

Fast forward five days of debugging Android Studio configurations and C code, and I now have a simple Heaps app running on Android. And it’s on GitHub!

https://github.com/altef/heaps-android

It’s built based on a couple of repos1, 2, the second of which was particularly helpful, but I had to mix and match some things between them.

I don’t intend to keep it up-to-date unless I have a use for it, but it works as of November 11, 2022.

How it works

The Haxe code lives in app/src/main/haxe. It’s a basic Heaps hello world project set up for VS Code, as described in the documentation section of the Heaps site. There’s a compile.hxml file which tells the compiler to place the generated C code in the out/ directory of the cpp folder.

The C code lives in app/src/main/cpp. It contains git submodules to some of the necessary libraries, as well as a CMakeLists.txt. Android Studio uses that during its build process. You can find out more about the other things there at the link, above.

This is also where the JNI function for the heaps app lives (in jni.c).

The Java code lives in app/src/main/java, io.heaps.android.HeapsActivity is the entry point to the Heaps hello world and triggers it to run. It extends org.libsdl.app.SDLActivity which handles a bunch of the SDL stuff. Add your own classes as necessary if you want, I probably won’t!

Each of those directories contains a readme with some info about what they contain.


One important note: The NDK version.

It didn’t work with any of the NDK versions I had installed. I ended up having to download r18b and use that. I placed it in the ndk/ folder of my Android SDK directory. You can find this under File > Project Structure, and then by clicking SDK Location.

So I placed it in C:\Users\Brad\AppData\Local\Android\sdk\ndk.

But that’s not all – apparently Android Studio expects the ndk version directory to be named a certain way, so I named mine 18.1.1.

The Android Studio project in the Git repo expects that, so if you name it something else, update build.gradle to reflect that.

After that it should just be a matter of clicking build in Android Studio.


Problems along the way

As you can imagine from the heading nearby I ran into so many problems along the way. So many problems, and so many android log statements.

But my memory is terrible, and Google found surprisingly few results, so I’m going to catalogue some of them here. You know, for next time. You should be able to ignore this portion, they should all be addressed already in the repo code.

OpenAL needs liblog.so: liblog.so needed by libopenal.so not found.

I tried a bunch of things for this, but the solution turned out to be adding arguments -DANDROID_LD=lld to the app gradle.build file.

hashlink/src/std/types.c error: undefined reference to 'hl_zalloc'

hl_zalloc is defined in hashlink/src/gc.c. I added that to CMakeLists.txt when building the Hashlink library.

fatal error: 'minimp3.h' file not found

Added hashlink/include/minimip3 to the target_include_directories for fmt.hdll, in CMakeLists.txt.

java unsupported major.minor version 52

I updated to Java 1.8.0.

E/EGL_emulation: eglCreateContext: EGL_BAD_CONFIG: no ES 3 support (and a bunch of other SDL / window creation errors)

These seemed to go away when I tracked down that Hashlink uses version 3.0 for mobile, added the appropriate declaration to my AndroidManifest.xml, and fiddled with the settings in the emulator. Honestly I’m not sure what ended up fixing these things because nothing did and then I restarted Android Studio and everything was magically working.

At which point I was just willing to accept that.

Posted on Books

A terrible novel or two

In the challenging-myself-to-do-ridiculous-things-just-to-see-if-I-can category: in 2020 I wrote a novel in a month. It was so bad. So, so bad.

But that’s okay! The point wasn’t to write a good novel.

For one and a half to three hours a day (however long it took to reach ~1700 words), and right before bedtime, I sat at my computer frantically typing. I hated every moment of it, which is how you know a challenge is truly funny. The best jokes are the ones you play on yourself.

After all that, you’d think I’d have learned my lesson. But, no. Instead I roped a bunch of friends into a shared goal for 2021: writing another bad novel, but with a twist (there wasn’t much of a twist). I would do a bit more planning and try to make it slightly less terrible. Still bad though. That was important.

I finished it on my birthday (the eighteenth of April), which meant I accomplished the first part, if maybe not the second. But in stranger news, I’ve now written two novels in six months. Which is kind of neat!

They are very, very different.

Interestingly, I found I my wordcount didn’t seem to scale linearly with time when compared against last year – a thousand words a night in about an hour. So either I’ve become faster at spewing words, or there’s some cutoff point between the two where I slow down. I’d guess the latter.

Here is an excerpt from the beginning of the first book, unedited and honestly just untouched from when I first clickity-clacked it out all those months ago – maybe you’ll hate it! Weirdly, I don’t. It’s bad but I don’t hate it.

“Come here, boy.” My grandfather called from the doorway, his voice rough.  A silhouette against the dawn’s light.  He was a tall, weathered man, his height barely blunted by age.

It took him two steps to reach the hearth.  Even in shadow its embers were dull against the morning light.  He took up a stick and began to poke at them, coaxing what life he could.  

I could feel the twigs and leaves under the callowskin insulating me from the cold earth. I pushed myself to my feet shivering against the cold, and shuffled over to join him at the hearth as he tossed in another log and the air was flooded with dust and ash.

He knelt before me, his hands on my shoulders and his expression stern.

“Winter’s time is ending, and you know what that means.”

I looked at him blankly, sleep still dragging on my mind.  Not yet fully alert as is the privilege of one who knows he is safe.  My grandfather pursed his lips and shook his head ever so slightly.

“The assessment is in a fortnight.” 

I felt my eyes widen.  Two weeks.  The cabin softened; my grandfather’s face was no more than a blur before me as tears welled in my eyes.

“Easy, boy.” His voice was gruff and I could picture vividly the stern look that must have taken his warbling face.  “None of that, now.”

I suppressed a sniffle and rubbed my eyes with my palms.

“That’s two weeks to ensure you’re ready.”

I nodded to him, barely listening, not sure what to think and my mind thrashing for it.  He mistook the cause of my concern and smiled at me.

“You’ll catch someone’s eye, boy, we’ll see to it.  See to your chores and we’ll do some training.”  He nodded again, this time to himself.  And with that I staggered through the still open door, and out of the cabin.  Just two weeks until my life would change forever.

Thank you for accompanying me on this generic first-person, past-tense, in a fantasy world journey. That is all.

Posted on crafting

Bluetooth footpedal

My mother has a piano and a Microsoft Surface Pro. The former is good for playing songs while the latter is good for many, many things, including, but not limited to, playing songs. Also the display of sheet music for use with a piano. It would be perfect, really, if there was a way to change pages in a hands-free manner. One traditionally uses ones hands, you see, to piano.

I know what you’re thinking – there is! You can buy such things, but also you can make them.

To start with, I ordered an Adafruit Feather m0 Bluefruit LE from BC Robotics. After that it was a simple matter of wiring a few buttons up to it, and writing some code.

Once I had that figured out (or while I figured that out), I had to design a model to house it. And, you know, act as a foot pedal. Luckily, I have an awesome 3d printer so models can come to life in only ten to fifty hours, or so.

     

The buttons fit into those two holes, and as you apply pressure to the pedal in either direction it presses them. It’s powered by USB, which also charges a battery so it can continue to work should it be disconnected. Here it is assembled!

Posted on Programming

Gradient Vodka Soda

Gradient vodka soda is vodka soda with a novel twist – each bottle has a different amount of alcohol, allowing you to easily taper off your consumption through the night – which they call modern moderation. Check them out if you’re in the market for that sort of thing (and are of legal drinking age).

I programmed their teaser website, which had a bunch of interesting technical requirements. In this post I will go over a few of the more interesting tests I wrote. Most will work best if you have hardware acceleration enabled.

Rotating cans

The website revolves around a 3d can (see what I did there?). To accomplish this, I used, as I do given whatever excuses I can find, the programming language Haxe. And this time in particular, Heaps.

I got a 3d cylinder rotating, and applied a material to it. (It’s not really a cylinder, I made a model to account for the inset near the top.)

I ended up rendering each can to 2D, and positioning it that way. It made it easier to line everything up and prevented skewing from the camera’s perspective. This allowed the overlays to fit consistently. (The metal of the can, and the shadows on it are overlays.) The actual 3D can is just an ambiently lit label applied to the model.

But I couldn’t find an easy way to switch the labels on it; so I ended up writing a shader to do that. And so it went for so many more things –

But what if it was a shader?

I wrote a bunch of these to accomplish neat graphical effects. Heaps actually makes it pretty easy. Though, in most cases, I ended up moving away from the shader solutions to better support visitors without hardware acceleration enabled.

Ever moving blobs

The client wanted some subtle blobs floating around in the background, so I thought to myself, high on my recent shader successes, why not do it as a shader too?

I made a quick proof-of-concept, and it looked kind of neat, almost like a lava lamp. The blobs ended up getting cut in favour of a background video, which then also got cut.

Different sized dots

I tried dots a few different ways to see what which worked best. First I tested moving a small canvas with the mouse, and that worked fairly well. Unfortunately, requirements shifted so I tested drawing dots over a large canvas.

Performance wasn’t great, so I ended up using a small canvas to draw the dot at the appropriate size (the sizes change as you scroll), and used that as a pattern to fill in the larger, screen-sized, canvas.

That seemed to work fairly well, except that iOS apparently doesn’t send mouse events while scrolling, which interacts poorly when you’re making a scroll-based website.

Scroll-based flash animations

As you get to the bottom of the page, there is a box that the cans slide into. It was meant to close, spin around, and settle onto the ground, as you scrolled down. Unfortunately, we didn’t get the rotating box assets in time, so Sheldon amended the animation concept.

I figured it would be a pain to do in code, and animations are exactly the sort of thing Adobe Animate (formerly Flash) was made for. All I had to do was hack their JS to animation to progress through the timeline on vertical scroll rather than time. I wrote a quick proof of concept (and ran into a bunch of issues with more complicated, nested animations), but overall it worked really well.

So well that it got me wondering if that’s already a thing people do. If not, it seems perfect for this sort of website. Adobe should consider adding as an option to their JS output. Or maybe I should just release a library for it.

As an added bonus, using Adobe Animate let Sheldon prepare the animation himself, which meant less work for me!

There were so many problems

Most to do with different devices and browsers, and the different values between them. It took forever to track down and deal with these, but in most cases we managed to get the numbers to line up.

But one thing that kept cropping up was the matter of hardware acceleration.

I kept it turned off for my tests, but apparently some Macbooks have it enabled by default, but disable it when unplugged. This caused a number of surprises when people tested it, many to do with a feature I had implemented for just this purpose.

Framerate scaledown

All of these things going on could be quite a load on a slower system, at times making it painful to use. No matter what, I wanted the website to be useable – responsive design, but along the dimension of framerate rather than browser width.

To help with this, I implemented a system of framerate scaledown. Basically, the browser would check your framerate, and if it was too low too many times, it progressively disabled features.

I was pretty happy with this system. In a lot of cases it would just turn off interactions (remove the background video, make the dots non-responsive to mouse position, etc.). It worked really well, but in conjunction with the above it lead to some confusion. Sometimes the dots resizing under your mouse would work, and sometimes they wouldn’t (they wouldn’t work if they’d been disabled).

If you want to checkout the website, you can find it at drinkgradient.com