There is a clear distinction to be drawn between YOU rendering and then reading back, and WINDOWS rendering (and 3rd party applications) and you reading back. It’s also important to know how you render, is it the GDI or is it OpenGL rendering. Is it the same application or a different one.
I think you need to spell out exactly what you’re doing and don’t assume responses to another poster (or to an scenario unclear to a poster) applies directly to you.
The various differences may seem subtle but technically they are huge and impact the calls you make and the performance in a big way, and even the feasibility (the requirement for dual head for example).
Originally posted by knackered: It’s not reinventing the wheel - that’s a silly statement.
…
Fact is, a simple and very fast dynamic array class is easy to write
uhm… wich std::vector exactly is… a simple, fast dynamic array class…
so you DO reinvent the wheel.
for most projects there’s no need to involve a third party library for such basic tasks…it’s enough hassle dealing with the external libraries we’re forced to use, without introducing yet more 3rd party wildcards.
on any c++ compliant compiler, this IS THE STANDARD. its not just another third party library.
and so… it is… actually… the way to do exactly that.
It’s ridiculous - if you can find a use for the more exotic features of these classes (the features that could potentially threaten the robustness of a homegrown variety), then use them, if you can’t then give them a wide birth.
exotic feature? constructing a dynamic array with the required size… what is so exotic at this? and then… accessing it… even more exotic
what i see is that he isn’t really consistent in the code, using new shortly later… while he could use a static array where he uses the vector… you could attack his non-existent consistency, THAT is very dangerous.
but the use of vector there is correct and good and simple.
Jesus wept, you’re not managing the countries inland revenue records, you’re writing renderers for games.
wich should be written in a a good way. so be, and stay consistent. thats the most important thing.
the second important thing is savety. your code is not allowed to fail in ANY way, and IF it does, to be able to check for all its own resources.
i don’t want to download patches for your app.
i think thats about it for the offtopic part in here…
std::vector<T>::begin() returns an iterator, which in old STL implementations used to be a straight forward T* so could be safely cast to T*.
However, Visual Studio .NET is amoung new breed of Standards complient compilers than the std::vector<T>::begin() return a interator which is a class in its own right, its no longer a T* so its not safe to cast it as one.
What I have to be most convient to do is do the cast the address of std::vector<T>::front().
I’m curious why it is necessary to create the DC and DIB section and then destroy them each frame. It seems to me that you could break the GrabScreenRip function into three functions: initialize, grab (this would be called each frame), and cleanup. Maybe this would make it fast enough to use in realtime.