Currently working on an upgrade to the NerfedButtons3Rift addon and one of the challenges is working out how to reduce the CPU load of the addon. Areas I need to look into include:
  • Reducing the CPU overhead when parsing macros
  • Caching the results from calls to the Rift API, especially Inspect.*.  This caching needs to at least cache the calls for the duration of each line of a macro and possibly for future calls to macros (for a short sub-second period).

Macro Parsing

Each time a macro key is pressed each line of the macro is parsed (one at a time) and checks are performed to determine if an ability should be used, this parsing takes considerable CPU.

The MacroCache

I propose to create a macroCache table that is indexed by a unique name per macro and is populated as each line of a macro is parsed. Each macro will have mandatory nb start <macroname> line so as to determine the start of a macro. The end is determined automatically based on current time-lapsed logic.

A new if statement will be added to the main CMD parser that checks for (in a global macroCache table) and if it doesn't exist stores the value from nb start <macroname> into a global macroTemp variable. Any commands that arrive are then assumed to be for that macro and appended  to macroTemp.

When a new nb start is received, any values in tempMacro are copied to macroCache.

Whenever the player leaves combat, macroCache is emptied. macroCache does not build when out of combat to facilitate out of combat testing.

NB4R getting updated

Finally got around to doing an Rift game-client update last night and re-installed NB4R to see what's broken and how to begin fixing things.

Thanks to work already done by rad0n my job is much easier and I can concentrate on enhancements rather than bug-fixes.

Changes that will come with the new version:
  1. Bug-fixes.
  2. NB4R.ahk will compile itself and run the compiled version when you start it. The .ahk script will terminate once the compiled version is running.
  3. The compiled NB4R will run under a different process name each time it is executed.
Once things are up and working properly again with this new version I'll take a look at optimisation, the current code makes frequent use of a large number of cpu intensive api calls.

Wizard Duels - Shared Media for codea spikes

Any images that I need to share I place here.

CastingCircle idle animation


Wizard Duels - References

Here is a list of webpages I've found that may-be/have-been useful when developing Wizard Duels:

Codea Tutorials: Tutorial 5 - Finite State Machines

Codea Tutorials: Tutorial 5 - Finite State Machines: Webcomic Courtesy of  Ethanol & Entropy 5.1 Introduction to Finite State Machines (FSM). Just about every game includes some...

I like the second example, perfect for my project.

Wizard Duels - Concept Part 1

Wizard Duels is going to be my first venture into the IOS game market. The premise behind the game title is that you take the part of a Wizard and duel in real-time other wizards by casting Offensive and Defensive spells.

Spell casting is to be achieved through the drawing of Elemental and Effect runes onto the iPad screen. You can see what you opponent is casting at they draw their own spells so that you have the opportunity to counterattack.


Elemental Runes determine the element type for the desired spell:

Casting one of these runes attunes you to a specific element.

Effect Runes determine the type of attack, defense or attunement you wish to achieve with your spell. e.g.
  • Fire bolt/Ice Spear/Gust/Rockfall ... - you send forth a low damage elemental missile at your opponent.
  • Blast/ - you attack or target with a medium damage attack.
  • Inferno/Maelstrom/Tornado/Quake - a high damage attack
  • Wall - you summon forth a permanent elemental wall that negates a single element type (e.g. fire negates water).
  • Shield - like at wall but a single use defence




Popular Posts


Search This Blog