Render Queue (2D), wtf am I missing?
by Tom Bampton · in General Game Discussion · 06/16/2003 (5:55 pm) · 6 replies
Couple of things ...
#1: It seems that you can only have one instance of a G2D_Image in the pipeline, and looking through the code indicates that if you want the same image drawn more then once, you need to load the image more then once. This seems silly (memory, perfomance, etc), I must be missing something there?
#2: The sort order for the render queue is *
#1: It seems that you can only have one instance of a G2D_Image in the pipeline, and looking through the code indicates that if you want the same image drawn more then once, you need to load the image more then once. This seems silly (memory, perfomance, etc), I must be missing something there?
#2: The sort order for the render queue is *
#2
What might be nice is a resource manager similar to the one in Torque, that handles all loading and tracking of resources. If this had a reference tracker, it could create duplicate handles to resources that share data. I only had a brief look at RE's current resource manager, but it doesnt seem too hard to modify to achieve this. I'm thinking that the resouce manager should be able to load any type of file that RE supports, and creates the relevant object for it. Done well, this should simplify things for beginners as well since there'd be a single load function to load anything.
As for the render queue, with 2D at least, the only effective way I can think of to fix sort order is to allow bypass of the render queue, which it sounds like you've done. As for other ways, the simplest suggestion is allow direct modification of the queue, e.g. MoveObjectUp(), MoveObjectToTop(), MoveObjectBefore() and their inverses.
You could take this further and implement a layers system.
The easiest way to do that, that I can think of, would be to assign a layer number to each object and keep the render queue sorted by that. The MoveObject* methods above wouldnt move an object outside of it's layer. I'm not sure of this is taking things too far, but it seems easy enough to add if the move functions are there.
From the distance at which I'm sitting, the hardest thing to do would be the resource manager. I think I'll have a crack at that and see what I can come up with, since I was planning on adding support for more image formats anyway. I guess it's time to start a local CVS repository for RE :)
I dunno how you kept RE beginner friendly, its quite hard to think of ways to do things that keep within that perspective.
Any ETA on the new build ?
T.
06/17/2003 (5:33 am)
Ahh, I'm not going mad, then :)What might be nice is a resource manager similar to the one in Torque, that handles all loading and tracking of resources. If this had a reference tracker, it could create duplicate handles to resources that share data. I only had a brief look at RE's current resource manager, but it doesnt seem too hard to modify to achieve this. I'm thinking that the resouce manager should be able to load any type of file that RE supports, and creates the relevant object for it. Done well, this should simplify things for beginners as well since there'd be a single load function to load anything.
As for the render queue, with 2D at least, the only effective way I can think of to fix sort order is to allow bypass of the render queue, which it sounds like you've done. As for other ways, the simplest suggestion is allow direct modification of the queue, e.g. MoveObjectUp(), MoveObjectToTop(), MoveObjectBefore() and their inverses.
You could take this further and implement a layers system.
The easiest way to do that, that I can think of, would be to assign a layer number to each object and keep the render queue sorted by that. The MoveObject* methods above wouldnt move an object outside of it's layer. I'm not sure of this is taking things too far, but it seems easy enough to add if the move functions are there.
From the distance at which I'm sitting, the hardest thing to do would be the resource manager. I think I'll have a crack at that and see what I can come up with, since I was planning on adding support for more image formats anyway. I guess it's time to start a local CVS repository for RE :)
I dunno how you kept RE beginner friendly, its quite hard to think of ways to do things that keep within that perspective.
Any ETA on the new build ?
T.
#3
As for supplying the queue management methods, that would be no problem either and I'll add it to my list.
Finally I'm setting up the CVS repo right now. Maybe you'd like to join the mailing list? It sounds like you'd like to help add some features?
General:
drunkenhyena.com/mailman/listinfo/reaction-users_drunkenhyena.com
Developer:
drunkenhyena.com/mailman/listinfo/reaction-dev_drunkenhyena.com
06/17/2003 (8:00 am)
As far as the resource manager is concerned RE has a pretty simple yet sophisticated strategy for handling resources. Adding some kind of texture manager should be no problem at all. The G3D system uses this system currently. And I'm planning to add this to the G2D system when I get time.As for supplying the queue management methods, that would be no problem either and I'll add it to my list.
Finally I'm setting up the CVS repo right now. Maybe you'd like to join the mailing list? It sounds like you'd like to help add some features?
General:
drunkenhyena.com/mailman/listinfo/reaction-users_drunkenhyena.com
Developer:
drunkenhyena.com/mailman/listinfo/reaction-dev_drunkenhyena.com
#4
A quick update with 2D rendering ...
I just got it bypassing the queue nicely. However, being not completely happy with things, I came up with the following:
I added to GFX_Device StartRender() and EndRender() methods. These basically do the original prologue/epilogue from Render().
Since managing *all* rendering yourself is a bit of a pain for things that are basically static, the following will be added in 5 mins:
Overloaded Render() function that takes a bool, true to act like old Render(), false to skip calling StartRender() and EndRender(). The original Render() will then just call Render(bool) with true. This way, you get the best of both worlds (e.g. you can do stuff yourself *and* use the queue) and old cold works as-is.
I'll have a patch later on, I dont have any patch tools on my Windows box so stuff needs copying to one of the Unix boxes. I also stupidly didnt keep a copy of the clean source, so I'll have to install RE on my debug box to get a clean copy. Oops.
Hm, am installing now, just glanced over and noticed the ogg decompressor ... how about adding ogg support to RE so it doesnt have to decompress them in the installer ? I havent looked at sound yet, and card games dont exactly need music, so its not something I'm worried about personally yet. We do have a few 3D games planned tho, not sure if we'll be using Torque or RE for some of them yet, though.
T.
06/17/2003 (8:19 am)
I'll check out the mailing list stuff in a sec.A quick update with 2D rendering ...
I just got it bypassing the queue nicely. However, being not completely happy with things, I came up with the following:
I added to GFX_Device StartRender() and EndRender() methods. These basically do the original prologue/epilogue from Render().
Since managing *all* rendering yourself is a bit of a pain for things that are basically static, the following will be added in 5 mins:
Overloaded Render() function that takes a bool, true to act like old Render(), false to skip calling StartRender() and EndRender(). The original Render() will then just call Render(bool) with true. This way, you get the best of both worlds (e.g. you can do stuff yourself *and* use the queue) and old cold works as-is.
I'll have a patch later on, I dont have any patch tools on my Windows box so stuff needs copying to one of the Unix boxes. I also stupidly didnt keep a copy of the clean source, so I'll have to install RE on my debug box to get a clean copy. Oops.
Hm, am installing now, just glanced over and noticed the ogg decompressor ... how about adding ogg support to RE so it doesnt have to decompress them in the installer ? I havent looked at sound yet, and card games dont exactly need music, so its not something I'm worried about personally yet. We do have a few 3D games planned tho, not sure if we'll be using Torque or RE for some of them yet, though.
T.
#5
As for ogg, I did have reasons for not supporting it in engine. Most notiably, on the low end test machines, with Chain Reaction, we saw some lagging. The ogg decompression occasionally interfered with the Chain Reaction physics.
The easiest solution was to decompress on install. This also decreased the overall download footprint by several megs. So given the choice of either compressing all files to ogg before building the installer, then decompressing them on install, or just decompressing the music in engine, I chose the former. That said it should be very straightforward to add in-engine ogg decompression.
Chris
06/17/2003 (8:31 am)
You should definitly get on the mailing lists. The community has already discussed a lot of these issues.As for ogg, I did have reasons for not supporting it in engine. Most notiably, on the low end test machines, with Chain Reaction, we saw some lagging. The ogg decompression occasionally interfered with the Chain Reaction physics.
The easiest solution was to decompress on install. This also decreased the overall download footprint by several megs. So given the choice of either compressing all files to ogg before building the installer, then decompressing them on install, or just decompressing the music in engine, I chose the former. That said it should be very straightforward to add in-engine ogg decompression.
Chris
#6
Re: Ogg, ah, see your point there. Also has the advantage that you can compress non-music sounds, too.
06/17/2003 (9:42 am)
I did just get on the mailing lists :) There seems to be some lag between me saying stuff and me doing stuff, hehe.Re: Ogg, ah, see your point there. Also has the advantage that you can compress non-music sounds, too.
Torque Owner Chris Cole
2)In the new build I've included a function pointer override of the render method. This allows you to supply a custom render function for your application. There should be no issues with just grabbing what you need from the original render function and filling in the rest.
BTW do you have any suggestions on changing the current render queue strategy? (Bare-in-mind the target audience.)
Great comments, keep it up. I love to hear your thoughts.
Chris