Exactly, but this makes it impossible to blit a bmap with transparency onto another bmap that is using transparency aswell - which is what I'm trying to do.

The only workaround I can come up with is using bmap_process. This way I could specify the blending mode in the shader's pass myself.
However, in that case the whole bmap needs to be processed for every single bmap that I want to blit which is a bit of an overkill for blitting a lot of small bmaps into a big one.

I could temporarily try to use this workaround but I hope that there'll be a way to alter how draw_-functions blend their content into the target-bmap, or simply chaging these functions to always use "correct" blending.

Soo.. I hate to be pushy, sorry, but I'm really concerned about one of the issues I addressed - being able to use draw_quad() on big
rendertargets and I have the feeling that I'm just being ignored and nothing's going to move forward.

That draw_...()-functions are culled when they're outside of the window's size is obviously a problem that makes bmap_rendertarget()
kind of useless, since I can't guarantee that the final user has a screen resolution high enough to fit all my draw_() calls in it.
In my case of rendering onto big atlas-textures, most users will definitely not have big enough screens to fit the whole texture in it.

I can't really believe that fixing this is going to need a lot of modifications. The culling-area for draw_...()-functions simply needs to
be set to the bmap's dimensions when calling bmap_rendertarget(), and reset to the window's size when it's disabled again.

As a workaround I tried bmap_blit(part)... However, despite having a pretty beefy cpu, the time it takes to blit some bmaps just skyrockets
when using it. Drawing a medium number of quads takes roughly 1 millisecond using draw_quad - while bmap_blitpart needs more than 1000
milliseconds.

Knowing that Acknex's updates have become extremely rare, I'd just like to see that draw_quad will work the way it should be working
in the (hopefully near) future, since I'm relying quite a lot on it and I'm having trouble proceeding without it.


I don't really know what else to say than asking you to try solving this issue.

kind regards, Alex

I understand, but if I were you, I would certainly not wait for the next Gamestudio update. I would just finish my project without draw_quad.

It's on my list, but I can not quickly produce an update for you. Draw_quad is the central panel drawing function and used at about 50 places in the code. Panels are early clipped at screen corners for speeding up 2D games. And there are internal functions that use draw_quad with a render target and also rely on screen clipping. Anything that affects existing projects in this way must be carefully implemented and tested, it's not done in half an hour.

I must also admit that the problem seemed not really urgent to me. Sure, you can not use draw_quad for your purpose, but there are tons of other draw functions. Can't you instead use draw_obj with a bmap object, or even just call a D3D draw primitive?

Okay, thanks for the reply.

It's just that every other approach I tried is just way too slow.
However, I'll see if I manage to get something using the directx api.
I'm not sure if this will work with acknex's bmap struct, though.

Well, now I look stupid.

Fixing this myself was actually possible and in the end it worked out much better than I thought.

I tried the draw primitive approach you've recommended. Took me quite a while to make that thing
render textures instead of vertex colors but I managed to get something usable.

For some reason it event works flawlessly with bmap_rendertarget(), which I did not expect at all.

Seems like I won't have to worry about this anymore, thanks again for the hint.