Input Components & Behaviors

I've been wrestling with the different types of rendering in The Render Engine, trying to keep the two in sync so that it's really ubiquitous as to which way you go: either canvas or DOM.  The problem is that events were "simulated" in the canvas and were "actual" in the DOM.

Down, but not Out...

While my provider let my domain name lapse, I want people to know that I'm still working on The Render Engine.  It was, for a while, not a priority as I was starting a new job.  However, a unique opportunity at my job allowed me to use the engine to create a demo for one of our clients.  Since then, I've been asked to enhance the engine more.  I expect to commit the revisions to the engine soon.  I found a number of things, mainly around DOM rendering, which needed to be tightened.  Additionally, I implemented autonomous steering behavior components which I intend to include.

I haven't forgotten about everyone - even sent an email to the appMobi folks to let them know that the engine is at GitHub so they could update their links.  When I get a moment, I'll put the old site there too.

v2.0.0.11 beta (Beta 2)

I have created a download for the next beta release.  I've also updated and uploaded the API docs for the current version.  As usual, please post any issues you run into on GitHub.  Thanks.

Get it: renderengine_2.0.0.11b
Get the docs: renderengine_2.0.0.11b (API)

New joint types

Just wanted to let folks know that I've just completed adding pulley, prismatic, and weld joint types.  I also did some refactoring to clean some things up.  Getting close to another beta soon...

Tutorial 14 - Data Storage

I have finished the tutorials by adding Tutorial 14 for data storage.  This tutorial demonstrates using TrimPath SQL which is included with the engine.  It exposed some issues with data storage objects, which have now been corrected.  Additionally, I've compressed TrimPath Query, and done some renaming to be consistent across files in the "/engine/libs" folder.  This concludes all of the tutorials I wanted to get done for v2.0.

If anyone would like to see some additional tutorials, please let me know in the comments.

Tutorial 12 - Physics

I just committed the Physics Tutorial to the repo.  It's just a simple example of setting up a simulation, adding rigid bodies, and getting them to animate.  I also made some changes to the tutorial naming for consistency.  Finally, I noticed a couple of bugs in the PolyBody component.  The first was a bug in the world scale division value.  The second, which is still unresolved, is that the polygon isn't rendering where the physical body is located.  There's an offset that exists that I need to resolve.

Refactored Tutorials and Small Updates

I've completed refactoring of the tutorials and only have two left to create (Physics and Storage) before I'll say they are completed.  I ended up splitting up what used to be tutorial 11 into two tutorials so I could demonstrate convex collisions and particles separately.  I don't want to combine too much into a tutorial which might end up confusing someone into thinking that two unrelated functions are somehow related.  I hope to get the Physics and Storage tutorials completed shortly, but it's a factor of how much time do I have.

In addition to refactoring the tutorials, I have made several small tweaks to the engine which were usually related to bugs I've found.  There are also some new methods added and old functionality cleaned up.  The engine continues to get more stable as the days go on.  Look for another beta shortly, as it feels about right to do so.  I haven't had the time to focus on the Level Editor, but I still plan on getting that completed for the final v2.0 release.

My website continues to be down which is extremely upsetting.  I really have enjoyed having a website for free for a long time, but it's probably time to find somewhere to host it.  Really all I need is a PHP host, and only in the very most basic sense of needing PHP.  I hope to have the website back up and running soon.  Also, the documentation is getting a bit outdated so expect that to get regenerated and uploaded soon too.

v2.0.0.10 (beta 1)

I know I'm kinda sneaking this out there, but I've released what I'm calling v2.0.0 beta 1 (officially v2.0.0.10).  The website is still down - I'm so pissed it's not even funny.  I'm losing followers on a daily basis and it's kind of hard to make a release without a website to back it up.  My emails and inquiries have fallen on deaf ears.  I guess this is what happens when hosting is free, eh?

Anyway, this is really just a version change and a ZIP build of the engine.  I just found myself really wanting to tag this because it's mostly there.  Please start hammering away at this and submitting bug reports.  I'm going to focus on the 2D tile map level editor from here on out.

Website Still Down

The Render Engine's website is still down.  I'm starting to get a bit frustrated, due to the fact that I really can't release v2.0.0 as a beta unless I have a site to promote it on.  I've spoken with my server host and he assures me it'll be up "soon" which seems to be code for "when I get around to it."  I guess I shouldn't complain about it... the site is hosted free and the domain costs me $1.00 annually to renew.  But it is frustrating, as I said.

UI Controls

Something new in The Render Engine v2.0!!  I've added a new demo which showcases the new UI controls in the CanvasContext.  They are still early in development, but when I abandoned the UI concept a while back, I figured it would be something people would accomplish within the browser with jQuery or something similar.  However, there isn't a good way to get UI controls, especially input controls, into graphical contexts.  There's now a new demo for them.  It only functions in Chrome right now, but I'll get it working in the other browsers soon enough.

