Why are pixel reads so slow?

[spathi]

Why do pixel read operations tend to be so slow?  Is it because they are attempting to read from vram?

Could things be sped up with custom draw routines that also blit to an array as well as drawing to vram?  Then your pixel read operation would read from the array, which would contain identical information.  Your draws might be somewhat slower but your reads faster?

[jace_stknights]

In wich language do you code?

There are a lot of techniques to draw pixels! I think you should give us the way you are doing actually.

[spathi]

I'm talking about readpixel operations, eg in Blitzmax or SFML or SDL where they are all rather slow.  For instance it would be very fast to blit an 800x600 rectangular memory area to the screen, but reading that (eg with getimagerect() in Blitzmax or the similar in SFML) you wouldn't be able to do ten times per second. 

[zawran]

Reading pixels in Blitzmax can be fast, but just not using the built-in functions. But the nice thing about blitzmax is that you have access to all the internal code so you can see where they have added extra stuff to make using their functions easier. This also allows you to add your own stuff so that you interact with their stuff using code you make.

I made a software framework way back which gave you the option of having image buffers in which you could manipulate pixels and then blitz everything to the screen at once. You can find the thread here:

http://www.dbfinteractive.com/forum/index.php?topic=4193.msg55969#msg55969

There were a number of other threads related to this, but this was the initial thread about it. You are free to use anything from this framework if you find use for it.

Using this framework I made a couple of retro looking intros and the speed is quite good I would say.

[spathi]

Wow, I'm very interested in this.  I haven't dug into the Blitzmax source at all, and I should probably do so.  But I got Monkey and have been working with that (love it!)

The Blitz languages really put the fun back in programming.