This is partly because my full time work does not use nor need PowerShell and my free time has become more precious.

Playing with PS1 has been fun and I’ve learned a lot, but ultimately, it’s just a toy to me, and there comes a time when you must put your toys away — one might argue that, at nearly 40, I should have put my toys away long ago

Now, I’ve been inundated with literally 3 requests for the source code to Grrr, the snapin-based framework behind Big Invaders, so here it is:

Grrr source code

Like the rest of the stuff here, it’s released under the creative commons license.

So long, and thanks for all the fish.

If someone else had a cmdlet called, say, out-banner, and that cmdlet was already loaded in a snap-in (perhaps mandated by site policy), would I be able to register and add the Grrr snapin, which also defines it?

I’ve scanned the available documentation and the language grammar, used introspection in the shell and so on, but could not find anything to deal with this problem.

With projects like PowerShell Community Extensions seemingly laying claim to hundreds of common nouns and verbs, I was concerned that the scope for writing unique cmdlets would dry up real fast.

To determine what would happen, I registered and added Soapyfrog.Grrr, then wrote a new snapin, Soapyfrog.Conflict, with a single cmdlet, out-banner, conflicting with the one in Grrr.

I registered and added this, and was surprised that no warning of a conflict was given. To see if both were added, I tried this:

PS> get-command out-banner

CommandType     Name                        Definition
-----------     ----                        ----------
Cmdlet          Out-Banner                  Out-Banner [-Text] <Str...
Cmdlet          Out-Banner                  Out-Banner [-Text] <Str...

Interesting. Both are available, so what happens when I try to invoke it?

PS> out-banner hello
The term 'out-banner' resolved to a cmdlet name that is ambiguous. Pos
sible matches include: Soapyfrog.Grrr\Out-Banner soapyfrog.conflict\Ou
t-Banner.
At line:1 char:11
+ out-banner  <<<< hello

OK, so at this point, we know it’s possible to break existing PowerShell scripts by simply registering and adding a new snapin with a same-named cmdlet. Not good. Is there a work-around?

PS> Soapyfrog.Grrr\out-banner hello -fg 'o'
o   o ooooo o     o      ooo
o   o o     o     o     o   o
ooooo ooo   o     o     o   o
o   o o     o     o     o   o
o   o ooooo ooooo ooooo  ooo

Yes! We can fully qualify the cmdlet name with the snapin name and a backslash.

So, it’s not as bad as I first feared, but as I noted above, you need to be very careful about how you code and run scripts in environments where you can’t predict what snapins are registered and installed.

I suppose you can create the correct shell environment with Export-Console and run your script with:

powershell -psconsolefile xxx.psc1 -noprofile -command myscript.ps1

Or if your script requires a snapin, add the snapin in the script and fully qualify each cmdlet you use.

Grrr 1.1 is now Cmdlet based and comes as a Snap-In. The most obvious benefit from this is performance, as I can now present a playable version of PowerShell Big Invaders.

BigInvaders is one of the demo PowerShell scripts that makes use of the Grrr.

Download this prerelease version 1.1 of the Grrr snap-in.

Update: this should now install on Vista – thanks to Chris Warwick for pointing out some issues

There’s no installer (yet) so to get going, follow this instructions:

Unzip the archive where you want to use it and CD to the top level director where the README file is.

Type: ./installgrrr.ps1 -r

The -r switch forces it to re-register the snap-in if a (possibly) older version exists. It then adds the snap-in to the current shell.

From here you can CD into the demos directory and run any of the scripts. Each one shows a feature of Grrr, but perhaps the most interesting is in the biginvaders directory.

To run BigInvaders, you need to have a very large console. To achieve this you probably need to set the font size of your console window to 6×8.

If you want sound, you need to install DirectX DirectSound. More on why later.

It should work without, silently, but this hasn’t had much testing as all my XP boxes have it installed If there are exceptions, start it with the -nosound switch.

Assuming all is well, type ./biginvaders.ps1 and you should see this title screen:

Hit ESC to quit or Space to play. In play, Space fires a missile and arrow keys move left and right. Hit F to toggle FPS display in the top-righthand corner.

The target FPS is 33. I achieve this easily on my MacPro, and my wife’s Dell (a core 1 duo, 1.66ghz) also just manages.

There are still a few snags to iron out here and I want to add proper PowerShell help and an installer, but it is functional.

I’ve learned a lot about C#, PowerShell SDK and .NET these last weeks and will write about my findings over the next days. It’s not all been rosy.

I’ll also be writing about the features of Grrr, and where I want to go with it.

That’s it for now.

Anyways, I’ve almost completed the transition of Grrr to Cmdlets and it’s looking very promising as this screen shot shows (I get 50fps with only 20% cpu load doing this):

I intend to redo the original PSInvaders using Grrr, with more authentic gameplay and original graphics.

The scrolling tilemap support is looking good, so games like Gauntlet, Scramble and Super Mario Brothers should be possible… all scripted in PowerShell.

So apologies for the low post volume recently and please do watch this space.

• A snap-in version of Grrr – I realised that PowerShell alone is just too slow for it to be useful, so thought I’d have a go at doing it all as cmdlets in a snap-in. It’s fairly easy, but I’m not there yet.
• In trying to understand the grammar of PowerShell better (the documentation is not so great, and Bruce hasn’t printed his book yet), I’ve started to write an interpreter in Java. I’ve got a more or less complete AST, and a prototype interpreter, but it’s slow going (well, I only started 4 days ago, and it’s in my spare time).

Watch this space.

Grrr is a pet project of mine that came after the exploratory work with psinvaders. I was somewhat dissatisfied with myself for doing so much without seeing how else it could be done, especially with respect to drawing of images, animation, etc.

So what is Grrr? Grrr is a set of functions written in pure PowerShell that let you create playfields with scrolling viewports, draw lines and images, animate and move sprites, and generally be an inappropriate use of the technology.

The version of Grrr discussed in this article can be downloaded from here. Updated versions will appear on the downloads page.
To use, you write a script of your own and source it with a dot/period, like this:

. ./grrr.ps1

I suppose you could do this in your $profile, but I prefer to keep things self contained as PowerShell’s global scope can get very cluttered very fast.

Testing

In the Grrr distribution, there is a very mini unit test framework called psunit.ps1.

The script grrr-test.ps1 uses this to unit test grrr.ps1. Hurrah for test-driven development! The picture shows it in action. Click on it to see the full thing.

To run the test your self, type ./grrr-test.ps1 in the directory where this is unzipped.

Example scripts

There are three example scripts. Run them like he unit test script.

They are:
⁃ grrr-test-clock.ps1 – a simple script that shows back buffering and drawing lines
⁃ grrr-test-sprite.ps1 – shows animation of sprites… some controlled semi-manually, and one by a motion path
⁃ grrr-test-scramble.ps1 – show the use of tilemaps to produce the effect of paralax scrolling.

The latter is very slow and really shows up how poor PowerShell by itself performs.

Have a look at the code, play around with it, tell me it’s rubbish if you like

The next steps for this project are adding a proper game loop controller, with key event handling, fps throttling and a few more motion handlers and behaviours – I’d like for sprites to be able to look after themselves, eg respond to proximity of others, shoot things, detect walls, etc.

I also want to make it faster. Maybe with C# inlining, maybe by making these things cmdlets, maybe by doing it all in C# in a custom host application. Who knows.