Antes de nada hola a todos. Tengo una pequeña pregunta que ha de ser fácil pero no paro de darle vueltas y no se cómo hacerlo. Vamos a ver. Estoy haciendo un pequeño juegecillo; al hacer el Flip desde el backbuffer espero al retrazo vertical con lo que (dependiendo del monitor) consigo aproximadamente unos 75 FPS. Hasta aki todo ok, pero me surge una duda. Con este refresco quiere decir que si creo una animación a 25 FPS, ésta podrá tener un desfase de +/- 1/75 FPS (unos 13 ms) ya que mientras estoy refrescando no estoy calculando posibles cambios en la animación. Entonces según veo, este problema se verá incrementado en ordenadores con refresco de monitor más bajo, pudiendo ocasionar que las animaciones no se ejecutaran a la misma velocidad en diversas mákinas.
Mi bucle principal del juego, en resumen sería:
- Controla entrada raton/teclado y varios
- Modifica estado juego
- Refresca
Claro, al ser lineal la ejecución pues mientras está refrescando NO puedo hacer otra cosa. Asi que, ¿Como se hace en los juegos de verdad? ¿Son dos procesos paralelos, uno encargado de modificar el estado del juego y otro de refrescar la pantalla? De ser así también tendríamos problemas, ya que podría refrescarse la pantalla ANTES de que terminara de actualizar el estado/posicion de los sprites.
Bueno, después de esta peaso parrafada no se si ha quedado claro el tema. A ver si me aclarais algo,... Venga, un saludo:
--plugin
No puedes resolver el problema utilizando el refresco, necesitas resolverlo por tiempos. Tienes que pensar no en pixels por frames, sino en cuantos pixels recorre en cuanto tiempo.
Si quieres que el personaje se desplace 2 pixels a la derecha, tu quizás uses esto:
X=X+2
Pero deberías hacer esto:
X=X+2*Timing
Porque ahora el tiempo tiene que formar parte de cualquier ecuación que implique movimiento!
Si quieres, échale un vistazo a mi motor en
http://webs.ono.com/dracularAhí está implementada esta técnica con los ejemplos muy documentados.
Hi.
En mi opinión (y seguro que muchos estan de acuerdo conmigo) lo mejor es no depender del retrazo vertical.
Lo que se hace es escalar el movimiento en función del tiempo transcurrido entre el último frame y el actual.
Esto se hace almacenando el momento en el que se renderiza el frame actual, entonces cuando vayas a renderizar el próximo frame, restas el momento actual y el del frame anterior, y con ese tiempo (tiempo transcurrido entre el último y el actual frame), puedes resolver la ecuación
Espacio = Velocidad / Tiempo
(esto si no hay aceleración claro :sonriendo: )
Y asi escalas el movimiento.
Para el caso concreto de las animaciones por frames, no lo se cierto, pero supongo que habrá que esperar a que pase un determinado tiempo para pasar al frame siguiente. Asi que se debe almacenar el momento en el que se pasó de frame en la animación, y en cada frame (de renderizado) mirar si ha pasado el tiempo necesario para pasar al siguiente frame de animacion (Tiempo = 1000 / FPS_de_la_animación (esto en milisegundos)).
Espero haberme explicado con claridad, si no lo he hecho, dimelo e intentare repetir con mas claridad lo que no te haya quedado claro.
Saludos.
Correcto. Con lo del desplazamiento estoy de acuerdo. Pero no tanto con el cambio de los sprites. Es decir (a ver si me explico), si baja la velocidad es posible que se pierdan frames y a lo mejor hay suficiente velocidad para mostrarlos todos. Supongamos una animacion a 25 FPS y que en ese ordenador el refresco de la pantalla es 60 Hz (FPS). Asi que la animacion podría actualizarse cada 1/25+1/60 segundos, con lo que se visualizaria a 17 FPS (en el peor de los casos). No se, a lo mejor me estoy haciendo un lio.
Yo ahora mismo el problema que tu solucionas con x=x+Y*timming yo lo hago así:
- Calculo posicion personaje
- ¿Ha pasado el tiempo necesario para actualizar posicion?
- SI -> Actualizo posicion
Claro está que si el ordenador es muy lento pues con este método la nimacion NO saltaría frames e iria muy lenta. Por otro lado es para animar un personaje (Que tampoco necesito mucha velocidad). Por eso comente lo de si se solía hacer en varios procesos. Puedo implementar uno que se dedique a actualizar posiciones y otro que refresque cada cierto tiempo. Mi idea es aprovechar de alguna manera el tiempo que se tarda en dibujar la pantalla.
Pos bueno, muchas gracias por la respuesta. Saludos!!
--plugin
El problema del personaje es exactamente igual. Imagínate que tienes una animación de 30 fotogramas que tiene que durar 1 segundo a tu gusto.
Entonces, calculas el fotograma actual dependiendo del tiempo en el que estés respecto a 1 segundo. Si el ordenador es más lento, verás menos fotogramas, pero cuando haya pasado un segundo, verás el último fotograma, que es lo que quieres. Si es más rápido, verás el mismo fotograma unas cuantas veces, pero eso no afecta negativamente visualmente!
[Contestando a NeLo]
Joder, que rápidez con las respuestas, jeje. Si, te explicas bien pero en el cambio de sprites yo sigo viendo el problema. Si hago lo que dices (y es lo que hago) puede ser que no se anime EXACTAMENTE los aprites. Verás, a ver si me explico:
- Supongamos que pinte el ultimo sprite en un tiempo X. Entonces el siguiente frame ha de pintarse en (por ejemplo) X+15ms
- Cuando voy a pintar de nuevo el frame pregunto ¿ha pasado ya el tiempo necesario? Entonces, si por ejemplo vamos por el tiempo X+14 pues la respuesta es NO, con lo que no se actualiza el frame.
- A continuacion se refresca la pantalla, que tarda (otra suposicion) 5 ms.
- A la siguiente vez pregunto ¿ha pasado ya el tiempo para cambiar de frame? La respuesta es SI. Pero claro, ya vamos por el tiempo X+14+5=X+19. Con lo que la animacion no es EXACTA (bueno, es que soy mu quisquilloso, jeje)
Pudiera ser que pasando de esperar al refresco ganara velocidad y el desfase fuera mínimo, no se... Gracias de nuevo
--plugin
Bueno, lo que te han dicho es mas o menos lo que yo mismo te explicaria. Para mi motor (CrisolEngine /
http://usuarios.lycos.es/crisolengine) estoy utilizando un esquema que NO hace uso del retrazado vertical. Lo que vengo a hacer es dibujar siempre que pueda y solo cuando han pasado x milisegundos actualizar la IA (ejecuto las solicitudes de eventos scripts que hayan sucedido) y la entrada.
Con el tema del movimiento y la animacion, que es lo que te interesa a ti, ya es otro cantar pues no podemos esperar nada de tiempo, ha de ejecutarse lo mas rapido posible para que tengamos unas secuencias suave. Para lograr eso, utilizo interpolacion lineal que viene a ser lo que te han explicado antes.
Me resulto de mucha ayuda el post que puso Javier Arevalo en Flipcode:
http://www.flipcode.com/cgi-bin/msg.cgi?sh...orum=totd&id=-1Echale un vistazo pues no tiene desperdicio y puede que te resuelva todas tus dudas.
Un saludo.
Fer.
Hola Frodrig,
He estado viendo el post de Arevalo, pero tiene un problema, y es que la resolucion que tiene la funcion del getTickCount es muy pequeña, para eso vendria mejor usar el QueryPerformance, que puede tener un margen de error de 1 microsegundo, mientras que el getTickCount tiene una precision de 1 milisegundo...
Eso se traduce en que aunque consiguieras mantener una medida de tiempo aceptable en tu maquina, tal vez la medida de tiempo no sea igual en otra maquina mas veloz o mas lenta...
Hay, ademas, una formula mas efectiva que las expuestas, aunque la pondre esta noche, que ahora mismo estoy en el curro y no quiero que me trinquen dandole gustillo al teclado...
Saludos
Hola plugin:
Pues yo me encontre con el mismo problema que tu hace unos dias.
La solucion ( a mi parecer ) es muy parecida a la que por aqui han dicho.
Supongo que te referiras a cada frame de la animacion con un indice, no? Supongo tambien que utilizaras un dato de tipo int.
Lo que yo hago es tener ese indice como un float. Si por ejemplo quieres que la animacion se mueva a un frame por segundo haces esto:
graph += 1.0f * deltaTime;
Y a la hora de pintarlo, lo tratas como un int:
draw( ( int )graph );
A mi con eso se me ha solucionado. Tenemos que con esto, para hacer 4 frames por segundo seria:
graph += 0.25f * deltaTime;
Y asi sucesivamente :sonriendo:
Espero haberte sido de ayuda.
Un saludo!!
< MChiz >
jeje, hola de nuevo
Acabo de ver el post de Emotion y tiene toda la razon. Las funciones QueryPerformanceCounter y QueryPerformanceFrequency son muchisimo mas precisas que GetTickCount. Pero debes comprobar que el hardware en el que correra tu juego soporta estos contadores ( son por hardware ). Si no los soportas, deberas buscar alternativas. Yo te recomiendo la funcion timeGetTime(), que CREO que es mejor que la GetTickCount() ( no estoy seguro ). Esta en la libreria de Windows "winmm.lib" y en el header "mmsystem.h".
Saludos y suerte!! :sonriendo:
< MChiz >
Citar
- Supongamos que pinte el ultimo sprite en un tiempo X. Entonces el siguiente frame ha de pintarse en (por ejemplo) X+15ms
- Cuando voy a pintar de nuevo el frame pregunto ¿ha pasado ya el tiempo necesario? Entonces, si por ejemplo vamos por el tiempo X+14 pues la respuesta es NO, con lo que no se actualiza el frame.
- A continuacion se refresca la pantalla, que tarda (otra suposicion) 5 ms.
- A la siguiente vez pregunto ¿ha pasado ya el tiempo para cambiar de frame? La respuesta es SI. Pero claro, ya vamos por el tiempo X+14+5=X+19. Con lo que la animacion no es EXACTA (bueno, es que soy mu quisquilloso, jeje)
Creo que ahi no puedes hacer nada, si el PC solo puede mostrar un frame cada 5 milesimas, no pretendas apurar en una animacion de 1 frame cada 6 milesimas (por ejemplo). Ese problema pasará siempre (siempre que no uses V-Sync, que es lo mejor, no usarlo), lo único que se podría hacer en el caso de los sprites, es hacer una animación lo mas suave posible, es decir, con el mayor número de frames por segundo posible.
Byez.
Cierto, cierto, yo tambien uso QueryPerformanceCounter. Supongo que Arevalo lo pondria mas que nada por motivos didacticos pero si es completamente verdad lo que comentais, hay que usar este temporizador.
Saludos.
Fer.
Lo del QueryPerformanceCounter no soportado por hardware olvidaros. Que yo sepa esa función utiliza internamente la instrucción ensamblador RDTSC, que mide el número de ciclos de procesador transcurridos desde el último reset.
Esta instrucción (muy utilizada hace tiempo para medir el número de ciclos por segundo de rutinas críticas) esta presente desde el Pentium, así que a no ser de que queráis dar soporte a los 486... :sonriendo:
Pues nada. Algo me he aclarado. Voy a darle vueltas a la cabeza a ver que saco en conclusión. Con respecto al contados, SI. Si ya nos ponemos a hacerlo exacto habra que utilizar el contador de alta precision en vez de timeGetTime() o algo así.
Bueno, a ver que hago al final.... Ya veremos a ver que nos cuenta Emotion, y la conclusion que saco de todo esto.
Gracias por toas las respuesta (joe y es mi primer post!!) . Thankx
--plugin
Saludos
Una cosa, has comentado que esperas al retrazado vertical y luego haces Flip. Usas el WaitForVerticalBlank? Si es asi quitalo, ya que el Flip ya lo hace por defecto :ojo:
SOBRE GetTickCount()
--------------------
Yo uso: timeGetTime(), que tiene más resolución. Échale un vistacillo.
Perfecto, el articulo que comentó Frodrig resuelve todas mis dudas (o al menos funciona bastante bien, jeje). La idea es bastante buena y soluciona los problemas que yo comentaba, asegurando un framerate medio constante. Así que animo a todos los que os interese este tema y no lo hayais leido, que lo hagais (idea simple pero funciona bien).
Pues nada, perfecto. Todo solucionado. Muchiiiisimas gracias por las respuestas (todavía estoy intrigado por la solución que comentaba Emotion iba a poner). Saludos
-plugin
Paciencia es la madre de la ciencia... aun estoy terminando de escribir el .txt que voy a postear... yo lo que prometo lo cumplo...
jejeje. Pues nada.... Paciencia tendré. Aunque lo que he implementado ya furula a la perfección (o al menos visualmente no aprecio ningún fallo). Pero el saber no está de más, así que nada, lo que tu dices, tendré paciencia....
Saludos
--plugin
Bueno, pues tal y como prometi aqui esta mi metodo, aunque no quiero que nadie se haga ilusiones, ya que posiblemente mi metodo se sale un poco del tiesto, es decir, mi metodo enfoca una amplia variedad de animaciones o efectos y posiblemente solo querais usarlo para mover unos cuantos objetos con traslaciones normales, etc...
Veamos... yo no estoy a favor de usar, como lei un poco mas arriba, la escala de tiempo en el movimiento de un vertice o modelo completo, ya que para poder tener garantias de que ese metodo funcione, ha de funcionar igual en todas las maquinas, y eso es MUCHO pedir (o suponer, segun sea el caso...). Eso esta bien para los programas de render tipo 3D Studio MAX, Maya, Softimage, Power Animator, etc. donde el objetivo final no es producir secuencias en tiempo real, sino secuencias CG, y como todo el trabajo lo hacen por software (al menos en la parte de control de tiempos), pues pueden tranquilamente confiar en la escala de movimiento por tiempo. Como creo que quieres usarlo para juegos, es mejor que no te decantes por el, ya que puede que no notes tirones o efectos extraños, pero ten en cuenta lo siguiente: pongamos que el metodo que utilizas de escala de tiempo, debido a la precision numerica de la/s variable/s que escojas tiene en total un margen de error de, pongamos por caso, un 15% (es mucho, ya lo se, pero tan solo es un ejemplo...). Eso significa que de cada 100 frames que renderices, en 15 de ellos el movimiento es 'extraño', ya que tus personajes o se mueven mas lentos o mas rapidos de lo normal (para un ojo no excesivamente observador puede pasar por alto, pero para ti o cualquier programador grafico o simplemente un entusiasta de los graficos 3D y la animacion en general, puedes estar seguro que NO va a ser asi...). Este efecto no puede ser evitado actualmente ya que no existe un standard en lo que a render por hardware se refiere (esta claro que estamos en mitad de una guerra por la rotura de las barreras del realismo grafico, pero cada compañia intenta asentar sus propias bases, con lo cual siempre estaremos (o al menos mientras dure todo esto) en mitad del meollo sin poder comprometernos con nadie... y ejemplos hay, como INTEL y AMD, NVIDIA y ATI, y asi sucesivamente...)
Bueno, pero al caso que estamos tratando, y siempre desde mi punto de vista, hay 2 maneras de controlar el flujo de animacion en un juego (o software grafico):
A. escala de tiempo (el metodo del que acabo de hablar)
B. control de tiempo consumido (el metodo del que hablare a continuacion)
Mirad, yo personalmente preferiria el primer metodo, ya que es mas facil y da muy buenos resultados, pero actualmente prefiero usar el segundo ya que me ofrece una alternativa de control mas o menos fiable y con un margen de error bastante mas pequeño que el primer metodo, aunque es mucho mas dificil de implementar, ya que implica diseñar el motor grafico casi desde cero (hay que meterle mano a casi todo el codigo).
El metodo, desde una perspectiva tecnica, es bastante sencillo, pues se basa simplemente en ir tomando una medida del tiempo que consume una u otra funcion del motor en ejecucion, es decir, mi metodo se basa en una tecnica de profiling (igual que el metodo usado por herramientas de debugging y profiling, caso del VTUNE, el SoftICE, etc...)
Este metodo contempla 2 fases en su ejecucion
A. analisis de tiempos (profiling)
B. ajuste de tiempo de ejecucion por ciclo de animacion/ejecucion (es variable, depende de lo que queramos hacer...)
la fase A implica el uso la instruccion RDTSC (ahora hablare de el) o el uso de funciones como QueryPerformanceCounter, timeGetTime o incluso getTickCount (si bien esta ultima es la menos precisa de las tres anteriores, pero tambien sirve para nuestros propositos, si bien no hablare de ella aqui, ni siquiera de las otras, mi metodo se basa en el uso de la instruccion RDTSC, la mas fiable de todas), para saber el numero de ciclos de reloj que consume la ejecucion de una cierta funcion.
Esto es importante, ya que nos interesa saber cuantos ciclos de reloj puede generar un determinado procesador para saber cuantos ciclos de reloj se pueden usar para calcular toda la informacion en 1 fotograma de animacion (y no solo considerando la parte grafica, tambien el sonido, la respuesta del joystick/teclado/raton/pad/etc.. y el juego en red) y a partir de ahi, saber si sobran ciclos de reloj, ya que de no ser asi, pues simplemente pasara lo de siempre (en algunos juegos con ciertas maquinas), es decir, dara tirones, pero si no es asi, podremos saber de forma efectiva cuantos ciclos extras podemos emplear en reprocesar ciertos calculos o añadir mas efectos visuales o auditivos para optimizar y mejorar mucho mas nuestro juego o aplicacion multimedia en general.
el procedimiento usual para medir el tiempo de una funcion seria el siguiente:
1. ejecutamos la instruccion RDTSC
2. almacenamos el valor del TSC en una variable
3. ejecutamos la funcion que queramos (p.ej: renderer->render())
4. volvemos a ejecutar la instruccion RDTSC
5. almacenamos el valor del TSC en otra variable
6. computamos el tiempo invertido, teniendo en cuenta que el computo es el siguiente: (TSC2-TSC1)-1xRDTSC-ElapsedTime(F(t))
*el tiempo invertido en ejecutar la instruccion RDTSC 1 vez (al final) mas 2 veces el tiempo para almacenar el TSC en las variables de contencion y ademas hay que quitar el tiempo empleado en el calculo del tiempo (TSC2-TSC1), en este caso una simple resta, a no ser que queramos añadir algun criterio de comparacion para un mayor control sobre ciertas funciones que hagan uso de ciertos recursos de la CPU o el sistema en general
Bien, ahora la primera pregunta... porque no usar simplemente TSC2-TSC1 para calcular el tiempo invertido en ejecutar la funcion? pues, sencillamente, por que NO es el verdadero tiempo de ejecucion, ya que el tiempo invertido en hacer los calculos de tiempo tambien cuentan, por eso hay que 'limpiarlos' del computo final. De esa manera nos queda el tiempo 'justo' empleado por la funcion que queramos medir... y digo justo porque al final hay que hacer un matiz sobre esto (lo definire como MATIZ1)
Bien, una vez explicado el primer punto de mi exposicion (era el mas dificil y como veis, tampoco ha sido tanto) vamos con el segundo y ultimo punto, que es el ajuste de tiempo
la fase B implica el diseño y posterior uso (si se desea, ya que este paso es puramente opcional, pero añade el 'punto' que le falta a la fase A para ser, literalmente, un metodo completo) de una funcion de delay(), que algunos tacharan como anticuada o algo asi (se suelen usar metodos mas sofisticados), pero que viene de perlas cuando no quieres procesar mas datos en lo que resta de fotograma, y de manera normal, pues hay que 'chuparse el dedo' y dejar que el mismo motor induzca a que la animacion sea demasiado rapida (o lenta... como ya dije, al no haber un standard pueden suceder muchas cosas, aunque esto qeu digo ya lo habreis comprobado por vosotros mismos...)
Y como hacerlo? pues hay varios metodos, pero el mas facil aunque no el mas (aparentemente) directo es recurrir a la deteccion de la velocidad del micro (paso 1) y luego acuñar la informacion obtenida en un registro para su posterior uso (paso 2).
luego definimos 2 pasos basicos para hacer que este metodo funciones:
A. medida de tiempo de proceso del microprocesador (o, simplemente, medida de frecuencia)
B. creacion funcion delay()
la fase A implica, en este caso (aunque anteriormente dije que no iba usarla) el uso de la funcion QueryPerformanceFrequency(), la cual nos da de forma aproximada la velocidad del microprocesador en MHz, si bien este valor nos lo da en forma real y nosotros debemos pasarla a forma entera
Una vez hallada la velocidad de trabajo del microprocesador, simplemente hay que hacer un calculo, que es simplemente:
Nc=V·1000000
es decir, Nc (numero de ciclos) queda representado por la velocidad por 1 millon (esto es facil de entender), de forma que al final nos queda el numero de ciclos que podemos usar en 1 segundo, pero para refinar mas aun el calculo hemos de dividir eso entre el numero de frames por segundo que deseamos mantener en la aplicacion, es decir, el computo final quedaria asi:
Nc/F=1000000·V/Nf
donde usamos las siguientes variables:
Nc/F = numero de ciclos/frame. ESTE es el valor que nos interesa
V = velocidad de proceso (en MHz) del microprocesador
Nf = numero de frames, es decir, cuantos frames queremos en un segundo (tipicamente 25/30/50/60, pero evidentemente puede ser mas, mucho mas... :riendo:)
Pues bien, para que sirve todo esto que he dicho? para una cosa muy simple... cada vez que ejecutais una funcion en vuestro motor de juegos, ejecutais el profiling y vais restando el valor obtenido a la variable Nc/F. De esta forma siempre sabreis el numero de ciclos que os sobran (u os faltan) por cada fotograma. Si os sobran, usad un delay() (que explicare a continuacion) o usadlos para computar mas efectos u optimizar procesos dentro de vuestro motor.
la fase B implica el diseño de una funcion para poner al microprocesador en IDLE durante el periodo de tiempo que le especifiquemos. Normalmente suele haber por defecto en C/C++ una funcion delay() cuya precision viene dada en milisegundos, una medida que, en mi opinion, es bastante corta para ciertos propositos. metodos como el QueryPerformance<...> son muy buenos, ya que tienen una precision de 1 microsegundo.
una funcion ideal seria la siguiente:
void delay(unsigned long ns)
{
for (long i=0;i {
__asm nop
}
}
pero esta funcion no tendria ni de lejos una precision de nanosegundos (que seria lo ideal). Cual es el problema? pues muy sencillo... como hay microprocesadores con diferentes velocidades, en cada microprocesador una sola instruccion no empleara el mismo tiempo en ejecutarse, con lo que el mismo microprocesador nos obliga a optimizar el codigo para que el ajuste de tiempo sea lo mas preciso posible. Por esa razon dije que mi metodo tiene un margen de error muchisimo menor, sin embargo no esta exento de el. Nada es perfecto...
La funcion que yo utilizo por ahora es la siguiente:
void delay(unsigned long dc)
{
__asm cli;
__asm mov ecx,dc;
__asm nop;
__asm rep movsb;
__asm sti;
}
Hay funciones mucho mejores para hacer delay de alta resolucion (estoy seguro de ello...), aunque no puedo ayudaros mucho al respecto, ya que cada uno implementa su propio metodo para hacerlo (no existe solo un camino...)
Y es todo lo que por ahora se me ocurre. Tengo la sensacion que me dejo algo en el tintero. Si notais que falta algo, dadme un toque e intentare completarlo (o corregirlo)
MATIZ 1
la funcion para calcular el tiempo de ejecucion de una funcion es bastante preciso, PERO (y siempre hay un pero), tiene un efecto secundario... y es que esta sujeto a posibles ciclos extra empleados por el micro para alinear datos en la cache, sincronizar transferencias de memoria, ciclos de autocomprobacion, etc. es decir, que este computo es un tanto ideal, luego en la practica pierde un poco de precision por el hecho de que el sistema a veces te juega malas pasadas por eso...
Saludos
_________________
Julio Meca
ALPHA SOFTWARE
[ Este Mensaje fue editado por: Emotion el 2002-04-22 11:39 ]
Sinceramente, me parece un método completamente enrevesado :sonriendo:
Es decir, hacer un profiling manual en TODAS las funciones me parece muy muy muy bestia para lo poco que pretendes obtener (y mal a mi modo de ver).
Primero de todo, porque no tienes en cuenta en absoluto a la tarjeta gráfica (la cpu puede estar "necesitada" de datos aún corriendo el juego a 2fps, por problema de fillrate por ejemplo). ¿Es significa que la CPU esta procesando una burrada de datos con respecto a lo que debería? no.
Básicamente tu sistema solo sería "útil" cuando procesamos -CPU- menos datos de los que deberíamos. Pero eso no significa ni mucho menos que vayamos sobrados (por lo que comenté antes, la aceleradora también existe). Y si encima fuerzas un delay() despues de eso, ya la cagamos :sonriendo:
Y en caso de que una tarjeta pueda pasar por ejemplo la barrera de los 50fps ¿para que detenerla? para eso están.
Sobre la pérdida de precisión, es una exageración el ejemplo que comentas. No por el 15%, que como dijiste era ilustrativo, sino porque el error es ínfimo (inapreciable). Si hubiese algún problema, sería en el caso de que el márgen de error fuese muy grande, y el método utilizado propenso a aumentar dicho error. Por ejemplo, usando un incremental de tiempo:
tiempo += tiempoframe;
en el que sucesivamente se va añadiendo tiempo a una variable, en vez de tomar el valor absoluto de nuestro timer.
Si tantas esperanzas tienes en este método, me gustaría ver algún test tuyo en el que realmente se vea la diferencia de calidad entre un sistema y otro. Pero realmente creo que no lo has probado o al menos no a fondo :sonriendo:
Un saludo.
Hola Ithaqua,
Bueno, pues en parte tienes razon, en parte, desde mi punto de vista, no (y no por tu planteamiento, que es ABSOLUTAMENTE correcto, sino por mi manera de ver mi motor de desarrollo).
Veras, mi metodo no debe seguirse a la ligera, ya que hay que saber utilizarlo, ya que si no se produce lo que tu dices, un desperdicio casi total de la CPU, pero como metodo de profiling es muy bueno y te permite ver mas o menos por donde estas tirando ciclos de reloj que luego te pueden venir bien. En mi motor de desarrollo esta esa opcion, pero incluso habiendola, la opcion es... remota (utilizo un sistema de depuracion a 2 maquinas, ya hablare de ello en alguna ocasion). lo que SI utilizo ahora mismo, es ese metodo, pero hago la primera medicion al principio del fotograma y la ultima medicion al final. Asi pierdo algo de precision en la medida por lo que dije del alineamiento (y como dejo pasar muchas funciones, el margen de error se vuelve mas grande), pero me permite saber cuantos ciclos me sobran... No obstante, es como he dicho, solo es una medida. Yo en cuanto hago un .exe, en el bucle lo quito de en medio, a no ser que quiera depurarlo luego...
Sin embargo, o al menos minimamente estaras deacuerdo conmigo en que escalar el movimiento de vertices atendiendo a un criterio tan simple como el de 'scale=1/timebase' y aplicarlo a todo es una locura, ya que la diferencia de velocidad entre maquinas echa a perder el metodo en una bateria de pruebas. Esta bien para experimentar, pero creo que como una manera de programar juegos con salida economica pues... como que lo veo un poco... digamoslo asi... impreciso :sonriendo:
En cuanto a lo de probarlo, pues tienes razon... no lo he probado del todo, aun estoy analizando un modelo mas de analisis de tiempos... en fin... arduo y a veces creo que inapreciable trabajo... pero si quiero hacer un motor de desarrollo de alto rendimiento, hay que pringar... :triste:
En cuanto a lo de detener la animacion mas alla de los 50/60 frames, es por simplicidad... veamos... para que quieres mas de, pongamos por ejemplo, 100 frames por segundo (o 50) si, a nivel del cerebro, no puedes percibir mas de 18 frames? el cerebro procesa señales a 18Hz, nada mas... es cierto que el movimiento se aprecia mas suave, pero aun asi no me propongo llevar mi motor hacia la barrera de los 120 frames o mas... ni mucho menos... tengo mis razones, y ya se que parecen un poco... estupidas (para que vamos a negarlo), pero cuando pueda lanzar el motor entero con sus herramientas y todo, entonces entenderas porque lo hago... :sonriendo:
Un Saludo
Joder!! Perdonar mi expresión y, quizás mi ignorancia, pero me ha parecido una pasada tu respuesta... Creia que ibas a proponer una mejora al tipico bucle de juego y lo que predicas es un gran trabajo extra que para mi caso creo no me vale mucho (creo). Estoy haciendo un engine para aventuras gráficas (de ahi la otra pregunta). Las animaciones de los personajes no son muy complejas (no es una aventura en plan serio) y tienen de media unos 10 frames reproduciendose a 12 FPS. Tal y como esta ahora implementado es siguiendo mas o menos lo expuesto por JAvier Arevalo en el articulo que se hacia mencion unos post mas arriba. Pues con dicha implementación y esa calidad de animaciones me parece bastante bueno el método. Ahora bien, si lo que tu comentas es para un motor en 3d, la cosa seguramente cambiaría...... Cuando termine este engine pasaré a experimentar con las 3d y quizás las cosas cambien.
Pues nada, aún así agradezco las respuestas, nunca se sabe cuando puedes utilizar los conocimientos que aprendes en este mundillo. Saludos
--plugin
Para plugin:
El metodo que explique no es solo para 3D sino para 2D tambien, lo que pasa es que es mucho codigo, en eso SI que te doy la razon, sin embargo, hoy en dia, que un codigo pese mucho no significa que sea muy lento... tal vez para producir no mas de 12 frames no te venga bien darte la paliza de programar, pero si quieres conseguir mas, en el orden de entre, digamos... 30 y 120... pues te viene bien intentarlo, ya que te permitira suavizar mucho las animaciones, al precio, eso si, de perder algunos ciclos de reloj en comprobaciones.
De cualquier manera, si el metodo que utilizas te va bien, no te merece la pena complicarte con el mio, ya que mi motor tiene soporte para multiprocesador a traves de multithreading, planos multiples de render, listas de objetos, cache dinamica/estatica.. y ahi SI que viene bien implementar el metodo...
Por cierto, ya que mencionas el texto de Arevalo, he aqui una razon por la cual decidi escribir la gran parrafada de antes:
(extraido de la ultima parte del post)
"in the range 20-60 frames per second (fingers crossed)", que traducido literalmente del inglispitinglis es "en el rango de 20-60 FPS (crucemos los dedos)"
Crucemos los dedos?? si su metodo es asi, tal y como dije, te funcionara bien a ti, pero si lo pruebas en otra maquina, ya veras.... o mas rapido o mas lento, pero no lo podras controlar... :riendo:
Saludos
_________________
Julio Meca
ALPHA SOFTWARE
[ Este Mensaje fue editado por: Emotion el 2002-04-22 20:39 ]
Para Ithaqua:
--Y en caso de que una tarjeta pueda pasar --por ejemplo la barrera de los 50fps ¿para --que detenerla? para eso están.
Respecto a la frase que comentas, creo que sí, las targetas estan para eso, pero como comenta Emotion el cerebro no és capaz de percibir más de 25 cuadros por segundo, más o menos (aunque a más cuadros más suavidad).
El inconveniente que le veo és que si podemos ejecutar el quake 3 a 200 FPS hay muchos cuadros que no llegarán a verse, por tanto hemos echo calculos innecesarios cuyo tiempo se podria haber dedicado a otras cosas como iluminación...
hasta luego.
Sobre la frase de los 18fps/25fps o cuanto queráis. Esa frase la he leido mil veces y la gente la interpreta mal. NO significa que no notemos diferencia entre 25 y p.ej. 60 frames por segundo (que lo notaremos, cualquiera puede comprobarlo). Significa que el cerebro humano no puede distinguir cuando se 'cambia' de imágen, que no tiene nada que ver en este caso.
Si hablamos de suavidad, hablemos de que el cerebro humano es capaz de ver más suave y fluida una imágen de 60 frames por segundo, que una de 30.
Sobre lo que dices Emotion, de usar un valor de tiempo para parametrizar movimientos. Esta clarísimo que este método no va a funcionar al mismo framerate en todas las máquinas. ¿Es eso malo? en absoluto! es JUSTO lo que buscamos.
Si tu tienes un buen sistema de animación, en el que puedes interpolar movimientos -y NO te basas en que tu animación tienes 30 frames, ni uno mas, ni uno menos- Puedes hacer que esa animación corra a 50 frames por segundo en una máquina que dé de sí, y 10 frames por segundo en una máquina que no.
¿Cual es la diferencia? Que en una va mas suave y en otra mas escalonada. ¿Hay diferencia de rapidez? NO, ¿Hay diferencia de suavidad? SI. ¿Se desperdicia tiempo? No.
Tu ejemplo de movimiento += k*inctiempo indica precisamente eso.
Dados un t inicial y un t final, ambas máquinas van a dibujar el movimiento con la misma rapidez (pongamos, una animación que dura 10 segundos). ¿Que diferencia hay entre una máquina potente y una lenta? Que la máquina lenta a lo mejor puede dibujar 20 frames en esos 10 segundos, y la máquina potente puede dibujar 2000. La animación de la máquina potente se verá mas suave, pero ambas ejecutarán el movimiento en esos 10 segundos con la misma rapidez.
Eso sí, no puedes pretender utilizar este método y luego usar animaciones o movimientos que no permitan interpolación. O al menos que no se puedan evaluar para un tiempo dado, porque no te va a servir de nada. Pero eso no será problema del timing, será problema de que tu sistema de animación es malo :sonriendo:
Saludos.
Buenas! menudo lio que se está organizando...
Emotion, lo que tu haces es simplemente algo para monitorizar el rendimiento de un bloque de código, por cierto échale un ojo a este link:
http://cedar.intel.com/software/idap/media...df/rdtscpm1.pdfexplica tu sistema con mas detalle, aunque se puede resumir en mirar el TSC al principio y al final del bloque y restarlos, y convertir el valor en ciclos en algo mas util como milisegundos. De todas son un poco pijos si de lo que se trata es de medir el tiempo que tarda en ejecutarse algo que tardará mucho mas que leer y restar el TSC.
Por otra parte si lo usas para medir lo que tarda en ejecutarse un frame, para eso te valia con el timeGetTime (salvo que vayas a mas de 1000 FPS :lengua: por cierto eso es en win98, en el win2k la precision no tiene porque ser de 1 ms, hay que usar timebeginperiod y timeendperiod por si acaso) de todas formas tu sistema de limitar a 50 FPS y desperdiciar el resto es muy válido, aunque yo no lo usaría ni loco, prefiero que vaya lo mas suave posible, y aquí habria que aclarar otra cosa.
Se está hablando de que no se reconoce mas de 25 FPS (bueno emotion, en tu caso 18, lo siento pero deberías hacertelo mirar... de verdad no distingues mas de 18 fps? :lengua: tonterias aparte, lo de los 20~25 FPS es para tener la sensación de movimiento continuo en vez de imágenes sueltas... pero claro que se nota la diferencia entre 30 y 60 FPS por ejemplo, y se nota bastante.
Estoy completamente de acuerdo con Ithaqua, a ver... el hecho de que vaya a FPS variable no significa que una animacion de 10 segundos termine antes en un ordenador rapido, significa que hay mas interpolaciones entre los frames de la animación para que se vea mas suave. Por otra parte actualmente no sirve de mucho medir lo que dura el render porque la aceleradora hará las cosas cuando pueda, por decirlo de alguna manera.
Una cosa importante Emotion, el delay ese que usa el rep movsb, adonde apuntan ds:esi y es:edi? miratelo bien porque podrías estar machacando la memoria aleatoriamente...
Bueno, en cualquier caso, Emotion... "motor de alto rendimiento?" :loco: espero que de verdad sepas lo que estas haciendo, ya escribirás un "postmortem" explicando lo que fue bien... y lo que fue mal... :ojo: suerte!
saludos
Para mallrat:
Gracias por el .pdf de INTEL :sonriendo: la verdad es que el metodo que yo uso es exactamente igual, aunque ellos ponen un monton de instrucciones...
De cualquier manera, y como dije justo en el anterior reply, solo uso el profiling para ver cuanto tarda la funcion en ejecutarse, aunque como dije eso depende de que no haya en ese momento datos para alinear en la cache, ciclos de saturacion en la via de multiejecucion (vias U y V) y alguna que otra cosa mas...
No obstante, eso de la interpolacion de fotogramas, pues hombre... a mi no me parece bien, ya que si lo dejo suelto no dara el mismo tipo de velocidad en todas las maquinas y yo quiero hacer como en las consolas... porque matarse a programar para mostrar 100 frames si con 60 o digamos 75 vas que te matas?
En fin... ah, por cierto, gracias por el toque en la funcion de delay, la verdad es que normalmente no me da problemas, excepto en un par de funciones, seguramente sera por eso, por haber pasado por alto los indices a memoria, lo que pasa es que esa instruccion nunca la he usado con otro prefijo que el movxx, se podria usar 'rep nop'? es decir, dejar el codigo asi?
mov ecx,ns
rep nop
en lugar de
mov ecx,ns
nop
rep movsb
??
Para Ithaqua:
Ahh, por cierto... de todas formas he de decir algo, y es que aparentemente no pensais en un tema importante: el sonido. Si, puede que querais dejar correr la aceleradora a sus anchas, pero cuando tengas que sincronizar imagen y sonido ya me diras como... y no me refiero a la musica de fondo, sino un dialogo hablado donde se vean expresiones labiales... como lo haces si dejas que el motor corra sin freno? :sonriendo:
Saludos a ambos :riendo:
_________________
Julio Meca
ALPHA SOFTWARE
[ Este Mensaje fue editado por: Emotion el 2002-04-23 09:49 ]
[ Este Mensaje fue editado por: Emotion el 2002-04-23 09:51 ]
Comentario a algunas frases de Emotion:
"No obstante, eso de la interpolacion de fotogramas, pues hombre... a mi no me parece bien, ya que si lo dejo suelto no dara el mismo tipo de velocidad en todas las maquinas"
En todas las máquinas irá igual de rápido, insisto que lo que cambia es la suavidad. Lee el ejemplo otra vez y lo entenderás. Es de cajón.
"y yo quiero hacer como en las consolas... porque matarse a programar para mostrar 100 frames si con 60 o digamos 75 vas que te matas"
Eso es imposible conseguirlo, una consola es una máquina standard. Todo lo que vaya a 60fps en una irá a 60fps en otra. Bienvenido al mundo del PC donde tienes mil configuraciones, y por tanto rendimientos, distintas.
"Si, puede que querais dejar correr la aceleradora a sus anchas, pero cuando tengas que sincronizar imagen y sonido ya me diras como... y no me refiero a la musica de fondo, sino un dialogo hablado donde se vean expresiones labiales... como lo haces si dejas que el motor corra sin freno?"
Otra vez: interpolación.
No es lo mismo mostrar una animación que consista en, por ejemplo, 100 frames, que mostrar una animación que consista en 10 segundos.
En el primer caso la máquina mas rápida ejecutará esos 100 frames en menor tiempo. En el segundo caso, la potencia de la máquina hará que en esos 10 segundos se vean más o menos pasos intermedios.
Sigo sin entender como no comprendes esto. ¿Tu guardas acaso las keys con un valor de frame, y no de tiempo? ¿Como interpolas con el primer método?
Objeto.Transforma(Timer.Segundos());
Es tan simple como eso.
Saludos.
¡Cuanto energía estais echando en este post!
Creo que ambos teneis razón, pero no tiene que ver lo que dice uno con lo que dice otro. La idea de Emotion me parece muy buena:aprovechar la potencia de tu máquina que sobra en pos de una mayor calidad, en lugar de una mayor suavidad.
E Ithaqua dices que viva la suavidad(en resumidas cuentas)
Pues eso, que teneis ambos razón. Ahora ya depende de cada uno.
Para Dracula:
Gracias tio!! :riendo:
Para Ithaqua:
Pues la verdad es que por ahora, SI. utilizo frames para las llaves, ya que por ahora me es mas comodo trabajar con ellos (puedo sincronizar la reproduccion de un video al mismo tiempo que puedo controlar la vida de un sistema de particulas (simple o complejo) y algunas otras cosas. En cierto modo, se podria decir que el keyframer es el nucleo de mi motor de desarrollo, pero vamos... en general y respondiendo a tu pregunta... SI (que barbaro soy, eh? :riendo:)
Un Saludo
Bueno como llego un poco tarde a este post y ya esta casi todo dicho solo puedo hablar de lo ultimo que se ha puesto (Sobre Ithaqua y Emotion). Estoy totalmente deacuerdo en lo que ha dicho Ithaqua y es verdad que con interpolación se suplen todas esas dificultades que no parecen convenver a Emotion, y como bien dijo lo único que varia es la suavidad con la que se realice. Y sobre lo de el sincronismo de musica, voces, efectos y tal, pues sinceramente tampoco se me ocurre una manera optima de hacerlo sin hacer uso de la interpolación. Solamente miremos a las miles de demos que podemos descargar por ejemplo en
http://www.pouet.net y veremos como en la mayoría (vamos las que tengan nivel aceptable) tienen una perfecta sincronización de música, efectos sonoros y gráficos, particulas, etc... y os aseguro que el 99% usa interpolación :lengua:
Un saludo
Drácula : Ya no es problema de la idea, sino del método. No se puede medir el % de rendimiento por frame que 'sobra' de esa manera que él propone.
Emotion: Y si tienes 30 frames, y una máquina te permite dibujar solamente 3 y otra 60, que haces? No hablo de vídeo, hablo de gráficos en tiempo real.
Y eso de sincronizar bien sistemas de partículas etc. ¿Que mejor forma de parametrizarlo que usando el tiempo? El movimiento en física 'real' se parametriza por tiempo (S(t) = funcion_de_t). Es decír, que dado un tiempo t (obtenido del timer por ejemplo) y aplicando las fórmulas, se nos da un valor de posición.
Buenas, este tema si que está generando polémica...
Emotion, creo que estas mezclando los fallos de caché con la alineación de datos, los fallos de caché es algo imprevisible (en general) dado un segmento de código, la alineación puede serlo o puede no serlo, según hagas los accesos a memoria, y el emparejamiento de instrucciones es perfectamente previsible. De todas formas creo que deberías preocuparte de optimizar el motor a nivel algorítmico antes que a bajo nivel.
El tema del delay, lo mejor es que no pongas nada en ensamblador si no estas completamente seguro de lo que haces, hay muchas cosas a tener en cuenta (las definiré como MATIZ-Que-Jode :lengua:). No puedes usar REP NOP, el prefijo REP es solo para ciertas instrucciones (movs, stos ins y outs creo). En resumen, mejor no uses REP MOVSB ni nada parecido, si acaso tendrias que hacer un bucle a mano pero... para que hacerlo en ensamblador? todavía no se lo que pretendías haciendolo así, en cualquier caso no estabas poniendo ESI ni EDI para que apuntaran a algo, ni estableces la dirección de la transferencia (puede ser incrementando o decrementando ESI y EDI -> CLD/STD), y lo del CLI y el STI... no creo que el windows de a las aplicaciones privilegio de E/S para usar esas instrucciones.
Respecto a las consolas, tampoco vas a poderlo hacer a una velocidad fija, tienes que tener en cuenta la selección de 50/60 Hz :triste: de todas formas en los PC el problema es mayor en ese sentido... puede ir a 20 o a 200 fps, personalmente no me preocupa cuando se va a los 200, me preocupa mas cuando se va a 20, eso es lo jodio. Si lo haces fijo a 75 y te va a 20... que vas a hacer? de nuevo la solución de la interpolación parece la mejor ya que se adapta a los FPS que de la máquina. Ademas si lo haces fijo a 75 y lo ejecutas en un monitor de 85 Hz queda realmente mal, como si los frames no estuvieran espaciados uniformemente (sobre todo si el vsync está activado).
Lo de la sincronización con el sonido, no le veo la pega, insisto en que la animación se verá mas suave, pero durará lo mismo en el tiempo. Precisamente el problema de sincro. lo vas a tener tu si lo fijas a 75 y te va a 40. Tendrás que saltarte frames "a lo bruto" para compensarlo, y eso suele quedar bastante mal.
ale, mas leña pal fuego...
saludos
[ Este Mensaje fue editado por: mallrat el 2002-04-24 02:49 ]
mallrat:
Citar
...no creo que el windows de a las aplicaciones privilegio de E/S para usar esas instrucciones.
Para dejar todos los cabos atados, windows deja usar TODAS las instrucciones de ensamblador habidas y por haber, la única restricción es si accedes a una parte de la memoria que no a sido reservada por tu aplicación, por lo demás no problem, yo lo estoy haciendo todo en asm...
saludetes
para Ithaqua:
Bueno, tienes razon... el movimiento se parametriza en funcion del tiempo, pero la medida de los FPS tambien es parametrizable en funcion del tiempo... ya que si tenemos por ejemplo 50 FPS cada frame esta consumiendo 0,02 segundos. Ademas, si quisieras controlar el movimiento de un objeto y quieres usar un segmento de tiempo menor, tendrias que poder generar mas frames EN EL CASO de que quisieras visualizar todos los pasos. De todas formas, lo dicho... a mi el sistema de los frames me funciona (por ahora), cuando me encuentre con el escollo entonces decidire que hacer... tiempo tengo casi todo el del mundo para corregir y depurar...
De cualquier modo entiendo tu punto de vista E INCLUSO lo comparto, solo que yo quiero hacerlo asi y lo voy a hacer asi, ya que no se tu como veras lo del keyframer, pero yo al menos el de 3DS4 usaba frames para las llaves, no tiempo (si no mal recuerdo, ya que louego supongo que utilizaba incrementales para los frames contiguos).
para mallrat:
Lo de que windows no te deja E/S no es cierto, lo que pasa es que segun el manual de INTEL, si se produce la interrupcion 05h mientras el rep esta por ahi dando vueltas, el comportamiento de la instruccion rep es entonces imprevisible, por eso desactivo las interrupciones antes del bucle y despues lo vuelvo a meter.
Aparte de eso, SIGO en mis trece de hacerlo asi, y con respecto a la interpolacion, bueno... quizas la idea de bloquear los fotogramas no sea tan buena como parece, pero aun tengo que hacer unas pruebas, aunque me mantengo en lo expuesto en los otros post... :riendo:
Saludos a ambos
Emotion:
Supongo que te funcionará bien porque no estas trabajando con gráficos en tiempo real, sino con imágenes/vídeo o algo parecido no-interpolable.
Por otra parte el 3ds siempre ha usado internamente valores de tiempo para las keys (como cualquier otro programa de animación 3D). Solamente que de forma externa se puede trabajar también a nivel de frames.
Un saludo.
Bueno, la verdad es que debo pedir disculpas ya que meti la pata en mi anterior post, ya que no es el keyframer el que trabaja con frames (es cierto, trabajaba con tiempo), sino que era el video-post el que trabajaba por frames, pero claro.. el video-post no es mas que un compositor y yo me estaba basando en eso... La verdad es que llegados a este punto me quedo bastante confuso, ya que mi sistema, al menos en las pruebas analiticas, funciona, ademas la estructura interna de funcionamiento de mi motor funciona de manera similar al video-post. De cualquier manera, lo siento de veras...
Quizas si me dejaras un mail te podria explicar con algo mas de detenimiento el porque quiero mantener (o me gustaria que en esencia se mantuviera asi) la estructura...
Un Saludo y mis mas sinceras disculpas :triste:
Hola Emotion,
¿a que te refieres con lo de que desactivas las interrupciones? ... entonces, cuando machacas una zona de memoria que no es "tuya", ¿no te avisa?, por que sin iniciar ESI y EDI a nada es rarisimo que no te casque siempre en ese retardo...
saludos
Emotion, todo menos pedir disculpas :ojo:
Para eso estamos todos aquí, para plantear dudas, dar consejos e incluso equivocarnos (o no) :sonriendo:
Hmm, parece que este thread está llegando a su fin. Increible...
para Ithaqua:
Si, la verdad es que me alegro de que todo haya casi terminado, y digo casi por el añadido que voy a hacer al post de fiero, pero vamos... parece que todo toca a su fin... :sonriendo:
para fiero:
Bueno, el manual de Intel dice eso, que si se produce la interrupcion 05h mientras el bucle esta corriendo aun, el comportamiento de la instruccion es impredecible, pero es todo lo que puedo decir, ya que es todo lo que dice el manual. Supongo que por eso es bueno hacer el CLI, aunque no se yo si a Windows le hace mucha gracia, para mi que no, pero si lo dice el manual...
Saludos a ambos
Buenas! aun no está acabao del todo el tema (aunque ya le queda poco...) :lengua:
fiero: Windows NO te deja usar TODAS las instrucciones. Hay algunas instrucciones que sólo las puedes ejecutar si estás en el nivel de privilegio en el que el S.O. te permita ejecutarlas. Para ser mas exactos, el windows NO te va a hacer caso de un STI o de un CLI a menos que estes en modo kernel, así que o haces un driver u olvidate de usar STI o CLI.
Son instrucciones muy concretas, como las de antes o las de E/S por los puertos. En cuanto a las instrucciones "normales", por supuesto puedes usar las que quieras.
Emotion: supongo que te refieres al problema que habia en los 8086 con el rep movsb (o cualquier otro "rep") que se cortaba cuando habia una interrupcion (del tipo que fuera) por simplicidad en el diseño del micro... (que vagos los de intel) pero valía con comprobar si cx habia llegado a cero, con lo cual habiamos terminado. Si no era cero, habia que continuar el "rep". De todas formas ya no tienes que preocuparte en absoluto de eso (si quieres échale un ojo al código ensamblador de strcpy/strcat/etc, seguro que no ves ni cli/sti ni siquiera ninguna comprobacion de que efectivamente ecx=0)
saludos
Ah, pues mira tu por donde... eso no lo sabia...
Gracias por la aclaracion, creo que eso me permitira hacer mi codigo ASM un poco mejor :sonriendo:
Un Saludo
vale vale, :riendo: oido cocina, como yo ejecuto mis viejos programas de MS-DOS en windows y CLI y STI me seguian funcionando igual... aunque ya se que eso es otra historia, ya que lo que utilizo es un "emulador" de un 8086 dentro del maravilloso mundo windows. Hacer una CLI o STI del 386 (o superior) cuando trabajamos en modo protegido y en capas superiores al kernel, pues la verdad no lo he probado, pero son instrucciones tan simples que ... en fin ... pensaba... lo siento... ala, a currar.
un saludo
Bueno, lo del kernel, realmente es el kernel el que esta por encima de la maquina... al menos organizativamente :sonriendo:
En cuanto a lo del modo protegido, pues mira... pensandolo bien, sera mejor que no le metas el CLI ni el STI, ya que el sistema no puede ejecutar interrupciones de modo real en modo protegido a no ser que las emule o antes de ejecutarlas vuelva al modo real. Es que ahora que caigo, si ejecutas una interrupcion normal en modo protegido lo normal es que te genere el famoso GPF o general protection fault por violar la proteccion de memoria... :sonriendo:
Pues nos estamos saliendo del tiesto....
yo no he dicho que las use en modo protegido, eso lo has dicho tú, que las usabas en tu programa y si es un programa para win9x estás en modo protegido...
yo lo de usar las interrupciones en windows, ni idea, simplemente todavia no lo he encontrado necesario, pero como según has puesto:
Citar
void delay(unsigned long dc)
{
__asm cli;
__asm mov ecx,dc;
__asm nop;
__asm rep movsb;
__asm sti;
}
tu utilizas CLI y STI y si el compilador no ha dado ningun problema, y luego al ejecutar, tampoco te da ningun fallo de "instrucción no permitida" ni nada de eso, he deducido que se podia usar en modo protegido, que es el modo en el que me encuentro ahora mismo escribiendo estas palabras...
saludos
PD: Jod*r con los programadores!!, siempre queremos llevar razón :riendo: :riendo: :riendo:
[ Este Mensaje fue editado por: fiero el 2002-04-25 19:48 ]
me referia al INT, no al CLI o el STI, esas dos ultimas si, ya que lo unico que hacen es deshabilitar un bit en un registro, que es el que hace que se habilite o no la tabla de vectores de interrupcion... lo que yo queria decir es que no se puede usar el INT en Win32 por lo del modo protegido (yo lo intente de varias maneras y siempre casca)...
Un Saludo :sonriendo:
ah, claro...
saludos