Sign in to follow this  
Vortico

How do I use my own game loop and directly call draw routines?

Recommended Posts

Is it possible to take advantage of MelonJS's WebGL renderer to make my render calls in a game loop instead of using Sprite objects and other abstractions? Something like

function render() {
	...
	renderer.clearColor('#000000');
	renderer.drawImage(image, 0, 0, w, h, x, y, w, h);

	window.requestAnimationFrame(render);
}

rather than creating states, sprites, containers, etc. MelonJS's low-level renderer looks impressive, but it's hidden behind higher-level classes that I don't need. All I really need are these two functions.

Share this post


Link to post
Share on other sites

Forgive me if this sounds skeptical, but most of the existing abstractions are already lightweight, and you'll just end up reinventing the wheel in many areas. The one major exception is probably the observable vector classes. On the other hand, there's really no requirement to use them, nor any of the physics classes, or particle emitters, or tile maps, etc. if you don't plan to use any of that functionality.

The existing game loop is about as bare-bones as it gets: https://github.com/melonjs/melonJS/blob/acf776161b421d64509c87bbedfe00501104c863/src/state/state.js#L153-L167

The update and draw loops are likewise very light: https://github.com/melonjs/melonJS/blob/97ede483f5798651e7a7c225df2bb77df66a4a27/src/game.js#L262-L363 ... handling various things like pausable timers and accurate frame skipping/interpolation logic. me.game.world is a container which hosts an array of children to update and draw. The complexity that you envision comes from the nested hierarchy of containers, that can build a complete-but-flexible scene graph. The added flexibility comes at the cost of added complexity.

Containers are also fairly lightweight: https://github.com/melonjs/melonJS/blob/acf776161b421d64509c87bbedfe00501104c863/src/renderable/container.js#L758-L849 Everything else in this module is a collection of utility methods to help support nesting. It is conceivable to replace the root container (me.game.world) with a non-nestable container, if that's what you're going for... Which is exactly what the ParticleContainer is. It's unclear just how much benefit you can extract from doing such a thing, but it is certainly an option.

So to answer your question, you just need to determine at which level you want to replace the game loop, and patch out that part. You can either monkeypatch it through the me.game references, or using the builtin patching APIs. And then you need to determine which pieces you need to reimplement for a solid foundation beyond just drawing textures.

Share this post


Link to post
Share on other sites

Thanks for the advice and the links to relevant classes. I have tried reimplementing the game loop and render calls from the implementations in your links while still using melonJS for rendering, and while there are some difficulties, it mostly works. It's still pretty hacky, so I decided to start my clean-room implementation based on what I've learned from using Pixi.js and melonJS in the last couple days, except by directly exposing `renderer.drawTexture()` classes. It's perhaps a useless activity because I'm almost certain someone has written a library to do what I'm doing, but it's taken me just a couple hours and it's mostly done now.

If you're curious, the reason is because my game holds a global state elsewhere, and I'm unable to easily keep a Sprite synced with the state due to frequent and arbitrary deletion, addition, and changing of data that gives rise to certain collections of Sprites. So my Sprite alternative is to have nothing at all since Sprites would have needed to be created/destroyed upon each frame. If you're familiar with immediate-mode GUIs, my game is essentially that (except for all graphics, not just UI elements) using a simple JSON state which is synced over the network. Taking advantage of texture caching and texture sharing optimization is still possible when removing the Sprite abstraction.

Share this post


Link to post
Share on other sites

I am familiar with immediate mode GUI! Never really considered it in the web stack, though. The DOM is already the opposite of immediate mode, and trying to reimplement the entire collection of GUI elements in webGL would be insane. 😅

I also can't see the immediate mode working well with a batching GL compositor that melonJS uses, since the compositor relies on the fact that GL is a stateful API; It tries to optimize rendering by uploading everything early and reusing state often. It is possible to stream vertices to the GPU, though. And that's exactly how dear imgui works.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.