touch my pixel

After realising we have a few people following us on RSS we decided to start publishing it in a way we could see how many people that actually is. So we’re now publishing through FeedBurner. If you’re already following us it would be great if you could change the address to:

http://feeds.feedburner.com/TouchMyPixel

Thanks!

And lots more coming very soon …

So after installing windows 7 i’ve had to reinstall all of my goods, the probem (ithink) is that installed flashplayer BEFORE Flash. This meant that installed its old flashPlayers over the top of the newer ones, so that i installed some of the newer ones AGAIN, and in the mess of many installs, i found that my FlashDevelop wasnt using the debug player anymore! gah!

Problem: FlashDevelop wont use the dubug version of flashPlayer when in popup mode (you need this to have trace’s come back to flash via ExternalInterface)

So, in reinstalled the debugplayer standalone about 5 times, in various varieties, before realizing that: FlashDevelop uses Ie’s ActiveX version of the player for popup mode

Solution: Install debug player for IE

since i dont really use IE, this was slightly overlooked, but now it all works fine. Just a little bit of knowledge that people might want to know

Tony

For a new game I’m designing, I’ve been learning a little about particles. Its actually really simple to get some great effects. I found a good as3 lib http://flintparticles.org – but in the aim of learning, and due to the fact that i need to use haxe not as3 (planning to target iphone) i’ve started from scratch. Ive only implemented a Gravity Well, and Gravity – but plan to add some magnets, simple collisions, brownian motion and maybe particle to particle attraction.

A few important things are:

• Rendering direct to bitmap- not using MovieClip or Sprite – as they kill performance
• Using copyPixels over draw – again for performance
• Using an Object Pool, for less memory and garbage collection issues in the future
• Created an ‘effectors’ interface for applying multiple effects to particles
• Frame independant (time based) motion for more predictable performance

so lets see a test:

Update: Here’s another example – not in the source, but just adding a colorTransform- fun fun!

heres the haxe code: download

cheers,

Tony

After the haxe meeting last saturday night, i was excited that the topic of targeting the iphone was brought up. This could cause a lot of adoption of haxe as a language. Being able to develop games for flash and Iphone at the same time would be perfect and something lots of flash game developers would love!

I tried my hand at compiling c++ into and ObjC wrapper a few weeks ago, and in my inexperience… failed miserably. Hugh (the haxe C++ target creator) has taken the challenge, and in the last few days, successfully made some first tests for haxe C++ on the iphone. Hopfully over the next few weeks everything will continue to come to plan (and more people just on bord for testing and dev) and we’ll have an iphone target

I cant wait to get a chance to do some testing (looking to buy a macbook next week when we go to LA for e3).

read about it here:

http://gamehaxe.com/2009/05/22/haxe-on-iphone-simulator/

cheers

Tony

In 2d platform games, you often want to have the different layers or graphics move at different speeds depending on the players movement. As you also probably know this is called parallaxing.

Your layers might be for example: a forground, midground (where the player often is), and multiple backgrounds. As the player moves around in the midground, you will want that layer to move as to keep the player in the middle of the screen. The foreground layer will want to move MORE, as to have a faster movement (looking closer) and the background less, as to look furthur away. Lets look at an example:

In this example the red dot is the “player” which is placed inside the midground (layer2).

It makes sense that closer layers move more- and distant layers move alot less. This means that your closer layers will need be bigger. Since size it directly related to the movement, and therefore their percieved distance on the imaginary Z axis – in our example we’ll define a layers disance via its size. In the above example, the layers are as follows:

They have been given a black border to illustrate their size, this would normally be invisible so that it doesnt show in the test. The rect of a layer is set automatically via getting the layers ‘bounds’. You have the option to set the rect manually. This can be useful for cropping into gfx, cleaning up the edges , etc.

You may notice that there is an AS3 version of the test AND a haXe version. The haXe version uses the example.swf (generated by flash) for the gfx. It will not use any code from flash – its code is in the src_hx folder.

