Posts Tagged ‘PixelBlitz’

• By Rich

  Tags

  PixelBlitz

  Posted in

  PixelBlitz

  3 comments

  BlitzKeyboard is live!

  2nd Sep 2008

  3

  After a mammoth coding session tonight I have committed the first version of BlitzKeyboard into the PixelBlitz Engine.

  I’m really happy with this work – it’s pretty much everything I’ve ever wanted from an advanced keyboard handler 🙂

  So what can it do for you? In short it’s about saving you time. At the core is an extremely fast keyboard event handler, so all you need to do is ask it if a key is pressed or not:

  [as]
  if (keyboard.isDown(BlitzKeyboard.LEFT))
  {
  player.x -= playerXSpeed;
  }

  if (keyboard.isDown(BlitzKeyboard.RIGHT))
  {
  player.x += playerXSpeed;
  }
  [/as]

  Simple. Fast. Efficient. Of course if that was all it could do it would be nothing special – but it can do so much more …

  Multiple Key Support
  Accurate detection for one, two or three simultaneous key presses, including Location support. That means you can check for the difference between the left shift key and the right shift key. A full range of constants are built into the class, so rather than remember which keycode relates to which key, you just use our constants list. This list has been extended to support Enhanced keyboards, so you’ve got it detecting the Windows (or Apple Command) keys as well as the Application key.

  Set the Key Rate
  In an arcade game you need to pick-up the key presses as fast as possible, and BlitzKeyboard does just that. But you can also configure a Key Rate, so if you only want a certain key to fire once every second then that’s no problem.

  Bind Events or Functions to Keys
  You can set a key (or key combination) to fire an Event or call a Function. You control if the Event should fire when the key/s are pressed down, or fire on the release (when you let them go again). You pass in the Event and then set an event listener to listen out for it, and it handles the rest. It even takes the Key Rate into account, so your Event will only fire at the frequency you set.

  Wait Key support
  Say you need to wait for the user to press a key before proceeding with your game – then just use the waitKey() function! You pass it an Event and a type, and the next time a key is pressed the Event is dispatched, no matter which key caused it.

  Key Hit Counter
  Want to know exactly how many times a key has been pressed? Then call keyHit() on it and this method will tell you just that.

  I’ll be adding a few final features, and preparing the demos in the coming days. But the core class now exists in Google Code for the curious.

  Next up is BlitzMouse which will handle advanced mouse events – things like mouse zones, reporting on how fast the mouse is moving, scroll wheel handling and more.

• By Rich

  Tags

  atari st, demo, PixelBlitz, scrolling

  Posted in

  PixelBlitz

  3 comments

  PixelBlitz Engine Update: AutoScroll support with demo

  30th Aug 2008

  3

  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:

  [as]
  // Continuously scroll this PixelSprite to the left by 4 pixels per frame
  pixelsprite.autoScroll(PixelSprite.SCROLL_LEFT, 4);
  [/as]

  Which allowed me to create the following demo in around 20 lines of code:

  [swfobj src=”http://sandbox.photonstorm.com/pbscrolldemo.swf” width=”640″ height=”400″]

  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.

  Here is the source + FLA.
  You’ll need to checkout latest revision (v21) of PixelBlitz from Google Code to compile it though.

• By Rich

  Tags

  PixelBlitz

  Posted in

  PixelBlitz

  0 comments

  PixelBlitz Engine Update

  29th Aug 2008

  0

  

  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

• By Rich

  Tags

  PixelBlitz

  Posted in

  PixelBlitz

  0 comments

  PixelBlitz first hands-on

  27th Aug 2008

  0

  

  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!