Which is faster?...

I''d take option 2, that way you don''t have the overhead of the surface header data and all that. Just make sure the surface is not wider than the primary surface because some video cards don''t support that.

Trying is the first step towards failure.

Oh, and about Blt vs BltFast, you are right in saying that BltFast does not clip, but that is only using the DX clipper. What I have done is to write my own clipper which is faster than the DX clipper and also has the features I need (passing a RECT to be clipped in rather than a hWnd... although the DX clipper should be able to clip an array of RECTs, I found it quite buggy)

Trying is the first step towards failure.

I would do both solutions but if I should choose one I would choose number 1.

I think it would be too anoying to manually put all those frames into a single surface and then hardcode the rect values into my code. Yuck !

Never mind the header memory overhead. There''s plenty of memory in machines these days.

Solution 2 can be a memory waster too..

Example:

You have 3 256x256 images. If you place all three next to each other then you would exceed a width of 640 (which is bad if thats your screen width).

Ok then you could place 2 of them next to each other and then the 3rd below the other..But hey that would waste 256x256 pixels because there''s only 3 images. Not enough to fill the bottom.

Ok to solve this problem you place all 3 images vertically. This would not waste memory. I''m not sure how DDraw feels about extremly tall surfaces though.

But what if the surfaces are not of the same size ? Then solution 2 is almost useless. It would be too much work to place all the different sized surfaces in one big surface...One giant puzzlegame and the rect values can''t be calculated by any means...

Ok, I disagree with using option 1... ever. There is no reason to use it unless you have a VERY old video card that does not support large offscreen surfaces... I have yet to find one myself.

You do not have to hard code rect values and it is a clean interface. For example, lets say you are using a WidthxHeight image and you want the source rectange for "Frame", just do as follows. This assumes you just lay it al out horizonatally, which is by far the easiest.

Left = Frame * Width;
Top = 0;
Right = Left + Width;
Bottom = Height;

There you are. This method is just as fast if not faster than the other and it wastes 0 memory.

Blt vs. BltFast: yes BltFast fails if you try to blit to a surface that has a clipper attached. No problem, use Blt. I''ve done a lot of performance testing on Blt, BltFast and Alpha Blending and my results are that Blt is always as fast and sometimes faster on certain cards than BltFast. Even on my old ATI 2MB card this is the case. I could be wrong talking about ancient cards again but this is my experience.

Also, templating your graphics to use this method is pretty simple. I have a very function and easy to use program that I wrote that makes it very simple. If you want it, just reply and say so and I''ll upload it to a web server somewhere.

I''m currently using this method for everything in my 2D game and it works brilliantly. The code is simple and readable, the game is very fast and there is no memory wasted.

Happy coding, hope that helps.

Cool, thanks. That would be great if you could send me the code for templating my graphics. I would appreciate it. Thanks.

Sure, here is a link to a program that I wrote to template graphics. It is only a couple hundred KBs. I made the entire thing in about 5 hours but it is very optimized and I think bug free. I'll provide the source if you want, but it is in Borland C++ Builder 5, so I doubt that most of you would be able to use it.

You may all have it completely free but I'd appreciate it if you guys send me some mail to tell me your thoughts and suggestions. Use my e-mail at andytx2000@hotmail.com.

Also, the file is just a simple EXE, no install necessary. That makes it easier to just move and delete at will. The program itself is fairly self-explainatory but if you have any questions, just send me an e-mail.

Enjoy, I hope it helps. Just click the link on the page that this link takes you to to download it.
http://www.geocities.com/galacticgladiator/gt.html

Edited by - AndyTX on October 4, 2001 8:58:58 PM

Definately option 2!!!!!
Who would ever in their sane state of mind would ever choose option 1?
Option 2 does not only SAVE memory, it''s much easier to code.
And yes, for all animated bitmaps, just line them up vertically, that never hurt anybody, dx loves it, and that''s the way i did it in my last game and it worked beautifully.

Example:
16 frames of 64x64
option 1:
create 16 SEPARATE surfaces (each with their own header, init calls, etc., bleh) and when drawing the appropriate frames, u have to go through all those surfaces, that''s not too bad actually.

option 2:
One nice and neat surface with all the bitmap info you''ll ever need for this poor old sprite. Make a wrapper function that passes the current frame or something like that, then you can easily figure out what Rect to make based on the curent frame.
I pretty much agree exactly with AndyTX, but he propsed u do this aligning them horizontally, which might be easier but will always cause problems if wide surfaces arent supported (and a lot of cards dont support them, you''d be surprised)
so for vertically aligned frames do:
Left = 0;
Top = Frame*Height;
Right = Width;
Bottom = Top + Height;

nice and neat, no extra surface headers, and I dont know it for a fact, but im sure it''s faster to keep accessing the same surface over and over rather than flipping through 16 just for one sprite (one of MANY sprites i imagine, who knows how many surfaces you would end up with if u do option 1)

But then again, that''s just my opinion




ByteMe95::~ByteMe95()
Cerebrum Software

hmm, I just checked the help file and it looks like u can make wide surfaces in system mem, makes sense.
But of course this would still be slower and not good for option 1

ByteMe95::~ByteMe95()
Cerebrum Software

True about the system memory thing. I don''t think it really matters, the code is the same either way. Choose whichever is easier for you. Also, I often end up having to use both horizontally and vertically for one image which provides a lot of flexibility. For example, 5 frames of animation vertically and 10 frames of banking horizontally. Just use the same basic math and you have seamless great animation.

Also, I think the bigger problem might be with video memory if you want to have graphics wider than the screen. That would probably take a heck of a lot. However, as I said, it doesn''t really matter which way you do it, just DO OPTION 2. I hope my program will help make it easier for you or anyone else who would ever consider option 1.

quote:

---

Original post by AndyTX
You do not have to hard code rect values and it is a clean interface. For example, lets say you are using a WidthxHeight image and you want the source rectange for "Frame", just do as follows. This assumes you just lay it al out horizonatally, which is by far the easiest.

Left = Frame * Width;
Top = 0;
Right = Left + Width;
Bottom = Height;

---

No hard coding huh ?? Well how do you obtain Width and Height of the "frame" ??

Hmm, well I personally use a constant, which is easy to change. You could also load it from the registry or INIs. Or you could append a file header to your image. Also, if you use square bitmaps (tiles for example) you could simply use one dimension size as the other as well. There are a host of possibilities that make it easy. Also realize that the final Width and Height would be variables in a sprite object for example, so it isn''t really "hard coding" per se. Finally, coding it the other way would require at the very least a "hard coded" variable for the number of frames and potentially file names. I still think option 2 is much better.

what do u mean getting the width/height is hard coding???

that doesnt make sense
every sprite has its own width/height, adn no matter WHAT you do, you''ll always have to supply those, i dont see a possible way not to.

ByteMe95::~ByteMe95()
Cerebrum Software