Loading textures from larger surface

Started by
7 comments, last by Trajar 23 years, 9 months ago
How would one go about greating a texture from an area of a larger surface? i.e. I want a 64x64 pieve for a texture from a 300x300 surface in memory. Thanks in advance Trajar
Advertisement
pieve=piece...
You could create another direct draw surface, sized 64x64, then blt the 64x64 portion from the 300x300 surface onto the smaller surface. For example to do this with BltFast...

small_surface->BltFast(x, y, big_surface, &Rect, DDBLTFAST_SRCCOLORKEY);

Of course you have to define the rectangle correctly...

RECT Rect = {left,top,left+64,top+64};

This means that from the coordinates defined by left and top, will be the top-left coordinates (on the big surface) for the 64x64 piece, and 64 pixels aways from these coordinates will be bottom-right coordinates of the piece.

+AA_970+
I was concidering of doing something very similar, but I''m not sure how fast BltFast really is. What''s it doing exactly? COPYING the memory from one surface to the other, or REORIENTATING a pointer? I think the second would be way faster, anf if that''s the case this shouldn''t cause any performance drop.
If BltFast was the ONLY choice that''s what I would have to do, but this will be initially a font engine for D3D using primitives.. I looked in the D3DX functions and found a function for loading textures from surface. One of the parameters is a RECT, so without studying the function I believe I found my way out.

(if it is the correct way out) Would creating this ''temp'' texture and loading it from a surface be faster or slower than a BltFast? Because I know BltFast is pretty fast....

Trajar
No BltFast is not the only choice, you can use the D3DX texturing functions too, i think (i've never done it). As for which is faster, i can't really say since i've never done it, but i'll guess that D3DX will be faster since 3d accelerator cards can render thousands of textured polys very quickly. Plus if you use D3DX you can take advantage of the hardware acceleration and do effects like fading and antialiasing much faster , and this isn't even supported in BltFast.

And NoNseNse, i have no clue how BltFast works
But i've used this method for a font engine (my game has a software mode so i can't only use D3DX) and it's pretty fast.

+AA_970+

Edited by - +AA_970+ on July 12, 2000 11:28:28 PM
Well since we''re talking DirectX, you''re going to have to do a blit at one point or another (unless you do a flip...and i dont imagine you''ll be flipping a single character in a font engine...anyway) So it would seem to me that the fastest way to do it would be to make a class or struct or some object type that represents a character. This object would contain coordinate information, IE a RECT or something that defines where on the surface the desired texture is. Then when it''s time to do the drawing, you can use bltfast...which takes a src-rect as a parameter.
Being that this will be a font engine specifically for my D3D games, I was wondering if/how much a ddraw bltfast would slow down the the 3D pipeline... All of us have been told not to mix Ddraw and D3D. So, in this case, would BltFast still be feasible?

Thanks
Trajar
In my game i mixed D3DX with Direct Draw. In the font engine, i use bltfast and there''s isn''t much of a performance hit, but you do lose a few fps when lots of strings are printed on the screen.


+AA_970+

This topic is closed to new replies.

Advertisement