Anuncios Google
efectos lua
Vie, 2008-02-15 16:03 — recoco
como puedo hacer que salga sangre cuando matas al personaje o cuando disparas y otra duda es que codigo debo de poner para crear un suelo y que camine el personaje por ahi y no por el fondo para lua
Anuncios Google
- Inicie sesión o regístrese para enviar comentarios
- 1704 lecturas
El software, código fuente, logotipos y marcas contenidos en este sitio web son propiedad de sus respectivos dueños y están, o pueden estar, sujetos a derechos y/o licencia de uso. Los anuncios, banners y la publicidad son propiedad y responsabilidad de los anunciantes. Los envíos y publicaciones, salvo indicación expresa en contra, son propiedad y responsabilidad de quien los realiza. El resto de publicaciones, elementos gráficos y contenido es propiedad de "SB IT MEDIA, S.L.".
SceneBeta.com, 2005 - 2018
Contactar con PSP.SceneBeta.com - Información legal, términos y condiciones de uso - Política de privacidad - Política de cookies
Mmmm...
Como dice Pana creo que tienes el concepto de prgramación un poco desvíado.
Te lo pondré así, lo que quieres hacer no es posible, ya que yo veo esto de los graficos como una ilusión óptica.
No se trata de crear un suelo, se trata de poner una imagen que asemeje el suelo, y que el personaje pase por ciertos pixeles para qiue parezca que camine.
Si un pixel de una imagen llega a cierto pixel de otra imagen aparecerá otra, que es la sangre.
No es por señalar...
Ni tampoco por personalizar; pero si alguien, quien sea, dice que "ve esto de los graficos como una ilusion optica", por un lado, y añade por el otro que para controlar una colisión "se trata de poner una imagen que asemeje el suelo, y que el personaje pase por ciertos pixeles para qiue parezca que camine", "(...) Si un pixel de una imagen llega a cierto pixel de otra imagen aparecerá otra, que es la sangre", lo que yo creo es que es esta persona quien no ha acabado de comprender lo que está haciendo, porque esto es una contradicción in terminis (pista #1 para ver dónde está el error garrafal: las negritas. Pista #2: LUA usa —doble— buffering de video, ¿no?. Pues queda claro por qué usar píxeles para colisiones es una pésima práctica de programación.)
Enseñad lo que sabéis. Decid "yo esto lo hago así por esto y por esto otro." Esto sí es útil. Si alguien realmente no sirve, ya se pegará el morrazo sin necesidad de agoreros. El resto es... prescindible como poco, seguramente cuestión únicamente de ego/actitud de matón o "abusaenanos", y algo que me parece totalmente deleznable (y que, casualmente, se suele dar entre programadores con poco currículum). Y quien crea que hay una Única Manera Grande y Mejor de programar, simplemente, está muy pagado de sí mismo. Las cosas nunca "se programan así" y punto. Hay miles de maneras de hacer una misma tarea, y todas tienen sus pros y sus contras. Una veces querrás rapidez; otras, que un mismo código se ejecute a la misma velocidad (estabilidad) en vez de "optimizar" y hacer sólo lo imprescindible, etcétera. Que a ti, amable lector que lees esto, no se te haya ocurrido más que una manera de hacer algo no significa, jamás, que sea la única. Tenlo muy presente, siempre, si quieres programar.
PS.: Pana... realmente creo que te sería muy útil intentar entender el concepto de "programación orientada a objetos" (OOP por sus siglas en inglés), el tipo que usan los grandes lenguajes actuales (C, Java, ActionScript... hasta el VBA, en mayor o menor grado) y que es lo que quiere ser el LUA cuando sea mayor, o eso dicen algunos. En OOP, no sólo es posible, sino además muy recomendable, hacer estructuras tipo:
if(enemigo.daPuñetazoA(personaje)){personaje.sangraPorLaNariz();};
Es decir, exactamente lo que tú dices que no es programar... Que luego (en realidad, antes) tengamos que definir los métodos no cambia en nada esta estructura principal; justamente, ahí está su ventaja, en el black box coding.
Strength is irrelevant. Resistance is future. We wish to improve ourselves.
La fuerza es irrelevante. La resistencia es futuro. Queremos mejorarnos.
Muy bonito tu texto, pero no
Muy bonito tu texto, pero no te mojas nada y si no te mojas... tus palabras no me sirven para NADA.
Lo primero, LUA no es programación por objetos (o concurrida, ya que te molan los tecnicismos). Java y C++ si, pero LUA NO. La verdad, no se que quiere ser LUA de mayor, yo quiero ser rico y dudo que lo sea :D. Ten en cuenta, que LUA existia antes que la PSP, dejame que dude que llegue a ser algo de programacion orientada a objetos.
Así pues, me parece ABSURDO hablar de lo que uno sabe, pero que no sirve para NADA. Es decir, me parece muy bonita la fardada que te metes aquí con tecnincismos (que si lua usa doble buffering de video blablabla), cuando al usuario NO LE SIRVE PARA NADA. A eso se le llama marear la perdiz, o como decimos entre amigos "Mucho humo".
Pues eso, mojate un poquito y resuelvele la duda al usuario en LUA (no en java por favor, dejemos a la perdiz tranquila), apañatelas con arrays para hacer el objeto sangre :D.
Saludos y centremonos en lo que se está hablando, que a mi me mola mucho la filosofia y podria parrafar sobre ella, pero creo que no serviria de nada.
No entraré al trapo...
En primer lugar... no tengo ni idea de LUA. Pero si me estaba centrando en el tema que tú sacabas, con eso de "no tienes ni idea del concepto de programaciónm, etc". Tú no te estabas ciñendo a LUA, porque entonces le habrías dirigido a otra parte... ya le echabas directamente del Olimpo de los programadores.
No veo qué tiene que ver que LUA existiera con la PSP como su desarrollo en cuanto a acabar, o no, como OOP. ActionScript también es anterior a la PSP (y más si incluímos el Lingo), y no siendo OOP al principio, sí lo es ahora.
Dices que haga el objeto sangre con arrays, como si eso fuera difícil. Yo pensaba que los objetos no solían ser más que arrays asociativos, mira tú por dónde :D
Tú le negabas toda posibilidad. Yo le digo que eso no es cierto. Sin arreglarle el problema, le doy un paso para que avance. Otro más sería " tienes que partir los procesos y pensar en cada detalle independientemente". Creo que eres la persona menos indicada —y es una muestra de cinismo por tu parte— que me digas que le resuelva yo la duda, cuando no te ocupó, en su día, más de dos líneas para mandarla a la porra.
Dices que mi mensaje no te sirve de nada; bueno, eso es porque no quieres. También que no me mojo; pero hasta quien no entienda el porqué, entiende que te he dejado en evidencia. El esquema que pongo de OOP bien se puede traducir a diagrama de flujo (si sabes lo que es...), y de ahí al lenguaje concreto. Eso es la esencia de la programación, un algoritmo abstracto no ligado a una forma concreta. Harías bien.
PS: Ciertamente, creo que no serviría de nada que tú escribieras sobre filosofía: los sofistas no aportaron nada bueno. Y recuerda que la mejor forma de predicar es con el ejemplo
Strength is irrelevant. Resistance is future. We wish to improve ourselves.
La fuerza es irrelevante. La resistencia es futuro. Queremos mejorarnos.
Pues predica con el ejemplo
Pues predica con el ejemplo y aporta algo útil, dejate de sermones que no son más que cortinas de humo, donde detrás no hay NADA.
Te vuelvo a repetir, no me vengas con batallitas de programación, que no entiende nadie.
Dices que me has puesto en evidencia, porque? porque has aparecido aquí con bolsas llenas de conocimientos que no nos sirven para nada? Porque te echas el moco de que sabes de programacion? Yo no tengo la culpa de que entre tus amigos no puedas fardar de que entiendes de programacion y la unica salida que te queda en tu vida, para sentirte bien y feliz con lo que haces, es intentar colar una fardada a la minima que puedes.
Como bien has dicho, no tienes ni idea de LUA, yo algo entiendo (no excesivamente) y para hacer colisiones se utilizan los pixeles, al igual que para delimitar el campo de la pantalla, o simplemente por donde se moverá un obetjo (te recomiendo que te pases por los tutoriales de LUA, son interesantes, aunque igual un ente tan poderoso como tu sobre programación los menosprecie).
Así pues, vuelvo a lo mismo, si aqui la duda está en LUA, no se para que metes las narices con tus historias de programación concurrida que NI NOS VA NI NOS VIENE, porque no soluciona nada.
Te doy la razón en una cosa, me excedí en "sacarle" del mundo de la programación en general... Es cierto, podría haberle dicho que se dejase de LUA y que se metiese en Java, que ahí podrá hacer lo que el quiere hacer.
El problema, quizás, esque yo (a diferencia de ti) me ciño a lo que leo y a lo que se está hablando. Por un lado, aprender a programar a través de programacion por objetos, no lo veo correcto y, por otro lado, creo que si un alguien no es capaz siquiera de entender los sencillisimos tutoriales de LUA, o simplemente no es capaz de entender como funciona un Script (que no es más que una maldita secuencia de comandos), me parece de cínico (quien hablaba de cinismo?) quererle mandar a programar java y que empiece a crear sus primeras .class.
Pues eso, ciñete a lo que hay, no nos vendas ilusiones creadas de aire, no le digas a alguien que no sabe ni programar un Script (y ni entiende el concepto de lo que es) que Traduzca el esquema que has puesto de OOP a diagrama de flujo porque la verdad, me da a entender que tienes una percepcion de la realidad bastante equivocada.
Por último, reducir el pensamiento filosofico a un movimiento tan primitivo y simple como el sofista... Me da a entender 2 cosas, o no tienes ni idea de filosofia y cres que los sofistas son los unicos filosofos (por eso de que ambas palabras contienen el monema "SOF"), o realmente entiendes algo de filosofia y, en tu linea de trasgiversar lo útil, anulas a los grandes filosofos colocando en el centro del pensamiento a los sofistas :D.
PD (que no PS): Te doy permiso, si quieres, de que te sigas echando la fardada de lo mucho que sabes programar, ahora bien, no pienso seguir contestando a unos discursos que están fuera de lugar.
Por ejemplo...
Empecemos por la parte en que demuestras ser un total y absoluto bocazas:
"Porque te echas el moco de que sabes de programacion? Yo no tengo la culpa de que entre tus amigos no puedas fardar de que entiendes de programacion y la unica salida que te queda en tu vida, para sentirte bien y feliz con lo que haces, es intentar colar una fardada a la minima que puedes."
El que se estaba tirando la fardada eras tú, con eso de pretender que tu escasa experiencia te permite decir quién puede y quién no ponerse a programar. Eso funciona con los novatos (y te quita competencia para tus limitadas aptitudes), pero no con los que llevamos un tiempo. Y pretendiendo corregir la ortografía a un corrector de estilo... que por cierto, seguramente lleve más años programando como aficionado de los que llevas tú vivo.
Luego, si quiero fardar de lo que sé de programación, remito a mi página de muestra. Mis amigos acostumbran a quedarse embobados; lo del juego de estrategia con inteligencia artificial y ¿cuarenta? tipos de unidades distintas y ¿eran cincuenta? edificaciones impresiona. Luego, cuando cuento cómo está hecho, y que tiene un soporte multijugador para Internet (no usado) ya flipan en pepinillos. Los otros, más normalitos... pero el tema colisiones lo llevan bien. Tan bien como para hacer un juego con ilusiones ópticas tridimensionales y que las colisiones funcionen.
Predícame tú con el ejemplo y soluciónale tú el problema en LUA, ya que tú puedes decir quién sabe programar y quién no...
En cuanto a los tutoriales de programación, como ya dije en su día y tú me respondiste que sí, están cojos en los aspectos más básicos. Cómo se construye el color, qué son las estructuras lógicas, cómo se organiza la pantalla y estas cosas. O sea que sí, son deficientes. No se puede cubrir todo, pero lo que veo malo de cómo están planteados es que parece que programar sea una especie de "magia con conjuros" en las que dices unas palabras mágicas y salen cosas en pantalla. Y programar es todo lo contrario del "esto se hace así" hay montones de maneras de hacer las cosas. Eso sí, hay algunas que siempre son malas.
Cualquier diagrama de flujo se puede traducir a cualquier idioma de programación. Si lo sabes, claro. Lo que él dice se puede hacer en LUA, desde luego.
Si usas los píxeles y no las coordenadas para hacer las colisiones, mal vamos. Porque los píxeles son puntos en pantalla que dibujas después de calcular su coordenada, un par de números. El Hol en Bol de mi página, obviamente, es imposible de hacer con el sistema que tú dices de colisiones por píxeles, ya que la ilusión óptica engañaría al ordenador y se trata que engañe sólo al jugador.
Si confundes píxeles y coordenadas... no me vengas con que soy yo quien tiene una percepción distorsionada de la realidad: empieza tú a distinguir lo virtual de lo real.
Ahora bien, ¿alguna vez has programado algo de esto de colisiones? No está por aquí, y dado lo puesto a fardar que eres (en tus instaladores pones tu nombre bien claro
No se dice "trasgiversar", sino "tergiversar".
Los filósofos me los leo en lengua original, griego y latín. Por algo traduje en la carrera la mitad de los diálogos de Platón. ¿Pretendes darme clases de eso, népios téknos? No me tergiverses, que lo que estoy diciendo no es más que tú estás haciendo el sofista. Si supieras de filosofía, te sonaría la anécdota de la "aporía del movimiento". Pero supongo que eso aún no lo has dado en la escuela.
PS significa "Post scriptum". Algo que se añade "después de escribir". PD significa "post data": algo que se añade después de la fecha del encabezado de la carta. Lo que tú pones es un PS y no una PD, aunque no lo sepas (ya me tienes acostumbrado a que no sabes muy bien lo que haces).
Strength is irrelevant. Resistance is future. We wish to improve ourselves.
La fuerza es irrelevante. La resistencia es futuro. Queremos mejorarnos.
Te gusta el humo eh?
Te gusta el humo eh?
Te lo vuelvo a decir? Me importa bien poquito lo que hagas en tu vida, lo que e sepas o no sepas, pero bien poquito. Me importa aun menos tu web y tu "juego" con "online", la verdad, vete a vender humo a quien quiera comprarlo, no a mi ;).
Volvemos a lo de antes? Uys, a lo de ¿Siempre? El tema es simple:
Por otro lado, repito, sí, no debí echar a nadie de programación, quizás si TU te dignases a contestar tantas dudas como hago yo dia tras dia, y no a saltar cual gallo peleón, también pensarías que lo mejor esque el chabal empiece de 0 (aprendiendo el concepto de programación).
Por último, ser super poderoso, aprende a leer definiciones de la RAE y luego me lo cuentas. Que si, que igual en terminologias cientificochorradas de las tuyas, se usa PS, pero te repito, baja de la nube en la que vives y se un poquito más humano anda...
Ejem...
To dije lo de los píxeles... Pero no escribo con el ánimo de Debatir, todo lo contrario, nunca podría contradecirte, me has dejado con la boca abierta.
Bueno, yo soy menos que un aficionado de Lua, acepto que sí me pasé...
Bueno quería aclarar (O que tú me aclararas), eso de coordenadas y pixeles. Es posible que las esté confundiendo, ya que en Lua se usa el siguiente comando:
screen:blit(x,y,imagen)
Eso quiere decir, o por lo menos eso creo, que estas indicando una coordenada, sin embargo en el PSP, no se está interpretando como en un plano cartesiano.
Si escribes screen:blit(0,0,fondo) el Fondo se mostrará en pantalla completa, es decir, que está actuando a modo de un sólo cuadrante, en donde los ejes X e Y don un pixel, así el fin de la pantalla del PSP es X=480, Y=272.
No sé si eso es una coordenada o un pixel.
Sólo escribo para aclarar.
De eso se trataba :)
... que alguien preguntase qué era eso tan ¿obvio?
Bueno, teniendo en cuenta que ahí pareces estar llamando a un método del objeto screen, lo que haces es pasar la coordenada a píxel. La pantalla mide píxeles. Las coordenadas van por un sistema cartesiano inverso en la y (lo que significa en cristiano que mayor cuanto más abajo); esto es común a todos los monitores.
No hay un pixel x>480 en la PSP, pero sí puedes tener una variable (=coordenada) >480 o <0.
¿A qué viene esto con el buffer? Pues que el buffer se tiene que pasar todo ya calculado (supongo que no puede pasarse de otra manera). Esto implica muchas cosas, una de ellas (quizá la más importante) que se trabaja todo de golpe. O mejor, se debería trabajar todo de golpe (a no ser que cuestiones de rendimiento impongan hacer turnos de comprobaciones). Es distinto a trabajar con píxeles: si trabajas con píxeles, la comprobación de colisión debes hacerla, por narices, después del dibujo. Si lo haces por coordenadas, antes. Puede parecer una tontería, pero saberlo, y ser consciente, es importante. El tempo, o cuando toca qué, es tan importante en programación (sin lenguaje: en la estructura algorítmica, del proceso en orden) como el evitar trabajo inútil al procesador o preparar el programa para una depuración fácil. O desglosar tareas, que es de lo que el autor de este hilo no es consciente. Un error típico de novato, por otra parte, que todos hemos cometido alguna vez: otra de las cosas básicas es saber "atomizar" las tareas y reducirlas a la mínima expresión del lenguaje de programación de turno. En C, para sumar 1 te basta añadir ++ a la variable. En ensamblador Z80, si mal no recuerdo, tienes que pasar el valor de la dirección de memoria a uno o los dos registros HL (si es de 1 o de 2 bytes), incrementar el registro en uno, y devolver el nuevo valor del registro a la dirección de memoria apropiada. La misma simplísima operación se "desglosa" de maneras muy distintas; de modo que si intentaras programar esa sumita " al estilo C++" en ensamblador tipo Z80, te encontrarías con el sorprendente error que "sólo puedes sumar al registro central", cuando "eso no es un bug, es una característica". :) Igualmente, hay lenguajes que trabajan sólo con coordenadas y no te permiten hacer comprobaciones directas sobre la imagen (veo que es el caso de LUA), pero otros te permiten ambas cosas: por coordenadas y por píxeles (el método .hitTest de la clase MovieClip de Actionscript comprueba si un píxel concreto se solapa con la forma de una imagen interna de Flash, el MovieClip. Es decir, te comprueba si toca formas irregulares.).
Pero en ninguna parte de los tutoriales he visto estas cosillas básicas. Esto de desglosar, que el color se hace con primarios RGB (y no CMYK), qué es eso que FF signifique 255, etc. etc. etc. Tú mismo usas un plano cartesiano inverso en las ordenadas y no sabes que lo es :), aunque aquí, ciertamente, es totalmente irrelevante saber la definición matemática. Pero habrá casos en que, si no eres bueno haciendo una "ingeniería inversa" matemática, quizá te cueste extrapolar un caso concreto a la técnica general. E incluso si puedes, corres un serio riesgo de acabar cogiendo "vicios" en cosas básicas y tener, luego, que desandar camino. O tirar siempre a lo seguro y no probar, que tampoco es bueno. Corres un serio riesgo de acabar asumiendo una "liturgia" de "palabras sagradas" jamás cuestionadas. Apostaría algo (no mucho, que soy pobre :) ) a que compruebas las colisiones mirando si la X Y la Y están en el rango correspondiente, o sea algo tipo (pseudocódigo tipo AS/ C++/PHP/estas cosas):
distanciaX=Math.abs(bueno.x -malo.x); distanciaY=Math.abs(bueno.y-malo.y); rangoDanyo=16;
if ((distanciaX<=rangoDanyo) AND (distanciaY<=rangoDanyo)) then {hazLoQueDebas();};
Es bastante posible que te hayan dicho que es la manera (distancia igual a valor absoluto de la resta de coordenadas, si es igual o menor a valor de rango, se toca). Es algo que suele decirse. Ahora bien, también puede hacerse así:
distanciaX=Math.abs(bueno.x -malo.x); distanciaY=Math.abs(bueno.y-malo.y); rangoDanyo=16;
if ((distanciaX<=rangoDanyo) then {
if (distanciaY<=rangoDanyo)) then {
hazLoQueDebas();};};
Es decir, meter una condición dentro de la otra ("anidarlas"), porque si el bueno y el malo no se tocan por la horizontal, tanto da que estén en la misma vertical, porque no se tocarán fijo: tienen que estar las dos en el rango. Esta segunda formulación del código es más rápida. ¿Es mejor por eso? Si lo que quieres es velocidad, p.e., estás haciendo un shooter, sí, es mejor; si lo que quieres es estabilidad, porque es más tipo puzzle con temporizador, y no quieres que te salte demasiado, pues igual no es tan buena, porque preferirás medir bien el tiempo a que vaya rápido pero más irregular. Aunque sea sólo ligeramente (todo se multiplica cuando lo pones con otras cosas). Bien, probablemente tú en concreto seas consciente de estas cosas en concreto, pero me he visto unos cuantos, con experiencia (y el vicio que digo) que tenían problemas de velocidad pese a corregir "todo" el código... menos cosas como ésa. Y la gestión de los booleanos, y la compresión del sonido, y... porque siempre lo habían hecho asá, y lo tenían tan integrado que ni se lo cuestionaban. Ni siquiera cuando se cuestionaban todo el programa: era algo ya inconsciente (cosas del aprendizaje humano). Pero en esa elección (sabes que uno es rápido y el otro estable; ¿sabes lo que quieres? ¿a qué eliges renunciar?) radica el concepto de programación: detallar una serie de órdenes para que el ordenador las cumpla (y explicárselo todo muy detenidamente para que lo que le decimos que haga sea lo que queremos que haga). Lo podrás formular de otro modo, pero la base es la misma (otro día ya hablaré de las máquinas de Turing :D). No es un don ni nada de eso. Es una serie de técnicas, y como tales se pueden aprender (y olvidar, y asumir, y...). No es esencialmente muy distinto a aprender un nuevo idioma humano que sólo se conjugue en imperativo y condicional. De hecho, uno de los mayores hackers de redes de la historia, Whistler, era autista y programaba silbando...
Strength is irrelevant. Resistance is future. We wish to improve ourselves.
La fuerza es irrelevante. La resistencia es futuro. Queremos mejorarnos.
Sinceramente, como le digo a
Sinceramente, como le digo a la mayoría, no entiendes el concepto de programación. Por tanto, olvidate de programar.
Programar no es decir: "Si enemigo pega puñetazo a personaje, personaje sangrar por nariz".
Saludos.
estoy de acuerdo
estoy de acuerdo con x_d pana fuiste muy grosero
El hecho q no sabe nada de
El hecho q no sabe nada de programacion no significa q no lo pueda intentar porq como comienzan todos nadie nace sabio en algun momento tubuieron q comoensar de cero igual q el por lo menos deja q lo intente
olvidalo
solo te aconsejo que marque ofencivo, para algo esta el boton.
No creo q alla llegado hasta
No creo q alla llegado hasta ese punto pero por lo menos deveria pedir disculpas ya q a nadie le gustaria q le dijeran q es una pelota y no vas a ser capas de hacer mas pero eso le corresponde a pana si lo hac o no
al fin y al cabo
de que !&$%a estan hablando que en la lua no se hace casi nah entonces empezare a programar en c++ aunque sea dificil.