With the supposed fate of the company still dependant on the success of their crowdfunding project for strategy/role-playing concept Wildman, Gas Powered Games' Chris Taylor has revealed a new piece of tech that is perhaps more interesting than the game itself.
A new video diary update introduces Project Mercury, which is a new web application platform that is being developed in-house at GPG, intending to leverage some of the studio's videogame UI ideas into an application desktop environment, with a client-server model, and supreme-commander style zooming and panning.
Project Mercury is currently being groomed for use as the modding platform for Wildman, but beyond that the features are clearly being designed with wider desktop computing aspirations. Hopefully GPG can stick around to make something out of it.
Watch the video below for Taylor's in-depth overview of the software. At the time of writing, the Wildman Kickstarter project has currently raised $372,004 of its US$1,100,000 goal with 17 days remaining.
Surprisingly cool, though comes with the requirement of downloading all stock-standard meshes/textures/etc to the browser, and WebGL isn't widely supported still.
Ah I see, I figured that your windowed system would probably allow isolation of WebGL components if you really engineered it well, but figured that it's a fairly hefty requirement for a side project so didn't really expect it - so I'm impressed that you did.
The overall system was just so smooth that it also seemed that you may have been using WebGL for the 2D rendering as well, since I wrote the tightest render loops that I could in HTML5 canvas a few years back, and still couldn't manage persistent performance (Could also just be that your machines are better than mine, or that browsers have improved significantly since then, or the effects of caching if you're reusing the same grid image). The case was actually very similar, where I was doing scrolling blocks of infinite procedural terrain, drawing a grid in each block (which later became a wire mesh. Sort like this to this).
Out of curiosity, if you're still around, are you using the canvas print/stroke text functions? Or your own text renderer? I've just been fighting different browser behaviours for stroke/print text, and am considering writing my own text printing library, but you guys seem to be one step ahead of me in general UI capabilities (I've been writing a lot of rendering libraries, procedural stuff, and AI stuff, for an indie project, but am now trying to make a perfectionist's canvas UI library from scratch with slow success).
Posted 12:45pm 30/1/13
Posted 04:17pm 30/1/13
Also, the platform works on non-webGL browers, but if you want 3D graphics - you simply switch to one of the browsers that supports it.
Posted 05:59pm 30/1/13
The overall system was just so smooth that it also seemed that you may have been using WebGL for the 2D rendering as well, since I wrote the tightest render loops that I could in HTML5 canvas a few years back, and still couldn't manage persistent performance (Could also just be that your machines are better than mine, or that browsers have improved significantly since then, or the effects of caching if you're reusing the same grid image). The case was actually very similar, where I was doing scrolling blocks of infinite procedural terrain, drawing a grid in each block (which later became a wire mesh. Sort like this to this).
Out of curiosity, if you're still around, are you using the canvas print/stroke text functions? Or your own text renderer? I've just been fighting different browser behaviours for stroke/print text, and am considering writing my own text printing library, but you guys seem to be one step ahead of me in general UI capabilities (I've been writing a lot of rendering libraries, procedural stuff, and AI stuff, for an indie project, but am now trying to make a perfectionist's canvas UI library from scratch with slow success).