Recent Changes - Nearing Beta

I finally got level saving and loading working, using object serialization and deserialization.  Objects now have the ability to serialize themselves into JSON, then back again which makes saving and loading a lot more robust.  I've split the 2D tile mapping demo into two parts - one with the editor and one without.  This will help with understanding how the two are related.  Additionally, I pulled comments from all of the JSON files because it was causing headaches that I didn't want to deal with.

Latest Progress

Sorry about the lack of posts, especially while the main web site has been down for a while.  My ISP is working on the issue.  The RAID array has been giving him multiple problems, so he's swapping it out with a new array and will have the site back soon.

The Render Engine Level Editor has been progressing nicely.  I've been battling with how to make the editor work, exactly, because everything is hosted in the browser.  There isn't a server side component to it which makes it a bit difficult to come up with how, exactly, to launch it.  It isn't a game of its own and instead functions as a game add-on.

Level Editor

I've been working on the Level Editor for The Render Engine for some time now.  It's really starting to come together.  It has core functionality in it which allows you to draw actors (sprites) and levels (tile maps) in the interface.  Right now it's still in its infancy, but it's starting to feel like an editor.  Eventually it will be how you set up a level for a 2d tile mapped game.  You can try it out by grabbing v2.0.0 from GitHub and firing up the Tile Mapping Demo.  When the "game" loads, press the F4 key and you should get the editor.  It isn't very intuitive right now, but it at least shows progress.

Updated Demo & Particle Emitters

I've updated the vector demo over at The Render Engine web site.  It now includes a particle emitter component on the asteroids.  I sped up the rotation of the asteroids so the effect is more evident.  I'll probably slow them back down in the future.  I also want to add some jitter to the particles themselves so they don't look so organized.  Go check it out here:
http://www.renderengine.com/demos.php

What's the Scoop?

Recently it's been about experimenting with The Render Engine.  There are a lot of things I want to do, but only so much I can do so that I can get a beta ready.  For those who haven't seen it, I uploaded a zip file containing the v2.0.0 docs to Github.  I've been working with raycasting and tried an experiment with a layered rendering context.

Raycasting and Collision Model Querying

Over the last few days I've added ray casting and querying to the AbstractCollisionModel class.  Ray casting is the method of tracing a line through a collision model and determining what objects the ray intersects.  Querying is a way to test the collision model for objects which satisfy a certain condition.  Ray casting can be used for quickly determining if something, like a bullet, would impact an object.

v2.0.0 Demo

I have updated the demo page at http://www.renderengine.com/demos.php with an updated version of the Vector Demo (Asteroids Evolution).  It has always been my testbed when it came to how the engine performs.  I base all of my performance testing on it because it demands so much in so many areas of the engine.  Newly added is the Accumulator Particle Engine which accumulates particles and fades old ones out over time.  The Mover2D component was updated to adjust to reduced frame rates and not feel sluggish.  The perfomance is almost identical to the demo from v1.5.3.  In fact, if you run them side-by-side, you should notice that they are nearly equivalent.  However, the v2.0.0 engine is doing so much more behind the scenes so it's a testament to its capabilities.

This update includes a number of things that v1.5.3 didn't have:

• Abstracted sound engine
• Accumulator particle engine
• Native screen redrawing with requestAnimationFrame()
• Performance improvements in Math objects
• SAT-based collisions
• Saving/loading of high score from localStorage
• Frame rate adaptive mover component
• ... and more

Virtual D-pad

Just a quick post to say that I restructured the engine a little so I could enable a virtual d-pad on touch devices.  Currently works on my iPad (but not on my HTC Thunderbolt).  Also corrected a bug in the Sprite resource type to correspond to the changes I made to R.math.Rectangle2D.

Oh yeah, one more thing... I put an "index.html" file in the "/demos" and "/tutorials" folder to make it easy to launch those.  I needed it because I was working on my iPad and typing in the full path was a pain in the backside.  You will be happy it's there because it's a quick reference to each demo and tutorial.

Sylvester & Speed

I've got some great news for The Render Engine!  This morning I did some optimizing for the engine that has resulted in a big speed improvement.  Since the beginning, The Render Engine has depended on Sylvester for it's 2d and 3d math.  While Sylvester is a fantastic library, it is generalized for solving a multitude of mathematical problems involving vectors, matrices, lines, and planes.  This generalization, while good for accurate calculations, is bad for performance.

Engine Stepping

