Shawn Rutledge wrote:
You don't. I've avoided learning SDL because I'm not convinced it's a value add if you're going to require OpenGL anyways. SDL began life as a 2D portability layer. I don't have a sense of how OpenGL oriented it is nowadays. I'm kinda jaded. I'm thinking, gee there's probably a lot of code in the way of the OpenGL stuff, because of SDL's long and sundry history. There's a bunch of stuff at www.opengl.org about this.What do you have to do to get text via OpenGL? Man this is so early 90s. Back when we all wrote our own 3D APIs from scratch! Look into OpenGL ES and what devices support it. ES is supposed to be the stripped down version of OpenGL for such gizmos.Another reason I was starting my own 2D graphics library (and procrastinating dealing with 3D) is that I see OpenGL uses floating-point arguments to most functions. For now that is not a good idea on small devices (even the ones that are powerful enough to do some 3D rendering). But klimt claims to have a fixed-point implementation. So I think it would be ideal to keep the numeric types swappable somehow. I stared long and hard at the problem, and concluded that doing 2D via 3D HW is the correct way to do things. You're going to need image rotation and scaling operations and so forth. There's a reason the rest of the industry went "3D for 2D." I wouldn't waste time reinventing last decade's thought processes on the matter.For my 2D library I planned to use 24.8 bit fixed point for screen coordinates, with the units being millimeters, and on most devices (where exact dimensions are not important) to fudge it by assuming there are 4 pixels per mm (101.6 dpi is pretty close to typical resolution of today's monitors). So you'd end up with 6 bits of sub-pixel resolution. A simple implementation would just round to the nearest pixel; an integer antialiasing implementation would use the subpixels to be more accurate; and if OpenGL acceleration is available, the 2D drawing commands could be translated into OpenGL calls, and the fixed-point numbers would get translated into floating-point. But, this approach assumes that the majority of the work is 2D, because OpenGL is just being used as an implementation. Wouldn't it be nice to get away from needing completely separate 2D and 3D methodologies? Unless this is going to get you big $$$$$$, this is a complete waste of time.My prioritized concerns are first, to get the best 2D performance on every device; Yeah, so, 2 years from now nobody will care. You'll waste all this time trying to optimize for obsolescent technology. Reminds me when I was going to port Free3D from i486 to Pentium. Glad I got lazy, because in hindsight, it would have been for nothing. The HW changes too fast. Plan for the future, not the past.second, to be forward-compatible with 3D hardware; third, to make the 3D functionality on such hardware available fully via a "nice" clean API which very closely resembles the 2D API (and last but not least, slow 3D should even be available on slower machines, using the same API). Apparently Cairo achieves at least the first two goals (it can do software 2D rendering, or you can use the "glitz" backend to render to OpenGL calls) but it's kindof heavyweight, and also uses floating-point extensively. Blow off the device that has poor market share. You know, I wasted my early career on trying to make 3D APIs portable to everything, everywhere. I ended up with a really spiffy portable 2D rasterization layer, and my 3D API barely drew a polygon. I was also an Autoconf and IMake guru. It's better to pick one platform that's worth *money* and do a decent job on it.So what if there was a version of Chicken for devices without math coprocessors in which flonums are really fixed-point 24.8 format, and another version in which they are floating point? I think I've been there, done that. I know everyone has to reinvent the world anew for themselves, but I hope you heed the warnings of older souls.Well sorry if this seems like a half-baked idea, but I'm curious what you all think of it anyway. Cheers, Brandon Van Every |
_______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
