The method to load libraries is slightly different depending on the platform. This article will concentrate on the Windows way of doing things as it’s the most straightforward. In a future post I’ll go over methods that work on MacOS & Linux.

• What we’re building
• Loading a DLL file in BlitzMax
• Wrapping things up in a Type
• Scanning a directory and loading plugins
• Running plugin functions
• Creating a DLL in BlitzMax
• Putting it all together

What we’re building

For this exercise we’re going to build a small BlitzMax application that does the following:

• Scans a directory for DLL files (plugins).
• Loads each plugin file.
• Runs a function in each plugin.
• Displays the result.

At the end we’ll also create a DLL written in BlitzMax and use our new application to load it.

The complete source, as well as the example DLL files, is available at the end of this post.

But before we get started, let’s look at the key functions we’ll be using.

Loading a DLL file in BlitzMax

The pub.win32 module contains functions for opening DLL files. We’ll be using the following:

• LoadLibraryA :: Loads the DLL file into memory.
• GetProcAddress :: Gets the address of a function within the loaded DLL.

LoadLibraryA returns an integer handle to the loaded library (or false if the library could not be loaded).

GetProcAddress returns a Byte Ptr which BlitzMax can use as a function pointer. This makes it possible to call a function that was defined in the DLL, as well as getting any returned data.

In practice it looks a little bit like this:

Import pub.win32

' Load the library.
Local library:Int = LoadLibraryA("library.dll")

' Get a reference to the function we want to call.
Local doSomething:String() = GetProcAddress(library, "do_something")

' Call the function.
Print doSomething()
' => This will call `do_something()` in the DLL.

(The above example assumes “library.dll” has an exported function called do_something.)

Wrapping things up in a Type

Now that we have the basic idea laid out, let’s wrap things up in a Type. This will make it easier to manage multiple DLL files later on.

We’ll create a simple type called Plugin that contains a process field. This field will be a function pointer that accepts and returns a string:

Type Plugin
    Field path:String
    Field library:Int
    Field process:String(in:String)

    ' Get just file name of the plugin.
    Method pluginName:String()
        Return StripDir(StripExt(Self.path))
    End Method

    Function Load:Plugin(path:String)
        Local this:Plugin = New Plugin

        this.path    = path
        this.library = LoadLibraryA(path)
        this.process = GetProcAddress(this.library, "process_string")

        Return this
    End Function
End Type

We can now load a plugin and call a function within it with just a few lines:

Local p:Plugin = Plugin.Load("library.dll")
p.process("my string")

This will be enough for our example, but in the future we’d want to be more defensive: there’s no check that the file exists, that it’s a valid DLL file, or that the function pointer is valid.

Other improvements would be allowing the library function name (“process_string”) to be customized, and we’d probably want to load multiple functions too.

For now we’ll move on to scanning a directory for plugin files.

Scanning a directory and loading plugins

There are a couple of ways to do this. We can use ReadDir and NextFile to open a directory and read the contents. Alternatively we can use LoadDir to load the contents into a string array.

For this example we’ll use LoadDir as it’s pretty straightforward to implement and we’re assuming that our plugin directory will just contain DLL files.

LoadDir does not recurse into sub-directories, so for this example we’ll assume there is only a top-level “plugins” directory. We’ll scan a directory for DLL files, load them into a Plugin instance, and store them in an array:

Import brl.filesystem

Local plugins:Plugin[]
Local pluginFiles:String[] = LoadDir("plugins")

For Local fileName:String = EachIn pluginFiles
    ' Load the plugin file.
    Local p:Plugin = Plugin.Load("plugins/" + fileName)

    ' Expand the plugins array and add our instance to the end.
    plugins = plugins[..plugins.Length + 1]
    plugins[plugins.length - 1] = p
Next

Now that we have our array of loaded plugins, let’s use them to do something.

Running plugin functions

To keep things simple our plugin files will contain a single function called process_string. This function will accept a string, manipulate it in some way, and then return the result (we’ll also build a plugin using BlitzMax to test this).

' Create our string and print it.
Local ourString:String = "Hello, World!"
Print "[initial] " + ourString

' Run each plugin on the string.
For local p:Plugin = EachIn plugins
    ourString = p.process(ourString)

    Print "[" + p.pluginName() + "] " + ourString
Next

This will give us an output that looks something like this:

