@ToniWestbrook
http://www.twitter.com/ToniWestbrook

One thing that I (and many others judging by forum posts) have run into is the fact that the Blackberry isn’t very good at mixing more than one sound together. You’ll be listening to music, or playing a game with music, and suddenly you’ll get a text message, and it will simply terminate the current sound and play the new one. If you’ve got a friendly application, it will restart/resume the original audio, but it’s a jarring audio experience.

What I’m about to post won’t fix that. However – developers also run into the issue when they want to mix sounds together in their applications and games. Play 2 or more sound effects simultaneously and/or while music is playing. I’ve seen official RIM developers comment that certain devices can achieve two simultaneous sounds by instantiating the Player class twice – but from what I gather, this is on GSM only phones – and still limited to two. On CDMA devices, you’re completely out of luck.

The Cheap and Quick Workaround

In my 6 part tutorial on writing a Blackberry game, in the audio article, I mentioned how the Alert.startAudio method can be used for simple sound effects (tone/duration pairs) that will play simultaneously while your midi or mp3 music plays in the background. For many applications, this is enough if you don’t need sophisticated sound effects.

The Start of a Mixer

I’m guessing that the limitation is imposed by the audio chipset/DAC inside of CDMA devices, and perhaps RIM realizes the CPU time involved in a software based audio mixer would slow the phone down too much. However, I think the software option should be there, and developers can use it if they’d like – they might not need a large amount of CPU, or might be dealing with low quality sound files – there are a few scenarios where a software mixer would just be a nice options.

Tonight I sat down and wrote a quick and dirty proof of concept application showing a PCM audio mixer in action. I loaded in 3 audio 44.1khz 8bit mono files and mixed them together in real time. I didn’t normalize the audio at all, so its a little soft, but the code works, and could be expanded on quite a bit to make a full featured mixer. Maybe I’ll run into problems down the road that RIM already has, but it’ll be interesting nonetheless.

Here is the video of the test:

This and all tracks are available at Synthetic Dreams.

(PS – If you haven’t played Portal yet – go and do it now. It’s a fantastic game, and a fantastic ending song.)

As I finishing up the full version of Galactic Blast (screenshots on this soon, its a fully fleshed out game inspired by the demo, to be released on App World) – I ran into an issue in a strange area. The animation was smooth throughout the game, except oddly enough, on the instructions screen.

The instructions screen in Galactic Blast includes some text describing the storyline, some text describing the keyboard controls, bitmaps showing each of the enemies and power ups with description text, and some credits at the end. Since there’s much more than can fit on a single screen, the user can scroll up and down – nothing fancy, just your basic instructions screen. However, the scrolling was anything but smooth. As I debugged more, I found out that redrawing all the bitmaps and text at each scroll was simply taking too long – all the function and helper calls involved in rendering everything was just too much for the processor.

The Solution

As I thought more about it, I realized that it would be much better to simply render one item instead of 20-30 items each time. And since instructions are static in nature (they don’t change or animate), it was a prime candidate for prerendering all the text and bitmaps to a single, big bitmap. However, I wanted the program to prerender the items automatically at runtime – I didn’t want to have to create the bitmap manually (which would be a huge pain anytime I needed to edit something – like adding a new line of text in). The code below achieves this by creating a bitmap in memory and rendering all the desired text/images to it at the start of the program, and then simply displays (and scrolls) this bitmap on the instructions screen.

The Code

I’ve removed the specific text, bitmaps, and positioning from the code to make things a little clearer:

