Holy shit batman. Fonts. Yes, I know, there was text in the images before this. That was using the built in ID3DXFont crap. This however is homegrown.
I'm really getting sick of those bouncing balls, but they really do help with the stress testing. Perhaps I should write something useful with this.
The TextSprite object seen here can be rotated, scaled, positioned and molested just like a normal sprite. It also has the advantage of being totally integrated and thus using the same buffers as the sprites for performance things. I've even got it set up so that you can provide colors to the vertex corners of the characters, so now you can get that nice retro metallic text look that used to be so mad cool on the C64. You kids remember the C64 don't you? You can also align the text to the center or right of the position of the Textsprite. Erm... there's other things... hold on, I know I can remember... fuck it, I can't remember. I also implemented crude axis aligned bounding boxes for the sprites. Those were a total joy to implement, like shoving a hot curling iron up my ass joy.
Overall I'm pleased with the performance of this beast at this point. I'll probably whip up a small demo (so Rob Loach can download it and call me a horrible horrible liar [grin] for saying how I got amazing FPS with 12000 sprites... fuck I'm dumb, you can read the horrible account of it here.) Don't know when I'll do it, whenever I'm not lazy, so you may never see it.
I do have some questions though:
- Clipping. Is it sufficient to just change the viewport (the D3DDevice.Viewport that is) per frame? Will this kill the framerate? I was thinking to implement a GUI of some sort I'm going to need to clip text and such to the respective controls and the like. I see very few GUI libraries do this, clipping that is, so I wonder if it's super difficult? Regardless, I hate that some libraries just size the control to the text, cut off letters, or just let overdraw happen. Doesn't look 'right' to me.
- Drawing to textures (or setting pixel data within the texture). I've been scratching my head over this one for a bit. I know lock -> set-pixel(s) -> unlock is slow as shit. Would limiting 'drawing' to RenderTargets and using DrawPrimitive (line primitive types, points, etc..) yield better performance? Considering how flexible drawing needs to be I would imagine batching here would be extremely difficult. I hear dynamic textures help, but they used to have such poor support (not sure how it is now), is it worth it?
- Input. DirectInput? Or just use the form events/specific API calls? I hate DirectInput, it needlessly complicates things, however it does work. On the down side it's apparently going to be discontinued at some point in the future (this is old info, I don't know if it's true anymore).
I think that's all for now.