🎉 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!
Blt vs. BltFast
Author
Okay, I have two questions...
One, which do you all prefer? To use Blt(), or BltFast()? Of course Blt() has much more features that can be done without manual coding, such as clipping. But how much faster is BltFast()? That would be good to know from anyone who''s experimented with this.
Two, does anyone have a general algorithm for finding which tile in an isometric map would appear in the very top left corner of the screen? I''ve been playing around with the math, but it''s not really working for me. The variable names I''m using are (they''re pretty self explanitory):
MAP_SIZE (per side of the map, so the map would be MAP_SIZE x MAP_SIZE in size), TILE_WIDTH, TILE_HEIGHT, SCREEN_WIDTH, SCREEN_HEIGHT. If I can get the top-left coordinate, then my isoengine will work a lot better. Thanks programmers!
-Coldfire
I think most people will agree that BltFast is the only blitter used. You will find quickly enough that the DirectDraw clipper is very very slow, so you will want to implement your own clipper. This is a relatively simple thing to do. The other option that most people eventually try are custom blitters - writing the data copying code yourself. This has to be very fast and very efficient. Most people seem to write it in assembler. In fact, if anyone has any samples I would love to see them. I am trying to do some myself and can''t get the frame rate fast enough.
I''d go with BltFast over writing a custom blitter - even the most tightly optimized code still locks the CPU, whereas BltFast has the capability to offload blits onto the gfx hardware...
Mason McCuskey
Spin Studios - home of Quaternion, 2000 GDC Indie Games Fest Finalist!
www.spin-studios.com
Mason McCuskey
Spin Studios - home of Quaternion, 2000 GDC Indie Games Fest Finalist!
www.spin-studios.com
Author
To respond to your responses...
In general, you should almost never have to write your own blitter if you''re using DirectX. If you don''t use DirectDraw''s own blitting functions, then you cannot use the hardware enabled acceleration, no matter how well you program your assembly blitter. You can probably unlock the accelerator in the graphics card somehow, but you would need to write card specific drivers for each individual card. Definitely not worth the trouble. And even if you did, you probably wouldn''t match the performance of DirectDraw''s acceleration.
In general, you should almost never have to write your own blitter if you''re using DirectX. If you don''t use DirectDraw''s own blitting functions, then you cannot use the hardware enabled acceleration, no matter how well you program your assembly blitter. You can probably unlock the accelerator in the graphics card somehow, but you would need to write card specific drivers for each individual card. Definitely not worth the trouble. And even if you did, you probably wouldn''t match the performance of DirectDraw''s acceleration.
>>
In general, you should almost never have to write your own blitter if you''re using DirectX. If you don''t use DirectDraw''s own blitting functions, then you cannot use the hardware enabled acceleration, no matter how well you program your assembly blitter. You can probably unlock the accelerator in the graphics card somehow, but you would need to write card specific drivers for each individual card. Definitely not worth the trouble. And even if you did, you probably wouldn''t match the performance of DirectDraw''s acceleration.
<<
There are a lot of reasons which should encourage you to write your own blitting functions, no matter if assembler or C (with every good compiler you have nearly no speed difference).
- If you use Alpha-blits, you HAVE to make your own routines since not all Graphic cards support Alpha and DD doesn''t emulate it.
- some graphic cards don''t support blitting at all (i think the voodoos belong to them)
- if you have a diamond-shaped tile, and really want to optimize your engine, you will develop your own file format which saves the diamond in a linear stream rather then in a rectangle. Then you need your own blitting funcions as well.
- You have NO compatibility problems since you always know what to do. You just have to fight with the color conversions.
And please don''t get the idea to use a D3D-quad with texture mapping, unless you really know what to do...
Chris.
In general, you should almost never have to write your own blitter if you''re using DirectX. If you don''t use DirectDraw''s own blitting functions, then you cannot use the hardware enabled acceleration, no matter how well you program your assembly blitter. You can probably unlock the accelerator in the graphics card somehow, but you would need to write card specific drivers for each individual card. Definitely not worth the trouble. And even if you did, you probably wouldn''t match the performance of DirectDraw''s acceleration.
<<
There are a lot of reasons which should encourage you to write your own blitting functions, no matter if assembler or C (with every good compiler you have nearly no speed difference).
- If you use Alpha-blits, you HAVE to make your own routines since not all Graphic cards support Alpha and DD doesn''t emulate it.
- some graphic cards don''t support blitting at all (i think the voodoos belong to them)
- if you have a diamond-shaped tile, and really want to optimize your engine, you will develop your own file format which saves the diamond in a linear stream rather then in a rectangle. Then you need your own blitting funcions as well.
- You have NO compatibility problems since you always know what to do. You just have to fight with the color conversions.
And please don''t get the idea to use a D3D-quad with texture mapping, unless you really know what to do...
Chris.
What''s wrong with using d3d quads with textures?
When the customer has 3d accelerated hardware then the speed boost is huge. Esspecially when you are using transparancy effects.
But you always have to fall back on normal blitting for people without software I suppose.
Jaap Suter
When the customer has 3d accelerated hardware then the speed boost is huge. Esspecially when you are using transparancy effects.
But you always have to fall back on normal blitting for people without software I suppose.
Jaap Suter
"which is faster?" - you can always try profiling it yourself, try couting the cycles each operation takes, should be quite exact. use the rdtsc opcode, which stores the result in eax:edx, use it again after the code you measure and substract the results. there''s an article on monitoring performance on inetls website.
http://developer.intel.com/drg/mmx/appnotes/perfmon.htm
http://developer.intel.com/drg/mmx/appnotes/perfmon.htm
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
