Revolution Engine

Un motor de juegos es básicamente un sistema para gestionar recursos, y para esa tarea C++ es simplemente perfecto. Os doy mis argumentos a favor de C++:

- No teneis más que mirar cualquier motor gráfico o de juegos y vereis que está hecho en C++. Por algo será.

- Es cierto que todo lo que se puede hacer en C++ también se puede hacer en C, pero requiere mucho más código, lo que da lugar a más bugs. Por si fuera poco ese código extra sólo sirve para replicar funcionalidades de C++ como los constructores, los destructores o las clases base abstractas (interfaces). Ya que C++ nos da ese trabajo hecho, ¿Para qué repetirlo?

- C++ es más lento, ¿realidad o mito? C++ usa tablas virtuales para determinar las dirección de los atributos y las funciones miembro de cada clase, por eso la referencia "Circle.radio" requiere dos accesos a memoria. Si "radio" fuera global se requeriría uno solo. Sin embargo, la primera referencia es "thread-safe" mientras que la segunda no. Es decir, si radio fuera global sólo podríamos usar funciones relacionadas con círculos en un único hilo. Además los procesadores modernos están muy optimizados para el uso de tablas virtuales, dado que hoy en día todo el mundo las usa. No se en un PowerPC, pero en un micro Intel ambas referencias se resuelven en el mismo tiempo. Por último, aunque C++ fuese un poco más lento, en un juego la CPU está todo el tiempo esperando a la GPU, así que no debería notarse ninguna ralentización ya que hay CPU de sobra.

- Aunque el motor esté hecho en C++ los usuarios del mismo no tienen que ser unos expertos en ese lenguaje. Con que se aprendan el API del motor van sobrados. Usarlo probablemente consistirá en declarar una o varias clases y hacer llamadas a sus funciones miembro. Es lo mismo que llamar a funciones de C pero anteponiendo el nombre de la clase y un punto... No creo que haya que hacer un máster en C++ para eso.

- C++ soporta templates y C no. Si alguna vez habeis trabajado con las STL sabreis lo cómodo que puede llegar a ser y los quebraderos de cabeza que ahorra. Además la librería estándar de C++ tiene algunas clases muy útiles, como string y wstring, que no se podrían usar si nos limitamos a C. Por contra desde C++ se puede usar cualquier cosa de la librería de C.


Usar un lenguaje u otro es vuestra elección, no la mía. Yo voy a seguir participando en este proyecto en la medida de mis posibilidades, tanto si usais C como si cambiais a C++. Sin embargo estoy casi seguro de que seguir con C va a suponer que tarde o temprano tengais que tirar el trabajo hecho y empezar desde cero con C++.

Saludos y buen rollo!

Por cierto compañeros, sobre el "documento", tener en cuenta de no podeis "copiar" nada para el engine, que si nos...
Si quereis algo sobre el 2D me avisais.


Saludos

si necesitais algo del autodesk maya, ya ire pasandome

Asi que el problema es que "el documento" no es ponible por aqui no=? =P a ver como lo hacemos xDD cunado tengamos la web nueva...^^

Ozzyo tienes un PM =3 (basicamente es que cuando quieras, pasame los datos =D)

kontakatilu: Claro tio ya lo tenemos presente, es solo para entender como funcionan las cosas.

frontier: bueno, veo bien que te guste C++, pero realmente todos los argumentos que has dado son inciertos. Empezando por lo primero que has dicho:
"Un motor de juegos es básicamente un sistema para gestionar recursos, y para esa tarea C++ es simplemente perfecto."
Los recursos de un sistema son la memoria, la capacidad de proceso... etc. y no creo que la tarea de un juego sea la de gestionar eso. De hecho esa es mas bien la definición de Sistema Operativo, de los cuales no conozco ninguno programado en C++, mas que nada porque realmente no te deja gestionar nada, lo hace él de manera genérica como le parece mejor.

Es como querer hacer un vehiculo que vaya en carretera y fuera de ella. Es posible, pero no irá bién en ningun lado...siempre vendrá un todo terreno en el campo y irá mejor, y un deportivo en carretera y irá mejor. Si nuestra tarea es hacer juegos vamos a optimizarlo todo para eso.

De todas maneras estoy ya cansado de argumentar todas las decisiones y de escribir tanto, así que voy a decir que no pienso programar en C++ para wii ni en ningún otro lenguaje que no sea ensamblador o C. La decisión corresponde a technik, pero si se decide usar C++ no colaboraré en el desarrollo del engine. Gottlieb Daimler dijo "lo mejor o nada" y yo pienso igual. Si voy a dedicar tiempo, esfuerzo y voy a poner mi nombre en un proyecto quiero que sea "lo mejor". No quiero hacerlo en C++ porque es mas bonito y rápido de programar para que dentro de un tiempo salga otro engine que esté mas optimizado (c y asm) y que por lo tanto haga juegos mucho mejores que el nuestro.

Me he puesto serio para que quede clara mi intención, pero lo digo desde el buen rollo. Es bueno que cada uno defienda sus ideas

EDIT:
pho: cierto, pero mejor esperar a que technik se pronuncie. Quedaria mal hacer una web de un proyecto para luego quitarla a los dos dias

