SFML community forums
Help => Graphics => Topic started by: SoulBlade on March 15, 2012, 10:50:39 pm
-
Hello,
I was wondering if any in this community have developed a class to handle renderTextures beyond a graphics card texture limit that uses the same getters and setters as the original class. I was about to begin my own work on this, but I figured this is probably something another has done so there is no harm in checking.
Basically, I see this Large RenderTexture class as having all the same methods as the original RenderTexture, the only difference being it will automatically handle sub-dividing into an appropriate number of textures in order to stay at or below the maximum texture size for a graphics card. As for getting the texture and drawing it, could just keep track of the offset per sub-texture and set a sprites position to that offset when trying to use it. Anyway, has anyone done this or something similar? Did I search and couldn't find anything, save the "Thor" library which deals with textures themselves, not renderTextures.
Thanks.
-
As far as I know, nobody has written such a class yet.
Out of curiosity, why do you need large render-textures?
-
As far as I know, nobody has written such a class yet.
Out of curiosity, why do you need large render-textures?
I've created a rather complex system built upon RenderTextures. I'm drawing thousands of sprites to currently 1 large RenderTexture. The reason I need it to be so large is due to scaling and rotations. I want to be able to scale and rotate without performing transformations on the coordinates used by the individual sprites I draw to the textures. I'm using about 4 different coordinate systems and it's hard enough to manage as is.
I originally thought RenderTextures operated the same way a view operates. Had I know about the texture limit when I was creating my framework a few months ago, I would have opted for another option. That said, given the purpose RenderTextures serve, I believe this would be a useful thing to make, so I suppose I will go ahead and code it unless there is a better alternative.
-
There are at least three simpler solutions to apply global transformations:
- using a view
- using a global sf::Transform that you pass to every draw call
- using a vertex array to gather all your geometry into a single entity
The problem with large [render-]textures is that it cannot be self-contained, you need a matching "large sprite" class.
And creating a large render-texture is not straight-forward, everytime you draw something you must first find which internal texture it will be rendered to, and adjust the view (projection matrix) accordingly. Not hard, but not as easy as the large texture class ;)
-
Oh I know they can't be self contained, but, frankly, I've come to understand how these work and vertex arrays don't agree with my brain. My system is also already built around the premise of using renderTextures, so it would be terribly time consuming to convert it to a different drawing concept. I figure the class can compute which texture to draw a sprite to based upon the position relatively easy, and I can simply loop through all the textures and render each texture individually using normal sprites.
Thank you for the assistance.
-
I created an implementation of the concept I devised here. To my dismay, it is much too slow to be workable in the context I am using it for.
So, I find myself needing some help coming up with an alternative, if possible.
The reason I am not able to use vertex arrays, beyond my brain not liking them, is because I have several different textures in use, possibly more than several (20+). They are high-res textures, so making 1 big texture is really not an option. Some of the textures are also procedurally generated, and the individual sprites being drawn do not have uniform transformations.
So, frankly, I find myself somewhat stuck without the possibility of using a single large texture. I mean...the renderTexture size I need, at a minimum, is 1024x1024. If a graphics card only supports 512x512 (I realize that would be a crazy old card...going for large compatibility), that means nothing is drawn, and I need to find a way around that.
Any assistance is greatly appreciated.
-
- using a view
- using a global sf::Transform that you pass to every draw call
;)
-
Oh boy, I am brain-dead. I use views for the RenderWindow that I draw everything to, but not the individual RenderTextures. I've been applying transformations to the RenderWindow. I'm not entirely sure if applying them individually to the RenderTextures will solve my problem, but churning through my brain it sounds like it will.
I'll post an update on this if it works and what I did. Thanks Laurent.
-
Just wanted to update, with some quick application of the views to the renderTextures I use, I can effectively make the "big" renderTextures I was talking about pretty easily. Some minor quarks I need to work out, but wow, I feel pretty dumb. Not to mention I've been doing my own transformations this entire time. My brain chemistry is just not geared towards the common sense, I guess. Probably why I'm a student physicist. I appreciate the help, and apologize for taking time on such a simple matter.
-
Just wanted to update, with some quick application of the views to the renderTextures I use, I can effectively make the "big" renderTextures I was talking about pretty easily. Some minor quarks I need to work out, but wow, I feel pretty dumb. Not to mention I've been doing my own transformations this entire time. My brain chemistry is just not geared towards the common sense, I guess. Probably why I'm a student physicist. I appreciate the help, and apologize for taking time on such a simple matter.
Mind telling us that awesome technique you thought of? I'm curious now :P
-
There should be something in the Game from scratch tutorial on the general help forum that might help with the Vertext array issue. I still don't understand them myself but the memory/object manager in that tutorial does wonders. It wouldn't take much to convert it for other objects like textures.
-
Mind telling us that awesome technique you thought of? I'm curious now :P
No awesome techniques here, just using a view applied to a RenderTexture to handle the transformations. This entire thread was due to my own over thinking and manually performing unnecessary math that SFML innately handles.
-
:o I need to have large renderTexture classes on the order of 16200 by 10800 pixels. That texture will then need to be saved to save to jpg or png files. The purpose is to create art works which will then be printed on large format printers. I can do it in Windows Forms and in Windows Presentation Foundation but I would like to do it in SFML which seems a little cleaner and faster. The current limit seems to be 4096 x 4096.
-
I don't think SFML will support render textures of this size. Maybe Thor one day, but it's definitely not a priority. So in your case, it might be wiser to use something else or handcraft your own BigRenderTexture class.
Do you have to render to the whole texture at once, or would it be possible to compose the final result from multiple smaller textures?
-
:o I need to have large renderTexture classes on the order of 16200 by 10800 pixels. That texture will then need to be saved to save to jpg or png files. The purpose is to create art works which will then be printed on large format printers. I can do it in Windows Forms and in Windows Presentation Foundation but I would like to do it in SFML which seems a little cleaner and faster. The current limit seems to be 4096 x 4096.
Well if you are using WinForms or WPF I assume you are working with C# and or SFML.NET. To the point, my NetEXT library (see signature) includes a LargeRenderTexture class. Just note that using textures that big is really going to take a hit on your performance.