you are wrong and you have been corrected.
for further correction, consult your local library. i''m not here to explain CS 101 to you.

-goltrpoat


--
Float like a butterfly, bite like a crocodile.

wayne - in my experience, most compilers automatically expand for loops to a dec/jnz pair even with optimization off.. but yeah, it''s probably better to declare them that way just in case

-goltrpoat




--
Float like a butterfly, bite like a crocodile.

And we''re not here to listen to your arrogant remarks.

Qoy, you''ve probably already heard this and are using it already, but here it is:

1.Don''t lock the surface more than once per frame. Lock it, blit, blit, blit, blit, etc., and unlock it.

2.Don''t use the Windows GDI for anything other than debug text that won''t be in the final version. (If you''re printing debug labels on the sprites, this will affect you.)

Other than that, I don''t know what could be slowing down your code other than unoptimized pre/post-blit sprite handling.

Hope this helps

[ L N T A K I T O P I ]
http://geocities.com/guanajam/

(P.S. How big are these sprites, anyway??)

[ L N T A K I T O P I ]
http://geocities.com/guanajam/

Mezz - if i see someone post absolute bullshit and try to sell it as gospel, chances are i''ll reply to that. chances are i will be less than civil. and, if you have a problem seeing that in one way or another i supply useful information with all my posts, chances are you shouldn''t read them.

-goltrpoat



--
Float like a butterfly, bite like a crocodile.

No, O(n) doesn''t require that there is a loop there. It simply means that for this algorithm, the most important part of that routine will be called N times. No matter whether you use compiled sprites, software blitting or hardware blitting, this will be O(n) for the simple fact that blitting is about drawing pixels - the presence or absence of explicit looping will not change the fact that you have a fixed number of pixels that need drawing no matter how you do it. This differs from, for example, search algorithms, where one method may move a given record just once to have it sorted, where another may move it 5 or 6 times to get the same sorted list at the end.

Compiled sprites may remove the loop overhead. Also unrolling the loop in the source would minimize it. But I don''t think there is any good alternative (unless you are aiming for distant backward compatibility) to using the GPU where you have a dedicated processor which can theoretically run in parallel with your game (meaning you may only pay the cost of the function call). And no doubt has many optimisations hardcoded into the silicon.

goltrpoat, perhaps you should calm down a little? Your accurate information is appreciated, I''m sure, but there are ways of correcting people without having to offend them, surely? If most of us stayed quiet for fear of not being an expert in the field and getting every suggestion 100% right, this board would only be populated by professionals and total newbies, which is not what is wanted I think.

goltrpoat, correcting people''s mistakes are cool, but being rude while doing so isn''t. Arguments are taken much more seriously when the person isn''t (whether conciously or not) putting other people down.

I second that houdini.

This forum is not for flaming - correct someones mistakes but be civil about it, if you really don''t like it, click "back" on your browser and stay out of the thread. Nobody likes a wiseguy.


#pragma DWIM // Do What I Mean!
~ Mad Keith ~
**I use Software Mode**

ok, here''s my take on this. it is too often that people that have very minimal knowledge of a subject assume that the said subject is limited by their scope of it and act as though they know exactly what they''re talking about. then the good helpful people that i''m sure they are, they proceed to derive conclusions from their limited knowledge of the said subject and distribute the said conclusions as authoritative advice. Example: "Algorithm A is O(n^2) and algorithm B is O(n), therefore algorithm B is faster." Nevermind that algorithm A is not really O(n^2) and algorithm B is not really O(n) or that the big-O notation has nothing to do with the implementation speed, but now some poor hapless chap somewhere within the depths of the ubiquitous information superhighway is slaving away on an algorithm that ceased being useful three years ago just because some good samaritan couldn''t keep their mouth shut.

-goltrpoat


--
Float like a butterfly, bite like a crocodile.