oyzzo: Tienes razón, me gusta C++, de hecho pienso que es el mejor lenguaje que existe para hacer aplicaciones de escritorio. En cuanto a los recursos, yo me estaba refiriendo a los recursos de un juego: Texturas, modelos para dibujar, modelos para la detección de colisiones, modelos para la física, scripts de IA, etc... Como ves ninguna de estas cosas las gestiona un S.O., e igual que no tengo constancia de ningún S.O. escrito en C++ tampoco tengo constancia de ningún motor gráfico ni de juegos escrito en C. Dicho esto creo que deberías moderar un poco tu posición y mirar las cosas con más perspectiva. Si de verdad crees que hay ventajas reales en usar sólo C, adelante, yo ya he dicho que apoyaré cualquier decisión, pero, por favor, no decidas siguiendo un criterio arbitrario.

Espero que no te tomes a mal mi consejo, lamentaría mucho que te enfadases o abandonases el proyecto por mi culpa.

oyzzo escribió:frontier: reholas compañero, yo estoy interesado en que me rules PNGU para poder ir haciendo cosillas ya, cuando termines las mejoras se incorporan y listo mira tus mensajes privados
Sobre lo de usar C++ creo que no es buena idea, C++ es bastante mas lento y todo lo que sea ganar velocidad se nota en el resultado final (poder usar modelos con mas detalle, mejores texturas...) En C se puede hacer todo claro, igual que en C++ usando estructuras y haciendolo funcional, sin contar que si se hace en C++ se complica para el usuario que lo quiera utilizar. De todas formas si hacemos el motor en C y alguien quiere hacer un juego en C++ lo va a poder usar sin problema.

Davpk: me gusta tu logo, pero es Revolution no Evolution mola lo del tablet pc, yo voy a pillarme un umpc con pantalla tactil para ver que tal va El resumen te lo hago, por examenes hemos estado un poco de tiempo ausentes (y aun no he acabado pero le puedo dedicar algun tiempo) y desde hace unos dias nos hemos orientado en la buena dirección y ademas ha salido la version nueva de devkitppc con libogc nueva wiiuse y libfat integradas y mejoradas asi que nos ha dado un empujon Al final el engine se llama Revolution Engine y se programa en C sobre GX (osea acelerado por hardware en la wii, usando su grafica) Hemos estado haciendo pruebas con modelos y texturas cargadas desde la SD, algo de iluminación y alguna cosilla mas. Se ha decidido montar una web con un foro en un servidor mio, mañana pho la subirá y la configurará. technik se ha puesto a hacer la base del engine y yo me voy a poner a hacer algunas funciones basicas ya mismo.

technik: yo voy a ir haciendo unas funciones de primitivas basicas(plano,cubo, piramide, cilindro, esfera), funciones basicas de manejo (mover, rotar, escalar), manejo de eventos (wiimote de momento) y algo de coloring (flat shading, goaraud shading)

Mersi por el resumen

Anda que vaya error el mio, iva tan empanao poniendo los textos en su sitio que ni me había eterado de que me había comido la "R" xDDD

Aguí está bien echo:



Las letras las he tenido que hacer más pequeñas para que quepa a 320x240.

Por cierto, el CVS lo puedo montar yo en un momentín, tengo montado uno para mi y mis propios proyectillos cutres. Aunque junto a varios amigos estamos haciendo cosillas en C# (con XNA, que tengo el Creators Club) y usamos el Microsoft Office Groove que está muy bien. Pero en todo caso, si preferiis el CVS, yo monto el CVS si me lo pedís en un 5 minutillos.