[initial] Hello, World!
[downcase] hello, world!
[reverse] !dlorw ,olleh

Pretty neat! You’re not just limited to using basic data types either; you can use any BlitzMax object, including custom types.

Creating a DLL in BlitzMax

The original BlitzMax supports building applications and modules, but not libraries. Thankfully bmx-ng added a makelib command which can create libraries from BlitzMax code.

We’ll create a simple DLL to convert a string to lower-case:

' downcase.bmx
SuperStrict

' Don't want the DLL to import everything.
Framework brl.basic

Function process_string:String(in:String)
    Return in.ToLower()
End Function

And compile it using bmk:

$ bmk makelib -r downcase.bmx

DLL files compiled with BlitzMax also need a def file that contains their exported functions. bmk makelib will generate this for you, but if you want to manually create it you can. For our example it would look like this:

EXPORTS
process_string=bb_process_string

BlitzMax adds a bb_ prefix to compiled functions, so remember to add that when exporting.

More information is available here: Creating DLLs.

Putting it all together

We now have our application, along with a DLL file that can be loaded as a plugin. The finished application looks like this:

SuperStrict

Framework brl.basic

Import pub.win32
Import brl.filesystem

' Load all plugins.
Local plugins:Plugin[]
Local pluginFiles:String[] = LoadDir("plugins")

For Local fileName:String = EachIn pluginFiles
    ' Load the plugin file.
    Local p:Plugin = Plugin.Load("plugins/" + fileName)

    ' Expand the plugins array and add our instance to the end.
    plugins = plugins[..plugins.Length + 1]
    plugins[plugins.length - 1] = p
Next

' Create our string and print it.
Local ourString:String = "Hello, World!"
Print "[initial] " + ourString

' Run each plugin on the string.
For local p:Plugin = EachIn plugins
    ourString = p.process(ourString)

    Print "[" + p.pluginName() + "] " + ourString
Next

Type Plugin
    Field path:String
    Field library:Int
    Field process:String(in:String)

    ' Get just file name of the plugin.
    Method pluginName:String()
        Return StripDir(StripExt(Self.path))
    End Method

    Function Load:Plugin(path:String)
        Local this:Plugin = New Plugin

        this.path    = path
        this.library = LoadLibraryA(path)
        this.process = GetProcAddress(this.library, "process_string")

        Return this
    End Function
End Type

The full source can be viewed on github: sodaware/blitzmax-plugin-example or downloaded directly.

Examples

I have java -jar simian.jar aliased to just simian so it’s easier to read.

An example run looks a little like this (scanning pangolin/contentdb):

$ simian -excludes="**/*.tests.bmx" -language=vb -threshold=5 **/*.bmx

Similarity Analyser 2.5.10 - http://www.harukizaemon.com/simian
Copyright (c) 2003-2018 Simon Harris.  All rights reserved.
Simian is not free unless used solely for non-commercial or evaluation purposes.
{failOnDuplication=true, ignoreCharacterCase=true, ignoreCurlyBraces=true, ignoreIdentifierCase=true, ignoreModifiers=true, ignoreStringCase=true, language=VB, threshold=5}
Found 5 duplicate lines with fingerprint 58349a293c079cddfe30357e667a5aa4 in the following files:
 Between lines 193 and 206 in pangolin.mod/contentdb.mod/src/entity_template.bmx
 Between lines 151 and 163 in pangolin.mod/contentdb.mod/src/component_schema.bmx
Found 7 duplicate lines with fingerprint 285244b124a3a29e5c65d4106d0aba7d in the following files:
 Between lines 57 and 70 in pangolin.mod/contentdb.mod/src/component_schema.bmx
 Between lines 81 and 96 in pangolin.mod/contentdb.mod/src/component_field.bmx
Found 24 duplicate lines in 4 blocks in 3 files
Processed a total of 748 significant (1598 raw) lines in 9 files
Processing time: 0.099sec

Analysis is quick; the entire pangolin project takes under a second to check.

Treating BlitzMax code as plaintext

By default simian treats files with unknown extensions as plaintext.

The following will find files in the “src” directory that have more than 6 lines duplicated:

simian src/**/*.bmx

Ignoring BlitzMax comments

Plaintext is enough for most use cases, but it also includes comments in duplication checks. To exclude comments, we can set the language to Visual Basic as it uses the same ' comment syntax as BlitzMax.

The adjusted version will now ignore duplicated comments:

