• Viernes 29 de Mayo de 2020, 00:51

Autor Tema:   Discusion:  (Leído 1858 veces)

JuanK

  • Miembro de ORO
  • ******
  • Mensajes: 5393
  • Nacionalidad: co
    • Ver Perfil
    • http://juank.io
Discusion:
« en: Jueves 16 de Junio de 2005, 06:30 »
0
Bueno lamento contradecirte..
Citar
Hola, el programa no necesita utilizar doble buffer para correr mas rapido, de hecho eso lo haria mas lento y al ser un sistema para dibujo directamente lo haría un poco mas complicado de programar y por lo tanto aumentaría la cantidad de instrucciones para realizar el mismo trabajo.

En esto estas totalmente equivocado, es mas rapido dibujar todo en memoria y luego hacer transferencia en bloque que hacer transferecia directa puto a punto (copia direta a memoria visible)
Citar
Si bien el doble buffer eliminaría el flickering, tambien se puede obtener ese efecto de otras maneras como utilizando máscaras XOR

El double buffer no ayuda mucho a lo del flickering, para esto es mejor conplementarlo con lo del retrazo vertical.
Citar
, pero como se ve en el código está utilizando las librerias GDI+ de .NET Framework por lo tanto no soporta esa función raster. Aunque bien podría utilizar SetPixel del GDI de windows, como está utilizando el GetPixel, y así aumentará el rendimiento. La mejor forma para aumentar el rendimiento del programa es utilizar la memoria directamente, pero eso es otro cuento...

En parte cierto, pero en realidad ningún sistema derivado de win32 permite usar la memoria directamente, lo más rapido seria usar la api de directX la cual evita pasar por el ciclo de mensajes de ventanas del GDI y permite usar las implementaciones de hardware a travez de las apis de bajo nivel de windows. o biien usar una version reciente de openGL
[size=109]Juan Carlos Ruiz Pacheco
[/size]
Microsoft Technical Evangelist
@JuanKRuiz
http://juank.io

niofis

  • Nuevo Miembro
  • *
  • Mensajes: 9
    • Ver Perfil
Re: Discusion:
« Respuesta #1 en: Jueves 16 de Junio de 2005, 09:20 »
0
Hola de nuevo, no es por molestar pero creo ke aun hay que hacer algunas aclaraciones...

Citar

Bueno lamento contradecirte..

QUOTE 

Hola, el programa no necesita utilizar doble buffer para correr mas rapido, de hecho eso lo haria mas lento y al ser un sistema para dibujo directamente lo haría un poco mas complicado de programar y por lo tanto aumentaría la cantidad de instrucciones para realizar el mismo trabajo.



En esto estas totalmente equivocado, es mas rapido dibujar todo en memoria y luego hacer transferencia en bloque que hacer transferecia directa puto a punto (copia direta a memoria visible)


Aqui estas totalmente en lo cierto... si se tratase de un programa que presentara animaciones, pero este no es el punto de este programa, y al estar esperando la entrada del usuario, se presenta mayor carga al procesador pues es necesario calcular las transiciones al punto origen y de vuelta a la pantalla; no es que sea algo complicado, de hecho es trivial, sin embargo se lo está ahorrando sin ningun problema. Pero obviamente el cuello de botella no es el uso directo de la pantalla, esta en otro lugar.

Citar
QUOTE 

Si bien el doble buffer eliminaría el flickering, tambien se puede obtener ese efecto de otras maneras como utilizando máscaras XOR
 

El double buffer no ayuda mucho a lo del flickering, para esto es mejor conplementarlo con lo del retrazo vertical.

Aquí creo que no fui lo suficientemente claro, con flickering me referia al parpadeo que se ve cuando se hace el movimiento de la imagen con los botones designados, para lo cual si funcionaria el double buffer. Sin embargo para poder utilizar el retrazo vertical (VZYNC) necesitas utilizar el double buffering, y como dije antes, no seria de mucha ayuda, pues no es un programa que presente animaciones, a demás el flickering(ahora si) es mas visible en pantalla completa.
Citar
QUOTE 

