Dynamic sprites
by John Pritchett · in Torque Game Builder · 07/27/2005 (9:33 am) · 2 replies
It would be useful to have options for working with the sprite canvas in script. Currently, you create a sprite and associated it with an image map datablock and a frame within that image map. I would love to be able to build a sprite using multiple image maps. This allows the graphical resources to be minimized. This can currently be done by mounting multiple sprites, I know, but in the interest of efficiency it would be better to be able to composite images onto a single sprite rather than link multiple sprites together.
Here are the commands I'd like to see added to the sprite (all varieties) object:
1) copy - Draws a frame from an image map onto the sprite canvas, optionally using alpha blending.
2) copyRect - Same as 1 but you can specify a particular rectangle for the source and destination.
And while I'm at it ;)
3) Pixel - set a point
4) line - draw a line
5) circle - draw a circle
I know vector drawing functions are already planned, but I'd really love to be able to do pixel-based modifications of my sprites on the fly. You can dirty them up, damage them, etc, as the game progresses. It's too inefficient to generate a different image for every possible configuration of a dynamic sprite.
And one other related request, though this one is not that important. It would be nice to be able to use image masks to generate collision boundaries for a sprite. It's probably just a timesaver for the developer, but it would be easier to toss out a black and white mask to specify a complex collision polygon than to code it.
Here are the commands I'd like to see added to the sprite (all varieties) object:
1) copy - Draws a frame from an image map onto the sprite canvas, optionally using alpha blending.
2) copyRect - Same as 1 but you can specify a particular rectangle for the source and destination.
And while I'm at it ;)
3) Pixel - set a point
4) line - draw a line
5) circle - draw a circle
I know vector drawing functions are already planned, but I'd really love to be able to do pixel-based modifications of my sprites on the fly. You can dirty them up, damage them, etc, as the game progresses. It's too inefficient to generate a different image for every possible configuration of a dynamic sprite.
And one other related request, though this one is not that important. It would be nice to be able to use image masks to generate collision boundaries for a sprite. It's probably just a timesaver for the developer, but it would be easier to toss out a black and white mask to specify a complex collision polygon than to code it.
About the author
Indie developer since 1994, games include TradeWars 2002 (named 10th best PC game of all time by PCWorld magazine), TW: Dark Millennium/Exarch/Dungeon Runners, and Rocketbowl 360. Have worked for Martech Software, 21-6, EIS and Black Squirrel Studios.
#2
You don't actually want that.
OpenGL is not known for having a fast ability to render to anything that isn't the framebuffer. Implementations of the framebuffer object extension are coming along, but even now, they're not something I would put into a shipping product. Maybe in another 6 months. But not today. Until then, the alternatives are all pretty slow and not worth bothering with.
Also, see below.
And it's a bad idea to be doing that much rendering to textures. It has to be done in such a way as the original sprite data is preserved. This means that the sprite image data cannot be modified (you wouldn't want all sprites that use the same image data to get damaged when one of them does). Which means that the modifications need to be applied each frame that the sprite is being used. Even with decent FBO support, such a thing would quickly become a performance bottleneck. Not to mention the memory overhead.
Rather than bothering with that (which is non-trivial, btw, and hardly guarenteed to produce the results that you want), why not just put a collision volume with your sprite data? That way, it's not in the script, and you don't have to have the T2D devs do anything. Presumably, a sprite animation editor would include such functionality.
07/29/2005 (12:11 pm)
Quote:Here are the commands I'd like to see added to the sprite (all varieties) object:
1) copy - Draws a frame from an image map onto the sprite canvas, optionally using alpha blending.
2) copyRect - Same as 1 but you can specify a particular rectangle for the source and destination.
And while I'm at it ;)
3) Pixel - set a point
4) line - draw a line
5) circle - draw a circle
You don't actually want that.
OpenGL is not known for having a fast ability to render to anything that isn't the framebuffer. Implementations of the framebuffer object extension are coming along, but even now, they're not something I would put into a shipping product. Maybe in another 6 months. But not today. Until then, the alternatives are all pretty slow and not worth bothering with.
Also, see below.
Quote:You can dirty them up, damage them, etc, as the game progresses. It's too inefficient to generate a different image for every possible configuration of a dynamic sprite.
And it's a bad idea to be doing that much rendering to textures. It has to be done in such a way as the original sprite data is preserved. This means that the sprite image data cannot be modified (you wouldn't want all sprites that use the same image data to get damaged when one of them does). Which means that the modifications need to be applied each frame that the sprite is being used. Even with decent FBO support, such a thing would quickly become a performance bottleneck. Not to mention the memory overhead.
Quote:it would be easier to toss out a black and white mask to specify a complex collision polygon than to code it.
Rather than bothering with that (which is non-trivial, btw, and hardly guarenteed to produce the results that you want), why not just put a collision volume with your sprite data? That way, it's not in the script, and you don't have to have the T2D devs do anything. Presumably, a sprite animation editor would include such functionality.
Associate Melv May
Some of what you say is down on my list of cool things to do. Stuff like compositing different imageMap regions together and primitive drawing to a bitmap canvas. There are huge issues with performance and you can just see people abusing this kind of functionality and then complaining it's really slow when they fill a sprite pixel-by-pixel but that shouldn't stop us developing at least some basic raster-ops for image-compositing.
What you ask for is a good idea and something that's on the cards.
- Melv.