Zardoz89
commented
11 years ago I just see that you did it. I think that isn't a bad idea. It's better that was doing previous, but :
- I think that we must avoid call updateScreen() in tick(). It's a slow process that can slowdown the VM. Instead, call be called from getScreen() when this function detects that the video ram has changed. To detect this, we can simply run a checksum (or a fast hash) routine in the video ram every 2000 CPU ticks. If the checksum has changed, before the previous flag, then the video ram has changed. A checksum it's much more faster that updating the whole screen.
- Using sf::Image is better that sf::Texture because avoid calls to the GPU inside of the hardware device. But at some point, we should change to use an array of uint8_t to store pixel data in RGBA format. And give read access to it from outside. This will allow to make the device implementation be independent of the graphics lib being used.
- By the same reason, getBorder() should return a uint8_t[4] storing the boder color in RGBA format.
Yep, cause : the updatescreen function is not called by tick but by main loop. Proposition : Monitor have their own sf::Image as member (no need allocation) updateScreen must be an internal function that only update the sf::Image and getScreen function return the sf::Image ptr.