This morning I was able to add a small bit of code that allows a developer to step the engine a frame at a time when the metrics panel is being displayed.  I plan to use this to profile single steps of the engine to find areas where large sums of time are being spent.  I also have a fix, from last night, that I thought I committed (but didn't) which cleans up some things, enables native frame requests, fixes IE9, fixes a bug in pooling, and also deprecates set- and getHostObject() in favor of set- and getGameObject().

IE9 Fixed, Updated HTMLContext

I have finally gotten some time to look at why IE9 wasn't working.  I knew it didn't support __defineGetter__/__defineSetter__, but didn't know what the alternative was until just last night.  I got everything that was working in the other browsers working in IE9, but the demos run slow.  For all of the brouhaha about how IE9 supports hardware acceleration, I'm not that impressed.  It used to run everything almost as fast as Chrome, but now it seems it runs it at 1/2 the framerate, if not worse.  Plus, Firefox seems to be running slowly too.  It may be due to the way I'm handling z-depth, but I'm not sure.  Need to do some profiling.

Yesterday I spent a considerable amount of time looking at the HTMLContext.  I have made numerous updates to it and cleaned some things up.  Plus, I added a demo for HTMLContext to the "/demos" folder.  I think this holds a lot of potential, but I'll need to figure out how to tap it properly.  Combined with the RenderUtil's capability to render to a temp canvas context, then extract imagery, it might be a way to get good performance out of the browser.  I'll have to see about that one.

Faster, better animation

I just pushed a change to The Render Engine so it will use the browser's native requestAnimationFrame() call if it's available.  Currently this is an engine option and defaults to false.  You can see the difference by changing the option in the Vector demo's "engine.config" file to true. According to Paul Irish's blog post (http://paulirish.com) it allows the browser to optimize the redraws.  Also, if I read correctly, I can target the actual rendering context and it will only perform the optimizations for that context.  I need to test that claim, but so far, this is a nice change!

TileMaps, the beginnings

I posted an update to Github today to fix some issues that popped up in the Linker.  It seems a lot more stable now and should resolve initialization issues people were seeing.  The Sprite Editor now has copy/paste enabled.  Why I forgot to do this earlier, I don't have a clue... It was fairly simple to add.

Pooling and Linking

Engine pooling has always been a foundational element of The Render Engine.  Saving time and memory due to object pooling is something that I think makes the engine more robust.  However, I realized that the pooling was being overused.

v2.0.0 Nearing Beta!

I've gotten The Render Engine v2.0.0 to a point where I'm just about ready to label it a beta.  The Sprite Editor v1.0.0 landed yesterday and will be followed with an update, shortly, to allow importing of sprite sheets and also importing frames from other applications.  As I said, in a previous post, a number of features will not be included in v2.0.0, but will follow in a point release.  I want to get this puppy out the door so people can start using it, and I can retire the v1.x branch.

Exporting and Animations

The Sprite Editor is still moving forward.  It's amazing how much has changed in just a few days.  I can now export to a PNG file, importing is starting to come together, and the beginnings of multiple animations is in the works!  Good stuff for all.

Sprite Editor, v2.5, and more...

I spent a goodly amount of time, yesterday, on the Sprite Editor.  First, converting it to the v2.0 code base, then fixing some nagging bugs, and adding some new features.  Nice to see that Chrome finally fully supports all of the canvas methods.  I was playing around with it, and seeing how usable it is and I'm pretty happy with what's starting to form.

Our New Home

The Render Engine has moved from Google Code to GitHub!  I've completed moving the v2.0 branch to GitHub and it is available now.  Further development will occur in Git and be pushed to GitHub regularly.  All development at Google Code will cease from this point forward.

The new location is @ https://github.com/bfattori/TheRenderEngine

Old versions of The Render Engine will remain at Google Code for historical purposes.  At some point I might move the old versions over to GitHub, but for the time being they will stay with Google.  Bugs for v1.5.3 and older should still be submitted to Google Code (I'll receive notifications).  Going forward for v2.0 and beyond, please submit issues at GitHub so I can properly associate them with the project.

For everyone that said, "if only you'd move your project to GitHub, I'd get involved..." well, now's your chance! Please do get involved and help me to advance the engine faster than I can do it alone.  I'm still learning Git, so be patient with me!  I've been a CVS and SVN user for so long, it's going to take time.

A note regarding demos and tutorials:  The demos currently run out of Google Code.  I will be moving those to the www.renderengine.com domain soon.

Moving to GitHub

The Render Engine, starting with v2.0, is moving to GitHub!  There have been enough people asking about this that I've finally decided to leave Google Code (our home for the last 3 years) and move to GitHub.  Hopefully this will mean that people will get involved and help to move the engine forward while I'm not available to work on it 100% of the time...  Expect the move to occur sometime in the next couple of days.

I tried to get it set up, but something on my work machine is blocking SSH.  Ignore the two failed attempts at creating the git repo, the official move will occur soon.

https://github.com/bfattori

Long time, no dev

Firstly, I have to apologize to all those who are waiting on v2.0 to get completed.  The engine has been getting a lot of attention, but I haven't had much time to work on it lately.  I really miss working on the engine because it's a source of stress relief that helps me to unwind and is a great way to keep my skills sharp.  Unfortunately, I have been doing a ton of contract work after hours.  About two months back I signed on to help a small company develop content for a digital magazine.

Things have been quiet...

Lately, I haven't been able to set aside enough time to work on the engine and do all the maintenance (blog, website, etc).  But I wanted to let people know that I'm still actively working on the engine and will post some new stuff soon.  I've been working on a tile engine and an editor for it.  Plus, there are many optimizations which have been taking place within the code.  I really need to do a commit to the repo soon because I hate having so many files in an updated state on my machine only. =/

Just saw this: http://www.ie6countdown.com/

HTML5

I remembered seeing the W3C logo for HTML5 somewhere...  found their builder and built a badge for The Render Engine.  It's about time I gave some love!

Tiles and Sprites

I've been working through getting a way to do raycasting into the engine.  While doing this, I created a Tile resource type which contains a solidity map to assist in detecting per-pixel collisions.  However, after going through all the work to get a new class created, which extends from Sprite, I realized that Sprites themselves should probably have the functionality too.  I guess I'll probably end up rolling this all up at a later date.  While I'd like to have a distinction between sprites and tiles, I don't know if it makes sense to have a class just to represent that.  Maybe it'll come down to a flag to indicate type.  In the end, I hope to get a tilemap renderer worked out so I can create tiled levels with ray casting and pixel-perfect collisions.

Absolutely AWESOME Article

Maryrosecook, who is writing Pistol Slut on top the The Render Engine, wrote up a fantastic article complete with pictures, pseudo-code, and JavaScript which describes the process of detecting collisions.  You can view it by going here.  It's a good read and quite impressive... To answer a couple of questions she posed, the technique for determining bullet collisions that she describes is known as "raycasting".  Additionally, determining the direction for a shower of sparks at the point of impact uses the "surface normal".  I am always amazed at the things that she has been able to do with the v1.0 engine!  I think I also need to add some sort of way to do "sweeping" (I believe the raycasting I plan on adding will do this) but I want to get it into v2.0.  She has had to learn the hard way... you n00bs are going to have it so easy with v2.0.  =)

Firefox 4.0 b11 - Impressive!

After sobbing a bit about having to create a separate class to handle IE property getters and setters, I decided to upgrade my current beta of Firefox to 11 and give the engine a quick run through.  I have to say, I am impressed!  The JavaScript engine is much faster and the overall experience was buttery smooth (except when the number of animated objects got pretty high - say 125 particles and 40 visible objects).  Overall, I am happy with the changes to the browser's JavaScript engine and memory handling.  It's getting on par with Chrome for performance within the demos.

Internet Explorer 9 woes

With the release of Internet Explorer 9 RC1 today, I decided to update and take a look at how the engine is performing in this shiny new beast.  To my dismay, I found that __defineGetter__ and __defineSetter__ don't work (supported, but don't work)!

Bummer...

Refactored components

Last night I decided to refactor the components. This has been something I've wanted to do for a while. Components were getting messy because they were all bundled together in one package. With the new namespace, it now makes more sense than ever.

Busy, busy...

I started a new job this week, so I've been busy with getting up to speed.  I think this means that for the next week or so I'll be slowing down on development.  It doesn't mean that I'll be stopping entirely, just that new features/optimizations in 2.0 will come out slower.  Don't worry!  Your favorite JavaScript game engine is still in development.

If some of you are feeling comfortable with the engine code and have ideas for how to continue moving it forward (maybe even at a faster pace) let me know about it.  I've already received a lot of positive feedback and good ideas for The Render Engine!  Even if you want to take on developing tutorials or demos for the engine, let me know about that too.

Box2dWeb Physics Engine

The Render Engine was using a customized build of the Box2DJS physics engine, which has now been replaced with Box2dWeb.  This makes using the physics engine a bit more simple, even though there was one place where it created a class collision.  I had to modify the code so that it didn't end up clobbering the Sylvester Vector class.

The only issue now is that to have physics, your game will need to load a 200kb file.  It's not the ideal solution, but it takes some of the worry about keeping up to date with the library.  If Box2dWeb is updated, I can drop in a new lib and get any fixes or new features, whereas before I had to mix and match the code if there were going to be any updates.

I've converted the PhysicsDemo to use the new physics lib, but it still needs some tweaking.  It also exposed an issue with R.struct.Container's append() method.  There appears to be an issue with it where it will create a circular reference and send the JavaScript VM spinning out of control.  I'm looking into that and will hopefully have an update soon.

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.