next »

[TheSpaceMan]

I am considering writing a procedural texture generator that saves data to textures for later use. If I remove restriktions for Language and API. (Even if i prefer c++)

What would be the easiest way to get access to the following features.

The possibility to ...

easy save a render target to file.
easy way to draw a "brush" texture onto the render target.
easy way to scale, rotate, the brush.
easy way to tint the color of the brush.
easy way to draw pixels on the render target as well as suport for lines circles etc.

Going straight from DirectX/OpenGL scaling and rotating is easy but pixel access is more difficult, going trough SDL getting pixel access is easy but doing rotation and scaling of textures/sprites become harder.

Any suggestions?

A bit tired, wrote post game first, I mean PRE game.

[TheSpaceMan]

Either there is no easy path to this or it's so easy that people find it silly to answer.

[increpare]

I don't see any reason to not just do it in SDL, though it wouldn't necessarily be fast.  Though, if it's PG, I'm guessing you'll do all the generation before the level starts, so.

Rotating sdl sprites is nastier than getting opengl pixel access, so I'd go for OpenGL, with maybe FBOs (which are pretty much perfect for what you're talking about, so).

[TheSpaceMan]

The path i will choose is simply a round white texture that i will scale do, not real but pixelish operations. The pixel size is not important per say, it's the size compared to the rest of the image thats important.

[increpare]

The path i will choose is simply a round white texture that i will scale do, not real but pixelish operations. The pixel size is not important per say, it's the size compared to the rest of the image thats important.

if pixel size isn't important then jeeze go with opengl...

[Flink]

I would go for SFML, i think they have everything you need.

[increpare]

oh, cairo is worth considering as well.  i've seen it used in PG texture stuff.

[Ivan]

If you're doing complicated blending stuff, there's no reason not to do it in opengl and render to texture.

[nihilocrat]

I would go for SFML, i think they have everything you need.

Please, elaborate. I haven't really looked much into SFML because I've prematurely written it off as "SDL with perhaps a few different features".

Based on reading the linked page, cairo looks pretty promising. There are commercial libraries for doing this out there, but being commercial, they are sort of restricted to a very specific workflow in anticipation of some artists cranking out textures in it for a DirectX-based game for 8 hours a day for 1-5 years. I'm sorry a name doesn't come to mind, I saw an article on it in Game Developer Magazine, tried it out, and promptly forgot about it.

I wholeheartedly encourage your effort. PG is P cool.

[Farbs]

I'm sure there's a reason not to do this, but...

Why don't you just build your textures as big ol' chunks of memory in software? Why do you need a rendering API for the texture gen stage at all? I'm sure you can find simple and fast algos for basics like lines and polygons, and you'll be left completely free to come up with wacky new drawing functions.

[Flink]

I would go for SFML, i think they have everything you need.

Please, elaborate. I haven't really looked much into SFML because I've prematurely written it off as "SDL with perhaps a few different features".

I have used both SFML and SDL and my opinion of it is that SFML design is much more OO and the source code is much nicer and easy to work with. The overall experiance of SFML is that it's easier to use but still have a lot of depth to it. Also there is features that i dont know if SDL has, like hlsl shader support and ftp/http access through the API. I strongly recommend it!

I have also tested HGE , which is a directx based 2D API, very easy to use with its helper classes but i dont really like the overall design of the API, but very nice for beginners.

[Alex May]

We do this in Dyson by using SDL surfaces. We convert them to OpenGL textures before using them in-game. There's a onresize event in SDL that lets us know when we need to upload the graphics to the card again to refresh the textures.

Generating the graphics themselves is a straightforward matter of getting hold of the surface and plotting the textures out pixel by pixel.

[Hajo]

I am considering writing a procedural texture generator that saves data to textures for later use. If I remove restriktions for Language and API. (Even if i prefer c++)

What would be the easiest way to get access to the following features.

The possibility to ...

easy save a render target to file.
easy way to draw a "brush" texture onto the render target.
easy way to scale, rotate, the brush.
easy way to tint the color of the brush.
easy way to draw pixels on the render target as well as suport for lines circles etc.

I'm using PovRay to generate textures. Povray has a lot of inbuilt procedural texture generators (well, pigment and surface normals) which can be used to create rather fine textures. Also all kinds of geometric primitives. And it's scriptable with a quite powerful scene scripting language.

http://www.povray.org

If "for later use" includes storing the textures in files, this is.

[TheSpaceMan]

Sorry for the late reply. I have decided to take flinks advice and i use SFML because it got a combination of the things i need. Right now i just have some basic features, nothing to show, but with some additional work i think i could do something fun with it.

[J.G. Martins]

Watch out, apparently render to texture is not implemented yet!

[TheSpaceMan]

If i need to render to texture i load the texture needed, draw a new image on top, save a screenshot of the image, to a temp texture. Since this doesn't need to be realtime, i have no problems.