by InexorableTash » Apr 11, 2005 @ 6:43am
Fundamentally, do you want the graphics being rendered on the client or the server?
If it's the client, you'll need some client-side bits. An ActiveX (if you don't mind being IE/Windows-only) using GapiDraw (as Johan suggests) or another technology altogether - for example, you could look into Flash or Java.
If it's server, then you'll be generating images using your server's available libraries. For example, in ASP.NET you can take advantage of the the .NET GDI+ wrapers (System.Drawing) to generate high-fidelity images on the server.
These are radically different approaches than what you were thinking of, but at the end of the day you're building a web app not a client app, so something has to give - either ubiquity of the runtime or a familiar architecture.
Speaking of architecture, the "AJAX" ("Asynchronous JavaScript and XML") buzzword sweeping the 'net lately is another thing to consider architecturally. The basic idea is to realize that most apps that users want to hit on the web are ridiculously simple and modern web browsers are pretty powerful. So you build a fairly deep script-based application that gets shipped down as a web page and just relies on calls back to the server for anything that can't be done locally.
I recently threw together a starmap navigator that feels like Google maps - you can zoom and drag in real-time. The front-end is all script, and it just requests image tiles from the back end - the server runs ASP.NET and uses System.Drawing to produce the tiles on demand. It only took a couple of hours to get everything working,
For a game, you can think beyond image tiles - take advantage of z-index layering (using CSS) and transparent GIFs or Alpha PNGs to do sprites. Nearly everything would be static, too, just like image resources in a "normal" client application using something like GapiDraw.
As an added bonus, the whole thing functions in "retained mode". Most graphics systems (e.g. GapiDraw in its normal use pattern) are "immediate mode" - that is, you're redrawing everything in every frame, and the logic to draw objects and move objects is tightly coupled. With an HTML-based app, the objects are persistent and you just update positions and let the browser do the dirty work.
And this is now completely off-topic. :)
[Edited: I originally gave the acronym as JAXA not AJAX; I claim being bedridden with an illness.]
Last edited by
InexorableTash on Apr 12, 2005 @ 3:20am, edited 1 time in total.