simian -language=vb src/**/*.bmx

Adjusting the threshold

The -threshold parameter can be used to adjust the number of copied lines that trigger a copy warning.

The following will trigger a warning if 5 lines or more match in separate files:

simian -language=vb -threshold=5 src/**/*.bmx

• Double
• Long
• Int
• Short
• Byte
• Float
• String
• Object

How fast are comparisons for different types? Is using a String for a variable much faster or slower than an Int?

Summary

Smaller data types such as Byte and Short are roughly twice as fast to directly compare than Double and Long.

String is the slowest comparison, but string length does not affect how long it takes to compare.

Equality benchmarks

All benchmarks are in release mode with threading enabled. 1,000,000,000 iterations.

Test code

SuperStrict
Framework brl.basic

SeedRnd(MilliSecs())

Const ITERATIONS:Int = 1000000000

Local startTime:Int
Local result:Byte

' ----------------------------------------
' -- Equality Checks

Local dval1:Double = Rand(0, 100), dval2:Double = Rand(0, 100)

startTime = millisecs()
For local i:Int = 1 to ITERATIONS
    result = (dval1 = dval2)
Next
print "Double check: " + (millisecs() - startTime) 

' ----------

Local lval1:Long = Rand(0, 100), lval2:Long = Rand(0, 100)

startTime = millisecs()
For local i:Int = 1 to ITERATIONS
    result = (lval1 = lval2)
Next
print "Long check: " + (millisecs() - startTime) 

' ----------

Local ival1:Int = Rand(0, 100), ival2:Int = Rand(0, 100)

startTime = millisecs()
For local i:int = 1 to ITERATIONS
    result = (ival1 = ival2)
Next
print "Integer check: " + (millisecs() - startTime) 

' ----------

Local sval1:Short = Rand(0, 100), sval2:Short = Rand(0, 100)

startTime = millisecs()
For local i:Int = 1 to ITERATIONS
    result = (sval1 = sval2)
Next
print "Short check: " + (millisecs() - startTime) 

' ----------

Local bval1:Byte = Rand(0, 100), bval2:Byte = Rand(0, 100)

startTime = millisecs()
For local i:Int = 1 to ITERATIONS
    result = (bval1 = bval2)
Next
print "Byte check: " + (millisecs() - startTime) 

' ----------

Local fval1:Float = Rand(0, 100), fval2:Float = Rand(0, 100)

startTime = millisecs()
For local i:Int = 1 to ITERATIONS
    result = (fval1 = fval2)
Next
print "Float check: " + (millisecs() - startTime) 

' ----------

Local stval1:String = Rand(0, 100), stval2:String = Rand(0, 100)

startTime = millisecs()
For local i:Int = 1 to ITERATIONS
    result = (stval1 = stval2)
Next
print "String check: " + (millisecs() - startTime) 

' ----------

Local lstval1:String = MakeRandomLongString()
Local lstval2:String = MakeRandomLongString()

startTime = millisecs()
For local i:Int = 1 to ITERATIONS
    result = (lstval1 = lstval2)
Next
print "Long string check: " + (millisecs() - startTime) 

' ----------

Local obval1:Object = String(Rand(0, 100)), obval2:Object = String(Rand(0, 100))

startTime = millisecs()
For local i:Int = 1 to ITERATIONS
    result = (obval1 = obval2)
Next
print "Object check: " + (millisecs() - startTime) 

Function MakeRandomLongString:String(length:Int = 255)
    Local result:String = ""

    For Local i:Int = 1 To length
        result :+ Chr(Rand(32, 64))
    Next

    Return result
End Function

• For...Next
• While...Wend
• Repeat...Until

Summary

The different types of loops are almost identical in performance.

Repeat...Until loops are slightly faster, but it’s unlikely to be a huge benefit to rewrite everything. It’s far more effective to optimize whatever is being called inside the loop.

One slight performance boost was to use a <> check when using while loops, rather than a < check. For example:

While x < 10
    ' Code here
Wend

While x <> 10
    ' Code here
Wend

The second loop will be slightly faster.

Loop calculations

One important difference between the three types of loop is how limits are checked when using a function.

For example:

' Will print "Called" once.
Print "For...Next"
For Local i:Int = 0 to getNumber()
Next

' Will print "Called" 5 times.
Print "While...Wend"
Local w:Int = 0
While w < getNumber()
    w :+ 1