I’ve started to think about how to allow the ‘camera’ to zoom in and out on the scene… that’ll be a test soon.

Download source code here

We gave a talk about the making of Scarygirl last night at Dissecta at the State Library of Victoria, Melbourne.

It went pretty well – couldn’t see too many Zs floating up above the audience’s heads. Thanks to Dissecta for asking us to speak and we’ll be seeing you all again for the next meet in a month or so!

The outline for the talk can be viewed at: http://sg.touchmypixel.com/dissecta/. Just click at the left and right of the slides to move through. Interactive elements can be used (after clicking on them) normally with the arrow keys, space, shift, and A, S and D keys (all of them use different controls, sorry).

Here are the best images we got, really should have got some better documentation! On the left Tarwin Stroh-Spijer & on the right: Tony Polinelli

After only a day or two playing in hxcpp i’ve got my first little test to show – Jellyroids!

This gametest compiles (using haxe) out to flash & C++ (exe in the cpp folder for windows only – i dont have a mac or linux, so cant test as yet).

Running the software rendered c++ version is a little slow – ~200fps on my comp, opengl is ~1500fps. Whereas flash clocks in at 100fps (maxed out). Prerendering the explosion animation (currently vector animation from a swf) will make it MUCH faster for c++ (stop the slowdown on shoot), as i feel its vector animation code isnt anywhere as optimized as that in flash.

Overall, its fun to see how easy its been to get out a simple test in hxcpp.

download the game test here

cheers – Tony

UPDATE:

to get it to work you need to change a few small things in the neash 0.9. realease.

hxcpp?

We've been recently looking at expanding our skills of games dev, to finally break out of Flash! (The whole platform that is.) Looking at Unity3D (seems to be a great platform) but also interested in getting a little closer to the root of most great games... C++.

Coming from a web background, and developing in Flash for about 10 years, I don't want to abandon all of my existing knowledge, and quite frankly, after learning C++ for a few days, it looks kinda clunky - or maybe just scary ;P

Luckily, Hugh Sanderson has been developing a C++ target for haXe (the open source Flash compiler) which after a little testing seems to look like it will take a LOT of the pain out of the transition.  For those who don't know, haXe is a multipurpose compiler, it can compile code, similar to ECMAScript, to many targets. Some of these being:  SWF bytecode (which out performs the Flex and Flash compilers),  JS, PHP, and more. This new C++ target will allow people to build a game which can compile to a SWF & C++.  Why would would a C++ and SWF output be good you ask? If PC, Mac and Linux arn't enough, iPhone can natively run c++ for instance.  If we want to make a game which will need more performance than Flash can offer or just want to target C++, at the very least it will allow us to develop games in the same style, and code base, as our existing efforts.

Many of the technicalities are still being worked on as the project isn't fully released as yet, but there are some great 2D tests, and some varying in progress OpenGL 3D. I was amazed that Hugh has even included a SWF reader in neash which will allow import of SWF assets and animations to your C++ games - wow!

Getting stated with hxcpp (haXe C++)  with Visual Studio C++ Express

I've been through some trials working out installation (as I've never compiled C++ before),  so i thought it would be good to share my findings for other noobs ;P

So without further adieu here's what you do.

haXe installation and setup for hxcpp

1. Download and install haxe
2. Access the the windows command prompt (console): Start->Run->"cmd"
   note you will have to close and re-open the command prompt after making any changes to environment variables before they will take effect in the command promt
3. Type "haxelib install hxcpp". This will install the hxcpp library for haXe.
4. Type "haxelib install neash". Installs the neash library.
5. Type "haxelib install nme". Note this may already be installed as a dependency.
6. Open your System Properties dialogue (Start->Control Panel->System), go to the Advanced tab, and then click Environment Variables button. Here we'll be adding some environment paths. You can add them either in the User variables (the top list, which will only work for the current user) or System variables (the bottom list, which work for all users).
7. Set an environment variable called "HXCPP" by clicking New under the list and entering Variable name "HXCPP" and Variable value to hxcpp install directory ie:  "C:\Program Files\Motion-Twin\haxe\lib\hxcpp\0,4"
8. Add "%HXCPP%" to the PATH variable, making sure that it is seperated with a ";" and no space.
9. Add "%HXCPP%\bin\Windows"  to the PATH as well. This is so haxecpp.exe can be found.
10. Type "haxecpp" in the command-prompt to check if it finds the compiler

