Johan Peitz - Let's make SOMETHING

Pixelizer

What is Pixelizer?

Pixelizer is a component based framework for writing games in AS3. That means that you have base entities and that you write little components for them. Components can be anything from game logic to rendering to whatever you can imagine. As all standard components and entities are already in the package, it is very easy to get started and getting your game on to the screen should be a breeze. I am aiming to make Pixelizer really flexible, reusable and extendable. The main rendering technique in Pixelizer is currently blitting. Blitting is a fast way of displaying hundreds of objects with virtually no slow down. However, as Pixelizer is very extendable, writing another type of renderer should be easy - it that's what you want.

Features

  • easy extendable component based framework
  • nestable entities for easy manipulation of groups
  • lots of premade components and entities
  • fast 2D rendering
  • automated collision detection and response
  • spritesheets, animations and tilemaps
  • recording and replaying of input streams
  • prerendering of movieclips
  • automatic panning and volume of moving sounds
  • exact mouse and keyboard input
  • fancy text rendering
  • handy math routines
  • effective object pools
  • useful logging

Examples

As Pixelizer becomes more and more mature, I hope to add build a library of examples that explains how to use it. At the moment there are only a few examples available (including a game) but more will come. Please check out the examples here.

License & Distributon

Feel free to look at the code and use it in your projects. If you do however choose to use Pixelizer, please give me some credit somewhere. I'd also be happy to get feedback if you see something crazy or want to improve it.

Also, please do not redistribute Pixelizer.

Latest version & Documentation

Pixelizer is on GitHub! All the latest code is there, just make sure you get the master branch unless you want to see the absolutely latest. Get get it: https://github.com/johanp/Pixelizer

GitHub is also a good place to see where Pixelizer is going, what the next version will hold, ask for changes and report bugs.

The latest docs can be found  here.

Feedback

All though Pixelizer is quite stable and shouldn't change too much, it is still under development. If you have any ideas on how to make it better or any feedback at all - please let me know!

