ZDoom

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

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

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

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

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]Canvas canvas = TexMan.GetCanvas("mycanvastexture");
canvas.Clear(0, 0, 64, 128, Screen.PaletteColor(123));
canvas.DrawText(bigfont, Font.CR_ORANGE, 0, 0, "HELLO!");[/code]

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

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.

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. :(

[quote="Graf Zahl"]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[/quote]
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:
[list]
[*]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)[/list]

[quote="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.[/quote]
I believe it does, yes. Think of it essentially as an offscreen version of the Screen API.

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.

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

From the pull request thread by dpJudas:

[quote]
This adds support for creating canvas textures in ANIMDEFS using same syntax as for camera textures (except the keyword is canvastexture instead).

On the zscript side the texture can be drawn into using the following method:

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

And out of curiosity, how does one do this now? I'd love to see an example!

Or the main functions can work.

For per-pixel we can reduce range checks to one check by allowing a special per-pixel texelation command to have a single one-dimensional addressing scheme which will access the entire texture. That should increase the speed of per-texel scripting a little bit. Bonus: cast it to an unsigned integer to reduce the checking even further since negatives will then always fail the check.

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

Probably a lot of calls to drawtexture with a 1x1 pixel texture. :wink:

So, technically, could the PSX fire sky be implemented this way now? What would the code look like?