Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 13 Jun 2008
Offline Last Active Jul 19 2016 02:44 PM

#5301247 D3D11 - Bitmap Font Rendering

Posted by on 18 July 2016 - 01:13 PM

I just do the naive thing with 2D and it seems quite fast. Even on older hardware I could throw tens of thousands of them around like it was nothing.


I pre-fill a static 16 bit index buffer and create a dynamic vertex buffer for my sprites. I create the sprite geometry each frame and do some basic sorting and batching. It's pretty easy to batch large amounts of the sprites into a single draw call. Buffers for it are created once up front and destroyed only at the end.


Since the index buffer was 16 bit, I capped the number of sprites at 10922 per draw call.


(10922 * 4) * sizeof(Vertex2D)... which was 32. So 1398016 bytes for the vertex buffer. About 1.4mb.

#5077298 Rendering a GUI efficiently

Posted by on 13 July 2013 - 03:06 AM

I dunno if it's optimal how I have my stuff set up, but I have a simple sprite batching class that I use to draw quads with. I don't really do anything special at all.


SpriteBatch manages the state, etc. It's really dead simple and really doesn't do that much work internally. Just tracking a few things, starting a new batch, finally issuing the draw call, etc. I pre-fill the index buffer and cap how large batches can get. Adding a sprite to the batch just needs a Rect for the position and another for the texture coordinates.


A batch is a simple struct like this

struct Batch
	Vertex2D*	verts;
	Texture*	texture;
	u32		numSprites;
	u32		numVerts;
	u32		numIndicies;

Then keep a vector of them. Batches hang around until you explicitly purge them, so once you add a bunch of quads, you don't need to re-add them and the only thing that needs to happen is the draw call (and prior memcpy() to push whatever batch verts to the underlying vertex buffer).


It's not fancy or super robust, but I don't see why I couldn't draw an entire UI with just one or two draw calls. Drawing thousands of textured quads costs practically nothing, and my framerate is still well into the thousands. What's GWEN doing that's taking so long?

#5020994 In-Game Console

Posted by on 13 January 2013 - 01:34 AM

The actual logic behind a console system isn't too hard to put together, I have a simple Cvar class which uses template specializations for the argument types I support (float, int, string, and nothing) so when you create a Cvar object, it sets an internal flag accordingly for the type you tried to give it so it knows how to act on it later. It uses a FastDelegate internally for the function pointer stuff.


Then I just dump them into a map<string, Cvar> for the lookup. The Console class has an exec() function which just takes a string -- if there's 2 parts to it (like "test 500") then I split that into to name and argument, use the name for the lookup, and 500 is converted and handled accordingly. It's not really robust, but it's really tiny and simple, I think the whole thing is like around 150 lines.

#5015670 Shader semantics

Posted by on 30 December 2012 - 01:08 AM

Seems kind of weird that they just leave things off their list, but whatever, I guess it doesn't really matter.

Now that things are working, I made it into a starfield. Pretty neat how I can just draw the whole thing in one call, and they can all be uniquely scaled, rotated, etc.

edit: Also solving things shortly after I post seems to be a trend of mine. I'm apparently incapable of working things out before I get annoyed and go to ask for help. smile.png

#5006471 Could Not initialize Direct3D

Posted by on 02 December 2012 - 08:26 PM

Make sure that you're definitely ending up picking the 10 feature level. You'll also need to change the shader profile argument for D3DX11CompileFromFile. It's probably "ps_5_0" / "vs_5_0" right now. Change it accordingly -- on your card you'd need to use 4 instead.

#5002308 C++ panel rendering

Posted by on 19 November 2012 - 05:19 AM

It's probably just drawing straight to the window itself, not a specific control. If you're in need of a framebuffer to just dump pixels to, the simplest way on Windows is probably a DIB Section. It's just a few lines to init and you'll just get a pointer directly to the data, BitBlt() to the screen when you're done.

#4963795 Which 3d Engine to choose for Skyrim clone?

Posted by on 27 July 2012 - 05:06 PM

Why not just mod Skyrim? The base is there and you have everything you need to make a completely new game.

Look at Nehrim for Oblivion. It uses the assets (and I'd assume plenty of their own as well), but it's still an entirely new world in the end.

#4833301 Will leaking memory be freed eventually once VS2010 shuts down?

Posted by on 10 July 2011 - 05:26 AM

After executing this program X amount of times, for X > 10,000, and X not less than 0, then shutting down Visual Studios 2010, will the leaked memory still stay in the RAM and not freed by the operating system? Even if it's Windows Vista/7?

Every process has it's own space for memory. You won't crash or damage the OS, but you might make things a bit sluggish and get a nice warning from Windows about the offending process. Windows doesn't see your leaked memory as anything special, it'll be nuked all the same when the process goes poof.

#4831677 Newbie Bitmap Woes

Posted by on 06 July 2011 - 01:48 AM

If you want to do drawing in GDI, it's probably a good idea to just go with a DIB Section and handle it all yourself. It'll probably be faster and simplify everything in the end.

#4784686 Is it still worth using SIMD for fast maths?

Posted by on 11 March 2011 - 11:02 PM

I rewrote most of my math stuff into SSE a while ago and there was a pretty nice benefit. Converting my math code over was pretty simple, the matrix / vector stuff didn't take long at all. The amount of arithmetic was basically cut to 1/4th what it was in some cases.

Restructuring some other things took a little longer. It's a software renderer and one of the biggest gains in really geometry heavy cases was redoing the final transformation stuff for SSE. I ended up changing how I fill my vertex buffer to dummy up verticies to keep alignment and try to keep things ordered in a way that doesn't require me to shuffle it around. It just goes in and I'm off plowing through data. My first "get it working" attempt was to move from transforming 1 vertex at a time to the entire triangle. Alpha blended pictures worked nicely too since I can do multiple pixels at once.

I haven't really had any issues with SSE yielding slower results on my Q6600. I ended up just ditching the x86 stuff and leaving the SSE code because I had nothing but nice boosts.

VS 2008 generated some stuff for intrinsics though that was beyond earthly logic. 2008 would generate downright awful code like somehow create tons of loads and moves instead of a single movaps or optimize nothing at all. I had some stuff in assembly but that went out the window in 2010 because the compiler started beating me nicely. Even trying to improve on what it generated didn't work as well, so it was clearly playing into some kind of black magic that I couldn't hope to match myself.

Just try to do as much work as you possibly can when you're in SSE land. Don't be afraid to saturate the entire SSE register file, squeeze in as much as you can and do as much as you can before leaving.