View Full Version : Render To Texture + Iso Tile Engine
08-07-2007, 03:12 PM
I've been reading a lot of tutorials on isometric tiles and how to render them, but one thing I haven't seen is a render to texture idea.
I am used to using it with standard 2D APIs, but I'm not sure how effective it would be with a 3D API.
Just to set it up, so there's no confusion, this is what I was planning: During the loading screen for the game, I would read in the map file and create texture objects of about 150x150 or so tiles in size. Then I would render the map to those textures. Then create planes for each of the textures and tile them as normal in a standard engine.
I'm not sure if this would boost performance, but it seems to me that there should be some speed benefit to doing it this way. I also figure that if I make sprite movement pixel-based, I don't need specific tiles for map information. I can use a 2d array to house my sprite locations and use collision management to make sure I'm within the game world.
Has anyone else used RenderToTexture with a tile-based engine before?
08-08-2007, 05:43 AM
If I'm understanding you correctly - you want to store tiles in textures, and instead of rendering tiles from polygons you want to simply apply them to screen?
If it's isometric view, then tiles will probably contain some empty spaces in corners of texture.
It means that instead of rendering some number of polygons in exact screen location you render a quad covering a bit more pixels on screen than these polygons would.
In means you render less polygons but more pixels. If your tiles have hundreds of polygons each, then it may give some extra performence, but if your tiles are simple then you will loose peformance because of using more fillrate than you need.
So, storing something prerendered into a texture only pays off if it had lot's of polygons.
08-08-2007, 01:22 PM
150x150 titles will be rendered as 22500 quads, that is a very small number, even for older cards :)
I doubt there would be a benefit.
As said k_szczech, isometric view means sprites going above/under other tiles. Using alpha instead of simply different drawing order may be slower (it needs more fillrate).
Maybe it is interesting for pure background tiles however.
08-09-2007, 01:21 AM
Thanks for the replies. That's not exactly what I was thinking of though... Perhaps I can try and explain again.
What I was thinking was creating large textures out of multiple small ones. This would only be done once, and then the large texture would be mapped to the surface of a similar size poly, which would then be rendered and moved accordingly.
Think about it with a small example. I have a room of 50x50 tiles. Instead of rendering all 50 tiles to the buffer/screen every refresh, (or using dirty rects to minimize the updating) I instead would (before the game even started) create a new texture of 50x50 size and render the room to that texture. Then, when I need to display the room, I just map the full texture to an appropriately sized poly, and just move the poly.
I hope that's a bit clearer. Maybe that's what you thought I was saying anyway, but I just want to make sure. Yes, this is for ONLY background tiles, so no need to worry about Zorder. That will be taken care of in a simple object array which will be rendered on top of this.
I hadn't thought about fillrate or even the small number of quads normally required, I was just thinking that lowering the polys rendered does usually mean a performance increase.
08-09-2007, 05:52 AM
We had understood you well :)
Lowering number of polys rendered is only useful if it is your bottleneck.
How many background tiles do you have on screen at the same time ? If less than 200000, don't even bother with it, it is negligible.
For 2d tiled engine, it is probably the number of pixel covered by polygons (ie. fillrate) which costs the most.
Anyway it will probably depends on the card and the resolution, so might help in some cases. Just don't expect miracles :)
Powered by vBulletin® Version 4.2.2 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.