, pero como se ve en el código está utilizando las librerias GDI+ de .NET Framework por lo tanto no soporta esa función raster. Aunque bien podría utilizar SetPixel del GDI de windows, como está utilizando el GetPixel, y así aumentará el rendimiento. La mejor forma para aumentar el rendimiento del programa es utilizar la memoria directamente, pero eso es otro cuento...



En parte cierto, pero en realidad ningún sistema derivado de win32 permite usar la memoria directamente, lo más rapido seria usar la api de directX la cual evita pasar por el ciclo de mensajes de ventanas del GDI y permite usar las implementaciones de hardware a travez de las apis de bajo nivel de windows. o biien usar una version reciente de openGL

En esto estas equivocado, pues con directx y su interfaz de directdraw(que ya no se llama asi), puede hacerse un lock del buffer de la pantalla y accesarlo directamente como si se tratase de una matriz de bytes y escribir o leer de ella como con cualquier otro arreglo.

saludos


niofis

JuanK

  • Miembro de ORO
  • ******
  • Mensajes: 5393
  • Nacionalidad: co
    • Ver Perfil
    • http://juank.io
Re: Discusion:
« Respuesta #2 en: Jueves 16 de Junio de 2005, 14:47 »
0
Citar
Aqui estas totalmente en lo cierto... si se tratase de un programa que presentara animaciones, pero este no es el punto

si es una animacion.. es el mismo principio pues al estar escribiendo pixeles directamente en pantalla se ve como se van pintando linea a linea.

Citar
y al estar esperando la entrada del usuario, se presenta mayor carga al procesador pues es necesario calcular las transiciones al punto origen y de vuelta a la pantalla; no es que sea algo complicado, de hecho es trivial, sin embargo se lo está ahorrando sin ningun problema. Pero obviamente el cuello de botella no es el uso directo de la pantalla, esta en otro lugar.
 

Estas seguro?, yo te puedo asegurar que no es asi, y menos en una aplicacion que corre en modo ventana.

Citar
Aquí creo que no fui lo suficientemente claro, con flickering me referia al parpadeo que se ve cuando se hace el movimiento de la imagen con los botones designados, para lo cual si funcionaria el double buffer. Sin embargo para poder utilizar el retrazo vertical (VZYNC) necesitas utilizar el double buffering, y como dije antes, no seria de mucha ayuda, pues no es un programa que presente animaciones, a demás el flickering(ahora si) es mas visible en pantalla completa.

Si lo fuiste y te reitero, la tecnica de double buffer ayuda a disminuir el efecto de flicker pero no lo elimina y en graficos grandes se sigue haciendo notorio.
Parece que estas muy confundido, el efecto de flicker no se genera por solo tener una animacion y no tiene nada que ver con los botones ni del teclado ni del mouse ni del joystick, dehecho puedes tarr dibujando siempre el mismo cuadro en pantalla y tendras el efecto de flicker sin necesidad de animarlo ni d relacionarlo con ningún botón ni cosa parecida.

Citar
En esto estas equivocado, pues con directx y su interfaz de directdraw(que ya no se llama asi), puede hacerse un lock del buffer de la pantalla y accesarlo directamente como si se tratase de una matriz de bytes y escribir o leer de ella como con cualquier otro arreglo.

Bueno yo se que DirectDraw fue Deprecado y hasta la version de enero aun existia, lo remplazaron? que se usa ahora? respecto a lo de interfaz DirectDraw no es una interfaz. Tienes razon en lo del lock del buffer de pantalla pero realmente cuando haces esto es directX quien se encarga de enmascarar todo y realmente no estas accediendo directamente a la memoria de video sino que DX enmascara su uso de esta manera pero por debajo debe de igual manera pasar por la capa de abstraccion de hardware usando llamadas de bajo nivel en la API.


