How do I read screen buffer?

[fabriziotappero]

hello,
I have read the whole wiki documentation but I could not find a way to actually read the pixel status (aka R,G,B) of the rendered window. It seems a bit strange to me that such a basic info is actually not there.

Just for reference, here is how you read the pixel status of a Sprite:

olc::Pixel pCircuitPixel;
sprCircuit = std::make_unique<olc::Sprite>("./assets/circuit.png");
DrawSprite(olc::vi2d(0, 0) * vCircuitSize, sprCircuit.get());

pCircuitPixel = sprCircuit->GetPixel(GetMouseX(),GetMouseY());
std::cout << "Pixel: " << std::to_string(pCircuitPixel.r) << " " 
                                 << std::to_string(pCircuitPixel.g) << " " 
                                << std::to_string(pCircuitPixel.b) << "\n";

The reason why I find this info important us because I imagine this is the way you work out how different sprites can interact between them when you cannot use their sizes as in the simple pong example in the documentation. Right?
In my case I have a large .png sprite that defined a race circuit and I need to read where the track is located (based on color) so that cars don't drive outside it.

[OneLoneCoder]

To read the screen, it is just a sprite like any other, but it is considered the draw target. So you can GetDrawTarget()->GetPixel() to retrieve a value. Notes: decals are not sprites so this won't work; also doing pixel based collision using the screen buffer is likely not a great way in most circumstances.

[fabriziotappero]

Great! thanks for clarifying.
yeah, I thought so. The fundamental problem is that if you use a background coming from a .png image and you want other objects to interact with it, GetPixel() seems the only way. The only other alternative I see is to construct the background using different sprites. however if it is a car interacting with a curved circuit curb, GetPixel() seems the best option.
What is the solution for advanced game engines?

[OneLoneCoder]

You'd represent the track as a polygon, even if it's not rendered as such. That way geometry comes to the rescue and makes things spatially invariant and simple(ish) to compute

[fabriziotappero]

thanks a lot for the suggestion! btw, thanks a lot for this amazing tool!