On Different Render Contexts

[Kevin Palis]

Hello Brett,

As I've mentioned before, we are developing a MMO-RTS game with
different views/screens and of course, a persistent world. Currently,
I'm having problems deciding which contexts to draw/add elements on.
So far I have been adding elements and implementing animations on a
single canvas. But upon looking on other games (like gskinner's
PiratesLoveDaisies), I figured that there might be an easier and more
efficient way to write our game. So I need your insights on these
first.
Is it better to use multiple canvases than just draw on a single one?
And is it better to use divs for the menus and buttons than just draw
them in the same canvas? I was thinking of having multiple contexts:

* Screens (ex: Help, Credits, About, and other menu panels) -
HTMLDivContext
* World Map / Battle Map - VirtualCanvasContext (initially I was
eyeing ScrollingBackroundContext but I found out that it's not in the
sources anymore, so I'm assuming that you changed it to
VirtualCanvasContext along with the way on how to use it, is this
right?)
* Menus and Other "Static" Buttons - HTMLDivContext

The thing is, all of them should appear in a "big" box, so most
elements will be overlapping with different opacity levels. Do you
think there's any advantage to this approach? I was thinking that it
is better to use HTMLDivContext/HTMLContext in conjunction with
Virtual/CanvasContext rather than doing everything inside a single
Virtual/CanvasContext because the elements inside the HTMLDivContext/
HTMLContext won't be adding extra processing load (ie. updates,
redraw) to the canvas(es) as they won't be inside any canvas in the
first place; and I will still have the DOM to manipulate those HTML
elements (especially with the jQuery effects).

I noticed that the current RenderAPI (v2.0.0.8a) is quite outdated
(ex: VirtualCanvasContext and VirtualElementContext are not yet
included). May we ask for the latest API? or should I just generate
them myself? I'm not yet familiar with JSDocs but I can start
reading. :-)

Lastly, I encountered some problems with dynamically setting the z-
index of elements. I'm not sure if this is already fixed as I haven't
updated my renderengine sources since July 1. I'll try to update later
and if I still encounter them, I'll post the error message here.

We're hoping that you can shed some light on these concerns. Thank
you!

[Brett Fattori]

Determining which contexts to use is really up to you.  The different contexts serve different purposes, each with their own pros & cons.  The canvas context is a purely graphical context which is ideal for drawing imagery and doing pixel manipulations.  Whereas the HTML contexts are also good at drawing imagery, care must be taken to avoid excessive redraws of the context and instead update an object's representation in the context so as to not create too many elements in the DOM.

That being said, The Render Engine does support multiple rendering contexts at one time.  Each rendering context is added to the render pipeline, the same as objects within each context.  However, doing so might not be advantageous when just rendering a user interface.  While the canvas now has support for UI form elements, it isn't the ideal way to do form input or rendering.  You could draw your user interface, independent of the render pipeline, using just jQuery and the DOM.  In fact, this might be the idea way to draw a user interface - it's really up to you.

The API is a bit out of date.  I'll see about updating it and getting it published.  I would recommend getting to know JSDoc so you can generate your own API documentation.  I'll also see about adding the build files that I use for the documentation as a download.

- Brett

--
You received this message because you are subscribed to "The Render Engine" group.
To post to this group, send email to the-rend...@googlegroups.com
To unsubscribe from this group, send email to
the-render-eng...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/the-render-engine?hl=en

[Kevin Palis]

Hello Brett,

Thanks a lot for the response. I have only been reading discussions
here so I haven't been able to have a clear overview of the engine
process until recently - when I read http://code.google.com/p/renderengine/wiki/EngineProcessOverview
:-) So now I have more understanding of how things work inside the
engine. So I'm following your suggestion of having the user interface
outside of the render pipeline. There will be a LOT of things to
process per frame and it will really be better if the menus, buttons,
and other parts of the user interface will not be adding extra load.

As for the API, we will really appreciate it if you can share the
build files that you used for your documentation. We can also use that
as a basis for generating ours, if you don't mind. :-)

Anyway, we're glad that you already released a beta version. We'll
help in submitting bug reports.

Thank you.