Ok ! Consider this: We are writing a 2D Game using SDL. Each time we move something on the screen we must remember its last and new position (two rectangles) so that we can redraw that area and update the screen (we call this, a dirty rectangle mechanisim) So at each frame we construct the region of the screen that has to be redrawen before calling SDL_UpdateRects to update the screen. The region is constructed 60 times per second (this the refresh rate of most screens), do you think that the game writer will want to convert a vector<rectangle> (whose size may vary between 0 and 100) into the corresponding vector<SDL_Rect> 60 times per second ? And remember there is far more stuff to be done in this 1/60 of a second.
Have you actually profiled this? I was quite happily acheiving much higher framerates than 60fps with dirty update region based 2d graphics on windows boxes nearly 10 years ago and using just a simple struct containing a pair of int's to represent a point that converted to windows points as neccesary. This is so unlikely to be any sort of bottleneck in the system, numbers would be good to back this up as it seems to be the fundamental reason behind the design of the library. I can imagine scenerios where the conversion could become a problem but yours as described just isn't one of them;) Also I think that as soon as you write a geometric library that contains points you need to introduce vectors and hence matrices (with probably homegenous forms) so you can simply set up the entire world -> device tranform pipeline. Without these the library just doesn't offer enough out of the box to make it interesting to me. Even then it would have to be very good to compete with Eberly's wild magic library as an off the shelf type of library. Martin -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 1/07/2005