Microsoft Visual Studio C++ Express intallation and setup

This is how to setup MSVSC++ for command-line compiling:

1. Download and install Microsoft Visual Studio C++ Express from http://www.microsoft.com/express/vc/
   Once these are installed, we need to set up some Environment Variables to help it work. As far as we can tell it's meant to do thi stuff itself, but never seems to.
2. Add vc\bin (location of vc.exe) to the user PATH  eg: "C:\Program Files\Microsoft Visual Studio 9.0\VC\bin"
3. Type "cl" into the command-promt. This will see if your C++ compiler is working correctly. It will probably throw an error, saying that it cant find some DLLs.
   1. If you get the error run the cl setup eg:  "C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\vcvars32.bat"
   2. Run "cl" again. If you still get the error, follow next step.
   3. Add Visual Studio 9.0\Common7\IDE to the user PATH (similar to before)  eg: "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE"
   4. Run "cl" again, and you should get the compiler usage message.
4. Add an environment variable INCLUDE which points to the vc/include folder eg: "C:\Program Files\Microsoft Visual Studio 9.0\VC\include"
5. Add an environment variable LIB which points to the vc/lib folder eg: "C:\Program Files\Microsoft Visual Studio 9.0\VC\lib"
6. Add another path to the LIB variable to points to the folder containing kernel32.lib eg:  "C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib"
7. For the hxcpp 1.0 release you also need another step
   Add another path th the INCLUDE which points to the SDK Includes - eg.   C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include

Now you should be ready to compile some C++!

You may find you have to restart your computer for the Environment Variables (PATH etc) to take effect globally in your system. No idea, but restarting Windows seems to fix it.

Hello World Test

make a main class

Main.hx:

I tried to get hxml files working on my system (assign 'open with...' to the haxecpp.exe, but it kept reverting to haxe.exe) so you can use a simple batch file as follows. Note the "-cp" command tells the compiler where to find the standard libraries for the new hxcpp.

make_cpp.bat:

This should compile the haxe, compile the cpp, run Main.exe and pause to show your trace.

Compiling the neash and nme examples

Remember to check out the neash and nme examples (found in the haxe/lib/xxx/samples  folders)  to see how to get started.

Just make a make_cpp.bat which compiles the haxe, as the .hxml would have, then compiles as per the previous example

Compiling with FlashDevelop

In flash devlop you can use the Build tab (project->properties->build) to set off the haxe & c++ compilers this will allow you traces in the results tab too. Use the make_cpp.bat from before:

in the build put:

make_cpp.bat
cpp/Main.exe

This will put all trace commands in the results panel. If you start to do things like include files, or loops - basically most more advanced things, the results might start to not show up - I'm not too sure how to keep them coming up in here - like how neko examples have a window for traces, and a window for the app - Hugh - any ideas?

Remember that you might need to restart FlashDevelop for all PATH and Environment vars to take effect

Also, Check out GameHaxe for more about hxcpp

Now that i've got this all working, i just need to find some time to make something cool!

Cheers,

Tony - Touch My Pixel

Its finally time! The Scarygirl project has been in the works for about 2 years, in production for about a year and a half, and in my nightmares for quite a while. So, we are slightly excited to see it out in the wild... and not on our todo lists

We have been surprised by the reaction so far, 200,000+ plays in the last 3 days. We've had to upgrade servers twice, and are rapidly making some fixes to bugs and improvements to gameplay.

