Estoy haciendo una lista de temas pendientes conocidos... pero para no olvidarme de nada me gustaria que Uds. me mencionen si falta alguno en la lista que estoy haciendo... no digo que todos los temas pedidos/sugeridos sean incluidos como TODO, pero bueno, seria bueno recolectar todo lo que se sabe esta pendiente o funciona mal...
Por favor, abstenerse de explicar temas en este hilo, solo mencionar el titulo del asunto e incluir link al thread/post si es posible... aca va la lista que por ahora tengo... pero se que faltan muchas cosas mas...
Quote
bugs conocidos
- ninguno
Fixed:
- change _L_BRACHET -> _L_BRACKET, _R_BRACHET -> _L_BRACKET
- volver a poner la transparencia a los alphas con menos de 50%
- error funcion abs, activate -fno-strict-aliasing
- Fix in get_timer(), add SDL_TIMER initialization
- bug que permite compilar publicas declaradas el primer proceso como de cualquier proceso
- verificar problema en sizeof de types (multi declaration of vars of user type)
- bug de declaracion multiple de variables tipo proceso, que solo la primera es considerada como tal
- bug de import con extension en el nombre del modulo a importar
- start of params (argv array) in exec function (Thanks Sandman)
- revisar tema con png y ancho impar
- draw_delete cuando parametro es 0
- mod_effects constants add:
BLUR_NORMAL 0
BLUR_3x3 1
BLUR_5x5 2
BLUR_5x5_MAP 3
GSCALE_RGB 0
GSCALE_R 1
GSCALE_G 2
GSCALE_B 3
GSCALE_RG 4
GSCALE_RB 5
GSCALE_GB 6
GSCALE_OFF -1
- problema que deja basura al dibujar graficos con punto de control no centrados.
- fade32 bits
a completar (urgencia media)
- libffi (corregir y completar)
- efectos blendop en 32 bits (operaciones blend sin creacion de tablas, lento)
addons (proxima release)
- lib grafica multihilo
- permitir que las dlls se busquen con el nombre de la misma o prefijando el nombre con "lib"
- rgb con parametro de profundidad y destino (opcionales)
- funciones matematicas extra (log10, exp, etc...)
- variables globales screen_width, screen_height, screen_depth (DESCARTADO, por el momento)
- container de recursos (zip)
- soporte enum
- notacion cientifica (ver factibilidad)
- notacion hexadecimales como "C" (0x...)
- frecuencia de sonido
- poder iniciar sonido en cierta posicion y obtener posicion actual
- textos multilinea
- efectos de paleta
- revisar constantes en libkey (nueva SDL)
experimental
- script callback
- libsock (crear nueva)
actualizado:
mp3 era un ejemplo, no una implementacion, la libsdl soporta mp3 pero hay que tener la version correcta, y en teoria funciona con las mismas funciones que reproduce los otros sonidos... pero por default no viene con mp3, asi que solo bastaria con hacerse con los paquetes correctos...
¿Soporte mp3?
¿Soporte video? Al estilo de la antigua mpeg.dll...
¿Oficializar alguna librería 3D? ¿La Bennu3D, o la de Sandman, o...? No digo encargarse de su mantenimiento, sino elevar alguna librería de estas como de referencia primera más cercana y modesta, sin tener que ir a buscar otras más allá a no ser que se requiera algo más potente. A lo mejor he dicho una tontería, seguramente.
Y lo de la libsock yo lo pondría como prioridad media...sería un puntazo realmente tremendo tener por fin una librería de red nativa...
esos en realidad son cosas nuevas... no necesarias para estar version, pero bueno, se toma nota a futuro...
;) ;) ;) ;) me encanta la librería water, podríamos ponerla para 32b y quizá agregarle algunos parámetros más, para restringir el agua, colocarla en scroll, crear espejos en lugar de agua, y algunas cosas más... :) ... quizá sean cosas nuevas, pero lo de cambiar la librería a 32b no ;D
El bug del ancho impar en pngs me parece que solo es en imagenes de 8 bits de color.
Por otro lado.
save_png con prundidad de color.
Soporte jpg.
Habian unas cuantas coosas acerca de los textos que no se si se llegaron a implementar (y tampoco recuerdo haberlo visto en las news) como escritura en vertical u otras cosas que comenté hace tiempo, no recuerdo donde (maldito alzheimer).
jeje... texto vertical, nunca lei eso... ahora se me ocurren muchas cosas, creo que el modulo de textos podria ser potenciado mucho, pero seria bastante trabajo, no para una primera release oficial.
Fue cuando hablamos las prmeras veces de los módulos de texto: creo que se comentó tambien lo de ángulos y demás, manejarlas como si fueran primitivas gráficas.
Y de igual forma, algo para manejar gráficos de la misma forma sin usar procesos (move_image(x,y), rotate_image(angle)...), se me ocurririan cientos de cosas, pero déjalo para la version 1.1 o la 2 ^^U
Quote from: Drumpi on December 10, 2008, 03:54:42 PM
Fue cuando hablamos las prmeras veces de los módulos de texto: creo que se comentó tambien lo de ángulos y demás, manejarlas como si fueran primitivas gráficas.
Y de igual forma, algo para manejar gráficos de la misma forma sin usar procesos (move_image(x,y), rotate_image(angle)...), se me ocurririan cientos de cosas, pero déjalo para la version 1.1 o la 2 ^^U
Yo también recuerdo que se habló, pero no se si fué siquiera en este foro. Puede hasta que lo hablaramos en divsite y con respecto a fenix, no se. El caso es que eran muchas y muy buenas ideas a tener en cuenta...
Ya que la verdad que en más de una ocasión he echado en falta en Bennu alguna simple función que emita aunque solo sea un simple sonido a través del altavoz interno del ordenador (ó speaker), por razones varias...
Y es que, por ejemplo, para un "aprieto" en donde no tienes a mano un sonido "wav" o porque simplemente es más tedioso andar buscándolo, poniendo las instrucciones de carga, reproducción y liberación de éste de la memoria (por no hablar de que consume recursos como memoria y disco), la opción que propongo creo que es más idónea y práctica :-)
Desde luego, lo interesante es que la función fuera más allá de la producción de un simple beep, recibiendo, por ejemplo, dos parámetros: uno la frecuencia (tono) y el otro la duración del sonido (segundos o milisegundos), al estilo instrucciones/funciones de viejos compiladores para MS-DOS como sound() (aunque bueno ésta solo recibe la frecuencia, y luego hay que hacer demora con delay y finalmente apagar el speaker con nosound()), para poder reproducir soniquetes de tono y duración variables de una forma simple y rápida.
Saludos.
en cuanto al tema del ancho impar, a mí me surgió otro problema (creo que es nuevo, no si se ya se había hablado). al importar un png ancho impar, guardarlo en un fpg, cerrar el fpg, cargar el fpg, y exportar el gráfico dentro de él te cambia el color transparente por otro.
eso depende del nivel de transparencia, pero este thread no es bugs. :)
actualizada a lista de TODO...
¡Buen trabajo! :-)
:)
gracias...
a mí me pasa algo raro que no ví en la lista, no se si sea bug. o sea un problema de otra cosa.
cargo todas las librerías, la wm y la libwm y le doy a la cruz y no se cierra la ventana. y según recuerdo anteriormente con cargar la wm o la libwm se cerraba.
antes estaba mal... hay una variable que identifica que debe cerrarse la aplicacion, que se setea cuando se pulsa la x de la ventana... ahora mismo no recuerdo, lee el diario de avances...
ya veo, entonces más me vale leerlo antes de decir que unload_fpg no funciona ;) . ¡¡leyéndolo ahora mismo!!
Quote from: Prg on January 16, 2009, 01:59:15 AM
ya veo, entonces más me vale leerlo antes de decir que unload_fpg no funciona ;) . ¡¡leyéndolo ahora mismo!!
Solo pasa si el fpg es 0... ya esta corregido, gracias...
alguien recuerda el post de este reporte?
- verificar reporte de problema que deja basura al dibujar graficos con punto de control no centrados.
nadie se acuerda? o nadie me dio bola?
necesito reparar el error, pero no encuentro el post y no me acuerdo cual exactamente era el problema...
je je je, yo si me acuerdo, yo te lo dije. si me permites, haré un ejemplo, para que lo veas en todo su esplendor. 5 minutos..!!!
haz mouse.left o mouse.right, y luego mueve el ratón.
gracias...
Este no era el error que yo decia, el que yo recuerdo tenia que ver con el punto de control 0 + angle o mirror, no recuerdo...
Estos son los dos temas que yo recuerdo donde se hablase algo parecido:
http://forum.bennugd.org/index.php?topic=366.0 (http://forum.bennugd.org/index.php?topic=366.0)
http://forum.bennugd.org/index.php?topic=247.0 (http://forum.bennugd.org/index.php?topic=247.0)
Pero no se si es lo que buscas...
ese! el 2do! gracias dario....
Quote from: Prg on January 20, 2009, 10:27:20 PM
haz mouse.left o mouse.right, y luego mueve el ratón.
este bug acabo de corregirlo, gracias.
je je, 2*1
corregido el ultimo bug conocido...
¿1.0? :P
Para la 1.0 me gustaria tener algo mejor...
¿0.0.1? :P
jajaja... creo que sera 0.94...
Añado bug:
set_text_color no funciona en 32bits con la fuente de sistema (y no me ha sido posible probar con una fnt de 1 bit)
set_text_color solo sirve para fonts de 1bit... y el color tiene que ser rgb...
igual veo que no funciona...
ahora recuerdo, no esta implementado aun...
agregado el soporte... gracias...
Por cierto, hablando del tema:
He estado buscando info acerca de las fuentes de 1bit y no encuentro las especificaciones por ningun lado. He estado mirando el código de Fenix (que es el que tengo) pero no he encontrado ninguna referencia (tampoco soy bueno rebuscando en el código), solo los load de fnt de 8 y 16 bits.
Ya solo me queda crear una fuente de 8 bits, suprimiendo la paleta, y buscar en donde se especifique el tamaño que se trata de 1 bit. ¿Las fuentes de 1 bit eran de DIV o de Fenix?
no hay diferencia en el formato de fonts de 1 bit o de 32 bits... todos los fonts tienen el mismo formato, solo varia el tamaño del dato pixel...
Y que la paleta solo se carga en 8 bits ¿no?
Es que he dado por pura casualidad con unas especificaciones que me lohan dejado casi todo claro, solo hay una duda que no me ha resuelto: en fuentes de 1 bit, los bits sobrantes (que se puede dar si el ancho*alto no es múltiplo de 8) se descartan o se toman como datos de la siguiente letra?
Y otra cosa ¿me lo parece a mi o el código toma las fuentes BDF y la del sistema segun la norma ISO nomeseelnumero y los FNT según otra distinta?
Bien, ya puedo empezar con un conversor de fuentes (entre FNT y FPG creo que sería lo ideal) ¿preferís método interactivo o me lo puedo ahorrar y hacerlo por comandos? Por comandos saldría muy rápido.
modo 1 bit = 8 pixels por byte
con una GUI es mejor, pero da lo mismo...
Okis ¿y respecto a los bits sobrantes del ultimo byte de cada letra? supongo que se dejan pero no se leen ¿no?
q bits sobrantes?
Veamos, supongamos una letra que tiene 9 pixels: tres de ancho y tres de alto.
Para representarlo se usarían 2 bytes: el primero para los ocho primeros pixels y en el segundo sólo valdría el primer bit, los otros siete no son necesarios.
Pues eso ¿los otros siete bits restantes forman parte de la siguiente letra o se descartan?
no, se usan 3 bytes.
solo se toman 3 bits de cada byte... 1 byte es hasta 8 pixels... el alto el es alto...
serializarlo seria una locura de antiperformance.
A ver si lo he pillado ¿se usa un byte por cada fila, y si la fila es de más de 8 pixels y menos de 16 se usan 2 bytes por fila? Eso no lo sabia yo.
Es un poco raro, teniendo en cuenta que con 8 bits se pueden usar 8 pixels, pero bueno, si es por rendimiento...
es correcto... es un uso es normal... es todo lo contrario a ser raro...
Actualizado...
Bueno, aunque ya lo pregunté en otro hilo y quizás por ello pasó más desapercibido, lo vuelvo a preguntar en éste que además es el propio...
La cuestión es saber que viabilidad existiría de que Bennu permitiera usar llaves {} (además del clásico begin-end) e incluso, que nos dejara ahorrárnoslas en aquellos casos de sentencia única, al igual que ocurre en el lenguaje C, por supuesto...
Imagino que esto te supondrá más trabajo todavía, claro :-), y que a lo mejor no entra en los planes actuales, pero teniendo en cuenta lo práctico que es y que ello no impediría, por supuesto, seguir usando (por cuestiones de compatibilidad y preferencia) el clásico begin-end, tal vez estaría bien...
En cualquier caso, buen trabajo el desarrollado con Bennu.
habia unos problemas con esto... que ahora mismo no recuerdo, y se hablo en este foro o en el de fenix... creo que fue en el de fenix, y yo habia hecho el cambio, pero tuve que volverlo para atras.
Oh, qué pena... pero bueno, voy a ver si encuentro tal discusión...
Saludos.
Igual voy a volver a ver la factibilidad de implementarlo.
Si encontras el post, mandame el link por pm, asi veo porque volvi para atras eso.
gracias.
Pues al final no he encontrada el susodicho hilo (los más "relacionado" con ello ha sido el que te he pasado por pm)...
A ver si alguien de por aquí sabe dónde está y nos puede echar una mano...
Saludos.
creo que es eso, y creo que no funciona porque use un alias a los keywords... si lo hago especificamente añadiendo dos nuevas keywords y tocando todo el codigo, se podria hacer...
ahh, ya recuerdo, es que si no eliminamos el modo normal, uno podria hacer un { para abrir y un "end" para cerrar... y quedaria un poco mal... aunque bueno, eso podria ser problema del programador.
Ah, ya veo el problema... pues sí, no quedaría muy serio ese permitido híbrido {-end jeje al tener que conservar el modo normal, aunque por otro lado, como bien dices, esto es problema del programador...
Pues no se, eso ya como tú veas (y te encuentres de ganas, porque tiene trabajo por lo que cuentas) pero estaría fenómeno de implementarse finalmente... en cualquier caso, Bennu está guapo tal como está.
Y a ver si me voy acostando ya, que entre la salida nocturna y el adelantamiento de hora son ya las 6:30... mañana más... ZzZ-O
SplinterGU, hay alguna posibilidad de que en un futuro los modulos se puedan ubicar en una carpeta distinta a la del interprete? Estaría genial porque no se verían tantos archivos juntos. Mi idea sería poder tener el exe solo y en una carpeta todas las librerias y recursos del juego. Como lo ves? es posible?
Gracias por tu dedicación, saludos!
esto ya se hablo mucho, ningun gamer comun y corriente, salvo los programadores, ven que tenes en las carpetas, y aun asi, a nadie le importa si tenes 2 o 1000 archivos... lo que importa es el juego... si estamos en la situacion de que a los gamers o usuario general de un juego le interese mas los archivos que el juego entonces ahi estamos en un serio problema.
Lo ideal sería hacer algo como
import "dll/mod_sound.dll";
De todas formas, blostec, ¿probaste el Packator que viene en el Fénix Pack?
Te lo guarda todo todo en un .exe! :)
Quote from: PiXeL on March 30, 2009, 10:50:35 AM
Lo ideal sería hacer algo como
import "dll/mod_sound.dll";
A eso me refiero, a mi personalmente me gustaría tenerlo todo mas ordenado con las librerías en una carpeta, los fpgs en otra, etc...
No he probado el packator, le daré un vistazo. Gracias Pixel.
It is very much possible to do this. Create a new folder (e.g. C:\bennu\bin) and add this folder to the PATH variable in Windows. Place the Bennu binaries, including libraries, in this folder and you're done: you don't need to have any Bennu binary anywhere else; just use this folder to add new libraries to.
External libraries (like SDL) can be placed there too, but I recommend keeping those somewhere else, because you might be confused later, if you have multiple versions scattered throughout your system and don't know which one is used. But well, it's not impossible to place them there.
In Linux it's all easy: it's installed automatically like this.
Now I hear you say that if you release your game/application, people have to do all this crap as well. Of course that's true, so there should be an automated Bennu installer for Windows, handling this. Else you'll just have to be happy with all the libraries with your game/application. If you don't want them in the main folder, place the binaries in a subfolder and use a batch file in the main folder to start the game/application.
Hombre, al usuario medio le da igual el número de carpetas, subcarpetas, ficheros y sus contenidos, pero no que el ejecutable venga escondido entre decenas de dlls. Es más, hay gente que si no ve el icono en el escritorio o en el menu de inicio se muere del susto :D :D :D
Lo ideal es poder meter la mayoría de los módulos en una carpeta, al menos, los que se invocan mediante "import" (¿no se puede poner la direccion a una carpeta?). Cuatro o cinco dlls con el exe no está mal, pero cuando sobrepasan la docena puede ser traumático.
Ojo, que a mi todo este tema me da igual (como suelo decir, me la "repanfinfla"), que yo programo y ejecuto sin problema todos mis códigos.
La verdad, a mí me gusta la idea de poder organizar las cosas por carpetas. Me gusta madnar mis ejecutables a la gente y que no tengan que navegar entre dlls hasta encontrar el exe, incluso a mí me gustá más y me resulta más comodo cuando estoy programando no tener que buscar el interprete y los códigos entre un mar de dlls.
Nadie dice que bennu no sea una bendición y el trabajo que splinter está haciendo una auténtica y titánica odisea por todos nosotros, pero esta pequeña opción estaría muy bien, aunque ya hay muchas sugerencias...
¿Para qué quiere saber el usuario dónde anda el ejecutable (suponiendo que el desinstalador sí lo sepa)? además, ¿en qué le puede afectar el que haya más o menos archivos sueltos fuera de carpetas?
Otra cosa es por cuestiones organizativas del programador, pero yo creo que de cara al usuario, basta con que tras la instalación del programa se haya creado el acceso directo de turno de éste en el escritorio...
Y es que, "ojos que no ven, corazón que no siente..." :-)
La verdad, sinceramente, cuantos de nosotros pierde el tiempo en ver que archivos hay tras cada instalacion, cuantos de uds. se puso a analizar la carpeta del office o del editor de turno? y ni que hablar de linux...
yo por mi parte solo instalo y uso...
No se puede hacer...
En linux, por mas que setee las variables de enviroment LD_LIBRARY_PATH desde el ejecutable, ya el loader del sistema no toma dicho path como path valido para buscar las dlls...
pero esto se puede hacer tranquilamente en todos los sistemas con un script (bat/sh) que setee los paths adecuados, esto es...
PATH en windows
DYLD_LIBRARY_PATH en MAC
y
LD_LIBRARY_PATH en unix
Yo no se vosotros, pero yo huyo de los instaladores siempre que puedo.
Si, es muy bonito hacer doble clic, aceptar cinco veces y tener tu icono en el escritorio, pero personalmente me da grima el no saber a ciencia cierta la basura que va dejando detrás.
Y normalmente, para juegos de este tipo, en plan amateur, que ocupa poco y que se juega rápido, se tiende a usar un archivo zip, descomprimir en carpeta y ejecutar.
Tambien puede ser que sea un flojo de cuidado y no me de por usar creadores de instalación gratuitos ;D ;D ;D ;D, que por cierto, no conozco ninguno. Sería un proyecto interesante para bennu.
Drumpi, para instaladores gratuitos en windows, yo he usado el nsis, que encima es libre y se pueden crear instaladores desde linux. Échale un ojo porque hay un montón de utilidades para crear scripts para él por ahí.
Otra cosa que estoy pensando a cuenta de esto de las variables de entorno: ¿existe setenv en bennu? sé que getenv sí, pero ¿setenv?. Es sólo por curiosidad, porque veo splinter que dices que ya lo has probado...
si, se puede setear variables de enviroment para la instancia en ejecucion...
pero por lo visto el sistema de carga de librerias se inicializa en el momento que carga el exe.
Drumpi:
Supongo el metodo "mochila" no es suficiente no??? ya que las DLL de de los mod y lib siguen viendose.
Puedes hacer con el WinRAR un archivo EXE autoextraible, que ejecute el exe después. Así sólo descargas un archivo ZIP o RAR y al decomprimirlo te deja únicamente un EXE (un rar en modo SFX) que contiene todo tu juego... y es capaz el sólo de extrarse en una carpeta temporal y ejecutarse automaticamente. Todo esto desde UN SÓLO archivo, que está muy bien.
De hecho... este metodo lo usan en muchos juegos... por ejemplo.... "Super Mario Fusion" que es OpenSource, solo tiene un EXE que te crea una carpeta temporal y se ejecuta sólo.
PD: A gente que le guste el SuperMario y el Halo recomiendo se lo baje y lo pruebe. Es una forma distinta de jugar al Mario y tener nuevos enemigos y ver cosas muy curiosas.
¿puedo poner algo que considero un bug?
Quote
private
ar;
begin
set_mode(800,600,32);
ar=find("001010011000aaa00","a",-1);
write(0,400,100,4,ar);
write(0,400,150,4,find("001010011000aaa00","a",-2));
write(0,400,200,4,find("001010011000aaa00","a",-3));
while (not key (_esc))
frame;
end
end
find con valores negativos (en posición de inicio) no funciona (regresa siempre -1), exceptuando cuando el valor negativo coincide con
la frase que buscas. con valores positivos va muy bien, pero con valores negativos no.
deberia dar
-1
-1
14
si te da eso, esta perfecto...
valores negativos representan caracteres desde el final de la string...
si la posicion excede los limites de la string da -1...
si te da valores segun estas reglas es correcto.
QuoteSin embargo, es posible hacer también la búsqueda de derecha a izquierda si se especifica como primer parámetro un número negativo, que indicará además la primera posición a tener en cuenta (-1 para el último carácter de la cadena, -2 para el penúltimo, y así sucesivamente).
entonces como le hago para hacer la búsqueda de derecha a izq?, para que me de:
15,15,15
recuerdo que antes funcionaba de otra manera, y lo recuerdo porque uso otras librerías y va bien a lo descrito arriba... creo...
jo jo jo... la invierto vd? ups, y luego la invierto de nuevo para recuperarla... ya tenía el archivo subido (del nuevo editor, pero debo cambiar esto... je je je)
antes estaba mal... mas alla de eso, los numeros negativos fueron siempre caracteres desde el final...
pero no se que queres buscar.
que es 15,15,15?
perdón, es que en las rutas busco una diagonal para cortar el nombre del archivo de su ruta (argv[1]), para abrir el archivo, guardar su nombre y su ruta.
14,14,14 sería el valor de find aquí, (me equivoqué era 14 y no 15).
("001010011000aaa00","a",-1
de cualquier forma ya lo arreglé, y ya tenemos nueva versión de editor fpg, inteno hacerlo lo más fácil y sencillo de usar. :)
Pues eso, y es que hasta ahora no había tenido problema para exportarlos a .png -aunque se ralentizara la ejecución de l programa, como es lógico- a fin de, a partir de estos, crear un vídeo, pero es que ahora en un programa distinto, me hace cosas raras como la de grabarme varias veces el mismo fotograma, o directamente detenerse la ejecución de este...
Saludos.
No entiendo el problema
La cuestión es que quiero hacer capturas de los fotogramas de un programa -con ayuda de la función save_png- para luego montar un vídeo .avi a partir de éstas.
Esto llegué a hacerlo sin problemas en alguna ocasión, vamos, que que logré hacer capturas de todos los frames del programa para luego montar el vídeo con el virtualdub, pero lo cierto es que estoy intentando hacer lo mismo con otro programa pero como digo me produce efectos indeseados tales como la grabación repetida de un mismo fotograma (frame) o como que simplemente se quede detenido -bloqueado- el programa... una cosa rara, ya lo sé, porque total va a tan solo 25 FPS el programa... pero bueno
No se, quizás el problema provenga de alguna función implementada por mí lo que esté originando el problema... tendré que revisarlo...
Ya diré algo, gracias y saludos.
deberia funcionar bien, si tenes las prioridades adecuadas en los procesos... el que captura deberia ser el de menor prioridad y tu set_fps no debe estar configurado con skip frames, si tenes todo eso, entonces deberia ir bien
Bueno, pues aun poniendo el proceso capturador con menor prioridad que ninguno (el set_fps ya lo tenía de antes trabajando sin frameskip) y tras numerosas pruebas, sigo teniendo los mismos problemas -incluso ocurre que durante la ejecución de programa no se ven las imágenes, quedándose la pantalla en negro-, al menos con el susodicho programa...
Porque después he probado a capturar los fotogramas de otro programa distinto que no habia probado y no he tenido ningún problema, salvo eso sí, un fade a rojo que no era grabado en los .png, es decir los fotogramas los grababa bien pero por alguna extraña razón el efecto de fundido no lo incluía en la exportación de los .png...
Ya seguiré testeando/investigando luego otro poco a ver si aíslo el problema...
Saludos y gracias.
Si es 8 bits es probable que el fundido no lo captures.
Estoy trabajando a 640x400 a 32 bits, aunque por lo que dices igual va por ahí el problema, no lo se... porque ahora mismo no recuerdo si he llegado a capturar o no fundidos con esa profundidad de color, aunque creo que sí....
si compartieras el codigo seria de gran ayuda.
Mira, te adjunto un ejemplo muy básico que muestra cómo falla la captura del fade en 32 bits...
Se trata de un simple fade a rojo, y para capturar las pantallas, simplemente tienes que descomentar el código que se encarga de ello y que viene claramente indicado.
Las capturas son creadas dentro de la subcarpeta 'captures'.
La get_screen es un tanto errada conceptualmente, lo que hace es forzar un frame, pero lo hace a medias... yo te sugiero el siguiente codigo:
Program prueba;
import "mod_video";
import "mod_map";
import "mod_string";
import "mod_draw";
Global
int counter=0;
begin
full_screen=false;
set_mode(640,480,32,WAITVSYNC);
set_fps(25,0);
drawing_map(0,0);
draw_box(50,50,100,100);
fade(200,0,0,1);
while(fading)
frame;
save_png(0,-1,"captures/img"+substr("00000"+counter,-5)+".png");
counter++;
end
end
save_png... con graph "-1"??? -1 es la pantalla? falta ayuda completa XD está bien el moddesc.exe pero está claro que no es suficiente.
Así que con -1 graba los fade? y esas cosas? a ver si puedo probarlo en un rato.
Yo si noté hace tiempo (y lo Posteé en el Foro) que el save_png guardaba el negro Puro como transparente. Lo que hice fue ponerle un graph como fondo con un negro rgb(5,5,5).
Quote from: SplinterGU on May 03, 2009, 11:57:30 PM
La get_screen es un tanto errada conceptualmente, lo que hace es forzar un frame, pero lo hace a medias... yo te sugiero el siguiente codigo...
Gracias, lo probaré.
Editado:
Ahora sí que captura el fade, gracias.
Editado II:
Y también he descubierto el problema que hacía que mi programa se detuviera a veces y en puntos aleatorios, y no era por mi código, no al menos directamente:[code language="bennu"]if(t%(fps*3)==0) k-=18; end
if(t%(fps*1)==0) k+=6; end[/code]
y es que como se ve, al depender 'k' de 'fps' la cual no mantiene siempre el mismo valor, si tenemos en cuenta que 'k' hace de índice de un vector, pues no es complicado imaginarse las malas consecuencias que ello puede traer, y que de hecho me ha traido...
Así pues, nada, he sustituido 'fps' por un 'fps2' que guarda un valor fijo de 25 y Santas Pascuas.
Quote from: TYCO on May 04, 2009, 06:56:31 AM
save_png... con graph "-1"??? -1 es la pantalla? falta ayuda completa XD está bien el moddesc.exe pero está claro que no es suficiente.
Así que con -1 graba los fade? y esas cosas? a ver si puedo probarlo en un rato.
Yo si noté hace tiempo (y lo Posteé en el Foro) que el save_png guardaba el negro Puro como transparente. Lo que hice fue ponerle un graph como fondo con un negro rgb(5,5,5).
Me extraña araña!
Eso del mapa 0,-1 deberias saberlo desde hace tiempo... 0,-1 desde los remotos tiempos de fenix fue la pantalla... no tiene nada que ver con la save_png.
Yo vengo de los tiempos de Fénix y me encargé una temporada de pasar Documentación a una plantilla XML, y lo que tengo de SAVE_PNG es esto:
SAVE_PNG
Guarda en disco un gráfico, en formato PNG
SINTAXIS
INT SAVE_PNG( INT librería, INT gráfico, STRING fichero)
VALOR DE RETORNO
INT :
PARÁMETROS
INT librería : Código de la librería FPG
INT gráfico : Número del gráfico
STRING fichero : Nombre del fichero
DESCRIPCIÓN
Esta función guarda en disco un gráfico cualquiera en formato PNG. Este gráfico puede formar parte de una librería FPG cualquiera, o haber sido creado en memoria con funciones como NEW_MAP o MAP_CLONE.
Los ficheros PNG no soportan información extendida como por ejemplo el centro, los puntos de control o las animaciones.
NOTAS
1. El gráfico PNG será de 8 o 32 bits en función del grafico original (8 o 16 bits respectivamente).
VEA TAMBIÉN
SAVE_MAP, MAP_CLONE, NEW_MAP
Como se puede apreciar no se hace referencia alguna a que si indicas GRAPH=0 o -1, sea la "pantalla". Por tanto... tengo razón, tanto la ayuda de Bennu como la de Fénix (las Wikis que yo conozca) no es completa, y cosas como éstas... para un novato pasan totalmente desapercibidas.... incluso para gente que lleva más tiempo como yo. Sino... que levanten la mano los lo sabian.... ves? ni una mano XD.
Respecto a las TRANSPARENCIAS al hacer el "save_png" con:
save_png(0,-1,"PRUEBA" + itoa(contador) + ".PNG");
Los negros PUROS me los graba como transparecia (o canal alpha), uso 16Bits. Pero si en vez de -1 le pongo un Graph capturado con get_screen(); lo hace bien, al menos en 16Bits.
como hago para declarar un tipo de una estructura algo asi como
type entidad3d
x,y,z;
end;
type entidad3d pointer PE3D;
actualmente estoy usando define:
#define PE3D entidad3d pointer
pero lo malo es cuando se declaran varias variables ej;:
PE3D i,j,x;
Pregunto, no se leen mis mensajes?
Quote from: SplinterGU on May 04, 2009, 11:15:45 AM
Quote from: TYCO on May 04, 2009, 06:56:31 AM
save_png... con graph "-1"??? -1 es la pantalla? falta ayuda completa XD está bien el moddesc.exe pero está claro que no es suficiente.
Así que con -1 graba los fade? y esas cosas? a ver si puedo probarlo en un rato.
Yo si noté hace tiempo (y lo Posteé en el Foro) que el save_png guardaba el negro Puro como transparente. Lo que hice fue ponerle un graph como fondo con un negro rgb(5,5,5).
Me extraña araña!
Eso del mapa 0,-1 deberias saberlo desde hace tiempo... 0,-1 desde los remotos tiempos de fenix fue la pantalla... no tiene nada que ver con la save_png.
No tiene que estar esto en el help del save_png... ni de ningun save... -1 es el mapa de la pantalla, sabiendo esto, las posiblidades y lo que podes hacer dependen de tu capacidad de imaginacion... es imposible que un help pueda documentar todas la posibles combinaciones de sus componentes... es lo mismo que pretenda que el man del C del printf me diga que puedo imprimir un atol de una string... eso es ridiculo, el uso depende de mi imaginacion...
Lo de las transparencias es exacto, si queres que no las guarde tenes que ponerle el flag no_colorkey al mapa en cuestion... por ende clonar el mapa de pantalla, y en fin...
Quote from: l1nk3rn3l on May 04, 2009, 05:30:01 PM
como hago para declarar un tipo de una estructura algo asi como
type entidad3d
x,y,z;
end;
type entidad3d pointer PE3D;
actualmente estoy usando define:
#define PE3D entidad3d pointer
pero lo malo es cuando se declaran varias variables ej;:
PE3D i,j,x;
A menos que exista una forma desconocida por mi, no es posible.
Hombre, yo sabía lo de file=0 graph=0 es el "fondo" de la ventana, y todo lo que se dibuje ahi es lo que se guarda, pero con graph=-1 nunca vi nada ¿cual es la diferencia? es decir, creo haber entendido que el graph=0 es el fondo, lo que se "put" en él, y que graph=-1 es todo lo que hay en la pantalla (se haya "put" o no, procesos incluidos, vamos, lo que hay en el buffer antes del volcado a pantalla).
Quote from: Drumpi on May 05, 2009, 11:31:54 AM
Hombre, yo sabía lo de file=0 graph=0 es el "fondo" de la ventana, y todo lo que se dibuje ahi es lo que se guarda, pero con graph=-1 nunca vi nada ¿cual es la diferencia? es decir, creo haber entendido que el graph=0 es el fondo, lo que se "put" en él, y que graph=-1 es todo lo que hay en la pantalla (se haya "put" o no, procesos incluidos, vamos, lo que hay en el buffer antes del volcado a pantalla).
-1 es lo que hay antes (y tambien es correcto decir "lo que hay despues", segun el punto de vista y en relacion a que) de lo dibujado en pantalla... es el ultimo frame dibujado, aunque si bien podes dibujar en este, este sera pisado en el proximo frame.
El 0 (fondo) es la imagen de fondo, o sea, lo que se dibuja (parcial o total) primero cuando se dibuja un frame.
Quotecomo hago para declarar un tipo de una estructura algo asi como
type entidad3d
x,y,z;
end;
type entidad3d pointer PE3D;
actualmente estoy usando define:
#define PE3D entidad3d pointer
pero lo malo es cuando se declaran varias variables ej;:
PE3D i,j,x;
L1nk, es sencillo, he abusado y abuso bastante del uso de tipos definidos (structs) en Bennu. Supongo que te refieres a esto:
Una vez declaras una nueva estructura:
TYPE tp_persona
string nombre;
int edad;
END
Para crear una variable de este tipo tendras que declarar:
PRIVATE
tp_persona windgate;
Es decir, prefijando la variable con el nombre del tipo que quieres que tenga, al igual que prefijas con los tipos primitivos como int o string.
Y si quieres tener una variable que sea un puntero puedes declarar:
PRIVATE
tp_persona POINTER windgate;
Añadiendo [10] al nombre de la variable puedes tener arrays del tipo definido, por supuesto.
Y añado que en el caso de los POINTER no es necesario poner el tp_persona, ya que con un pointer puedes apuntar a donde quieras, ¿Me equivoco en esto ultimo?
Si era eso a lo que te referias espero haberte ayudado, puedo pasarte ejemplos de programitas Bennu breves con hartos TYPE declarados y variables asociadas a ellos si quieres, pide por esa boquita.
No amigo, lo que el quiere es hacer un tipo de dato que sea puntero.
Eso que dices es parecido a lo que el hace con el define.
Pero el pregunta si se puede hacer un tipo de dato que a la vez sea un puntero.
Por otro lado, creo que ya es hora de largar la version actual como release.
Hay cosas que sabemos hay que mejorar y completar, pero me parece que esta ya podria ser la 0.93 oficial o 0.94... no se que opinan Uds.
Hombre, yo creo que habría que romper la nomenclatura de fenix.
Debería ser algo como la 0.1 (esto da poca seguridad de uso) o la 1.0, no comprendo porqué no empezar en la versión 1.0, nunca vi que un programa no empezase en la versión 1.0.
Un poco ilógico, si ya se usa y está al alcance de cualquier persona es la primera versión útil, por tanto es la primera y la primera implica 1.
Alguien conoció msdos 0.X o windows 0.X o div 0.X o cuaquier otro programa de índole reconocida, no se nunca los ví, y los pocos que he visto con esas nomenclaturas de cero coma lo que sea han sido versiones internas de testeo de programadores implicados en el desarrollo o personas allegadas. Bueno o proyectos abiertos en los que a priori se sabe que es imposible llegar a una versión final, ejemplo MAME: es imposible terminar el proyecto, debido a que son innumerables máquinas recreativas las que existen y siempre van saliendo nuevas con nuevos sistemas o rescatando antiguas con sistemas antiguos.
Una buena nomenclatura sería con tres cifras, la primera para cambios drásticos en apariencia y funcionalidad, la segunda para cambios masivos de mejoras y correcciones y la tercera para correcciones pequeñas o mínimas pero importantes
Bueno todo este rollo es para defender la entrada de, por lo menos, la versión 1.1.5, o así
el primer 1 por ser el primer bennuGD, el segundo 1 por las mejoras añadidas y cambios añadidos desde la versión inicial de bennu y la 5 porque llevas 5 binarios distintos soltados por ahora.
http://es.wikipedia.org/wiki/Versi%C3%B3n
http://es.wikipedia.org/wiki/Fases_del_desarrollo_de_software
http://www.tldp.org/HOWTO/Software-Proj-Mgmt-HOWTO/users.html#ALPHABETA
SplinterGU, no con esto quiero romperte los esquemas, solo es una opinión desde el punto de vista de un usuario nuevo. Puedes seguir con la nomenclatura fenix si lo que quieres es dejar rastro para que los antiguos usuarios de fenix migren a bennu.
Desde luego, yo no lo llamaría 0.1 :)
Pero sí que creo que va siendo hora de hacer una release, aunque antes de hacerlo haría algo como la "semana de la documentación" donde pusiéramos un poquito de énfasis todos y mejoráramos un par de artículos cada uno del wiki para ir mejorando la documentación.
Quote from: josebita on May 06, 2009, 09:42:16 AM
Desde luego, yo no lo llamaría 0.1 :)
Sí, no se ve muy pa allá pero es la cruda realidad, todo tiene un comienzo. :D
Si tenemos un "antes", eso se dilata eternamente... tenemos que tomar alguna medida drastica...
me parece razonable que sea la version 1.X
yo pensaba en <version>.<release>.<builddate>, con esto seria muy facil identificar/relacionar los binarios...
en este caso, la siguiente seria: 1.49.20080506
Yo creo que sería bueno usar la nomenclatura 1.x. Una duda, la release traerá documentación como la que tenía Fenix con su .pdf? Sería bueno que el usuario disponga de documentación para empezar a trabajar sin necesidad de estar conectado a la wiki.
Un poco largo diría yo, pero que mas da :D.
De todas formas le veo un problemilla, que quizás no sea tan problemilla pero la dependencia al número de revisión de subversion daría lugar a binarios alejados en números por ejemplo si haces 8 subidas separadas sin crear binarios y luego mas adelance creas uno saltarías así como de la versión 1.49.20080506 a la versión 1.57.20080608 (fecha inventada) y los usuarios no puestos en el tema preguntarían por las versiones intermedias.
También pasarían cosas como estas, en la versión 2 lo que sea, el segundo número seguiría incrementándose por donde quedó
versión 1.59 - vesión 2.60. Y como resultado pasaría que el usuario nuevo vería la falta de versiones intermedias.
Como conclusión, normalmente se separan las nomenclaturas de control de versiones a las nomenclaturas de entrega final de binarios o bién se usa el mismo número para ambas, no se entremezclan nomenclaturas porque da margen a error.
Por ejemplo binarios de la release 48 de svn, o binarios de la versión 1.1.5, pero nunca binarios de la versión 1.1.48 porque puede pasar que cambiese a 1.2.50 en vez de pasar a la 1.2.0.
Lo normal es resetear números inferiores al cambiar a versión superior, podeis ver ejemplos en la mayoría de programas conocidos. Si por ejemplo ejecutais el comando ver en windowx xp vereis algo como 5.1.2600, el último número es el "build" si haceis lo mismo en un xp con service pack ese último número cambia, ya que es el mismo programa pero con mejoras no significativas. en cambio si lo haces a windows vista verás que empieza de nuevo 6.0.1000, no sigue por la dosmilypico.
El número final "build" normalmente es incrementado automáticamente por los programas de compilación de alto nivel tipo borland c++builder, delphi, visual c++. Y se incrementa por cada vez que tocas el botón "build and compile".
Lo que quiere decir,que representa el número de veces que ha sido ejecutado dentro del entorno de programación para pruebas de resultados del programador.
Pero vamos, eso es lo que tengo yo entendido, no tiene porqué cumplirse siempre porque hay muchas formas distintas de llevar el versionado y no está muy estandarizado, cada uno suele seguir su propio criterio o adoptar el que les imponen las reglas de programación.
Con ésto solo intento explicar los problemas que le veo a tu propuesta Splinter.
Algo como 1.49.20080506 lo veo un poco redundante, porque sabiendo el número de revisión la fecha lo único que te dice es cuándo se compiló, que no sé si hace mucha falta.
Pero vamos, que como lo veas. Mis nombres del PPA son bastante más largos (0.93svn20090503, por ejemplo :), también es cierto que el usuario no los usa para nada, en general).
Entonces no es redundante ¿no? Redundante sería si se volviera a repetir un dato, te refieres más bien a que es fútil,
http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=redundante
http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=f%C3%BAtil
:D, yo y mis defensas/problemas con mi idioma nativo.
PD: Dejo esto en el aire, ¿está bien dicho "veinte y dos"?
Sin documentación en modo offline (sin internet), no debería salir la versión 1.0. Ya sea en un PDF u otro formato.
Con que se llamará v0.94 Build 231, sería suficiente. A grandes cambios: 0.95 Build xxx, a pequeños cambios: 0.94 Build 290. Hay varios programas que lo indican así, no sería el primero.
Algo sencillo y conciso.
PD: Si está bien dicho DCELSO.
Veintidós.
1. adj. Veinte y dos.
2. adj. Vigésimo segundo. Número veintidós. Año veintidós. Apl. a los días del mes, u. t. c. s. El veintidós de mayo
3. m. Conjunto de signos o cifras con que se representa el número "veintidós".
lo de la documentación offline lo veo fácil de hacer, usas teleport pro y te descargas la wiki y la comprimes en un zip,
En cuanto a mi pregunta dije "veinte y dos", ya sé que está bien veintidos que es lo que buscaste en en la rae.
Date cuenta que está pendiente de revisión, revísalo de nuevo y dale al botón azul que hay arriba a la derecha y verás el cambio de esa palabra para la 23ª Edición.
De ahí de nuevo que lance mi pregunta.
PD: te he cambiado una b que teniás por ahí que me dañaba la vista :D, así que por este motivo verás que tu post está editado.
Quote from: DCelso on May 06, 2009, 02:12:37 PM
Un poco largo diría yo, pero que mas da :D.
De todas formas le veo un problemilla, que quizás no sea tan problemilla pero la dependencia al número de revisión de subversion daría lugar a binarios alejados en números por ejemplo si haces 8 subidas separadas sin crear binarios y luego mas adelance creas uno saltarías así como de la versión 1.49.20080506 a la versión 1.57.20080608 (fecha inventada) y los usuarios no puestos en el tema preguntarían por las versiones intermedias.
También pasarían cosas como estas, en la versión 2 lo que sea, el segundo número seguiría incrementándose por donde quedó
versión 1.59 - vesión 2.60. Y como resultado pasaría que el usuario nuevo vería la falta de versiones intermedias.
Como conclusión, normalmente se separan las nomenclaturas de control de versiones a las nomenclaturas de entrega final de binarios o bién se usa el mismo número para ambas, no se entremezclan nomenclaturas porque da margen a error.
Por ejemplo binarios de la release 48 de svn, o binarios de la versión 1.1.5, pero nunca binarios de la versión 1.1.48 porque puede pasar que cambiese a 1.2.50 en vez de pasar a la 1.2.0.
Lo normal es resetear números inferiores al cambiar a versión superior, podeis ver ejemplos en la mayoría de programas conocidos. Si por ejemplo ejecutais el comando ver en windowx xp vereis algo como 5.1.2600, el último número es el "build" si haceis lo mismo en un xp con service pack ese último número cambia, ya que es el mismo programa pero con mejoras no significativas. en cambio si lo haces a windows vista verás que empieza de nuevo 6.0.1000, no sigue por la dosmilypico.
El número final "build" normalmente es incrementado automáticamente por los programas de compilación de alto nivel tipo borland c++builder, delphi, visual c++. Y se incrementa por cada vez que tocas el botón "build and compile".
Lo que quiere decir,que representa el número de veces que ha sido ejecutado dentro del entorno de programación para pruebas de resultados del programador.
Pero vamos, eso es lo que tengo yo entendido, no tiene porqué cumplirse siempre porque hay muchas formas distintas de llevar el versionado y no está muy estandarizado, cada uno suele seguir su propio criterio o adoptar el que les imponen las reglas de programación.
Con ésto solo intento explicar los problemas que le veo a tu propuesta Splinter.
Yo no le veo ningun problema... mira Ubuntu, saco la version 8.04, luego la 8.10, ahora la 9.04... esto es porque ellos versionan usando <año>.<mes> y sacan una release cada 6 meses...
Nada tiene de malo que nosotros hagamos <version del proyecto>.<revision>.<fecha> o <version del proyecto>.<fecha>.<revision>
Quote from: josebita on May 06, 2009, 02:34:57 PM
Algo como 1.49.20080506 lo veo un poco redundante, porque sabiendo el número de revisión la fecha lo único que te dice es cuándo se compiló, que no sé si hace mucha falta.
Pero vamos, que como lo veas. Mis nombres del PPA son bastante más largos (0.93svn20090503, por ejemplo :), también es cierto que el usuario no los usa para nada, en general).
la fecha del build es muy importante, tan importante como la revision.
Quote from: DCelso on May 06, 2009, 03:43:19 PM
Entonces no es redundante ¿no? Redundante sería si se volviera a repetir un dato, te refieres más bien a que es fútil,
http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=redundancia
http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=f%C3%BAtil
:D, yo y mis defensas/problemas con mi idioma nativo.
Me acojo a la tercera acepción de redundancia :). Sabiendo el número de revisión, en http://bennugd.svn.sourceforge.net/viewvc/bennugd?view=rev&revision=49 se puede saber la fecha y hora de commit, así como revisar los cambios y el registro de subida.
Quote from: splinter_work on May 06, 2009, 07:01:47 PM
la fecha del build es muy importante, tan importante como la revision.
Así sea; el que manda, manda :)
Je, bueno, tampoco tiene que ser dictatorial la decision... por eso pregunte...
Pero creo que la idea es que la revision y la fecha sean rapidamente identificables y no tener que ingresar a un svn para ver eso.
El usuario medio (el alto y el bajo tambien :P ) no sabe (y ni tiene por que saber ) que es un svn.
...¿Qué es un SVN?... Aunque sea así por encima... Suelo llevar control de versiones, pero simplemente empiezo por 0.0 y voy sumando 0.1 a cada nueva versión... ¿Es algún sistema de numeración de versiones o algo de eso?
bennu es tan estable que ya empecemos con la 1.x
bennu ya no tiene nada parecido a fenix 0.76 del año 2000
recuerdo que corria el pang con esa version y
bueno trataba de hacer algo interesante y la SDL
ocasionaba errores de vez en cuando,,
yo creo que bennu ya tiene madurez
porque no llamarlo bennu v1.0
en lugar de bennu r50
Voto por utilizar esta nomenclatura más que estándar:
CAMBIOSGRANDES.PACKDENUEVASFEATURES.BUGSOFEATURESMENORES (no sé si m'explico xD)
Empezando por: Bennu 1.0.0
Bugs corregidos: x.y.z+1
Nuevas funcionalidades: x.y+1.z=0
Cambios transcendentales (no se esperan en mucho tiempo, por ahora): x.y+1.z=0
Pero bueno, hablo sólo de las releases, para las builds sería, el x.y.z actual y detrás "build r$n"
Ahí le has dado, te has explicado de PM, eso es lo que quería decir yo no me expresé del todo bien, veo que no soy el único que ha usado esa nomenclatura mas o menos estandarizada :D.
Con respecto a lo del SVN es subversion (http://es.wikipedia.org/wiki/Subversion).
Es para control de versiones de archivos de código fuente, nada que ver con control de versionado de binarios soltados o liberados.
Empezar con Bennu 1.0.0 y llevar el sistema de numerado propuesto por PiXeL me parece correcto, he probado Bennu todo lo que he podido... Y lo considero estable y digno de una 1.0.0. (Aún estoy haciendo pruebas con structs, memoria dinámica y un spaghetti de punteros curioso, pero por ahora va bastante bien todo)
Si lo aceptamos... ¡¡¡Hay que celebrarlo!!!
Me refería a que tampoco me iba a poner a discutir el sistema de numeració de versiones :).
Pero debo decir que estoy con Pixel; creo que es el sistema que usa más gente, sobre todo en programas libres.
La idea que todos coincidimos (salvo uno) es que debemos sacar la version 1.
Convengamos que no necesitamos seguir la manada y tomar una nomenclatura de versionado especifica, lo importante es identificar facilmente si estoy con un ejecutable viejo o no, y a que revision del repositorio corresponde... despues detalles como saber si se hicieron o no 80 agregados o 500 fixes a una version, son datos estadisticos y anecdoticos, pero el saber a que version de fuentes corresponde y a la fecha en que fue liberado es importantisimo a la hora de asegurar compatibilidad con modulos o incluso para saber si tenemos tal o cual cosa corregida, cuantas no es un dato critico.
Resumiendo y combinando lo que todos decimos, propongo tomar la siguiente nomemclatura... (que para mi parecer es mas importante la parte que esta entre parentesis)
<version>.<new features>.<fixes sobre la ultima version feature> (Build YYMMDDr<revision>)
por ejemplo:
1.10.5 (Build 091025r48)
o
1.10.5 (091025r48)
o
1.10.5.091025r48
Quote from: josebita on May 06, 2009, 11:05:31 PM
Me refería a que tampoco me iba a poner a discutir el sistema de numeració de versiones :).
Pero debo decir que estoy con Pixel; creo que es el sistema que usa más gente, sobre todo en programas libres.
Repito que Ubuntu (vos que andas armando paquetes para Ubuntu), la nomemclatura de version es totalmente ilogica, y sin embargo funciona, hasta que uno comprende el por que de esos numeros puede pasar un buen tiempo.
Muy buena idea. Aceptamos Barco
Quote from: SplinterGU on May 06, 2009, 11:27:16 PM
Repito que Ubuntu (vos que andas armando paquetes para Ubuntu), la nomemclatura de version es totalmente ilogica, y sin embargo funciona, hasta que uno comprende el por que de esos numeros puede pasar un buen tiempo.
Claro, pero Ubuntu no cuenta, es raro :)
En serio, esto que has propuesto sí que me mola. Quizás más la tercera, incluso con un guión para separar la fecha-release.
jajaja... quien dice que bennu no sea raro...
por otro lado, creo que entonces deberemos hacer votacion... con esas 3, o si alguno se le ocurre alguna otra...
mmmmmm
tendremos release!!! :D
genial.
yo creo que ya vamos a más de la 1,
me gusta la nomenclatura 1.x.x
me encanta la idea de una ayuda offline (la del flamebird es mi ayuda todos los días, pero le hacen falta ejemplos).
y si hay versiónn en español, mucho mejor...
lástima que las vacaciones por enfermedad (ese virus) en méxico se acaban la próxima semana, ya no estaré tanto por aquí... (mis maestros intentarán recuperar tiempo perdido :'( ) :D
Esta 1.10.5 (Build 091025r48) me parece perfecta.
Yo opto por la segunda, es un poquito más breve.
por cierto para hacer la documentación offline usando la actual online wiki, he encontrado esta herramienta gratuita de descarga de páginas web, httrack, voy a probarla a ver que consigo
En Linux, con un simple comando wget (o curl) ya se consigue descargar sitios web enteros...
Yuju, por fin documentadion independiente del online. Menos mal, me gustaría ayudar (tengo en la pila de proyectos un tutorial de manejo de ficheros), pero me temo que estoy tan tan tan desfasado que voy a cometer errores gordos y que me voy a dejar muchas cosas nuevas (pues lo más que he llegado ha sido la última de Fenix).
De todas formas, a ver si este fin de semana reuno fuerzas y hago algo.
Aparte de eso, Bennu lleva ya bastante tiempo siendo estable, creo que desde que salió la siguiente versión a la wip2, así que podríamos ir a por la 1.x, lo que pasa es que cualquier versión 1.x debe ir bien preparada, o al menos, es mi opinión de cara a los novatos que quieran entrar en la comunidad: una versión 1.0 llama a la gente, pero sin documentación que lo apoye...
Y en cuanto a la fecha de compilación, no lo veo util, salvo para el propio desarrollo de bennu. Dado que va a ir de cara a usuarios, debería tener lo dicho: 1 (punto) versión definitiva de los cambios añadidos o cambios importantes (punto) cambios menores y solución de bugs, y luego aparte las revisiones de desarrolladores, porque la fecha puede salir cuando se ejecuta bgdc/bgdi por la linea de comandos sin parámetros.
Drumpi se podría adaptar el tutorial de fenix que hiciste, sólo faltaría añadir una breve explicación de los módulos y los imports, luego es crear el pdf y sería un tutorial muy útil para los novatos en BennuGD. Como lo ves?
Quote from: blostec on May 07, 2009, 12:44:23 PM
Drumpi se podría adaptar el tutorial de fenix que hiciste, sólo faltaría añadir una breve explicación de los módulos y los imports, luego es crear el pdf y sería un tutorial muy útil para los novatos en BennuGD. Como lo ves?
¿Quisiste decir osk? O es que Drumpi también hizo un tutorial.
A ver, primera prueba con el programilla ese, me he descargado 70 megas, estoy probando y parece que está todo offline, pero qué pasote, 70 megas de htmls, no parece muy optimo, pero la ventaja es que comprimidos en 7zip ocupa 5 meguillas y está todo.
Edit:
http://www.gigasize.com/get.php?d=bb1hlkx5bnd
Quote from: DCelso
¿Quisiste decir osk? O es que Drumpi también hizo un tutorial.
Me refería al de Drumpi, lo puedes ver en su web.
El de Drumpi está muy bien (de hecho le cogí un montón de ideas) para tener en poco tiempo un juego de matamarcianos totalmente funcional. Es muy didáctico y pasito a pasito te va guiando para tener finalmente tu juego ya hecho. Viene de perlas como tutorial inicial.
Mi manual es mucho más extenso y empieza desde 0, está más pensado para gente que no ha programado nunca y que empieza a hacerlo haciendo videojuegos (de hecho, lo hice pensando en aprovechar Bennu/Fenix para motivar más a mis alumnos de mis clases del instituto).
Cuando salga la versión primera definitiva de Bennu (¿1.0.0?, ¿20090507? ;-)), y en todo caso, en verano, reestructuraré el manual para actualizarlo...Seguramente quite muchas cosas que ya están en la wikipedia, no sé. Pero os prometo que para septiembre habrá manual de introducción al lenguaje para todos los públicos -en spanish sólo, sorry-.
Ya esta disponible en el SVN "Bennu Game Development 1.0.0 RC (Release Candidate)"...
Hombre, lo mio, más que manual, es más bien un apartado, pero bueno. No pretendía hacer EL manual de Fenix (que para eso venía el PDF de la 0.7 ;D) sino algo sencillito para novatos, para la gente que venía de DIV y para los que se querían adaptar.
EL manual es el de OSK.
Podría hacer unas modificaciones para adaptarlo, y así tener los tres lenguajes, no sería muy complicado (teniendo en cuenta que el código es igual al de Fenix), sólo habría que añadirle cómo se meten los módulos y eso (y ya de paso, incluir la lista de comandos de Bennu que tengo por aqui, que es muy útil cuando no estoy en linea). Pero no puedo darle prioridad, pues hay cosas más urgentes: desde los exámenes, que ya estan aqui cerquita (con una máscara de hockey y un hacha), como otra cosita que ando preparando para "los V days" que llevo más de un año retrasando (y el 80% de la culpa es por el tema del sonido).
Aunque ya puestos, me lanzaría a una segunda parte, que este enseña lo más básico de DIV/Fenix, pero no saca la potencia que tiene en la superficie (size, angle, alphas...)
Pequeño bug encontrado: get_screen pone como centro 0,0 al gráfico que crea :)
En realidad es un clon de la pantalla, y la misma tiene centro en el 0,0... pero bueno, esto se puede cambiar...