project genesis compiler cancelado

[boubou]

                                y entonces lo podria hacer en bitecode y despues compilarlo????
se podria hacer??                                

[HaltedMode]

                                Despues de haberlo "compilado" a byte-code, ese codigo ya compilado lo podrias interpretar. Asi es como trabaja Java por ejemplo (y no le va mal). Asi que piensate eso de compilar o interpretar, porque con un lenguaje interpretado podrias hacer tu trabajo mas facil (pues a los ficheros en byte-code les pones tu la cabecera que te salga de los .... :sonriendo: o incluso ninguna) y tus programas podrian ser incluso mas portables (lease Java), pues solo tendrias que construir un interprete para cada arquitectura, aunque si dices que solo va a ser para DirectX entonces lo de la portabilidad te importara tres cojones(con perdon por la expresion :sonriendo:).
Saludos.                                

[Javi SJ Cervera]

                                Ehmm... no entiendes para qué es el bytecode.

Primero, te vuelvo a insistir en lo de siempre. Mira, vas a tardar mucho es hacer un compilador que produzca un EXE nativo como salida, y además requiere mucho trabajo. No merece la pena todo el trabajo que vas a emplear en el proceso, sobre todo teniendo en cuenta que el ejecutable no estaría para nada optimizado. Si generas un bytecode, luego sólo tienes que escribir un programa que lo entienda y lo ejecute directamente, no necesitas compilarlo a EXE. Así es como funciona, por ejemplo, Java. Hay una llamada "máquina virtual" que lee e "interpreta" (ejecuta) un fichero binario de Java (un bytecode). Para hacer el bytecode puedes hacer una tabla que contenga un valor numérico que identifique a cada palabra reservada del lenguaje, cada operador, etc. El compilador crea un fichero que es muy similar al código fuente que lee, pero en lugar de contener cada palabra clave u operador en sí, contiene el valor numérico que lo representa en la tabla. Las funciones, variables, etc, no se indentifican tampoco por nombre, sino por un valor numérico que indica, por ejemplo, la posición en que fue declarada (1ª variable declarada, 2ª, etc). Las ventajas de leer un bytecode sobre leer el código fuente directamente es que ocultas el código fuente, que no necesita comprobar que la sintaxis es correcta durante la ejecución (ya lo hizo el compilador), y es más rápido leer un byte con el valor identificador de un "token" (pieza del lenguaje) que leer una cadena de texto completa e identificar la pieza.

Si todo esto parece complicado y lioso, no es NADA en comparación con generar un EXE nativo. Si sigues queriendo generar el EXE, pues yo te aconsejo que hagas lo que te dije en un principio, que el compilador traduzca a C++ y despues llame al GCC para compilar. Es poco profesional pero dará muchiiiiisimo mejor resultado de lo que quieres hacer tú.
                               

[seryu]

                                a boubou:

Empieza por hacer programas que lean archivos de configuracion, luego interpretes que ejecuten lo qe vayan leyendo del programa, luego un lenguaje interpretado... ve desde lo basico, porque sino no seras capaz de sacarlo nunca, ni tu ni nadie a hecho jamas una casa desde el tejado. Esto es como montar en bici, como no empieces usando las ruedas de atras te meteras miles de ostias.

a jedive:

qe tal con tu brightbasic, hay ya un sitio con noticias de lo ultimo?                                

[Javi SJ Cervera]

                                Nas Seryu.

No hay página web de BrightBasic de momento. Últimamente meto más horas al 3D Architect, porque queda poco para estar acabado y la comunidad del DarkBasic Pro me está metiendo presión para que salga al tiempo del DBPro. Además tengo la competencia del futuro CShop3, y no puedo dejar que me coma mucho terreno :ojo:

Cuando acabe 3D Architect (y los exámenes de septiembre), meteré horas al BrightBasic como Dios manda. Por ahora le dedico poco más de un par de horillas a la semana.
                               

[seryu]

                                oka, una duda mas, creo qe usabas directx al final, estas haciendo tus propias funciones o usas una libreria?                                

[Javi SJ Cervera]

                                Estoy desarrollando dos versiones en paralelo de la librería: una en DirectX 8.1 y otra en OpenGL. Depende de como evolucione cada una, decidiré con cual me quedo. OpenGL es muy buena en cuanto a estabilidad, robusted, y sobre todo de cara a una futura portabilidad del BrightBasic. DirectX en cambio hace uso de las técnicas de las últimas tarjetas (las nuevas ATI y la serie geForce3 en adelante), trae todos los APIS que necesito para programar (sonido, entrada/salida... ) y alguna cosilla más. Todo se verá. Por ahora la versión DX está muuuuuuuucho menos avanzada que la de OpenGL, pero es que aún estoy aprendiendo Direct3D.

En principio me basé en la librería NukeDX. Suponiendo que finalmente escoga DX para BrightBasic, programaré una librería en DirectX sin wrappers intermedios. NukeDX usa DirectDraw, mientras que yo empleare D3D para hacer tb las 2D.
                               

[DraKKaR]

                                Ke capacidad de las ultimas tarjetas hace direct3d ke no haga opengl?                                

[BeRSeRKeR]

                                Ninguna...lo que pasa es que mientras que en Direct3D programas una cosa para todas las aceleradoras, en OpenGL sueles programar varias cosas que hacen lo mismo pero lo tienes que hacer para que funcione en el mayor nº de aceleradoras posible. Por ejemplo según Carmack Doom3 tiene unos 4 o 5 renderers...uno para cada aceleradora que se quiere soportar. Ese es el inconveniente actual de OpenGL. Y bueno, esto es debido a la política de extensiones...cada uno hace las suyas y hasta que el ARB no saca un estándar pues tienes que aguantar. Por ejemplo, creo que hace poco salió el ARB_VERTEX_PROGRAM.

Saludos
                               

[Tyrell]

                               

El 2002-09-03 14:14, MFlores escribió:
Pues venga, yo ya gano a unos cuantos.
Tengo 30

33, la banca gana.                                

[synchrnzr]

                                Boubou: mira, si te apuntas a Ingeniería Superior en Informática en cualquier Universidad española, te mandaran hacer un compilador como pràctica en el último año XDDD

Sync :guay:

PD: Y compilarás EXEs ¿eh? :ojo:

[ Este Mensaje fue editado por: synchrnzr el 2002-09-05 12:46 ]                                

[Javi SJ Cervera]

                                DirectX 8 trae soporte para cosas como el bump-mapping que traen geforce3 en adelante. Con OpenGL, hasta k salga la 2.0, la única forma de hacerlo es recurriendo a las malditas extensions.
                               

[BeRSeRKeR]

                                Ya, por eso digo, que OpenGL soporta todo lo que las aceleradoras de hoy en día son capaces de hacer gracias a las extensiones. Por ejemplo bump mapping puedes hacer con OpenGL a través de los register combiners...aunque creo que ya hay extensiones para crear fragment programs (pixel shaders)...lo que no sé es si ha salido la extensión del ARB...

Saludos
                               

[Emotion]

                                si no recuerdo mal por un articulo que lei por ahi las implementaciones 'estandarizadas' del ARB para los pixel shaders no estaran listas hasta OpenGL 1.5, creo que en OpenGL 1.4 ya esta disponible la extension ARB_vertex_program, pero no estoy muy seguro                                

[BeRSeRKeR]

                                Si, el ARB_vertex_program si ha salido ya