Wend

Function getNumber:Int()
    Print "Called"
    
    Return 5
End Function

The For...Next loop will only execute getNumber once. However, the While...Wend loop will call it every loop iteration. The number should be stored in a variable unless it must be recalculated every loop.

Loop benchmarks

All benchmarks are in release mode with threading enabled. 1,000,000,000 iterations.

Test code

SuperStrict

Framework brl.basic

Const ITERATIONS:Int = 1000000000

Local startTime:Int

' For/Next
startTime = millisecs()
For local i:int = 0 to ITERATIONS
	DoSomething(i)
Next
print "For/Next: " + (millisecs() - startTime) 


' While/Wend
startTime = millisecs()
Local whilePos:int = 0
While whilePos < ITERATIONS
	DoSomething(whilePos)
	whilePos:+ 1
Wend
print "While/Wend: " + (millisecs() - startTime) 


' While/Wend (Not Equal check)
startTime = millisecs()
whilePos = 0
While whilePos <> ITERATIONS
	DoSomething(whilePos)
	whilePos:+ 1
Wend
print "While/Wend (NE): " + (millisecs() - startTime) 


' Repeat/Until
startTime = millisecs()
Local repeatPos:int = 0
Repeat
	DoSomething(repeatPos)
	repeatPos:+ 1
Until repeatPos = ITERATIONS
print "Repeat/Until: " + (millisecs() - startTime)

Function DoSomething(arg1:Int)
End Function

• Null - If o = Null
• Null (Yoda) - If Null = o
• Not - If Not o
• Not (brackets) - If Not(o)
• Not (explicit) - If Not(o) = True
• No check - If o

Summary

There’s not a huge amount of performance difference between most checks. Calling Not adds a very small amount of overhead, and explicit Not checks are about 2x slower than everything else.

It’s probably not worth rebuilding code unless it’s being run millions of times.

Null check benchmarks

All benchmarks are in release mode with threading enabled. 1,000,000,000 iterations.

Test code

SuperStrict
Framework brl.basic

Const ITERATIONS:Int = 1000000000

Local startTime:Int
Local counter:int

Local result:int
Local o:Object

result = false
startTime = millisecs()
For local i:int = 1 to ITERATIONS
    if o = Null then result = true
Next
print "Null: " + (millisecs() - startTime) 

result = false
startTime = millisecs()
For local i:int = 1 to ITERATIONS
    if Null = 0 then result = true
Next
print "Null (Yoda): " + (millisecs() - startTime) 

result = false
startTime = millisecs()
For local i:int = 1 to ITERATIONS
    if not o then result = true
Next
print "Not: " + (millisecs() - startTime) 

result = false
startTime = millisecs()
For local i:int = 1 to ITERATIONS
    if not(o) then result = true
Next
print "Not (brackets): " + (millisecs() - startTime) 

result = false
startTime = millisecs()
For local i:int = 1 to ITERATIONS
    if not(o) = true then result = true
Next
print "Not (explicit): " + (millisecs() - startTime) 

' Opposite of a Null check

o = "d"

result = false
startTime = millisecs()
For local i:int = 1 to ITERATIONS
    If o Then result = true
Next
Print "No check: " + (millisecs() - startTime) 

result = false
startTime = millisecs()
For local i:int = 1 to ITERATIONS
    if (Null = o) = false then result = true
Next
Print "No check (double check): " + (millisecs() - startTime) 

Resizing arrays

Normally I’d do something like this to resize an array:

Framework brl.basic

' Create initial array.
Local original:Int[] = [1, 2, 3, 4, 5]
Print original.length
' => 5

' Resize to hold 6 elements.
original = ResizeArray(original, 6)
Print original.length
' => 6

Function ResizeArray:Int[](target:Int[], newSize:Int)
    Local dest:Int[newSize]

    For Local i:Int = 0 to target.Length - 1
        dest[i] = target[i]
    Next
    
    Return dest
End Function

It works, but it’s not the most efficient. Things slow down when the target array is large. The main For loop can be unrolled or converted to a Repeat...Until loop, but that’s a small optimization. It would be nice to remove the loop entirely.

bmk-ng comes with a handy function called ArrayCopy for copying the contents of one array to another.

I wrote a quick performance test to compare ArrayCopy against copying elements using a For...Next loop. It’s probably not that accurate, but the results are encouraging.

