Estoy completamente de acuerdo con Seryu y con Lord Trancos.

Por cierto Trancos, muy bueno el ejemplo de 1984, vaya pedazo de libro.

Ethernet:

La informacion de kriptopolis es tan sensacionalista y corrupta como la imagen q da el gobierno de la LSSI.

¿El gobierno da una imagen corrupta de la LSSI? Todo lo contrario. La LSSI es obra del PP, CiU y Coalición Canaria, y de hecho en la web del Partido Popular se muestran como "los grandes promotores del avance tecnológico en nuestro país" y bla bla bla... se nota k no saben k somos el país europeo después de Grecia más atrasado en el tema d internet... y mira k los griegos son prehistóricos en esto.

Jaure:

La ley está aprobada para bien o para mal, será el tiempo el que nos de el remedio, si de verdad es una ley tan restrictiva como decís algunos, pues se arreglará votando a otros, y estos que cambien otra vez la legislación.

Eso por supuesto, la LSSI no es ni de lejos lo único k me revienta del gobierno actual (y lo mismo me pasa con el anterior). Sé que esto está completamente fuera de lugar, pero se supone que en España los tres poderes (legislativo, ejecutivo y judicial) están separados. Pues bien, Aznar es presidente del gobierno o, lo k es lo mismo, del poder ejecutivo, y está demostrando tener más influencia (junto a su gabinete de gobierno y muy especialmente el Ministerio de Cultura) que lso diputados del Parlamento en asuntos legislativos... y es k la mayoría absoluta no es más k la dictadura de 4 años.

Y por otro lado... ¿a kien más vas a votar? El PSOE está hecho un asco y mi keridisima Izquierda Unida últimamente no sabe ni para dónde mira. Sobre el resto de partidos, la verdad es k desconozco bastante su situación.

PD: Perdon por el rollo politico fuera d lugar                                

                                emacs                                

                                Pues yo te recomiendo el Dev-C++ más que nada porque es completamente gratuito y libre. Además, la última beta del Dev-C++ 5 es muy funcional y estable (creo k es la beta 6). Es una descarga de sólo 10 mb, y trae el compilador, el entorno, la librería estándar de C y unas cuantas librerías extra como OpenGL, que es por otra parte la librería que te recomiendo para programar en 3D. Te lo puedes bajar de www.bloodshed.net

Tienes que tener en cuenta que OpenGL es sólo para gráficos, así que el resto de cosas, como el sonido, el teclado, etc, tienes que hacerlas con otra librería. Puedes usar GLut o, lo que yo te recomiendo, SDL. En www.libsdl.org te puedes bajar las librerías de desarrollo para mingw, que es el compilador en el que se basa Dev-C++.                                

                                Mira en nehe.gamedev.net. Hay tutoriales de proyeccion ortogonal q tb tocan el tema de las 2D en OpenGL. El tutorial 21 puede serte util.
                               

                                muchas gracias a todos
                               

                                Hmmm... vaya. Entonces, ¿no es mejor una geForce2 Ti que una 4MX?
                               

                                no se yo, sync... eso ya se lo pase yo hace tiempo, pero el problema es que está en ingles...
                               

                                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.
                               

                                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.
                               

                                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.
                               

                                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ú.
                               

                                " bueno jedive, aunque sea en bytecode
porfa dime la cabecera de los exes o donde lo has encontrado!!!!
necesito saberlo solo asi podre morir en paz!!!"