Comments (33) Trackbacks (2)
  1. This is amazing! Two small suggestions:
    1) Please put this on github, a lot more people will have access to it.
    2) Also, a HaXe port would be much appreciated.

    • Thank you!

      1) Absolutely! It’s on my list.
      2) Probably. I’ve been looking at HaXe a lot but never got around to dive into it. Anyway, I want to make Pixelizer awesome for AS3 first, then we’ll see if it’s worth porting. :)

  2. It’s funny because I have been working on my own component engine in HaXe for about a month once I stumbled over Pixelizer. Let’s trade ideas and concepts later when I publish mine :3

  3. Cool engine! I’ll definitely dive in this code and want to help port it to HaXe.
    I’ll write you in a week or two about it.

  4. Hey, looking great. I’d love to give this a try. But I have no clue how…

    • Thanks, it’s not that hard. :) You need to know how to code in AS3, then just add pixelizer to your source tree. To get the grasp of how picelizer works, browse the examples. I will try to put up a tutorial on how to make a basic game here soon!

  5. Hi Johanp!
    I made first commit to repository with the haxe port (https://github.com/Beeblerox/PixelizerHX)
    All examples are successfully compiles to flash target. And almost of them are working on C++ target (currently there is the problem with spriteSheets which uses movieClip assets).

    • Wow, that was fast!

      • I have little experience in this area :)
        There is a huge place for rendering optimization on c++ target, because bitmap manipulation is really slow. I’ll try to create new one specially for c++, but it will take much more time.

  6. Hi johanp, I’ve read about the API document, but find
    little information about Tilemap format.
    Can Pixelizer read tilemap files created by other editors, like DAME or Tiled?

    • I’m afraid the tilemap are quite poorly documented at the time. The reason for that is that they are not tied to any specific format. I hope to support as many formats as possible in the future but at the moment you should be able write your own, it’s not that hard. :) More info on this will come soo I hope!

  7. Nice! I’ll take a look at it! :D

    Btw, I am missing a ‘subscribe to this blog’ widget here :(

    • Cool! Not sure what you mean by subscribe… There’s a rss feed available at the top right corner of the screen. Good enough?

  8. Wow this is really amazing!
    I love all your allegro games like spacehog, alex, klabutong. These were the games that made me want to create my own. I finally released my game “bungluwa” last year (http://www.newgrounds.com/portal/view/545717). It was written in AS3 and so it will be a real pleasure for me to try your new framework as well!
    Keep on rocking johan!

    • Thanks for the kind words! Happy to hear that you make your own games. I played a few levels of Bungluwa – nice work!

  9. Hey, I’m just starting to work on a Flash game after meaning to get around to it for ages, and downloaded Pixelizer first thing – absolutely loving it, and thanks so much for providing this great framework!

    I’ve found one thing that’s stumped me a bit so far. On first loading up the engine, you have to offer a scale. I’ve set this to 1, as I don’t want my images to be scaled up from their current size. However, this has made the PXGUIButtons tiny!

    I tried scaling one of the buttons up, like this:

    rollButton = new PxGUIButton( “Roll!”, onButtonClicked );
    rollButton.transform.setPosition(320, 200);
    rollButton.transform.scale = 4;
    addEntity(rollButton);

    The button scales up, but the collision box doesn’t, so the button only works if you click the upper left corner. I had a look in the PXGUIButton class and I *think* this is because the PXBoxColliderComponent is only called in the constructor of PXGUIButton, so the box is getting created at the button’s original size, and then isn’t getting set to the new size.

    Is there a better way I could be doing things to avoid this issue, or a simple way to fix Pixelizer so that it scales up the collision boxes appropriately when a transform is carried out?

    Thanks again – I’m pretty sure without your framework I wouldn’t have managed to get my game partially running today.

    • Hi there! Glad to hear you’re putting Pixelizer to good use! You’re doing it right, but the problem is with the current version that collision boxes do not scale with the transform scale (nor rotate). I’ve put it on the issue list now so it will be fixed in the future! Until then various hacks include replacing the font in the button to a bigger one, or resize the collision box manually.

      • Thanks for the quick reply! Glad to hear I’m using it correctly. How do you resize the collision box? If there’s an example of doing this in the Examples just point me towards it. Thanks again!

  10. Definitely need some benchmark on entity frameworks, Ember, Ash, Xember and now Pixelizer…

  11. Hello,
    Is Pixelizer still moving on? Or it is given up.

    • It is absolutely moving on! But quite slowly these days since I’ve recently became a father. Check the github page for the most recent activity.

      • My congratulations! I also recently became father and understand how it is hard to do something :)
        I’m new with Pixelizer, should I learn 0.4.3 ver or I can to learn 0.5 ?
        (fast question – 2d renderer it is stage3d or blitting techniques) ?

        Thank you

  12. Thanks! I’d go with 0.5 as it is much more future proof and just as stable. It’s using blitting, but the render system is set up to be exchanged with stage 3d in the future with little to no code changes in the games.

  13. Hi Johan,

    I’ve been looking at Pixelizer’s collision management and resolution routines and am wondering why in the boxToBox solver method in PxCollisionManager you only push in the “smallest direction.”

    I’m imagining two boxes hitting each other (both having x and y velocities) and the resolution not being correct if the separation only happens in the smallest direction. If you could explain why this separation works it would be very helpful.

    Thanks.

    • Scott,

      thanks for your question! The ideal case would be to push the boxes away from each other in the opposite direction of the collision. However, since each collider isn’t required to have a PxBody (where the velocities are stored) the collision system has no idea of these velocities.

      It all works as long as movements are small. If the boxes passes eachothers’ centers, they will be pushed through each other instead of blocking.

      Room for improvment!

  14. Hi Johan,
    I’m learning to work with Pixelizer and have a few questions. I guess you should to update asdoc for new version (0.5) and write a few basic tutorials to understanding how to organize game with Pixelizer :)
    1. If I understood right PxScene is a thing where game happens, isn’t it? Can I have multiple scenes and in what cases it is need for me?
    2. What is PxSystem? Can I organize logic modules of game (like game loop, collision interactions, different screens (splash, choose level, game over etc.)) in different PxSystem classes? Or what PxSystem is?

    Thanks a lot

    P.S. Can I write questions about Pixelizer here or exist more appropriate place?

    • 1) Yes! The scenes are organized in a stack, so you can easily push the game scene on the menu scene, and the options scene on the game scene and then drop back to any previous scene.

      2) Yes! You probably don’t need to write your own ones at first, since the engine comes packed with systems for input, rendering, collision, etc.

      Questions here are fine. :)


Leave a comment