Prof, I understand your method but it's a bit loop intensive. I just wanted to work out how to split the rects into two/three smaller non overlapping rects i.e. end up with two/three sets of rect coords (x,y,w,h) that's all.
One Eyed Jack: I need to get the opmisations in now because the game engine (+title/menus/basic gameplay/sound/music) is done, I just need to add extra graphics and gameplay elements, but I don't want to have to redo that code later. I wanted to get the optimised engine in place now to save time in the long run. Forget "today's hardware"! The game needs to run on machines maybe 5 or more years old e.g. 500MHz PCs with no 3D card = BIG MARKET. My 3.2GHz PC can handle pretty much anything I can throw at it in Blitz but without dirty rects a 1GHz PC is borderline if it will drop frames and as for any less forget it, unless optimisations are made. The main optimisation I made was Dirty Rects full stop, this one might not make a massive difference but I'd thought I'd try it and see.
Also, yes in theory too many rects will slow down BUT remember that it's NOT doing a straight mem copy because it's going from a 24bit graphics buffer to a 32bit graphics buffer thus the CPU can do a batch mem copy it has to read 3 bytes, write 3 bytes and move the souce pointer by 3 and the dest pointer by 4. If you can reduce the amount of pixel read/writes by 20% or more by a bit of simple maths then it really should be faster unless the rects are really small (as I've already said).
Tim: I know I could do a bounding rect (and I see why it's useful) but as with the above point the CPU isn't doing a straight mem copy so a "bad" bounding rect could be very inefficient. Imagine a tall rect overlapping a long horiz rect, the bounding box could be a massive square yet the two rects may only be pixels wide!
One Eyed Jack: I need to get the opmisations in now because the game engine (+title/menus/basic gameplay/sound/music) is done, I just need to add extra graphics and gameplay elements, but I don't want to have to redo that code later. I wanted to get the optimised engine in place now to save time in the long run. Forget "today's hardware"! The game needs to run on machines maybe 5 or more years old e.g. 500MHz PCs with no 3D card = BIG MARKET. My 3.2GHz PC can handle pretty much anything I can throw at it in Blitz but without dirty rects a 1GHz PC is borderline if it will drop frames and as for any less forget it, unless optimisations are made. The main optimisation I made was Dirty Rects full stop, this one might not make a massive difference but I'd thought I'd try it and see.
Also, yes in theory too many rects will slow down BUT remember that it's NOT doing a straight mem copy because it's going from a 24bit graphics buffer to a 32bit graphics buffer thus the CPU can do a batch mem copy it has to read 3 bytes, write 3 bytes and move the souce pointer by 3 and the dest pointer by 4. If you can reduce the amount of pixel read/writes by 20% or more by a bit of simple maths then it really should be faster unless the rects are really small (as I've already said).
Tim: I know I could do a bounding rect (and I see why it's useful) but as with the above point the CPU isn't doing a straight mem copy so a "bad" bounding rect could be very inefficient. Imagine a tall rect overlapping a long horiz rect, the bounding box could be a massive square yet the two rects may only be pixels wide!