Scripted Textures

[Marisa the Magician]

Yeah, you basically use the same functions on it as you would the Screen.

[Major Cooke]

Right, but I'm curious if I could see a workable example? I.e. i'm not sure if that belongs in drawing functions like RenderOverlay or otherwise.

[phantombeta]

ZScript may be too slow to do textures that are programmatically generated per pixel. Even in the best of cases it may be too slow even with JIT due to all the range checks

The range checks really aren't as bad as you'd think. IMO the only thing missing right now is a fast way to blit a texture. To prove this point, I've made a proof of concept PK3. It's the same PSX Doom fire I did a while ago, but drawing to a 320x96 canvas texture using 1x1 squares through Shape2D.
(For efficiency, it generates the tri coords and indices at initialization, then only changes the texture coords to blit the texture)

VM time as reported by "stat vm" barely rises, and the framerate drop is low. And if you disable rendering the Shape2D, you'll actually notice the framerate drop is caused by actually rendering those 1x1 squares, which means proper, efficient pixel blitting for canvas textures would solve this issue.

CVars:

• OGNNTH2_Enabled toggles everything on and off (off by default)
• OGNNTH2_Update toggles the PSX fire simulation (on by default)
• OGNNTH2_Render toggles blitting to the screen (on by default. It only disables actually rendering the Shape2D, the texture coordinates are still generated and added to the Shape2D)

Right, but I'm curious if I could see a workable example? I.e. i'm not sure if that belongs in drawing functions like RenderOverlay or otherwise.

I believe it does, yes. Think of it essentially as an offscreen version of the Screen API.

[Major Cooke]

I guess I'm just lacking imagination on what one can do with this. While I did check out Phantom's package, I guess I just have to wait until people roll out with more examples on what it can be used for.

Oh well.

[Rachael]

One of the first things that come to mind is UE1-style fire effects. Those are simply a thing of beauty. And a simple 32x32 texture doing this, or maybe even a 64x64 one, shouldn't be too much for the engine to handle.

A very *very* useful use case for this is passing a large amount of data to shaders via uniform textures - I can't think of a use case for that, specifically, of the top of my head, but it does allow for this none the less.

[Major Cooke]

Never played UE before.

It'd be appreciated if someoen can explain and break this down a bit more because I had trouble getting the example dpJudas posted (and for the sake of others who are wondering what this all is and where to start). Attempting to run his example and nothing else will result in a VM abort.

Code: Select all

Canvas canvas = TexMan.GetCanvas("mycanvastexture");
canvas.Clear(0, 0, 64, 128, Screen.PaletteColor(123));
canvas.DrawText(bigfont, Font.CR_ORANGE, 0, 0, "HELLO!");

No, I've never actually dealt with making camera/canvas textures before.

[Marisa the Magician]

You need to actually define the canvas texture in animdefs first.

[Major Cooke]

Does it specifically need to be a camera texture or can it be anything else?

[Marisa the Magician]

You define it as "canvastexture" instead of "cameratexture". The arguments are the same.