🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Untitled

posted in DruinkJournal
Published March 28, 2007
Advertisement
Well, I've got some stuff done to TEH ENJIN!!1. Nothing that major though. Texture atlasing is working, textures are automatically atlassed if possible, and you can reserve chunks of a texture up to 256x256 if you want (This is all platform-layer stuff).
And my font manager stuff is in too. You can't actually render strings yet, I'll do that today hopefully. But you can preload the glyphs, which locks the texture sheet and blits the glyphs to it. And for hilarity, I tried preloading 65536-32 glpyhs, and it ate up 6 2048x2048 textures. So I won't be doing that again any time soon. Although it was a good stress test.

Getting text actually rendered will be the same plan as with TEH MMORPG!!1, it'll generate a bunch of sprites, one for each glyph. I'll make an EText class which will save me having to arse around with vectors of ESprites whenever I want to render some text. I can also make an EText hold a pointer to the font and let you replace the text and stuff more easily. In TEH MMORPG!!1 it was all done with game-level objects, which was ugly.

So, in theory you'll be able to do this:
EFont::SP pFont = EGraphics::Get().GetFont("Ariel", 12, EFont::Bold);EText::SP pText = pFont->CreateText("Hello World!");EScene::Get().Add(pText);
Which is nice and neat, and allows me to give EText member functions to change the text. Changing font will need the text to be reconstructed, which is fair I think.

Anyway, work...
Previous Entry Untitled
Next Entry Untitled
0 likes 3 comments

Comments

Aardvajk
Just a bit curious about your atlasing system. Mine imposed a limit of a single 2048x2048 texture (if available) but I read your above to suggest that when a 2048 texture is filled, it allocates another one.

In that case, how does the client code know how to call SetTexture() (if you are using Direct3D) without mucking up batching of sprites on the same texture?

Hope that made some sense. [smile]
March 28, 2007 10:53 AM
Evil Steve
Quote: Original post by EasilyConfused
Just a bit curious about your atlasing system. Mine imposed a limit of a single 2048x2048 texture (if available) but I read your above to suggest that when a 2048 texture is filled, it allocates another one.

In that case, how does the client code know how to call SetTexture() (if you are using Direct3D) without mucking up batching of sprites on the same texture?

Hope that made some sense. [smile]
The texture manager has a vector of structs describing each 2048x2048 sheet. When you load a sprite, the texture manager bungs the texture onto a sheet if possible, and sets up the returned texture. The returned texture contains the texture coordinates of the top left and bottom right corners of it's region (which may or may not be on a sheet, it'll be (0, 0) to (1, 1) if it's not on a sheet), and a LPDIRECT3DTEXTURE9 which points to the texture (sheet, or single texture).

When the sprite manager comes to render its sprites, it goes through each sprite and grabs its texture, and then checks the LPDIRECT3DTEXTURE9 pointer in that texture to see if it needs to change texture. The sort function (which is used by std::set) also sorts by texture.
March 29, 2007 07:16 AM
Aardvajk
Makes sense. Cheers.
March 29, 2007 07:33 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement
Advertisement