Bueno no te habia visto por aqui y aprovecho para decir que eres bienvenido, se ve que tienes buenos conocimientos del tema y nos pueds ser a todos de mucha ayuda.
[size=109]Juan Carlos Ruiz Pacheco
[/size]
Microsoft Technical Evangelist
@JuanKRuiz
http://juank.io

ibito

  • Miembro HIPER activo
  • ****
  • Mensajes: 552
  • Nacionalidad: mx
  • Se mas de C++ que lo que se de ese CSS
    • Ver Perfil
    • http://www.ibquezada.com
Re: Discusion:
« Respuesta #3 en: Jueves 16 de Junio de 2005, 16:26 »
0
Lo que yo si puedo afirmar, es que el double buffering si es mas lento, y mas aun con el uso de vsync. Tambien puedo decir que el double buffer no elimina por completo el flickering, esto se puede notar cuando estas moviendo imagenes grandes por la pantalla.
______________________________________
www.hazjuegos.com Una comunidad dedicada al desarrollo de videojuegos.

niofis

  • Nuevo Miembro
  • *
  • Mensajes: 9
    • Ver Perfil
Re: Discusion:
« Respuesta #4 en: Jueves 16 de Junio de 2005, 20:28 »
0
De vuelta con unos peqeños comentarios a tu post JuanK...

Citar

si es una animacion.. es el mismo principio pues al estar escribiendo pixeles directamente en pantalla se ve como se van pintando linea a linea.

Reitero sin intencion de molestar, la finalidad de este programa no es generar animaciones, y el ke se vea que se pintan linea por linea en pantalla es mas culpa del GDI+ pues está usando FillRectangle para pintar los puntos.

Citar
Estas seguro?, yo te puedo asegurar que no es asi, y menos en una aplicacion que corre en modo ventana.

Aqui si no entendi muy bien, pero lo que se me fiura que pensaste es que puedes sin ningun problema pasar del backbuffer al frontbuffer sin calculo alguno, simplemente indicando las coordenadas left/top origen-destino, utilizando  un BitBlt, DrawImage o un memcpy, pero eso no es razon de procesamiento extra. El problema es cuando hay que calcular las coordenadas de la entrada del mouse del usario, en el area de dibujo y convertirlos al origen, para luego pasarlo al backbuffer; lo cual es precisamente lo que digo que se está ahorrando.

Citar
Si lo fuiste y te reitero, la tecnica de double buffer ayuda a disminuir el efecto de flicker pero no lo elimina y en graficos grandes se sigue haciendo notorio.
Parece que estas muy confundido, el efecto de flicker no se genera por solo tener una animacion y no tiene nada que ver con los botones ni del teclado ni del mouse ni del joystick, dehecho puedes tarr dibujando siempre el mismo cuadro en pantalla y tendras el efecto de flicker sin necesidad de animarlo ni d relacionarlo con ningún botón ni cosa parecida.

Muy bien, el efecto de flicker es cuando es notorio tanto el barrido de la pantalla y/o el borrado y redibujado sobre el frontbuffer. Pero aqui al parecer el confundido eres tu, yo mencioné que el flickering en el area de dibujo en el programa de ibito se genera cuando presiona algun boton de panning, lo que hace que el dibujo dentro del area de pintado se mueve, ya se hacia arriba, abajo o los lados, y como hay un redibujado se ve el efecto de parpadeo.
Por otro lado, si no vas a mostrar animaciones (ni un solo cambio de texto, redibujado, etc.) no tiene caso utilizar el backbuffer. Pues no se necesita borrar la pantalla para redibujar en ella, a final de cuentas nada ha cambiado, por lo tanto si no hay animacion no hay redibujado(o no tiene porque haber) programado (solo el de hardware), y como no hay movimiento tampoco puede  notarse el barrido generado por el refresco vertical.

