1. Take your entitys coordinates and size and transform them into the coordinate space of the screen. If an entity is in the middle of the screen, it should be at the origin of this coordinate system (assuming you use the screen center as the origin of the screen coordinate system; you could use a corner too i guess)

If your camera/entity cannot rotate, this is simply:

localPos = globalPos - cameraPos

to get the camera/screen local coordinate of the entity. If you have zooming or such you need to scale the size of the entity, otherwise you dont need to touch it.

2. Use this screen local coordinate to make some trivial comparisons to see if the entity is within the screen. To make this simpler, you can calculate the lower right corner by adding the size of the entity to its top left corner which you have.

-Make sure top left corner is not below bottom of screen or right of the right screen edge

-Similarly make sure bottom right corner is not above top of screen or left of the left screen edge

Look into spatial indexing using quad trees.

http://blog.notdot.net/2009/11/Damn-Cool-Algorithms-Spatial-indexing-with-Quadtrees-and-Hilbert-Curves

They allow you to make super fast look-ups on renderable entities, allowing you to cull them in almost no time at all. Doing checks on every entity probably produces the same overhead as just rendering them anyway.

Doing checks on every entity probably produces the same overhead as just rendering them anyway.

That's probably incorrect in most instances unless thousands of calcs per-entity is needed to cull them. Though culling calcs are likely done on the CPU, anything that is rendered is going to go through a culling calc somewhere. From the OP's description, maybe 6 or 8 point calculations per-entity in that case.

I need a formula for my 2D game that calculates whether or not a game object/entity should be rendered.
This means, if an entity is not visible on the screen(the translated view), skip the rendering it.