30th Aug 2008
Just a small update to the PixelBlitz Engine today, but a pretty cool one!
I’m creating an intense shoot-em-up game as my water shed test of the PB engine. Each day I get to add a few more features to PB that makes the game closer to reality. Once I have reached that point I know we’ll have something truly useful on our hands
Today I added in a backdrop behind my ships and thought “damn, that ought to scroll” – but I figured that PB ought to handle the scrolling for me, automatically – just set it and forget it. So that is what I’ve added to the engine tonight.
It’s a piece of piss to use:
// Continuously scroll this PixelSprite to the left by 4 pixels per frame
Which allowed me to create the following demo in around 20 lines of code:
I’m quite pleased with how this is shaping up You can autoscroll any PixelSprite, with full transparency preserved (so they can be overlaid on-top of other PixelSprites for true glass-window scrolling effects). The PB engine takes care of making the scroll seamless for you, and you can modify the speed on-the-fly (although I’d recommend not to do it every frame if you’ve got a lot going on).
The only issue is that scaling an auto scrolling PixelSprite will mess it up, so I’ll need to remedy that.
It’s now the weekend, but if i get some spare time I plan on continuing my task of fixing the left over issues before cracking on with collision groups and sprite mask tests.
29th Aug 2008
Another day, another update I just pushed my latest changes to the PixelBlitz Engine into svn. Each day it becomes something closer to something you could use to write a decent game with!
Today was mostly boring but important tasks. You can now set the registration point (hot spot) of any PixelSprite object. This works in exactly the same way as setting the registration point of a MovieClip in the Flash IDE, except you do it via one line of code.
There are 9 pre-defined locations (such as top-left, center and bottom-middle), but you can also set any x/y hotspot value you wish (of any size). The hotspot can be updated in real-time, and the renderer takes account of this immediately. If you scale the object it automatically scales the hot spot as well, thus keeping it perfectly aligned.
The term “hot spot” comes from the STOS/AMOS world, where it served the exact same purpose.
PixelSprites will now center themselves upon creation, but you can over-ride this with a single function call. I updated the getDistance() method so it will now report the distance between either the hot spots of two objects, or their x/y values (i.e. top left-hand corners).
Other new additions include:
Scale – PixelSprites can now be scaled in exactly the same way as you’d scale a Bitmap / Sprite.
Alpha – Set (or get) the alpha value of any PixelSprite, in the same way you would on a Bitmap / Sprite.
Smoothing – if you scale the object you can now control if it’s smoothed (or not) during the process.
Tint – you can now tint your PixelSprites! You specify the red, green and blue amounts, but you can also set the overal tint intensity (meaning you can do a full red tint at 50%, so instead of your object turning out completely red in colour, it looks like a proper 50% alphad red tint has been applied.
I also updated the in-line documentation and fixed a bug in the renderer where it would still render an object who’s alpha value was set to zero. Now it doesn’t waste time doing that
Check out the latest version from Google Code:
svn checkout http://pixelblitz.googlecode.com/svn/trunk/ pixelblitz-read-only
28th Aug 2008
After Norm added me to the PixelBlitz project team I worked hard on it tonight, ironing out a number of the issues that were bugging and expanding the library further.
The changes are all in svn (Change Log can be viewed here) including enhancements so PixelSprites now work from Bitmaps, and retain scaling; also added a new super-fast box collision method, a new getDistance method, and various other smaller changes and fixes.
Next I hope to work on opening up more control over the PixelSprites themselves so you can scale, rotate and skew them at run-time (while retaining collision detection of course), and the all important feature of allowing you to set the registration point where-ever you want it to be.
27th Aug 2008
Norm Soule has released the first version of PixelBlitz, his 2D AS3 library that’s geared towards helping you create fast 2D “sprite” based games. I’ve had a good play with it today and this is definitely one to keep an eye on. It allows you turn any movieclip into a PixelSprite, which is essentially an extended bitmapData object upon which you can perform pixel accurate hit detection. PixelClips are similar to sprites except you have rudimentary timeline controls which are useful for animations.
PixelSprites/Clips are then added to a RenderLayer. Items in the Render Layer can be z-depth sorted, have effects applied to them, and be set to enable parallax scrolling. There are 4 effects in the current build, including trails, glowing, fog and a grid effect. To be honest they’re not a massive deal of use as they exist due to the speed hit involved, but you can easily customise them as you see fit.
RenderLayers (and you can have more than one of them) are added to the 2DRenderer, which does all the donkey work and needs to have its update() method called each frame.
This is just the first release, so I’d expect some changes to happen internally, driven by design decisions made post-v1. The system is nice and fast (when you don’t mess with the effects at least!) and is a good starting point if you’ve never worked like this before. It does have some serious limitations though, for example the PixelSprites cannot be rotated, scaled or have their alpha set. You also can’t use masks on them, which is a great shame. I believe this is mostly due to PB internally using the bitmapData’s hitTest method, which itself cannot handle scaled or rotated bitmaps.
It’s lacking in other areas that would make it truly useful right now – for example there’s no way to quickly check for regional collision (i.e. a quad tree system) which means you’re performing pixel level collision on every single object, against every single other possible object and you need to create your own functions to avoid this. As PixelSprites extend the EventDispatcher base class of all things (a truly strange design decision imho!) you don’t have access to methods like hitObject that could speed this up for you.
I’m not knocking the release – it takes a brave developer to throw a library out to the wolf packs of the internet – but I do feel it certainly needs further work before it becomes truly useful for a full game. I’ve already contacted Norm to offer my help, if you’re reading this and would like to see PB turned into a really killer library, then it would be wise to do the same!
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