// _instructionsBM is the large bitmap we will be rendering all our text
// and images to.  This is the bitmap we will actually
// display on the instructions screen, thereby increasing efficiency
// since we're only redrawing one bitmap each time the
// player scrolls instead of a bunch of bitmaps.
private static Bitmap _instructionsBM;

   public static void prerenderInstructions() {
      Graphics tempGraphics;
      String objectiveString;
      Bitmap tempBitmap;
      Object castArray[][];     

      // Populate a string with the objective of the game
      objectiveString = "Text describing the objective of the game  ";

      // Populate an array with the enemy bitmaps, their names,
      // and how many points they are
      castArray = new Object[2][];
      castArray[0] = new Object[] { enemyBitmap1, "Enemy 1", "50 Points" };
      castArray[1] = new Object[] { enemyBitmap2, "Enemy 2", "75 Points" };

        // Initialize the bitmap, and then give it an alpha channel for
        // transparency, allowing the background to show through
        // behind the text and bitmaps
       _instructionsBM = new Bitmap(Bitmap.ROWWISE_16BIT_COLOR, WIDTH, HEIGHT);
       _instructionsBM.createAlpha(Bitmap.ALPHA_BITDEPTH_8BPP); 

        // Start with a blank, completely transparent image
      _instructionsBM.setARGB(new int[_instructionsBM.getWidth()*_instructionsBM.getHeight()], 0,
                                             _instructionsBM.getWidth(), 0, 0,
                                             _instructionsBM.getWidth(), _instructionsBM.getHeight());

      // The Graphics object acts a surface that drawing operations
      // can be performed on.  By calling the Graphics constructor
      // with the bitmap as an argument, all drawing operations
      // will be performed upon the bitmap itself.
      tempGraphics = new Graphics(_instructionsBM);

      // All operations to follow will be fully opaque (so pixels not
      //acted upon will stay transparent, while any text/images drawn
      // will be solid.
      tempGraphics.setGlobalAlpha(255);

      // Draw the text onto the bitmap
      tempGraphics.setColor(Color.YELLOW);
      tempGraphics.drawText(objectiveString, 5, 5);    

      // Draw enemy bitmaps onto the bitmap
      for (int lcv = 0 ; lcv < castArray.length ; lcv++) {
         tempBitmap = (Bitmap) castArray[lcv][0];
         tempGraphics.drawBitmap(Utils.getDimension(5, 50+lcv*50,
                                                tempBitmap.getWidth(), tempBitmap.getHeight(), tempBitmap, 0, 0);
         tempGraphics.drawText((String) castArray[lcv][1], 100, 50+lcv*50);
         tempGraphics.drawText((String) castArray[lcv][1], 200, 50+lcv*50);
      }
   }

Additionally, the link on the blog to the PSX64 firmware now points to version 1.1, the latest update which incorporates the macro and speed fixes. For archival purposes, I’ve left 1.0 and 1.0a in the download directory as well.

Also, hopefully another new track soon, maybe even this weekend!

1. Replaced the Zak Mckracken remix with the Bombo theme as one of the 10 tracks included in Shredz64
2. Since there are now a couple versions of Shredz64 out there (the original had the Stairway Intro as a track, others had the Zak remix, and the new ones will have Bombo) – I’ve made ALL tracks available for download off the Synthetic Dreams website, found here. That way, you can grab any songs you’d like, regardless of what version you have.

This balances out the difficulty range of the included tracks a bit better. All disks shipped out from here on will contain the Bombo theme.

Also, there is a new download track available on the Synthetic Dreams website – Bombo by Ben Daglish. We’ve gotten a lot of feedback from people that the game difficulty is quite high, so I was sure to make this track at an easy difficulty level. It’s a great tune – you can take a listen here.

It means a lot that people are still very interested in this work, so I’ve started by making the following updates:

1. Updated the PSX64 firmware to fix a bug in macro recording, tighten up the analog joystick response, and increase sensitivity for precision game play when a non-Guitar controller is plugged in.
2. Updated the Shredz64 webpage with a downloadable bonus track, the Stairway to Heaven Intro, by Nantco Bakker. This track appeared on very early versions of Shredz64, but was replaced with Edwin’s Dream. Now both tracks can be enjoyed.
3. Since shipping varies wildly, and I tend to make boards as the need arises, I replaced the Paypal button on the order page with a link to the contact page. If you’re interested in ordering a PSX64, simply contact me with your shipping address, and I’ll quote you out the total price.

Thanks for your support everyone!

Use Your MDS to Its Full Potential!

If you’ve taken some time looking through all the thousands of things NX-OS and Fabric Manager can do, you’ll know that the MDS line is amazingly powerful. I’m totally a CLI guy, and I do most of the basic switch configuration in NX-OS, but don’t hesitate to the abuse the hell out of Fabric Manager – it’s a fantastic tool for getting a visual representation of your Fibre Channel infrastructure. And, it gives you a quick visual (both in a textual list and graphical layout) into exactly what device is plugged into what port.

Example FabricManger Layout

Perhaps older switches couldn’t report what device was attached to what port, but if there is no pragmatic need for port zoning, then I believe it shouldn’t be used, as it is NOT aligned to the purpose of zoning. The conceptual purpose of a zone is to define security at the device level – i.e. what device can talk to what device. The purpose is not to be a mechanism for port security. Port security exists at a lower level (or more appropriately, layer, if we think in terms of an OSI-esque model), and should be handled separately and independently.

port-security ENABLE!

The engineers at Cisco are pretty smart people, and they understood the need for port security in a WWN zoning environment. They understood that we, the administrators, deserve the best of BOTH worlds, and they gave it to us. Not only can you configure what WWNs are authorized to be on what physical ports with port-security, but you can also have the MDS automatically learn what devices are currently connected, and set them up as authorized WWNs, expire them, auto-learn new devices, etc.

What does this mean? Quite a bit. We get the ease (and conceptual correctness) of managing zone membership by WWN, MUCH easier migrations, an instant snapshot of exactly what device is connected to what port, and the security of Cisco’s standard port-security mechanism. Maybe I’m crazy (okay, I’m pretty sure I am), but I’m a firm believer that WWN zoning is completely the way to go.

Device Aliases Rule, FC Aliases Drool

A key to making Fabric Manager work the best for you (especially if you’re dealing with a pure Cisco fabric), is to make heavy use of Device Aliases and say goodbye to FC aliases. There are a number of reasons for this, but mostly center around the fact that Device Aliases can be used in most sections of the MDS configuration where pWWNs are used, whereas FC aliases are pretty much per vsan and for zone membership only. Not only does this make configuration easier, but Fabric Manager makes heavy use of the device alias (remember above when we were talking about having Fabric Manager show you what devices are connected to what physical ports? Device Aliases make this work, as then you get a nice readable name instead of a pWWN). Additionally, for you CLI guys and gals, anywhere in the config that a pWWN with a Device Alias is mentioned, NX-OS prints the Device Alias right below it, which is extremely helpful while trudging through lines and lines of WWNs.

You may be stuck with FC Aliases if you have a hybrid switch environment with something other than Ciscos, but otherwise, it’s time to ditch FC Aliases.

Single Initiator, Single Target Zoning

It’s a little more work than making big easy zones with lots of members – but it’s honestly the safest and most technically efficient method of zone operation. There are some times when it becomes necessary to include multiple initiators/targets in failover clusters or other special cases, but other wise – make your zones 1 to 1. This ensures that there is no extra traffic in the zone, protects your other zones in the event that one of your HBAs malfunctions – and safe guards your remaining connections from a server to other SANs should you screw up the configuration in one of the zones. It’s extra work, but it’s worth it.

Feedback!

Most of these are based off of best practices gleaned from Cisco, VMware, and Compellent – but as mentioned, there are debates out there surrounding many of them. Please feel free to share your Fibre Channel thoughts or experiences, I think this is definitely an area that deserves more attention.