Citar
Bueno yo se que DirectDraw fue Deprecado y hasta la version de enero aun existia, lo remplazaron? que se usa ahora? respecto a lo de interfaz DirectDraw no es una interfaz. Tienes razon en lo del lock del buffer de pantalla pero realmente cuando haces esto es directX quien se encarga de enmascarar todo y realmente no estas accediendo directamente a la memoria de video sino que DX enmascara su uso de esta manera pero por debajo debe de igual manera pasar por la capa de abstraccion de hardware usando llamadas de bajo nivel en la API.
Aqui sí no te puedo dicutir mucho sobre la abstraccion de hardware, pero con el lock del buffer si se accede directamente a memoria, puesto que una vez hecho esto no se puede dibujar sobre este a travez de ninguna llamada a API(alto o bajo nivel), pues la unica forma de acceder al buffer blockeado es a travéz de punteros y funciones de memoria (memcpy,zeromemory, etc), hasta que al buffer se le haya quitado el lock, entonces ya se podrian utilizar funciones como PutPixel y otros. Tampoco estoy diciendo que no se pueda accesar a la memoria de video, pues esto es posible al indicar que tipo de memoria utilizara el backbuffer, al momento de ser creado.

Y... creo que ya nos salimos del tema...

Muy buen programa ibito, felicidades!


niofis

JuanK

  • Miembro de ORO
  • ******
  • Mensajes: 5393
  • Nacionalidad: co
    • Ver Perfil
    • http://juank.io
Re: Discusion:
« Respuesta #5 en: Jueves 16 de Junio de 2005, 20:54 »
0
Citar
Reitero sin intencion de molestar, la finalidad de este programa no es generar animaciones, y el ke se vea que se pintan linea por linea en pantalla es mas culpa del GDI+ pues está usando FillRectangle para pintar los puntos.

Nuevamente en desacuerdo, como cres que funciona el panit? adivina...con el gdi+ de hecho todo cuanto vez del sistema de ventanas de windows usa el GDI+ y nunca veraz que suceda eso, realmente es problema es la programacion.

Citar
Aqui si no entendi muy bien, pero lo que se me fiura que pensaste es que puedes sin ningun problema pasar del backbuffer al frontbuffer sin calculo alguno, simplemente indicando las coordenadas left/top origen-destino, utilizando un BitBlt, DrawImage o un memcpy, pero eso no es razon de procesamiento extra. El problema es cuando hay que calcular las coordenadas de la entrada del mouse del usario, en el area de dibujo y convertirlos al origen, para luego pasarlo al backbuffer; lo cual es precisamente lo que digo que se está ahorrando.

bueno es cierto que ahorra un tiempo pero es despreciable a cmabio del costo que implica pasar repetidamente por el DMA para enviar los datos a la memoria de video, ya que es mucho mas rapido hacer un solo viaje con un bloque de datos por DMA que hacer muchos viajes con pequeños segmentos.

Citar
Por otro lado, si no vas a mostrar animaciones (ni un solo cambio de texto, redibujado, etc.) no tiene caso utilizar el backbuffer. Pues no se necesita borrar la pantalla para redibujar en ella, a final de cuentas nada ha cambiado, por lo tanto si no hay animacion no hay redibujado(o no tiene porque haber) programado (solo el de hardware), y como no hay movimiento tampoco puede notarse el barrido generado por el refresco vertical.

Al usar backbuffer no se nceesita borarr la pantalla, solo se remplazan los datos que estan en ella y por otro lado el dibujar un circulo en un buffer y luego pasarlo a la pantalla no implica que se redibuje toda la pantalla sino solo el area donde esta el circulo.
Código: Text
  1.  pues la unica forma de acceder al buffer blockeado es a travéz de punteros y funciones de memoria (memcpy,zeromemory, etc),
  2.  