Pues si lo qu equieres es generar bytecode, no necesitas saber la cabecera de los EXE, ni nada de eso. El bytecode tiene el formato que tú quieras darle, simplemente crea un intérprete que sea capaz de leerlo y ejecutar lo que sea necesario.
                               

                                Bueno, boubou, te lo digo otra vez y espero que me hagas caso... te vas a ahorrar muuuuuuuchos problemas si haces tu lenguaje pseudo-interpretado. Teniendo en cuenta el nivel al que serías capaz de optimizar los EXEs que generes, irán prácticamente a la misma velocidad. Si de verdad alimenta tu ego el que genere EXEs nativos tu compilador, adelante. Pero para cuando lo saques no tendrás que ponerle DirectX 8.1, sino el 29 por lo menos... además, el curso de Daniel Navarro te facilita mucho las cosas, no te compliques más.
                               

                                La razón por la que postee ese mensaje de boubou no era para que nadie le trate ahora de imbécil o se ría. Simplemente, en mi opinión debía enfocar el proyecto de otra manera, ya que anunció un compilador ultrarrápido que compilaría a código máquina y aprovecharía las funciones DirectX 8.1 específicas de hardware, y que después resulta que no sabía hacer ninguna de las dos cosas.

Nadie hemos aprendido sabiendo. De hecho, he tratado de contestar a boubou lo mejor que he podido en otros foros. Pero ya no podía aguantar más el ver que estaba anunciando continuamente un compilador que iba a ser la leche, con unas características impresionantes, y que después andara tan SUMAMENTE PERDIDO, ya que no sabía hacer nada de lo que anunciaba y a veces preugntaba verdaderas barbaridades. Pretendía que se informara bien, leyendo manuales al respecto (como creo que hacemos todos) y que después se embarcara en este proyecto, ya que por lo que veía no es que se hubiera encontrado con algún problema al desarrollar el compilador, sino que no sabía ABSOLUTAMENTE NADA sobre el funcionamiento de un compilador.

Desde aquí pido disculpas si se ha podido molestar, y espero que antes de lanzarse a desarrollar algo así sepa bien lo que va a hacer, por que evidentemente, si, ha preguntado VERDADERAS BARBARIDADES.
                               

                                Bueno, vamos a ver...

Primero, tú nos has preguntado cómo se generan binarios de Win32, yo te di un enlace a una web con el formato de los EXE que, obviamente, no te vale para nada, por que compilar a código máquina no es como coser y cantar.

Después, estás anunciando un compilador supuestamente increíble, con unas características que se espera hagan temblar DBPro y BlitzBasic, lo único que te he dicho es que estás completamente perdido, que hacer esto lleva mucho tiempo de estudio, y no dudo que Mark Sibly y Lee Bamber han dedicaod mucho tiempo a aprender esto. No puedes venir, preguntar cuator cosas en un foro y pretender hacer que te salga un lenguaje increíble.

Vale que Yuji Naka no es español, pero Daniel Navarro sí lo es (el del Div), y también lo son Bit Managers (un estudio de Infogrames) y Pyro Studios (los del Commandos 2), entre muchos otros.

Lo único que te digo es que no puedes preguntarnos a todos cómo se hace el compilador y después venir a vendérnoslo (tu mismo dijiste que el precio iba a depender de la distribuidora). Si quieres hacer el compilador, pues cúrratelo. El curso de programación de compilador de Daniel Navarro te vale para la parte del compilador, mientras que el libro "C: Manual de Referencia. 4ª edición" de Herbert Schildt puede ser útil para el intérprete. Si quieres hacer un lenguaje que compiler a código máquina como poco necesitas saberte el "Compilers: Principles, Techniques, and Tools" de Alfred V. Aho, Ravi Sethi y Jeffrey D. Ullman como el Padrenuestro.

Mira, si de verdad me dices que abandonas el proyecto por esto entonces nuca llegarás a nada boubou. Entendería que, después de mirar muchos libros vieses la poca viabilidad del proyecto e intentases enfocarlo de otro modo, o incluso abandonarlo, pero que lo hagas sólo por que intentemos abrirte los ojos y decirte que estás equivocado...

Suerte si decides seguir adelante. Recuerda que los foros están para ayudarnos y consultarnos, y por supuesto estaremos encantados de hacerlo, peor no para que otros nos hagan el trabajo. Esto va más por los posts del foro de as_xuri que por este, pero en fin...