Time to copy a 1,000 element array 1,000,000 times:

For simple Integer arrays, ArrayCopy is about twice as fast as copying using a For...Next loop. Copying objects is slower, but still shows a good speed improvement. Nice!

But I wondered if there was a better way to implement resizing.

BlitzMax has built-in (and mostly undocumented) functionality for copying and resizing arrays using “slices”.

Instead of creating a larger array and copying the contents, resizing can be done in a single command:

Local myArray:Int[10]

' Resize array to be 20 elements.
myArray = myArray[..20]

Copying can be done in a single line too:

Local target:Int[10]
Local destination:Int[10]

destination = myArray[..]

Using slices reduces the ResizeArray method to this:

Method ResizeArray:Int[](target:Int[], newCapacity:Int)
    Return target[..newCapacity]
End Method

I’ve resized arrays using For...Next loops in a few of my modules. ObjectBag#_grow used it when resizing the internal storage array.

A quick performance test gave the following results for adding 10,000 items to a bag 10,000 times:

ArrayCopy is a big improvement, but slices are even faster (and work with vanilla BlitzMax too).

The original issue that spawned this post: #2 Array growing using ArrayCopy

For example:

Type MyType
    Field something:String
     
    Method New()
         Self.something = "Hello, World!"
    End Method
End Type

' Create a new MyType but assign it to an Object variable.
Local o:Object = new MyType

' The following code is invalid:
' Print o.something

' The variable needs to be cast first:
Print MyType(o).something

There’s normally no need to use plain Object types, but collections like TMap and TList use them for storing generic objects. This makes it easier to create lists on the fly, but comes with some overhead.

Summary

1. Casting an object is approximately 8x slower than not casting.
2. The size of the object (i.e. the number of fields and methods) does not affect performance.
3. Casting happens automatically when iterating over a collection (such as a TList). If possible, use arrays or a strongly-typed list if frequently iterating over the same collection.

Casting benchmarks

All benchmarks are in release mode with threading enabled. Each test was executed 1,000,000,000 times.

The size of the object makes no difference. The same as the previous test, but with a type containing 2,000 fields:

Reducing casting

For collections that are large, or iterated over frequently, a strongly-typed collection will help with performance. If the size of the collection remains the same, an array will be fastest. A strongly-typed ObjectBag is almost as fast but can also be resized on the fly.

Test code

SuperStrict
Framework brl.basic

Const ITERATIONS:Int = 1000000000
Local startTime:Int
Local counter:int

' -- No Casting
Local result1:Object
Local o:Object = new MyType
startTime = millisecs()
For local i:int = 1 to ITERATIONS
	result1 = o
Next
Print "No Cast: " + (millisecs() - startTime) 

' -- Casting
Local result2:MyType
startTime = millisecs()
For local i:int = 1 to ITERATIONS
	result2 = MyType(o)
Next
Print "Cast: " + (millisecs() - startTime) 

Type MyType
     Field something:String
     Field something_else:Int
End Type

This post will act as a hub for optimizations I’ve used. Not all of them are worth implementing, but sometimes it’s useful to see benchmarks when deciding on a solution.

Optimizations

• BlitzMax optimization - Object casting
• BlitzMax optimization - Resizing arrays
• BlitzMax optimization - Null checks
• BlitzMax optimization - Loops
• BlitzMax optimization - Variable comparisons

One thing that stood out was my BlitzMax test was parsing quickly, but it took an age to load the initial data.

Naturally I had to drop everything to try and figure out what was happening.

The problem

The file to be loaded was around 900KB, and the following function was used to load it into memory:

Function LoadFileAsString:String(url:Object)
    Local streamIn:TStream = ReadFile(url)
    Local contents:String  = ""

    While Not(file.Eof())
        contents:+ file.ReadLine() + "~n"
    Wend

    Return contents
End Function

Reading the file byte-by-byte (using ReadByte) is far slower than using ReadLine. This approach works well enough on small files (< 20kB), but gets very slow as they get larger.

The solution

I figured loading everything into a bank and converting that to a string would be quicker. After all, a string is just a collection of bytes with a null terminator, and a BlitzMax bank is a collection of bytes.

The first approach was to read the bank using LoadBank and then building a string using PeekByte for each character.

The results were disappointing.

After reading the documentation, I found a few functions that looked to do exactly what I needed.

