On 2/10/06, Peter Keller <[EMAIL PROTECTED]> wrote: > Because what happened was that I did the bigloo opengl port (my god was > it *sexy*) and then Mr. Serrano changed the FFI a version later causing > my work to crumble and I didn't want to repeat it so it died.
That's terrible! > And, if you wanted the most bang for your buck, then the SDL_* API should Forgive my naivety but why do you still need SDL in that case? To display images you map them as textures onto rectangles, and the OpenGL implementation takes care of the rest, right? What do you have to do to get text via OpenGL? Would you need an interface to freetype or something like that? And if so, would the output from freetype have to be a bitmap? Or is it too terribly expensive to translate glyphs into sequences of OpenGL drawing commands for each line segment? 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. 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? My prioritized concerns are first, to get the best 2D performance on every device; 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. When a file containing a model is saved, if you are saving a Scheme data structure in ASCII form, then you cannot necessarily tell whether a number with a decimal point in it (like say 167.25) is fixed or floating point (except when it's obvious that the number can't be exactly expressed in fixed-point). 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? For many uses of flonums (for middle-sized values at least), an approximate implementation would be available on the fixed-point version, which is better than just not having flonums at all. And the OpenGL API would appear identical - it takes flonum coordinates, and only the implementation is different. The PDA version could be linked with klimt and the PC version to Mesa, or whatever. And 3D models would be portable across the two; just that they might not render the same, depending on the scale of the numbers that are being used. As fp implementations get faster and more pervasive the fixed-point implementation would fade out of use anyway. Well sorry if this seems like a half-baked idea, but I'm curious what you all think of it anyway. _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