As a bit of background, the project is based on the concepts and designs of Nathan Jurevicius. He is a comic artist from Melbourne, Australia, but living in Toronto. The character Scarygirl has had quite a journey over the last 10 years, but is finding her feet in this online game (Funded by Film Victoria & Passion Pictures), soon to be released graphic novels, and an upcoming feature film. We had the opportunity to work on the project due to our friend Suren at Renmotion, and his contact with Nathan.

The project has stretched our skills and through its arduous process, we've learned a lot about planning, designing and developing a game. TouchMyPixel is only two people (Tarwin & myself) so the project was a huge workload. We have a background in Flash development, design, and smaller advertising style games, but not a larger scale game of any sort. Scarygirl, in its essence was only planned to be a 9 month project (sorry Sophie), but I think, in our excitement of making a "proper game", not what people generally see a flash game to be, we overshot the timeline a little. We tried to give the game a depth which most Flash games don't have, as it seems most flash games are focussed on being small, fun snippets of a game. We wanted to produce a full experince. I think everyone on the project felt this way, and wanted to push themselves and the project.

The game is quite artwork driven, which is obviously one of the major requirements (being to promote Nathan's artwork). This challenged us with the task of designing a world which would well reflect Nathan's irregular style while keeping farmiliar game mechanics. We spent a lot of time finding ways to faithfully display his artwork. For instance, we wanted the character to be able to walk over irregular surfaces, surfaces we could quickly mockup in Flash to match to the artwork as needed.

Our first stage was conceptualizing what each level would entail (or even if there were "levels"). Nathan had given us a basic ideas for some levels, and a pre-release of the graphic novel for story reference. Then it was up to use to sketch out some levels. We wanted to incorporate adventure game elements to highten the journey aspect, but also keep with traditional platform style gameplay. From sketches of characters, we would decide how they would fit into the world and react to the player. After producing mock levels without artwork (see non-graphical demo), we handed over level designs to Nathan to have them beautified. At this stage we often had NO IDEA what a level would look like, which gave us the joy and sometimes suprise when we finally saw what a level really looked like; we may have just drawn a small brown patch for tree which would come back as a beautiful peice of art. This was wierd, and made level design hard, as we really didnt have much of a concept of what we were designing, or more to the point were worried that our concepts was wrong.

Progression of level design: 1. sketch  2. level in Flash  3. artwork overlay  4. final product

After getting the graphics and adding them to levels, we found that the game ran at about 1FPS. Which was a slight issue. This brought us to the stage of optimizing, refactoring, and rebuilding all of the levels to work with graphics. In the end all of the level graphics are pre-cached as tiles of bitmaps (starting as vector to save download), as the level might be up to 20,000 x 20,000 pixel in some cases. The bitmaps then have effects such as noise and glows applied to more closely replicate what Nathan is currently doing with his art. Some levels such as the peninsula (Escapade) have multiple levels of background and foreground. We then started adding the animated characters and enemies and found they too slowed the game to a carwl. So all of the animations needed to have each frame pre-cached as well, and kept in a frame cache in memory. Every sprite then works off the same frame information. With all of this caching some levels started to take up to 600mb of memory... which was the next issue. After overcoming the many trials of technically getting the game working, gameplay testing and debugging proceeded for about five months.

As i stated earlier, we've learned a lot about planning and developing a game, and think we'll fair a little better in the future. As for Scarygirl, a standalone version might be on the horizon. We'd also love to look at other platforms too, such as iPhone; not sure if i want to learn Objective C too quickly though.

Well its good to see it released. We are still be making some notable tweaks, and are taking users comments into account, so the job still isn't over yet, but there's light at the end of the tunnel.

cheers

Tony - TouchMyPixel

When AS3 came out many people, myself including, were frustrated and confused by the lack of a quick and dirty function to check whether a key was down (pressed). You can have a listener that gets fired when a key is pressed and see which key it was within that function. This could lead to someone putting all their key behaviour code in one spot which could become quite messy.

The best way to fix this is with a class that does all the heavy lifting for you. Without any any further ado here's the test. Use the arrow keys, space, z and shift+z to try it out [source]:

more »