lo que pasa es que funciones como las que has mencionado, y de ehco cualquier operacion tenga o no tenga punteros... es hecha a travez de la api, el compilador convierte el codigo en llamados a la API que le autorizan o no una transaccion en memoria por ello cuando con un puntero vas por una locacion de memoira no asiganda te sale el mensaje de error del sistema (sea linux o windows) diciendo que hay una infraccion de acceso ya que es el propio sistema quien determina si se puede o no hacer algo en una locacion de memoria.
[size=109]Juan Carlos Ruiz Pacheco
[/size]
Microsoft Technical Evangelist
@JuanKRuiz
http://juank.io

niofis

  • Nuevo Miembro
  • *
  • Mensajes: 9
    • Ver Perfil
Re: Discusion:
« Respuesta #6 en: Viernes 17 de Junio de 2005, 00:25 »
0
Citar
Nuevamente en desacuerdo, como cres que funciona el panit? adivina...con el gdi+ de hecho todo cuanto vez del sistema de ventanas de windows usa el GDI+ y nunca veraz que suceda eso, realmente es problema es la programacion.

Así es, el paint (versiones nuevas) utiliza gdi+. Y tal como lo dices es "problema" de la programación, ya que al no estar utilizando las funciones de gdi+ para el dibujado, hace  mas lento las cosas al tener que utilizar un seudo-punto hecho con un fillrectangle con ancho y alto puestos a 1.

Citar
bueno es cierto que ahorra un tiempo pero es despreciable a cmabio del costo que implica pasar repetidamente por el DMA para enviar los datos a la memoria de video, ya que es mucho mas rapido hacer un solo viaje con un bloque de datos por DMA que hacer muchos viajes con pequeños segmentos.

En eso tienes razon, pero a final de cuentas, solo son unos cuantos puntos los que vas a transferir al frontbuffer, comparado a todo el tamaño del backbuffer en un solo bloque, incluso si tan solo transfieres un area determinada, por decir un círculo, de la manera que él lo hace solo transfiere los puntos del perímetro. De otra forma, si transfieres el cuadro donde está el círculo con un BitBlt te traes muchisimos puntos mas (una transferencia de memoria mas grande, que tal vez no supere la velocidad que hacer las transferencias individuales para cada uno de los puntos de la circunferencia); ahora bien podrias decir utilizar un TransparentBlt pero con eso tambien te puedes traer mas informacion que la necesaria.

Citar
Al usar backbuffer no se nceesita borarr la pantalla, solo se remplazan los datos que estan en ella y por otro lado el dibujar un circulo en un buffer y luego pasarlo a la pantalla no implica que se redibuje toda la pantalla sino solo el area donde esta el circulo.

No mencione que fuese necesario, borrar la pantalla para traerse el backbuffer. Pero al tratarse de graficos vectoriales, solo se dibuja la parte necesaria y obviamente hay que borrar el area de dibujo para redibujar, ya que si no los dibujos ke se encontraban ahi, kedarán sobrepuestos. Si se tratase de un programa con graficos tipo raster entonces no habria que borrar, simplemente sobreponer la parte cambiada o todo.

Citar
lo que pasa es que funciones como las que has mencionado, y de ehco cualquier operacion tenga o no tenga punteros... es hecha a travez de la api, el compilador convierte el codigo en llamados a la API que le autorizan o no una transaccion en memoria por ello cuando con un puntero vas por una locacion de memoira no asiganda te sale el mensaje de error del sistema (sea linux o windows) diciendo que hay una infraccion de acceso ya que es el propio sistema quien determina si se puede o no hacer algo en una locacion de memoria.

Creo que no me di a entender, cuando tu utilizas punteros para acceder a la memoria no pasas por ningún API ni el compilador lo convierte a llamadas de API. Te puedes dar cuenta de esto si desensamblas un código ejecutable, cuando hayas hecho un acceso a memoria verás algo como MOV eax,[eax] donde esta cargando al registro eax, la informacion a la que apunta el valor de eax, sin llamar a la API, pues no hay ningun CALL.
Con el block de memoria que te deja accesar el lock del backbuffer tu puedes hacer algo como esto:
Código: Text
  1.  
  2. int *video;
  3. //...
  4. video[100][100]=0;
  5. //...
  6.  
  7.  