PD: En la pequeña batlalla-decisión entre C/C++, en mi opinion me he manejado siempre mejor en C y ahora empiezo a "comprender" la programación a objetos (gracias al C#), pero en este caso creo que Frontier tiene razón, para un motor seria mejor utilizar C++ para organizarlo mejor, pero bueno, al igual que Frontier si finalmente se hace en C yo también colaboraré (e incluso quizás de mejor forma, ya que como digo en c++ estoy flojo xD).

Un Saludo

frontier: tranquilo, enserio que no me enfado ni nada parecido... librerias graficas escritas en C hay muchas, GTK de escritorio. SDL, openGL openVG de graficos etc... engines.. raydium, lightspeed, quake en todas sus versiones y muchos mas, de hecho hay mas en C que en C++.

Mi decision no es arbitraria, esta justificada, lo que pasa es que me siento como un testigo de jeova convirtiendo a todo el mundo y por eso no la justifico. xD

Tranqui, no me tomo mal tus opiniones sobre programación, al contrario. y si dejo el proyecto no será culpa tuya sino de technik que es quien se tiene que pronunciar xDDD es coña, si me voy será porque crea que este proyecto no se corresponde con mis ideas.

Yo de opengl y GX no tengo mucha idea pero si queréis algo con la SD o con el Wiimote pedidmelo

hola
no suelo intervenir en estos foros, pero la verdad llevo muchos años programando en c,c++,java,etc y aunque es verdad que el c es mas rapido que c++, no lo es tanto como oyzzo se piensa, una prueba de esto lo teneis en el proyecto firebird, que estaba hecho en c puro y lo pasaron a c++, ahora pueden avanzar mas rapido y aplicar algoritmos como por ejemplo btree que hacerlo en c sería realizar parches para casi transformarlo en c++
Pienso que la programacion orientada a objetos es lo ideal para el funcionamiento del motor aunque para cosas a bajo nivel se podría usar c puro. Creo que usar c en vez de c++ retrasará bastante el desarrollo del motor y lo hará mucho menos modular y encapsulado por lo que luego será mas dificil que otra gente se involucre. Es mi opinión por supuesto y ni mucho menos quiero desacreditar a nadie, de hecho me parece estupendo lo que estais haciendo y si consigo quitarle algo de tiempo al trabajo intentaré ayudar en lo posible, ya que es por ahora el proyecto de la scene que mas me ha llamado la atención.
Solo desearos mucho ánimo.

Bueno, yo como de programación ni idea (mentira, se C y Java, pero no al nivel que teneis vosotros ), me gustaría preguntar si hay algún proyecto no-español de este estilo.

A mi, la verdad, C++ me asusta un poco. Y espero que si al final el motor se hace en C++, sea sencillo de usar para gente como yo, que no tiene ni idea de C++.

Mi opinió personal es que la programación orientada a objetos es tremendamente útil para un videojuego. Como proyecto para una asignatura hice un pequeño motor de RPGs, y la POO me facilitó mucho las cosas (cosas que implementé en Java no se me habría ocurrido como hacerlo en C).

Pero vamos, yo preferiría que lo hicieseis en C, más que nada porque así podría seguir mejor el desarrollo.

Como el motivo que he expuesto es tremendamente egoísta, no tengas mi opinión en cuenta

Salu2

A ver, llega el momento de la decision jeje.
Llevo un rato pensando en ello y os cuento lo que he decidido (y por que). Creo que lo mejor es comenzar a escribir el motor en C. Escribir tooda la base en C, para que asi quede mas optimizado. Sin embargo limitarnos a este lenguaje seria un desperdicio (igual que no veria bien limitarnos a C++) Por este motivo, cuando el engine en C sea funcional creo que deberiamos comenzar a añadirle funcionalidades de C++. Esto lo digo porque tras haber trabajado con algun que otro motor, me quedo con la sensacion de que el uso de C++ facilita muuuucho las tareas a los usuarios. A la hora de hacer un juego es mucho mas sencillo utilizar clases, templates, y demas que hacerlo todo en Ansi C puro y duro. Hay que tener en cuenta que el objetivo es simplificar al usuario la creacion de juegos homebrew y para ello el uso de C++ esta muy bien. Basicamente esas son las razones de mi decision. El fruto de esto seria un Engine que el usuario avanzado podria usar solo con C, descartando las librerias extra en c++, y que el usuario novato o menos avanzado podria seguir utilizando de forma mas comoda aunque quizas menos optimizada.

Ahora comentadme que os parece

PD: oyzzo, lamentaria mucho perder tu colaboracion, espero que eso no suceda.

Vamos a ver pero si en c con hacer una structura ya tienes hecha una clase

Yo no veo más simple el C++ que el C y además como se dice casi todas las librerías gráficas están escritas en C

Pero bueno es vuestra decisión

A mi lo que dice technik me parece bien, así cada uno elige lo que quiera

C++ no es mas simple que c, pero si es muy comodo de usar para juegos, como ejemplo clarisimo te puedo poner el Ogre3d, que esta escrito en C++ y se usa en C++, es potentisimo e increiblemente comodo de utilizar.

Y una estructura dista muchisimo de una clase jeje, para muchos usos es equivalente, pero para otras cosas es bastante complejo emular las funcionalidades de C++. De todas formas ya digo que creo que para escribir el engine desde la base lo mejor es C, y eso es lo que estoy haciendo, pero si yo fuese un usuario del engine (y espero serlo ademas de desarrollador) me alegraria de contar con ambas opciones, y eso es lo que pretendo que el RE ofrezca.

A mi en principio me da igual, con que pongais ejemplos de uso del motor, igual me da uno que otro... por cierto yo pensaba que era lo mismo, jeje...

Por cierto, no tendriais por ahi algun ejemplo de un cubo con textura, hace tiempo que espero uno para hacer una demo de headtracking con el wiimote.

Venga saludos.

Kontakatilu escribió:Por cierto, no tendriais por ahi algun ejemplo de un cubo con textura, hace tiempo que espero uno para hacer una demo de headtracking con el wiimote.

Venga saludos.

Mirate los ejemplos de las gx del utlimo devkit =D hay algunas cosas interesantes

Bueno, technik se ha pronunciado porfin
Lo cierto es que mi idea es hacer un engine que conste de un conjunto de herramientas para facilitar (en el sentido de agilizar) la tarea al programador de videojuegos, pero no hacerlo facil...y además sin tener que sacrificar potencia por facilidad de programación, porque sino lo que haria seria crear un GLBasic o fenix o algo así. En resumen, mi idea es hacer Buenos juegos aprovechando al maximo el hardware de la wii y para eso se tiene que hacer en C , y si se tiene que optimizar alguna parte en ensamblador pues también. Ademas para hacer miles de juegos mediocres ya está PC.

Nose, esa es mas o menos mi idea, pero parece que vosotros preferis hacer un engine que pueda usar mucha gente para hacer juegos aunque para eso se sacrifique algo de potencia. Eso hace que la gente que no sepa y no quiera matarse mucho a aprender, pueda hacer juegos resultones, pero así habra muchos juegos resultones, nada especial. De mi manera puede ser algo mas complicado de usar y eso hace que la gente que sabe programar bien o la que se quiere complicar la vida un poco mas en aprender la use... vale que es menos gente, pero es la gente que al fin y al cabo es capaz de hacer juegos buenos.

Por eso aunque la base sea en C, si luego se mezcla con C++ es tirar el trabajo de optimización hecho antes.

No comparto para nada esa opinion. Incluir librerias C++ para facilitar el trabajo no quita que quien no quiera no las use y se quede con el Engine en C. Eso no baja en absoluto la calidad y potencia del engine, solo aumentara el numero de usuarios que lo utilizaran.

Casi siempre que me he puesto a programar ha sido por hobby, y hace tiempo que dejé de hacer jueguecillos y rutinas. Me veo ampliamente superado por las capacidades que evidenciáis los impulsores del hilo pero también quisiera apuntarme a opinar.

Lo primero que quisiera decir es que estoy totalmente de acuerdo con oyzzo en que si hay posibilidades de preparar un engine robusto y que saque todo el rendimiento posible a la wii, debería hacerse. Eso me parece de perogrullo. Me vienen ejemplos a la cabeza de algunos de los primeros juegos de las 32 bits que prescindían de devkits oficiales y los equipos "metían mano" dándole caña al bajo nivel escribiendo código y más código en ensamblador... el Dead or Alive de PSX o la secuela de Landstalker que apareció en Saturn supusieron un salto cualitativo con respecto a todo lo anterior. Wii es una consola necesitada de gráficos de calidad y me parecería un crimen coartar las posibilidades del motor sólo por hacerlo accesible a un público mayor; si hay quien se viera con capacidad para explotar el engine debería disponer de él a pleno rendimiento: léase "bajo nivel", siempre que lo considerase conveniente.

Y ahora viene un "sin embargo" también a colación de la manera de pensar de oyzzo. Resulta que no sé si entiendo su postura por completo, porque lo de proporcionar además una capa a más alto nivel para facilitar la tarea a la mayor parte de humanos me parece también una idea muy correcta. Lo que no sé es si tú interpretas que al proporcionar las correspondientes librerías en C++, los posibles desarrolladores van a tirar por el camino fácil y no prestarán atención al soporte de las funciones en C puro. Con esa duda me he quedado.

Personalmente soy de los que veo perfectamente posible que coexistan C y C++ como capas independientes. Incluso imagino que se podría limitar a incluir ciertas librerías en el código con las que activar la orientación a objetos, en caso de obviarse se trabajaría sólo en C. Algo así.

Dado el caso, y como tiene pinta que wii va a aguantar bastante gracias a sus posibilidades multimedia y a la scene, yo utilizaría C para tontear haciendo alguna que otra demo (pues el tiempo del que disponemos algunos ya no da para meternos en fregados demasiado grandes), y C++ para colaborar en algún proyecto.

Perdón por el tocho, me he venido arriba Saludos.

Yo tambien entro a opinar:

No se puede comparar el nivel que tiene C, con el nivel que tendria de facilidad el C++ a la hora de programar un juego tan solo por ser un codigo de lenguaje orientado a objetos.

Por otra parte es totalmente falso que una clase se pueda emular haciendo una estructura de Datos en C. No tiene nada que ver una estrucutra de datos, con una clase. Vamos.... lo UNICO que se le roza a una clase, y que se pueda hacer en C, es un TAD (Tipo Abstracto de Datos), con todas sus funciones prohibitibas, con todas sus funciones de seguridad y todo... y aun asi es una matada, 3 o 4 veces mas grande que en un lenguaje orientado a objetos. Y lo digo por experiencia propia, porque pensaba lo mismo cuando empezé con codigo orientado a objetos, y despues de usarlo bastante, me he dado cuenta que la facilidad que incluyen las clases, es posible hacerlas en C, pero la matada y la currada que debes hacerte, tan solo para emular una de las clases (ya ni te digo si quieres hacer herencia o poliformismo) es tan espectacular que quitan las ganas.

A parte, hasta donde se, si como supongo que hareis, como compilador tendreis gcc (no creo que os metais a crear un compilador de c++, seria demasiada currada inutil, teniendo un compilador tan potente como gcc o g++), aunque se hagan librerias de C++ para en engine creado, no creo que habria ningun problema en incluir las basicas de c, y que una rama o un grupo de gente que realmente le apetezca que solo sea en C, que se meta a traducirlas. Pero creo que para empezar lo mejor seria tratar de que fuera con un lenguaje orientado a objetos, por su facilidad a la hora de crear juegos.

Espero que mi opinión sirva de algo !!

Saludos!

La verdad esque programa mediante engines si se le puede denominar asi solo he trabajado con el fenix (evolucion del div game studio) que esta en gp32 gp2x dc ps2 linux windows etc... y que me molaria mil que se portada tb xk se podrian aprovechar juegos molones ya que al ser un interprete.

La cuestion de mi pregunta el uso de este engine sera algo mas complicado que el uso que yo hacie del fenix no? Me temo que ya puedo enpezar a cojer libros de C que un dia tarde o temprano tendre que aprender pero esque los libros me duermen u_u

Realbrucest, lo has visto bien.. si alguien puede programar de manera mas facil no se va a matar a usar las funciones mas chungas. Y ademas de eso, si la gente quiere programar facil y bonito en C++ me parece bien, pero yo no quiero soportar ese estilo de informatica de la ley del minimo esfuerzo. De ahí mi postura radical de no aceptar que se haga una capa superior en C++ a mi codigo.
Optimizar algoritmos es una cosa compleja y que necesita mucho trabajo(ademas de práctica y conocimientos), optimizarlo luego en ensamblador del procesador es tambien complejo y requiere horas y horas de pruebas y calculos(ademas de los conocimientos)... Si solo una persona usa ese codigo que tanto trabajo me ha costado optimizar desde una funcion en C++ le está pegando una patada a todo mi trabajo.

En ese caso creo que sera una lastima no contar con tu apoyo, pero la decision es tuya.

Solo quisiera hacer un apunte, el trabajo en equipo en C a secas se puede hacer mas dificil, hay que estar mas compenetrados quiza que usando clases, ademas de que la cantidad de lineas de codigo en C pienso que seria mucho mayor que en C++, por lo cual la optimización tambien se puede ir al garrete directamente, para un analista siempre es mucho mas sencillo poder recurrir en el ultimo paso a poder plasmarlo todo en clases o no segun prefiera, no poder hacerlo pienso que siempre es un paso atras.

Y para ilustrar un poco mi opinion os dejo aqui una tabla de equivalencias en lineas de codigo, segun Cocomo y los puntos de función.



Como podeis ver la equivalencia es:

128 lineas de codigo en C equivalen a 29 lineas de codigo en C++

Bueno, mi opinión es que el engine debería ir en C.

Pero aparte de eso... hay nuevos progresos?

Cual sería la potencia que desesais alcanzar? Similar al WiiSports? MarioKart? (Lo digo para comparar con un engine "comercial")

Los ultimos progresos son que la primera Alpha del motor tardara mas de lo esperado en salir xD. Esto se debe a que estoy reescribiendo el codigo para hacerlo mas estable, rapido y potente (aprovechando los nuevos conocimientos que tengo sobre GX).
Ahora el motor utiliza tablas de datos y displaylists que aceleran bastante su funcionamiento. En cuanto a prestaciones no se hasta donde seremos capaces de llegar, pero lo que es seguro es que sacar todo el potencial de la wii sera dificil y tardara. Mientras tanto iremos sacando pequeñas versiones cada una con mas cosas que la anterior. La priemera de todas ellas, Revolution Engine Alpha 01 espero poder sacarla pronto, pero de momento no esperes mucha potencia, creo que hace un par de posts puse las caracteristicas.

oyzzo: Voy a hacer un último intento de convencerte de que no te vayas porque me parece que tu decisión está basada en premisas falsas.

oyzzo escribió:Y ademas de eso, si la gente quiere programar facil y bonito en C++ me parece bien, pero yo no quiero soportar ese estilo de informatica de la ley del minimo esfuerzo. De ahí mi postura radical de no aceptar que se haga una capa superior en C++ a mi codigo.

C++ no se inventó para programar fácil y bonito, sino para programar cosas que hasta ese momento no eran factibles, es decir, C++ (junto con otros lenguajes OO) pretendía resolver la llamada "crisis del software". Esa crisis fue algo de lo que se empezó a hablar a principios de los 90. En aquella época se comercializaron procesadores mucho más rápidos y con soporte para multiusuario y multitarea simulada (80386, 80486, sólo por mencionar a Intel). Sin embargo la inmensa mayoría del software no aprovechaba los enormes recursos que ofrecía el hardware. Esto era debido a que ahora se disponía de una base hardware que permitía resolver problemas mucho más complejos pero no se disponía de las herramientas adecuadas para abordar dichos problemas, ya que resolverlos usando el paradigma modular requería un enorme esfuerzo que se hacía más y más grande con cada nuevo problema planteado. Para eso se inventaron los lenguajes OO, ya que facilitaban mucho el modelado de problemas complejos y con ellos se dió por resuelta la crisis del software.
Si estas pensando que cualquier cosa en C++ se puede hacer en C y que por tanto la crisis del software era una invención, te contesto desde ya que el que algo se pueda hacer "en teoría" no implica que sea factible "en la práctica", ya que hay que tener en cuenta el coste económico y de tiempo.
Por cierto, otra crisis se avecina: Cuando intel saque sus micros de 40 y 80 núcleos no va a haber ni Dios que pueda aprovechar eso. Para resolverlo se habla de hacer lenguajes OO que sólo admitan objetos inmutables, va a ser un cambio raro...

oyzzo escribió:Realbrucest, lo has visto bien.. si alguien puede programar de manera mas facil no se va a matar a usar las funciones mas chungas.

Si ese alguien tiene interés en su propio juego se molestará en aprender las funciones más chungas, suponiendo claro, que estas le aporten alguna ventaja. Para los novatos la interfaz C++ sería más asequible, un punto de partida. Cuando estuviesen más familiarizados con el motor ya podrían meterse en la interfaz C. No tiene nada de malo suavizar la curva de aprendizaje.

oyzzo escribió:Optimizar algoritmos es una cosa compleja y que necesita mucho trabajo(ademas de práctica y conocimientos), optimizarlo luego en ensamblador del procesador es tambien complejo y requiere horas y horas de pruebas y calculos(ademas de los conocimientos)...

Los algoritmos se optimizan sobre el papel, así que para este caso el lenguaje usado es lo de menos. En cuanto a "optimizar" usando ensamblador te diré que eso se hacía cuando los compiladores estaban en pañales y generaban código "funciona y da gracias". En estos años se han invertido millones en investigación, rara es la Universidad que no tiene a alguien trabajando en este campo, y los compiladores han mejorado mucho. Dudo que alguien sea capaz de escribir un código más rápido que el que genera el último Visual C. No se en que estado están los compiladores GNU, pero me imagino que también habrán avanzado y la situación será similar. Hoy día sólo tiene sentido usar ensamblador para acceder a partes del hardware inaccesibles desde tu lenguaje, que es, única y exclusivamente, para lo que se usa ensamblador en libogc. Por supuesto eso también se puede hacer desde C++.

Para terminar vuelvo a recordarte dos cosas:

1 - Hoy día los micros también han avanzado mucho y están optimizados para ejecutar muy rápido el tipo de código que generan los lenguajes OO.

2 - En un juego típico la CPU está la mayoría del tiempo bloqueada esperando a la GPU, así que el camino de la optimización pasa por planificar mejor el trabajo que se le envía a la GPU y no por ahorrarse un par de ciclos de procesador cambiando de lenguaje.

Espero que te pienses bien todo esto y que cambies de idea, o que compartas los motivos que te llevan a aferrarte a C, y así tal vez seamos nosotros los que cambiemos de idea.


technik: Me parece una gran idea hacer parte en C y parte en C++. De hecho hay tareas sencillas que avanzarían incluso más rápido hechas en C. Por ejemplo, yo he escrito PNGU en C en lugar de en mi adorado C++ porque es una librería lo bastante sencilla como para abordarla "de un vistazo". Si ahora quisiera hacer un visor de imágenes lo haría en C++, ya que la interfaz de usuario es un problema complejo. Eso no quitaría que desde el código C++ invocase a funciones de PNGU escritas en C. En resumen, yo optaría por hacer las partes sencillas y bien definidas del motor en C y las más complejas en C++. Estas últimas usarían internamente tanto partes sencillas en C como otras partes complejas en C++. Esto que propongo no es exactamente igual que hacerlo todo en C y luego añadir una capa C++, ¿Tú como lo ves?

frontier, la verdad es que lo que planteas es cierto. Quizá sea mejor asi. Mas adelante me planteare hasta que punto entra el c++ en la base del engine. Por el momento el codigo que escribo es lo suficientemente directo como para poderlo escribir en C y eso es lo que hago. Supongo que esta situacion empezara a cambiar cuando cree tareas mas complejas como por ejemplo cuando me meta de lleno con la fisica. C++ sera añadido en el futuro, de momento voy bien escribiendolo en C y las primeras versiones es muy probable que no tengan nada de C++.

technik: Bueno, no pasa nada... igualmente iré pasando por el hilo a saludar y si puedo ayudar en algo lo haré. Yo por mi parte iré programando segun mis ideas. Si algun dia tengo una duda te preguntaré Que haya dos proyectos cada uno con su filosofia será muy bueno para la scene de wii. Espero que sean dos proyectos hermanos que se puedan beneficiar el uno del otro.

frontier: valoro tu intento, pero igualmente podria rebatir todo eso que has dicho, y tu rebatir lo que yo te diga xD Espero poder usar tus PNGU y contar con tu ayuda si en algun momento concreto tengo alguna duda

Saludos a todos los demas que han posteado en el hilo y que se han interesado

technik: Estoy de acuerdo. Si lo que estás haciendo ahora es más o menos abarcable entonces no hace falta que metas C++ de por medio. Tal como dices, cuando comiences con las tareas más complejas será el momento de usarlo. Ahí entrará tu criterio de lo que es sencillo o complejo.
Ahora mismo estoy ocupado añadiendo mejoras a PNGU, pero en cuanto acabe me gustaría ayudarte. Ya me dirás en que hago más falta, aunque si puedo elegir me decanto por la parte del sonido.

oyzzo: Es verdad que no tiene sentido embarcarse en una disputa si ya has tomado tu decisión. Espero que sigas por aquí dando tus opiniones y que si inicias otro proyecto lo lleves a buen puerto para que todos nos beneficiemos de él. Puedes contar con mi ayuda, igual que yo espero contar con la tuya cuando me haga falta. Y claro que puedes usar PNGU, faltaría más .

Bueno, pasamos a la noticias jeje
Aprovechando que estoy reescribiendo el motor voy a hacer un par de cambios en mi forma de trabajar para manteneros mas al dia.
El priemr cambio es que ahora estoy haciendo el codigo bastante comentado (antes apenas ponia un comentario cada 40 lineas) para que sea mas legible y asi os podais hacer con el mas rapido. El segundo es que en vez de teneros en vilo os ire contando cada mejora que consiga añadir al engine y las funciones disponibles. De esta forma sacare la primera version cuando vosotros considereis que tiene funcionalidad suficiente, es decir, si alguno cree que ya hay material suficiente para hacerse aunque sea una pequeña demo, que lo diga y yo lo publico. Asi de simple. En un rato os comento las primeras funciones.
Edit: tambien me podreis pedir las funciones que considereis oportunas y yo intentarea añadirlas.

PETICION: Necesito ayuda de alguien que se maneje con GX.

He añadido soporte a PNGU para cargar el canal alpha de una imágen, de modo que ahora se puede usar para crear texturas con transparencias. Mi problema es que no puedo comprobar si funciona correctamente porque no se pintar objetos con dos texturas, así que las partes transparentes se mezclan con la basura que hay en la memoria y no veo nada. Lo ideal sería pintar un objeto con dos texturas, la primera sólida y la segunda con partes transparentes, así el resultado final sería una mezcla de ambas y se vería si la textura transparente está bien creada.

Si es posible me gustaría que alguien me pasara un programa que pinte un cuadrado con dos texturas superpuestas, o al menos que me indicase las funciones de GX que habría que usar. Muchas gracias de antemano .


No se si este es el hilo adecuado para hacer esta petición o debería abrir uno nuevo, en todo caso espero que a technik no le importe .

Lo puse al principio del otro post. Ahora q la cosa ya está más avanzada puede venir bien recordarlo. Va sobre como impletar efectos de shader en GC, y sobre como combinarlos sin consumir demasiados recursos con la acumulación. De los creadores de Rogue Leader.

http://www.gamasutra.com/features/20021002/sauer_01.htm

Debería servirte.

ojala se logre algo sigue con tu proyecto!

Rmn: Gracias por el enlace, lo tengo en mi lista de marcadores desde que lo posteaste la otra vez

Aunque el documento está muy bien, lo que necesito ahora es que me den el trabajo ya hecho. La idea es no perder el poco tiempo que le puedo dedicar a PNGU aprendiendo algo que me llevará días. Se que tarde o temprano tendré que ponerme las pilas y mirarme GX, pero es que ahora estoy muy muy liado con PNGU y no quiero retrasar más la siguiente versión.

frontier, no es mas facil si usas una sola textura con trasnparencias, pero encima de un solido con color?
yo es que aun no he hecho nada practico con texturas, estaba esperando a tener pulidas las display lists y luego pensaba pedirte las pngu para usarlas en las texturas.

technik: No se si sería más fácil porque eso tampoco se hacerlo, pero como servir serviría. ¿Me puedes pasar un programa de ejemplo?

El problema es que no se como cargar una textura desde el programa. Para eso queria usar las PNGU porque supongo que abriran un archivo PNG de la SD y te pasaran la informacion que este contenga. El problema para hacer un programa con eso es que no se en que formato esta la informacion que devulelven las PNGU ni como trasnformar de ese formato al formato de texturas de la wii. Dime como te devuelven la informacion las PNGU para ver que podemos hacer

Las PNGU convierten directamente al formato de texturas de Wii, esa es la gracia de usarlas .

Te voy a pasar el último código que tengo, para ver que puedes hacer. Mira tus MPs.

Bueno, una pequeña curiosidad. Con idea de comprobar la optimizacion a la que da lugar el uso de display lists hace un rato he hecho una prueba que os voy a clogar ahora. Es la misma demo del cubo que colgue hace unos dias, pero por aquellos entonces estaba hecha con la primera version del engine y la version de ahora esta hecha con el engine optimizado. Es la misma demo exactamente pero ahora va "ligeramente" mas rapido jeje. Espero que os llame la atencion tanto como a mi, que pensaba que la optimizacion iba a ser solo superficial xDD

Madre mía, que velocidad. Ahora es cuando tienes que hacer una demo con 400 cubos en pantalla moviéndose a la vez.

je eso de los 400 cubos me recuerda a una demo que hice con la primera version del engine, en la que habia hacia un mapa con xxx y donde había una x me pintaba un cubo y me hacia el escenario con ellos, llegaba un momento que cuando habían unos 30 cubos en pantalla, la wii se me relentizaba, me llamó la atencion porque yo pensaba que eso solo pasaba en los ordenadores y que las consolas no se relentizaban

En fin, buen trabajo

Kontakatilu, lo de ralentizarse era con tinyGL verdad? Imagino que si, por el tema de rasterizado por soft y eso. Ahora ya no te pasara mas jeje.

frontier No he cogido el tema de texturas todavia porque no tenia disponible el portatil para pasar los archivos de textura a la SD. Pero acabo de recuperarlo asi que ahora me pondre a ello (bueno, cuando cene xD). Os adelanto tambien que aprovecahndo intentare hacer un cargador de 3ds. Si me sale en unos dias os cuelgo la demo y a lo mejor hasta la V1 del engine xD

technik escribió:Kontakatilu... Os adelanto tambien que aprovecahndo intentare hacer un cargador de 3ds. Si me sale en unos dias os cuelgo la demo...

P.D.:Soy modelador

technik escribió:Bueno, una pequeña curiosidad. Con idea de comprobar la optimizacion a la que da lugar el uso de display lists hace un rato he hecho una prueba que os voy a clogar ahora. Es la misma demo del cubo que colgue hace unos dias, pero por aquellos entonces estaba hecha con la primera version del engine y la version de ahora esta hecha con el engine optimizado. Es la misma demo exactamente pero ahora va "ligeramente" mas rapido jeje. Espero que os llame la atencion tanto como a mi, que pensaba que la optimizacion iba a ser solo superficial xDD

GXProject.rar

Así me gusta, ver avanzes y sobretodo demos
Si le añades back face culling irá el doble de rápido de lo que va ahora al no procesar las caras traseras. Sé que tu al tener la doc ya lo sabes pero para los que no, va así el back face culling:
Se tiene que indicar las normales (no hace falta que sean por vértice si no se usa iluminación) o construir las caras en el sentido horario. y en GX_SetCullMode(GX_CULL_NONE); se tiene que pasar GX_CULL_BACK en lugar de GX_CULL_NONE

Lo pongo porque en todos los ejemplos que he visto lo hacen sin back face culling, en un ejemplo incluso decía que sino no funcionava... eso no es cierto. Siempre que se pueda se tiene que usar y funciona bien (siempre que las normales de las caras esten bien) doy fe

ajajaja, a mi tambien me hizo gracia ese ejemplo cuando lo vi por ahi. decia algo como "//any else produces weird results" xD.
Pero efectivamente, haced caso del consejo del backface culling ya que se dejaran de rasterizas todos los poligonos que no esten mirando a camara. Y esto acelera un monton. El backface culling siemrpe lo he usado. Ahora estoy pendiente de activar el clipping. Y mas adelante, cuando ya se puedan cargar niveles supongo que le añadire Bsp tree y cosas por el estilo.

En serio... cada vez que os leo me quedo alucinado con vuestras capacidades.

Tengo algunas preguntas y una proposición. Disparo:

¿como se manejan las fuentes de texto desde el motor? (¿o no se manejan todavia?)
A la hora de crear un juego usando Revolution Engine, habría que lidiar directamente con las Wiiuse, o el engine proporcionaría funciones de nivel más alto para acceder a los wiimotes? Es decir... programando un juego se podría hacer algo tipo "if(REV_Nunchuck_shake()==true){haz algo}" ?

La proposicion es la siguiente:

Una vez que consigais cargar texturas (que parece que se os resiste un poquito ), creo que estaríais en condiciones de crear un juego/demo simple que demostrase las capacidades del motor. Se trataría de una sala cuadrada, con una pelota. Se trata de lanzar la pelota según la inclinación del wiimote y con una potencia que vendrá dada por el tiempo que hayas pulsado A en el wiimote. Con texturas en las paredes y la pelota, y gravedad implementada.

El las primeras versiones, la demo sería muy patatera (la cámara se quedaría donde está, la pelota no levantaría polvo, no habría muebles en la sala, no habría fuentes de luz... etc), pero creo que sería una forma muy interesante de ver el progreso del engine.

¿Qué os parece? ¿Demasiado prematuro, quizás?

Salu2, fieras

Pro fin hay texturas !!
Gracias a la inestimable ayuda de frontier y a sus pngu, el Revolution ya tiene soporte para texturas monocanal
Hay una demos para demostrarlo en el blog que he creado para el Engine. Espero que no se considere spam si pongo el enlace porque ni siquiera es una pagina personal mia, es la pagina del proyecto. http://www.revolutiongameengine.blogspot.com
El nombre es asi de largo porque sospechosamente los dominios revengine o revolutionengine estan ocupados por blogs en blanco...pero da igual (bueno, si el dueño de estos dominios me los pasase desinteresadamente no estaria nada mal).

Lo proximo que hare sera incorporar un cargador de modelos 3ds.

Nota: para que la demo funcione bien teneis que poner la textura que querais como una imagen PNG en la raiz de la SD con el nombre plasma.png xDD es que ese era el nombre de la textura que yo usaba para mis pruebas y se me olvido cambiarlo a uno mas comun.

PD: Si poneis una textura con transparencias aun no se veran zonas transparentes, sino con un color de fondo "aleatorio", ah y la textura que no sea paletizada, que ese formato esta demasiado obsoleto y no esta soportado.

Espero que os guste y que me conteis vuestras experiencias con vueltras propias texturas.

frontier: Como llevas lo de las transparencias? Si quieres te puedo hechar una mano.

technik: Si las pngu te cargan el canal alpha de la textura para que funcione necesitas:
GX_SetBlendMode(GX_BM_BLEND,GX_BL_SRCALPHA,GX_BL_INVSRCALPHA,GX_LO_CLEAR);
GX_SetTevOp(GX_TEVSTAGE0, GX_MODULATE);

y poner el modelo de color blanco y con el alpha a tope:
u8 colors[] ATTRIBUTE_ALIGN(32) = {
// r, g, b, a
255, 255, 255, 255,
255, 255, 255, 255,
255, 255, 255, 255,
255, 255, 255, 255,
255, 255, 255, 255,
255, 255, 255, 255,
};