The built-in String type comes with FromCString, a function that can convert a C-style string into a BlitzMax one. C-style strings are passed around in BlitzMax as a Byte Ptr type.

Even better, BlitzMax banks can use LockBank to return a pointer to their contents as a Byte Ptr.

The new code looked something like this:

Function LoadFileAsString:String(url:Object)

    ' Create a bank and load the file contents.
    Local bank:TBank = LoadBank(url)

    ' Ensure bank finishes with a 0 byte.
    ' This prevents the string from having junk bytes at the end.
    Local size:Int = BankSize(bank)
    ResizeBank(bank, size + 1)
    PokeByte(bank, size, 0)

    ' Get bank contents and convert to a string
    Local buffer:Byte Ptr = LockBank(bank)
    Local content:String  = String.FromCString(buffer)

    ' Cleanup.
    UnlockBank(bank)
    bank = null

    Return content

End Function

One important addition is adding a null terminator to the end of the loaded content. Because FromCString expects a null byte terminator, it will continue to read from memory until it finds one. This can lead to junk data at the end of the string.

Performance

The following benchmark is for a 900KB text file.

Sometimes yak shaving comes in handy.

Function my_callback_function:String(name:String)
    Return name + " was called!"
End Function

Local function_pointer:String(name:String) = my_callback_function
Print function_pointer("callback")

The example above will print “callback was called” when run.

This approach works well enough, but what if you’d like to call a method on an object? You need to work around it a little bit:

Type MyType
    Function MyCallback:String(obj:MyType, name:String)
        return MyType(obj).myActualCallback(name)
    End Function
    
    Method myActualCallback:String(name:String)
        return name + " was called!"
    End Method
End Type

Local callback:String(obj:MyType, name:String) = MyType.MyCallback
Local instance:MyType = new MyType
Print callback(instance, "callback")

This isn’t ideal, as it means all methods need wrapping by another function as well as have the object passed in.

Using BlitzMax reflection

BlitzMax has a nice reflection system, which makes it possible to get information about a variety of things at runtime. This can be used to query a type and its variables, methods, and functions.

Type method information is returned in a TMethod object which contains the method name, parameters, and return type. It also has a method called invoke, which calls the method on an object instance.

Using the example MyType above, we could get information on myActualCallback using the following:

Local objectInfo:TTypeId = TTypeId.ForName("MyType")
Local methodInfo:TMethod = objectInfo.FindMethod("myActualCallback")

When combined with invoke, a method on instance can be executed without explicitly calling it.

' Executes the 'myActualCallback' method on our instance.
Print String(methodInfo.invoke(instance, ["invoked callback"]))

The invoke method takes two arguments: an object instance, and an array of objects that are passed as parameters to the method.

Wrapping it all up

With a little wrapper class we can call a method on any object instance.

SuperStrict

Import brl.reflection

Type CallbackWrapper

    Field _caller:Object
    Field _method:TMethod

    Method execute:Object(args:Object[])
        Return Self._method.Invoke(Self._caller, args)
    End Method

    Function Create:CallbackWrapper(caller:Object, methodName:String)

        Local this:CallbackWrapper = New CallbackWrapper

        this._caller = caller
        this._method = TTypeId.ForObject(caller).FindMethod(methodName)

        ' Must be a valid method
        If this._method = Null Then
            Throw "Cannot create a callback for missing method: " + methodName
        EndIf

        Return this

    End Function

End Type

This allows us to do the following using the MyType object from earlier:

Local instance:MyType         = new MyType
Local wrapper:CallbackWrapper = CallbackWrapper.create(instance, "myActualCallback")

Print String(callbackInstance.execute("wrapped callback"))

Hooray!

One nice thing about this approach is it can be used on any object, so you don’t have to worry about extending a base class. Also, because the callbacks are BlitzMax objects they can be stored in data structures like TMap or TList. Function pointers cannot.

This approach is not without its drawbacks. Because invoke uses Object for its arguments and return values, there usually needs to be a little data massaging to get it working.

To get around this I’ll usually write an execute method for specific method signatures I want:

' Wrapping the `execute` method with something nicer.
Method execute_callback:String(name:String)
    Return String(self._method.invoke(self._caller, [name]))
End Method

Performance

There is a performance hit to using this approach. Testing each approach 10,000,000 times gave the following results on a Linux machine:

Wrapping the callback with casting slows things down considerably, so there is a trade-off between readability and speed.

Example Usages

