Jump to content
  • Advertisement


Sign in to follow this  
  • entries
  • comments
  • views


Sign in to follow this  


Unf! I got drawing working. "BUT MADOX! LOLZ!".. er wrong webpage. "But tape, why? And isn't drawing to a texture in realtime very slow?" Well silly mortal: It's quite handy to have basic drawing routines simply because doing simple things like a selection rectangle via a static texture is a pain in the ass. And yes, it is slow. But not my drawring! How's that?

Learn to think in the terms of 3D hardware
Doing the following is catastrophically slow in .NET (and native code):

Enter crazy fucking loop.
Lock texture.
Write pornographic image pixel by pixel.

I don't do that. But, consequently, for the speed increase you lose a little flexibility. So here are the ru-els:

  • You can only draw to a render target (this includes rendering windows like the Screen).
  • You can only write data, you cannot read it (unless someone knows a good method of reading pixels from a render target).
That said, what I do is write pixel data to the render target using DrawPrimitive using the D3DPT_POINTLIST. For lines/hollow rectangles, I use D3DPT_LINELIST. And for filled rectangles I use D3DPT_TRIANGLELIST with an index buffer. This is very fast (in comparison to lock write unlock) and is totally metal .

Of course, it's not free, but I do get a FPS of ~180 FPS with constant pixel drawing and 1000 sprites and 2 render targets. I'm sure this could be optimized more, but I don't care at this point, you should probably only draw shit up front before your app begins its rendering cycle.

Overall, I'm pleased with this. Sadly though, I wish I could implement a flood fill function, but I cannot without reading pixels (for borders), which can't be done using this model.

Still, this is indeed awesometastic. I'd like to be able to implement something like this with textures in general using lock-write/read-unlock, but I honestly don't know if it's worth it.

Obligatory Screenshot:

You can't see it, but the blue background in the render targets are being 'eaten' away by filled circles being drawn in realtime. All drawing functions can take an image as a pattern and do patterned drawing as well. In this instance it's drawing the circles using the texture for the balls as a pattern. Notice that even the alpha from the pattern texture is preserved and passed on through to the render target (notice the translucent ellipse in the center and that some areas in the swiss cheese effect are totally transparent).

Soon I'll actually do something useful with this. Or I'll scrap it.. again...
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!