PixelBlitz – It’s time for a fresh start22nd Apr 20092
PixelBlitz was originally released by Norm Soule as a means to help him speed-up the process of creating a game. He graciously released it into the public domain, and shortly after I joined him in expanding and pushing the feature set upwards and onwards.
But for various reasons (mostly to do with the geek annoyance that is Real Life™) Norm hasn’t had much chance to update the engine at all, and I was left pretty much on my own with it. Various things about the way it worked internally bugged me. I was still quite green to AS3 when I got involved, and some API design decisions really show because of this.
Now almost a year later I have a much clearer understanding of how I want it to work. How the API should be structured, how it should sit much better with the Flash IDE. And also how utterly vital documentation and examples are (hello PushButton Engine, I’m looking at you).
So it’s time for a clean break and a fresh start. I will be discontinuing my involvement with PixelBlitz as it stands today, and focusing entirely on building the new game engine from scratch. As of now I don’t know if that will mean releasing under a new name, to keep Norm’s original creation intact. Or if he agrees perhaps we will literally dump the current codebase and replace it wholesale. Right now that isn’t too important. What is important is that I start carefully planning the new API.
While I don’t expect any responses to this final part, I’ll throw this out anyway: If you want to get involved, please email me. I would love to not be the only person working on this.
PixelBlitz – First 2009 Update, lots of new toys and shmup test 116th Jan 2009
This evening I managed to find time to push a lot of updates through for PixelBlitz. This fixes some serious bugs that I introduced last year when trying to optimise the speed of the renderer. It also brings in new methods in the BlitzMath class (my favourite being the excellent wrapValue() function!), the new Box2D Physics classes (lots more on this to come) and the starting classes for BlitzGrid, BlitzDraw and BlitzWorld.
More importantly I’ve started putting the examples source code into Google Code, which I’ve tested and it all compiles against this latest build. So far all of my demos from last year are converted and working, including this new little Shoot-em-up Test. Use the cursor keys to move and control to fire. Firing doesn’t actually do anything, you can’t die, the aliens can’t die either, but I think it shows the potential speed a PixelBlitz game can have, and I’m not even starting to push it yet.
[swfobj src=”http://sandbox.photonstorm.com/ShmupTest1.swf” width=”550″ height=”400″]
Get the latest release from Google Code including the rough and ready source for the demo game above, you’ll see the start of the new Collision Group system in there, which I’ll be evolving this year.
PixelBlitz – Optimised RenderLayer part 119th Sep 2008
Tonight I updated the PixelBlitz Engine with a small but significant feature. I attacked the issue of redundant redrawing of elements, and updated both the PixelSprite and RenderLayer classes so they no longer refresh all of their content if nothing has actually changed since the last render call.
Sounds simple and it is, but it makes a world of difference to the speed of things.
I’ve been researching how beneficial adding a dirty rect system in the engine would be. The problem I have is that it’s all dependant on the type of game. For example a vertical shooter, with a scrolling background and bullets flying everywhere, would have no benefit at all – if anything the extra calculations may even slow it down. But in a sedate game, especially one with large (overlapping) objects, it could be a dream.
So, still in two minds really – perhaps it’s something we allow the user to disable at will.
For now I’m going to optimise the 2DRenderer further by making it only copyPixels() from the area of the RenderLayer that has changed. At the moment it grabs a full sized layer even if the layer only contains say a 64×64 sprite somewhere.
Anyway until then the new code is available in svn.
BlitzMouse right-click capture example16th Sep 2008
sergej wrote a comment to my BlitzMouse post saying that if you right-clicked the custom pointer gets lost until the page is refreshed. Here is some simple code to work around this.
In your main SWF make sure you import ContextMenu and ContextMenuEvent. Then add 2 new global vars:
private var rightClickContext:ContextMenu;
private var contextOpen:Boolean;
and within your init (or constructor) add this:
rightClickContext = new ContextMenu();
this.contextMenu = rightClickContext;
rightClickContext.addEventListener(ContextMenuEvent.MENU_SELECT, contextMenuOpen, false, 0, true);
“this” is a Sprite in this case, but any valid display object (that has access to the contextMenu) will do. The “contextMenuOpen” function is literally just the following:
private function contextMenuOpen(event:ContextMenuEvent):void
contextOpen = true;
and finally, in your main game loop, just check the state of this var and reset accordingly:
if (contextOpen && mouse.isDown)
When the context menu is opened (by a right-click on Windows) it fires the ContextMenuEvent.MENU_SELECT event, which we capture and set a boolean for accordingly. While the menu is open we can do nothing about the standard mouse pointer, but in our main loop we can listen out for a mouse click (mouse.isDown) and then hide the pointer again accordingly.
I’ve not tested this on a Mac (where you can command-click to get the context menu up) so if anyone reading can do so, please let me know if it works.
The SWF below should allow you access to the context menu, but upon clicking the SWF again the custom pointer should return (assuming you click within the limit zone!)
[swfobj src=”http://sandbox.photonstorm.com/blitzMouseTest2.swf” width=”550″ height=”400″]
BlitzMouse Released + Demo15th Sep 2008
After working my butt-off on my latest game I decided it was time to redirect some love and attention to PixelBlitz. So this weekend I finished off a new class I had planned out a while ago. Introducing… BlitzMouse! This pairs up with BlitzKeyboard to complete the input set, and is a feature rich (and very fast) mouse handling system.
Here’s a very simple demo of it in action:
[swfobj src=”http://sandbox.photonstorm.com/blitzMouseTest2.swf” width=”550″ height=”400″]
Press the cursor keys to limit custom mouse pointer movement.
So what can this bad boy do? The aim (as with all things PixelBlitz) is to make working with the mouse in your games easier. Here’s a quick overview of the core features:
Accurate mouse tracking
Keep an eye on that rodent! Easily check if it has left the stage, or re-entered again. Doesn’t use any CPU time processing events that require the mouse if it’s not over the stage!
Button / Click handling
Detect when the mouse button is down, or up.. or being held down. Find out how long it took the user to make that last mouse click (the speed from down to up again). Find out how many clicks the user has made since you last checked. Writing those god-awful “Ninja Finger” style games has never been so simple 😉
Want to know if the mouse is moving up? Just check isMovingUp! You can poll all 4 directions easily and quickly. Want to know how far in pixels the mouse has travelled on the X axis? Call distanceX() – want to know how fast it moved? Call speedX!
To know which angle the mouse is at call angle(), and you can have the result back in degrees or radians. Use the optional “lowerAccuracy” parameter and it uses a much faster calculation, but sacrifice a little accuracy in the process (great for a quick arcade game, not-so for a physics simulation).
You can set the point of the angle calculation (it defaults to the centre of your stage), which allows you to track the angle from anywhere to the mouse. You can even get the angle from any display object to the mouse using angleToObject() (with all the same parameters that angle() supports). This means if you want 3 things all pointing right at the mouse then it’s no problem! (see the demo above) Want to know the distance from any display object to the mouse? Call distanceToObject() and it’ll tell you.
Custom Mouse Pointers
Use changePointer() and you can set the mouse pointer to any display object – with custom X/Y offset support incase the pointer needs aligning differently to the standard top left. As the mouse moves, the display object is updated. If the mouse leaves the stage the display object is made invisible, so you don’t get that “cursor stuck on the edge” problem 🙂
Want to limit the movement of the custom pointer? No problem! You can limit it in all four directions (up/down/left/right) with optional snapBack support on both axis. For example if you were making a Pong game (please… don’t) by just calling limitMovement(true, true, false, false) you will lock the bat into only moving up and down with left/right movements ignored.
Want to limit the mouse to a specific area of the stage? Call limit(new Rectangle(x,y,w,h)) – if the mouse goes outside of this zone it will be hidden from view. You can see this in the example above as it hides when it leaves the light grey box. This limit also effects custom pointers. Of course when the mouse leaves the stage there is nothing you can do about that – but we have to work within the limits of Flash here 🙂
So there we have it – BlitzMouse! Hopefully more useful than you thought when you first read the title, aye? 🙂 I plan to add more features, such as custom events/function calls on mouse actions, the ability to attach as many display objects as you like to it (so they all update at once) and custom zones, so you can have as many “mouse zones” as you want. The code is uploaded to Google, so enjoy 🙂
All about Photon Storm and our
HTML5 game development services
Filter our Content
- Cool Links
- Flash Game Dev Tips
- Game Development
- Geek Shopping
- In the Media
- Phaser 3