Barrapunto

Si te haces tú mismo las librerías no sólo te estarás perdiendo el trabajo de otras muchas personas, sino que te arriesgas a que no sea compatible con otras tarjetas. Usando, por ejemplo, librerías que te den acceso al framebuffer te ahorras mucho trabajo, y ganas más ventajas: soporte en cualquier tarjeta, aceleración (si la hay), etc.

Bueno, en primer lugar para saber cómo se hace (que creo que ya es motivo suficiente), y en segundo lugar porque quizá me interese tratar algún tema de forma más específica. Supongo que los que han escrito esas librerías habrán sacado la información de algún lugar, pero no he podido encontrar cual :(

Pues tendrías que trabajar exactamente igual que si lo hiceras en DOS o en Windows. La única diferencia estriba en cómo pedirle al sistema operativo que te deje acceso directo al hardware. En concreto al rango de memoria de vídeo y a la BIOS de la misma, o, si eres lo suficientemente hombre (antiguamente se decía que si uno era un hombre de verdad, se dejaba de tonterías y se saltaba incluso la BIOS, en los tiempos heroicos del DOS y del CP/M, y accedía directamente al hierro) el acceso a los puertos y al mapa de memoria físico (esto es, posiciones de memoria fijadas de antemano que programan o leen configuración de la tarjeta).

Pero como ya han comentado por aquí, eso supondría que lo que hicieras seguramente sólo funcionaría con tu trajeta de vídeo y que incluso un cambio de modelo dejaría a tu programa poco menos que inútil.

Y si a eso le añades que posiblemente lo que tu hagas ya lo han hecho otros, y también posiblemente mejor, pues no creo que valga mucho la pena. Supongo que cosas como SvgaLib y demás han sido revisadas por varias personas para sacarle mayor rendimiento y estarán bastante optimizadas...

Hola.

Yo en unices no tengo experiencia programando gráficamente a bajo nivel, apenas he tocado las X y el GTK+ un poco.

Sin embargo, en DOS sí que he trabajado mucho a bajo nivel, utilizando ensamblador y C. Y para ello utilicé documentación bastante antigua, aunque aplicable a las tarjetas modernas si conoces algunas especificaciones de las mismas.

Es por eso que te recomiendo un tutorial un poco antiguo pero que trata a la perfección (desde mi punto de vista) este tema y muchos otros. Lo lamentable es que se necesitaba DOS o Windows para leerlo cómodamente y para algunos ejemplos, aunque ahora hay una versión online. La documentación en sí se llama PCGPE, era un intento de crear una enciclopedia de conocimientos para programadores de videojuegos y de la demoscene, y la puedes encontrar en perfecto inglés en http://brand107.home.attbi.com/pc-gpe/. Utiliza seudocódigo en algunos docs, pero también usa mayoritariamente Pascal (y algo de C y assembler). De todos modos, el código es fácilmente transportable con unos mínimos conocimientos.

Yo con ella aprendí a programar la SVGA, a mover gráficos 3D, y algunas cosas más que cuando me pasé al PC no dominaba mínimamente.

Ya de paso me gustaría abrir una lanza en favor de que te programes tu propia librería. Si bien es cierto que esto a la larga puede dar problemas de compatibilidad si la librería que programes no está suficientemente testada en distintas combinaciones hardware (necesitarás por tanto o muchas máquinas o muchos amigos), estoy ya un poco cansado de ver que parece que existe una ley no escrita que dice que "no se puede programar nada que ya exista". Si esto fuera así, entonces no existiría Minix, Linux, *BSD, KOffice, ni nada, porque ya existían en mayor o menor medida las mismas implementaciones con anterioridad.

Creo que, además, programar una librería gráfica desde cero es un gran aprendizaje porque te va a plantear montones de problemas, y tendrás que ingeniar montones de soluciones. Te deseo suerte en el empeño.

Saludos.

La programación gráfica a bajo nivel (accediendo directamente al hardware) se puede hacer básicamente de dos formas.

1. Confiando en que tu tarjeta sea VESA y acceder a la memoria 0xa000:0000 (dirección en modo real), hechandole mano a la interrupción 0x10 (más modo real). En el caso del linux tendrás que mirarte como acceder al modo real desde el modo protegido.

2. Olvidandote del modo real y de las interrupciones e ir directamente a tocar los puertos de entrada/salida. El problema con ésto es la baja compatibilidad entre las tarjetas (supongo que hasta una resolución de 320x200 todas funcionan más o menos igual). Creo que hay poca documentación de esto ya que la mayoría de la gente que programa en bajo nivel (vease MS-DOS) usa el método 1.

Yo personalmente creo que es una tontería intentar a hacer programación gráfica a bajo nivel. Si quieres aprender como funciona la tarjeta internamente ponte a programa un driver para las XFree.

La mejor forma de programación gráfica es SDL, FrameBuffer, XFree, OpenGL, etc...

PD: La web me da un internal sever error si intento poner el comentario con mi usuario. Soy samsaga2.

¿ Alguien te impide ver el código de la svgalib y ver como lo hacen ?

Supongo que el grupo de la svgalib tendrá una lista de correo, pide allí alguna página/libro/recurso que ellos hayan utilizado o utilicen.

Dices que en freebsd? pon "man vgl". Es como la svgalib, solo que la documentacion se limita a una pagina man y a mirarse el codigo fuente. Eso si, es mas sencilla que svgalib, creo recordar que el codigo fuente de la vgl son 5 o 6 archivos. Muy bajo nivel no sera, pero el codigo fuente puede ser mas sencillo de "descifrar"

La programación grafica a bajo nivel tiene sentido en sistemas como MS-DOS, donde la única forma de hacerlos es asi, pero en sistemas donde la forma de generar graficos es tan elevada como en linux (vease x11,dga,framebuffer,etc...) lo mejor es usar una libreria que se encargue de darnos un buffer a donde acceder (que es lo que realmente queremos) y ya está, ganamos en portabilidad, y velocidad de desarrollo.

Si quieres apredender como funcionan los gráficos a bajo nivel estudia el código de estas librerias, pero despues de estar muchos años haciendo programación gráfica en MS-DOS, no creas que es tan útil aprender este tipo de cosas, a menos que quieras usar algun modo gráfico especial como los modosX pero pienso que esto pertenece a otra época.

Si lo que quieres es escribir una libreria gráfica mirate las existentes,pruébalas y si alguna se ajusta a tus necesidades úsala, si no se ajustan a tus necesidades usa el código ya escrito para adaptarlas, y si aún asi crees que hace falta una nueva (aunque lo dudo) pos ánimo,si es sencilla de usar, soporta openGL, sonido, y soporte para usar el teclado y el ratón, y ademas es portable (UNIXs, windozes, BeOS,etc..) hasta la uso, pero sinceramete si vas a desarrollar apps gráficas usa SDL.

La red es vasta e infinita.

Bueno, no voy a ser muy extenso, pero la programación gráfica en LinuX...BSD es un tema apasionante. En primer lugar programar a bajo nivel carece de sentido, realmente no es muy útil en un mundo donde el hardware es muy cambiante. Además que programar a bajo nivel obliga a programar para modelos concretos de tarjetas, ya que los fabricantes rara vez siguen los estándares, o bien con los estándares te quedas muy corto.

Yo abogo por una solución intermedia entre el bajo nivel y algo tipo OpenGL (que es indiscutiblemente portable y MUY potente), prueba las SDL que son unas librerías fantásticas para programar a un relativo bajo nivel. Por otro lado SDL presenta algo que a todo programador interesa, son MUY portables[incluso tienes la versión para Play Station] y te abstraen del hardware (incluso del S.O). nota: !Ánimaos a programar gráficos para LinuX! y vistad Grafix que somos un mini-grupo de desarrollo de gráficos para Linux (ahora por el momento con SDL y algo de Allegro...)

Hay una libreria que se llama tiny-ptc, que te ayuda a crear un frame buffer en muchos SO, y por su puesto, hay version X11.
Si lo quieres mirar, el codigo es muy pequenyo y esta muy bien comentado. (Es lo justo para abrir un fb en X11, tanto en ventana como en fullscreen).

Bueno encuanto a lo de acceder a zonas de memoria privilegiadas, debes pensar que el servidor X se ejecuta como setuid root, o como root si usamos xdm. Ellos si pueden acceder a estas zonas de memoria, pero tampoco lo he intentado nunca.