Donde pondrás el pixel 100,100 en color negro, acceso directo al backbuffer (VRAM o RAM).
Lo que hacen los sistemas operativos, es monitorear el uso de la memoria de cada uno de los programas que están en ejecución, en ningún momento los programas le piden permiso a windows para leer o escribir en ram (aunque para reservar memoria si), eso no implica ke solo puedas leer o escribir en tu espacio de memoria, por ejemplo puedes obtener el puntero de una ventana ajena a tu sistema y hacer con ella muchas cosas. Hay espacios de memoria restringidos y es cuando el sistema operativo destruye el proceso que la esta tratando de acceder. InvalidMemmoryAddress error, el mas clasico es el (0x000000), por punteros nulos.

niofis


niofis

ibito

  • Miembro HIPER activo
  • ****
  • Mensajes: 552
  • Nacionalidad: mx
  • Se mas de C++ que lo que se de ese CSS
    • Ver Perfil
    • http://www.ibquezada.com
Re: Discusion:
« Respuesta #7 en: Sábado 18 de Junio de 2005, 01:56 »
0
Citar
QUOTE

Nuevamente en desacuerdo, como cres que funciona el panit? adivina...con el gdi+ de hecho todo cuanto vez del sistema de ventanas de windows usa el GDI+ y nunca veraz que suceda eso, realmente es problema es la programacion.


Así es, el paint (versiones nuevas) utiliza gdi+. Y tal como lo dices es "problema" de la programación, ya que al no estar utilizando las funciones de gdi+ para el dibujado, hace mas lento las cosas al tener que utilizar un seudo-punto hecho con un fillrectangle con ancho y alto puestos a 1.

QUOTE

bueno es cierto que ahorra un tiempo pero es despreciable a cmabio del costo que implica pasar repetidamente por el DMA para enviar los datos a la memoria de video, ya que es mucho mas rapido hacer un solo viaje con un bloque de datos por DMA que hacer muchos viajes con pequeños segmentos.


En eso tienes razon, pero a final de cuentas, solo son unos cuantos puntos los que vas a transferir al frontbuffer, comparado a todo el tamaño del backbuffer en un solo bloque, incluso si tan solo transfieres un area determinada, por decir un círculo, de la manera que él lo hace solo transfiere los puntos del perímetro. De otra forma, si transfieres el cuadro donde está el círculo con un BitBlt te traes muchisimos puntos mas (una transferencia de memoria mas grande, que tal vez no supere la velocidad que hacer las transferencias individuales para cada uno de los puntos de la circunferencia); ahora bien podrias decir utilizar un TransparentBlt pero con eso tambien te puedes traer mas informacion que la necesaria.

QUOTE

Al usar backbuffer no se nceesita borarr la pantalla, solo se remplazan los datos que estan en ella y por otro lado el dibujar un circulo en un buffer y luego pasarlo a la pantalla no implica que se redibuje toda la pantalla sino solo el area donde esta el circulo.


No mencione que fuese necesario, borrar la pantalla para traerse el backbuffer. Pero al tratarse de graficos vectoriales, solo se dibuja la parte necesaria y obviamente hay que borrar el area de dibujo para redibujar, ya que si no los dibujos ke se encontraban ahi, kedarán sobrepuestos. Si se tratase de un programa con graficos tipo raster entonces no habria que borrar, simplemente sobreponer la parte cambiada o todo.

QUOTE

lo que pasa es que funciones como las que has mencionado, y de ehco cualquier operacion tenga o no tenga punteros... es hecha a travez de la api, el compilador convierte el codigo en llamados a la API que le autorizan o no una transaccion en memoria por ello cuando con un puntero vas por una locacion de memoira no asiganda te sale el mensaje de error del sistema (sea linux o windows) diciendo que hay una infraccion de acceso ya que es el propio sistema quien determina si se puede o no hacer algo en una locacion de memoria.


