Daryl Teo

Gah! What is with all the clipping issues I get? The problem arises specifically at angles close to multiples of 90. I suppose these are problems arising mathematically due to some special trigonometric properties, and seriously hope they get fixed soon.

Again, of course, the library is still currently in Beta status. So it is probably not perfect. However these are the kind of things I’m hoping they will iron out as time goes along.

Unfortunately, I can’t seem to grasp 3D Rendering techniques, and I won’t be making my own engine anytime soon! There goes my Rubik’s Cube idea…

Seems that my contact form has finally been spidered by spammers. Therefore, I will be taking it down, since it is flooding my mailbox.

Some people really need a life… No I don’t need a new ToyAta or a Lexus give me a break!

I’ve been playing abit with Papervision3D recently, and I’m seriously impressed with their work. However, there were some parts I had trouble with, but I’m willing to let it pass, as it is still in Beta status. Seemingly trivial things like “changing the textures of each side of a cube” seems to require some subclass. And in some cases, I still found evidence of bad clipping. Though that is probably my fault.

Over the next few days, look out for my wonderous journey in learning Papervision3D.

Recent speculation suggests that the Adobe Flash Player plugin would be coming sooner for Apple iPhone’s Safari sooner than we’d thought/dreamed.

I can’t even begin to speculate the amount of possibility this opens up to flash developers. This is perhaps far more revolutionary than WiiFlash! Imagine the touchscreen capability of the Nintendo DS, opening up to the Flash platform, allowing for a whole new slew of creative works for Flash. One thing I’d definitely want to see, if the above does turn out to be true, is a port of Ouendan!.

That aside, though, there will be a number of things to think about. Firstly, public adoption of the iPhone seems rather low at the moment to me, due to price and also network restriction. Not to mention its only only available in the US. The other interesting thing I’d like to see being taken advantaged of would be the iPhone’s Multi-Touch technology. Most “WiiFlash” games that take advantage of the WiiMote are no more than glorified Flash games using the mouse. How would Flash developers be able to take advantage of the different Multi-Touch capabilities?

Although this may never come, its still something worth keeping a tab on.

I was recently alerted to a new marketing effort by XGen Studios, asking people to guess the name of their new game.

And I believe I may have guessed the name.

The clue gives a direct letter swapping. Thus it would be most possible that the first and last words are similar. Also, the most logical word for the middle is “the”, meaning that “e” represents “s”.

Thus, the best combination I could get is “Pillage the Village”! So if this is right, I got it right here first!

As everybody knows, not keeping track of referenced objects is BAD. And the one thing worse than not keeping track of referenced objects is dead references.

For example, if you had an instance of an object, you must dereference everything associated with it before it is garbage collected. This may seem like child’s play to most veterans; things like event listeners are easily removed. However, it is important to note that in the case of DisplayObjects, your DisplayObject may have children that are also referencing it (through the ‘parent’ property). Removing the DisplayObject at this stage will therefore result in dead references to its children and itself! You’ll end up with massive amounts of memory leak as time goes along.

Luckily, there is a handy Event you can use. The Event.REMOVED Event fires when an object is removed from the display list! So with a bit of code, one can easily remove all children when it is removed from the display list.

this.addEventListener(Event.REMOVED, iveBeenRemoved, false, 0 , false);
private function iveBeenRemoved(e:void):void
{
   while (this.numChildren != 0)
   {
      this.removeChildAt(0);
   }
   this.removeEventListener(Event.REMOVED, iveBeenRemoved, false);
}

Simply one of the things we might overlook in our coding practices. I myself will try to remember about child objects.

Recently I’ve begun my foray into the web developing world, where I was asked to develop a site for a small start up company. After a year of operation, my client decided it was time to revamp the website in order to impress her bigger clients. “Flashy” was the buzz word thrown about during our initial discussion regarding the redesign.

By that time I had already decided to investigate AJAX technologies, and apply them to this project. (Some of you who know me might know how much I shun Full Flash websites, and was reluctant to use it despite the term “flashy” used a few times). And in a short time I was using the MooTools JS library to perform most of the grunt work.

Having the MooTools library granted me a considerable speed boost in developing, and I had an impressive and “flashy” gallery frontend coded in 2 nights (that surprised even me, a newbie in this arena). By that time I was hooked. Images were loaded dynamically, with images resizing and fading into view. Then the terrible blow came when I passed it on my friends to try it.

Lo and behold, it died. Turns out my site doesn’t render very well in some other browsers. Not only that, it was completely inert without Javascript!

Thus I embarked on a google-quest for the holy-grail, and came across numerous articles on both sides of the epic battle. It was then that numerous “flaws” of AJAX was revealed to me. But the main problem, however, was me! I was abusing AJAX, and that worked against me. Which brings me to the first point: just because something can be done easily doesn’t mean you should do it.

The speed at which I was developing AJAX lured me into thinking that I could use it for the entire site. This meant that it suffered from many userability issues that was prevalent with Flash websites. I was falling into bad habits again without noticing it!

And what are the problems?

• Firstly, one cannot guarantee that Javascript is enabled.
• Secondly, most experienced internet users would be most comfortable with the “backspace” or back button. AJAX destroys this functionality. Sure , there are workarounds for it, but it doesn’t do the job half as well. Furthermore, if a person were to press the back button, and go forward again, you lose data that he was trying to access previously

Of course, one could easily build 2 version of the site. But while that allows Javascript to gracefully degrade, it doesn’t take away the problems associated with abusive AJAX in the first place.

So my conclusion is that one should always take care not to abuse AJAX. Building entire sites for public view is not a good idea. However, so called RIAs or Web Applications use AJAX as a given. The key here is being able to distinguish between an Application and a Site. If all you’re making is a site, you’re better off not using AJAX for anything at all.

The best way to look at it is to imagine yourself using your site. Turn off Javascript. Then try navigating your site. If you have difficulty, its time to rethink your strategy.

Recently a flash game was published on a site which I frequent, and as a result it riled up a few members of the community. Now, flash games of all varieties have existed for many years. Gory and violent games that could rival Manhunt can be commonly found. But this particular SATIRE touched on a topic of controversial nature, and after a series of events, the game was eventually taken off voluntarily by the developer, although it can still be found on other sites.

A few issues come to mind. Why is it that Flash Games seem to be free of the regulation constraints that plague our mainstream games? Similarly, why aren’t websites that distribute these games required to moderate their content, especially since Flash Games can reach a much wider audience, far wider than your mainstream game, and is distributed faster and to an enormous demography of internet users?

Another big issue is that of opinions. Who could be responsible for rating these games? Efforts in this area such as TIGRS depend on the developer, and do not enforce this. Some of them are simply tedious and require too much effort on the developer’s part to even bother. And just because a developer does not find his game offensive, does not mean that everyone else will think the same.

Thus, the question in the end is “what does the future hold in store for us developers”? How long more will we be able to enjoy this freedom on the internet? And what can we do to ensure developers can enjoy this luxury?