Awesome Speed Gains!

I completed my updates to broad-phase collision and the SpatialGrid.  In addition, I removed the "spatial" package and put the classes in the "collision.broadphase" package.  The speed gains are very noticeable on Firefox 3.6!  Overall, I was able to cut down processing time by doing the PCL caching and sharing, plus I modified R.struct.Container and added a new append() method.  This method appends one container to another by chaining the head of the second container to the tail of the first.  It's a destructive method, but useful in this situation, and it's a big speed improvement.  Additionally, I was able to drop two loops from the PCL construction method which sped things up even more.

Optimizing Broad-Phase Collisions

As I mentioned yesterday, I had an "ah-hah" moment when I realized that objects were rebuilding their potential collision list (PCL) over and over.  Plus, each time it would rebuild these lists it would also create a copy of all of the objects in a collision node before adding them all to the PCL.  So, after some work I have come up with a way to perform some caching and optimizations of PCLs.

Interesting "Discovery"

Discovery is in quotes because my revelation was actually more of a palm-face when I thought about it.  I was doing some optimizations in the engine when I noticed something that smacked of an "area of interest."  In the Asteroids Evolved demo, whenever I had all five bullets on screen in Firefox 3.6, the game would slow down by a factor of 2x to 2.5x!  At first I was wondering what would cause such a noticeable slowdown and then it hit me.

What's the Purpose?

One user mentioned that in other game engines, GameObject is the root class but in The Render Engine it is HostObject.  I decided to take his advice and create R.engine.GameObject, from which R.engine.HostObject is now derived (so instanceof checks should still work).  HostObject is deprecated in favor of GameObject, so get used to it... ;-)

Recent Developments

Hey folks, been really busy lately with my "real life"(tm) so the engine hasn't gotten as much love as it could.  But, rest assured it'll be getting some soon enough.  I cleaned up most of the documentation, but still have to get to the physics engine for conversion to the new namespace.  I've also done some optimizations which were causing excessive repetition of calculation.  One example is the new convex hull collider component...  It was performing an early-out test using simple circle-to-circle testing to see if a collision could even occur.  When it was determined that they might, if the actual hulls were circular it would do the same work again.  Very wasteful...  Correcting this resulted in a small, but noticeable speedup.

API for v2.0.0.5a

I have uploaded a ZIP file of the API for the new version of The Render Engine which is in development.  The API contains all of the class documentation for anyone who is currently testing or developing against the latest version.  The API is subject to change.

Render Engine v2.0.0.5a API

Scriptable events and variables

SpriteActor will be the foundation of 2D platformer style games.  Along with  the Level Editor, it will be used to construct a game from a configuration object and your game's framework.  To accommodate this, I've started adding scriptable events and variables.  Using the Level Editor, you'll be able to put a SpriteActor into your game level and then script things on "onInit" and "onCollide" which will allow you to tweak your game logic from the Level Editor.

Criminey!

Seems that when I changed how the Level Editor was organized, yesterday, I forgot to commit a couple files.  As it is now, the editor isn't loading.  Too bad since I've added even more functionality to it, including Import and Export functionality and an actor "Action Panel" with the beginnings of setting up actor defaults.  Oh well, tonight I'll get it committed and y'all can play with it and give feedback.

Level Editor

Hey there... been a while, eh?  I've been away for a while, both for work and because I've been pretty sick.  But lately I've been feeling better and had some time so I fired up the engine and got the Sprite Demo working with the new namespace.  In doing so, I also got a renewed interest in the Level Editor for 2D platformer style games.  I spent a fair amount of time getting things reorganized and cleaned up.

Almost Done!

The refactoring is almost complete (I still need to do physics, demos, tutorials, and tests) but the Asteroids demo is working with the new namespace, as is Tutorial 1 in both Chrome and Firefox.  Everything appears to be working as expected.  There's a shiny new "R" object on the DOMWindow which contains all of the engine classes.  Yay!

Refactored Again

I just committed the v2.0 updates (as they stand so far) which has taken me the better part of a week to do.  I still haven't touched the physics package.  I was able to get the vector demo (Asteroids Evolved) running on Firefox, but not in Chrome.  Tutorial 1 is also converted and running in Firefox.  So, for the time being, v2.0 is very sick but is getting better all the time.

Everything is different.  Yep, I introduced the "R" namespace, renamed some of the classes, renamed all of the components (removed "Component" from the end of the class name), moved some files around, and did other things to make my life very difficult.  Trust me, it's taking a lot for me to get used to it.  I've been working with this engine since 2008 and it's a huge change to do what I've done.  I'm still making mistakes when I write class names.