Creo que no me di a entender, cuando tu utilizas punteros para acceder a la memoria no pasas por ningún API ni el compilador lo convierte a llamadas de API. Te puedes dar cuenta de esto si desensamblas un código ejecutable, cuando hayas hecho un acceso a memoria verás algo como MOV eax,[eax] donde esta cargando al registro eax, la informacion a la que apunta el valor de eax, sin llamar a la API, pues no hay ningun CALL.
Con el block de memoria que te deja accesar el lock del backbuffer tu puedes hacer algo como esto:
CODE

int *video;
//...
video[100][100]=0;
//...

Donde pondrás el pixel 100,100 en color negro, acceso directo al backbuffer (VRAM o RAM).
Lo que hacen los sistemas operativos, es monitorear el uso de la memoria de cada uno de los programas que están en ejecución, en ningún momento los programas le piden permiso a windows para leer o escribir en ram (aunque para reservar memoria si), eso no implica ke solo puedas leer o escribir en tu espacio de memoria, por ejemplo puedes obtener el puntero de una ventana ajena a tu sistema y hacer con ella muchas cosas. Hay espacios de memoria restringidos y es cuando el sistema operativo destruye el proceso que la esta tratando de acceder. InvalidMemmoryAddress error, el mas clasico es el (0x000000), por punteros nulos.

niofis



alguna duda?  :whistling:
______________________________________
www.hazjuegos.com Una comunidad dedicada al desarrollo de videojuegos.

JuanK

  • Miembro de ORO
  • ******
  • Mensajes: 5393
  • Nacionalidad: co
    • Ver Perfil
    • http://juank.io
Re: Discusion:
« Respuesta #8 en: Sábado 18 de Junio de 2005, 17:29 »
0
Por supuesto, pero no seguire discutiendo pues seria una discución sin fin y la verdad no me la paso todo el dia sin hacer nada y tengo que trabajar... :(

asi que decidi abandonar la converzacion, lo ideal que queria hacer era hacer un ejemplo yo mismo donde demostrara que lo que digo es cierto, pero lamentablemente ando muy mal de tiempo y tengo otros desarrollos muy urgentes por hacer. :huh:

Lo siento, si tengo tiempo en algunas semas hare lo de el ejemplo.. sino.. pues bien cada cual es libre de experimentar.
[size=109]Juan Carlos Ruiz Pacheco
[/size]
Microsoft Technical Evangelist
@JuanKRuiz
http://juank.io

ibito

  • Miembro HIPER activo
  • ****
  • Mensajes: 552
  • Nacionalidad: mx
  • Se mas de C++ que lo que se de ese CSS
    • Ver Perfil
    • http://www.ibquezada.com
Re: Discusion:
« Respuesta #9 en: Sábado 18 de Junio de 2005, 19:32 »
0
Cita de: "JuanK"
Por supuesto, pero no seguire discutiendo pues seria una discución sin fin y la verdad no me la paso todo el dia sin hacer nada y tengo que trabajar... :(

asi que decidi abandonar la converzacion, lo ideal que queria hacer era hacer un ejemplo yo mismo donde demostrara que lo que digo es cierto, pero lamentablemente ando muy mal de tiempo y tengo otros desarrollos muy urgentes por hacer. :huh:

Lo siento, si tengo tiempo en algunas semas hare lo de el ejemplo.. sino.. pues bien cada cual es libre de experimentar.
En realidad escribi "Alguna duda?" porque para ser sincero de todo lo que dijeron apenas entiendo un 30%... fueron muy tecnicos y yo no entendi del todo  :P
______________________________________
www.hazjuegos.com Una comunidad dedicada al desarrollo de videojuegos.