Sign in to follow this  
  • entries
    557
  • comments
    1237
  • views
    422137

Untitled

Sign in to follow this  

50 views

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...
Sign in to follow this  


3 Comments


Recommended Comments

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]

Share this comment


Link to comment
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.

Share this comment


Link to comment

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