Anyways, if you're curious you can look at the code in the v2.0 repo.  There's still time that something might change, but I'm thinking that this is how the final layout will look.

Oh yeah, biggest change was the namespace but it also allowed me to change the Linker.  Yep, now Linker is a very simple class which uses the predefined class dependencies to determine what needs to be loaded.  It doesn't do any parsing or symbol table checking.  It's a lot faster and it's a lot simpler.  You can write your code in more ways than you used to be able to (however, I suggest keeping it clean).

Feedback is appreciated.

v1.5.4 Cancelled

I hate to do this for anyone who was waiting for v1.5.4, but I've decided to cancel it.  v2.0 is such a big priority to me that unless some major bug shows up in the current release (v1.5.3) I probably won't be touching that code branch anymore.

Again, apologies to anyone who was waiting on it.

Namespace, Part Deux...

Okay, well, that didn't exactly go as planned.  While setting up the namespace, I have also been trying to clean up the Linker.  I have been removing the calls to Engine.initObject(), but I just realized (after completing 95% of the refactoring) that it was going to blow chunks the first time I tried it.  It comes down to the fact that I'm using Base.js by Dean Edwards to set up my OO model.  As such, a class definition looks like:

var ClassB = ClassA.extend({
   ...
});


Due to this, ClassA must exist, otherwise calling the extend() method will fail with an exception.  There has to be some sort of delay before it checks to see if ClassA exists!  Well, after some hemmin' and hawin' I think I've settled on an acceptable alternative.  Now each class will look like this:


var ClassB = function() {
   return ClassA.extend({
      ...
   });
}

Not as pretty as before, but I can eliminate the need for the Linker to do as much work as it has been doing.  This will cause a lot less hair pulling when trying to get your game running.  Plus, instead of R.Engine.requires(), I'm changing it (so soon?) to something like the following:

R.Engine.define({
   "class": "R.collision.OBBHull",
   "requires": [
      "R.collision.ConvexHull",
      "R.math.Point2D"
   ]
});

This goes at the top of each class file.  What this does is it allows the engine to know that R.collision.OBBHull has two dependencies.  It can wait until those two dependencies are initialized (loaded and their dependencies are resolved) before initializing.  For those who wish to know, when it's time to initialize:

R.collision.OBBHull = R.collision.OBBHull();

Tada!!  Thoughts?

Namespace for The Render Engine

I'm in the process of giving The Render Engine a namespace, and reorganizing the way that objects are included so that the Linker isn't a thorn in developers' sides.  The new namespace (for the time being) will be "R".  I know, not very inventive but it's short (and being a developer, I hate typing).  Additionally, files are getting renamed left and right.  For example, now the components are like the following:

Transform2DComponent => R.components.Transform2D

Also, when you want to use the component, it's gone from:

Engine.include("/components/component.transform2d.js")

to:

R.engine.Engine.requires("R.components.Transform2D");

And the filename is now:

"/engine/components/transform2d.js"

Originally, I had figured that a namespace wasn't necessary since a game should really be the only thing running in the browser (along with the engine).  If people wanted to have 5 to 10 libraries loaded, and the game, and the engine, and things conflicted... well, that wasn't my fault.  But, as one user pointed out, even if I accounted for naming conflicts with browser objects, there may be naming collisions with a game's objects and the engine's objects.  So, here I am doing a huge refactoring.  It's going to be as big of a change to me as it will to you. Eventually, this will help me to fix up some of the drawbacks of having the Linker do excessive checks.  This will all affect v2.0 of the engine, which I feel will be a major improvement over v1.x.

Now that I'm looking at it, I think I'll also move R.engine.Engine => R.Engine.  No reason to put it into the "engine" package...  That will simplify some things as well.

Browser Storage Objects

The website is back up and running.


Today I finished the implementation of PersistentStorage and TransientStorage which use browser-based localStorage and sessionStorage objects.  On top of this, I found the TrimQuery API which supports a nice SQL-like syntax for querying and modifying the data.  PersistentStorage is used to maintain data between browser sessions, whereas TransientStorage exists to provide a place where current session data can be stored. TransientStorage provides a mechanism which would allow a developer to store data and retrieve it with SQL, rather than simply storing it in many JavaScript objects.

TrimQuery supports a wide range of SQL-like syntax so a developer can put data into multiple tables and perform simple joins to get aggregated data.  I can see a developer using this to store data for their MMO, or to store configuration information about keyboard setups and other things.  I've updated the Asteroids Evolution demo to store and retrieve the high score using PersistentStorage.

You can try it here.