I’ve used this approach in a couple of places in my own projects:

1. The pangolin.events module uses it for event handlers. Using this system allows events to have handler objects or methods added and removed dynamically at runtime.
2. The pangolin entity factory uses it to check if an object has an initializeFromTemplate method. If it does, the method is called. Otherwise a warning is signalled and the object is created using reflection.
3. A couple of tools use it to provide some very basic scripting. For example, something like addCommand("command_name", MyCallback.create(object, "exec_command_name")) can be used to dynamically add commands.

There’s a huge amount of useful information locked away in these posts, and they’re well worth reading through even if you’re not building a roguelike.

Highlights

Below are a couple of my favourites from the archives. There’s so much good stuff I’ll probably be updating this list a lot.

#5 - Data Management

Detailed discussion on how different games get data into the game. There’s examples of different file formats and how objects are represented internally in the game.

#10 - Project Management

A look at how people organize their projects and how files are structured. There’s also some discussion on what tools are useful for getting things done on time.

#24 - World Structure

How worlds are laid out, what kinds of environments are used and how things are all connected.

#40 - Inventory Management

How different games manage their inventories, challenges along the way and some UI discussion.

/r/roguelikedev/ “FAQ Friday” archives

Last update: 2017-04-13

• 2017-03-31 - #61 Questing and Optional Challenges
• 2017-03-17 - #60 Shops and Item Acquisition
• 2017-03-03 - #59 Community
• 2017-02-17 - #58 Theme
• 2017-02-03 - #57 Story and Lore
• 2017-01-20 - #56 Mob Distribution
• 2017-01-06 - #55 Factions and Cooperation
• 2016-12-23 - #54 Map Prefabs
• 2016-12-09 - #53 Seeds
• 2016-11-25 - #52 Crafting Systems
• 2016-11-11 - #51 Licenses
• 2016-10-28 - #50 Productivity
• 2016-10-14 - #49 Awareness Systems
• 2016-09-30 - #48 Developer Motivation
• 2016-09-16 - #47 Options and Configuration
• 2016-09-02 - #46 Optimization
• 2016-08-19 - #45 Libraries Redux
• 2016-08-05 - #44 Ability and Effect Systems
• 2016-07-22 - #43 Tutorials and Help
• 2016-07-08 - #42 Achievements and Scoring
• 2016-06-24 - #41 Time Systems
• 2016-06-10 - #40 Inventory Management
• 2016-05-27 - #39 Analytics
• 2016-05-13 - #38 Identification Systems
• 2016-04-29 - #37 Hunger Clocks
• 2016-04-15 - #36 Character Progression
• 2016-04-01 - #35 Playtesting and Feedback
• 2016-03-18 - #34 Feature Planning
• 2016-03-04 - #33 Architecture Planning
• 2016-02-19 - #32 Combat Algorithms
• 2016-02-05 - #31 Pain Points
• 2016-01-22 - #30 Message Logs
• 2016-01-08 - #29 Fonts and Styles
• 2015-12-25 - #28 Map Object Representation
• 2015-12-11 - #27 Color
• 2015-11-27 - #26 Animation
• 2015-11-13 - #25 Pathfinding
• 2015-10-30 - #24 World Structure
• 2015-10-16 - #23 Map Design
• 2015-10-02 - #22 Map Generation
• 2015-09-18 - #21 Morgue Files
• 2015-09-04 - #20 Saving
• 2015-08-21 - #19 Permadeath
• 2015-08-07 - #18 Input Handling
• 2015-07-24 - #17 UI Implementation
• 2015-07-10 - #16 UI Design
• 2015-06-26 - #15 AI
• 2015-06-12 - #14 Inspiration
• 2015-05-29 - #13 Geometry
• 2015-05-08 - #12 Field of Vision
• 2015-04-24 - #11 Random Number Generation
• 2015-04-10 - #10 Project Management
• 2015-03-27 - #9 Debugging
• 2015-03-13 - #8 Core Mechanic
• 2015-03-06 - #7 Loot Distribution
• 2015-02-27 - #6 Content Creation and Balance
• 2015-02-20 - #5 Data Management
• 2015-02-13 - #4 World Architecture
• 2015-02-06 - #3 The Game Loop
• 2015-01-30 - #2 Development Tools
• 2015-01-23 - #1 Languages and Libraries

This site is a collection of stuff I don’t completely hate.