#3841 Ummm... Vircon no está muy pensada para trabajar pixel a pixel. Quizá podría hacerse algo si es a baja resolución (cuadrados más gordos), o si no cambian muchos pixels en cada frame
#3837 Pues mejor que nunca la verdad, mi pareja me tiene muy bien en ese sentido
Tranqui quizás algún dia puedas dejar tu pareja actual, aka mano izquierda, para tener una nueva pareja, aka mano derecha
#3842 humm toy mirando la api http://www.vircon32.com/api/video.html
Intentaré hacer al menos que la consola explote al intentar mover millones de pixeles a lo loco. Eso se me da bien
Trabajo en Austria donde pagan a un junior por debajo del salario minimo del país xDDDDD, brutal, y luego nos quejamos de Españita.... xD
#3847 No me hago responsable de los destrozos.
No sé cómo se implementan estas simulaciones, así que igual no te puedo ayudar mucho. Pero en principio sí te digo que la pantalla no tiene un getpixel con lo cual para saber el estado de las partículas necesitarás tener una copia en ram de la cuardícula, no puedes operar con pixels directamente.
#3849 Sí, casi mejor tener un array2d en este caso. De todas formas sigo dándole vueltas a ver qué puedo crear para la jam de vircon32. Que me veo que va a llegar el día y no sabré lo que quiero hacer.
#3856 Por aquí? Creo que ha habido una pequeña confusión que Jastro AKA el Censuras se ha encargado de fumigar.
Y tú qué tal? Cómo llevas el plural mayestático?
Pues ha sido divertido implementar la planta:
He cambiado partes del programa, añadiendo un checksum para saber si debo seguir calculando o descansar. Solo con eso se nota una mejora en el rendimiento brutal.
El lunes abriré devlog, pero será un playground pequeño como el de la imagen. Añadiré un par o 3 de elementos (aceite, fuego, semillas, y poco más) y ya. Espero no liarme más allá de un par de semanas.
Os gusta de momento?
#3863 de momento visualmente mola mucho. Una pregunta muy tonta pero que se te puede haber pasado, estás destruyendo los granitos que salen fuera de la pantalla?
#3865 Sí, de lo primero que tuve en cuenta. Si no la memoria se me va al carajo.
Lo de no destruir objetos inútiles ya lo sufrí cuando hice el juego de entombed xd
#3866 mírate por ahí cómo hacer código óptimo, recuerdo que en la carrera tuve un profe que era muy bueno con esas cosas y estuvimos haciendo programillas para editar fotos y midiendo rendimiento y haciendo optimizaciones y llegamos a hacer cosas tipo 100 veces más rápido. Pero recuerdo que metimos código ensamblador + simd, etc o sea que no se aplica a tu caso pero igualmente hay cosas que das por sentado que hay formas más rápidas de hacerlas.
Edit: Carrera no, fue en el máster, pero vaya, lo mismo da que da lo mismo.
#3867 Lo que debería hacer, para este caso, es implementar islas. Exactamente las mismas islas que utiliza un motor para calcular las colisiones.
El motor agrupa objetos cercanos en una misma isla y solo comprueba las colisiones de cada isla. Es absurdo comprobar si una caja que está en una esquina del mapa colisiona con una pelota que está en la otra punta. Este concepto debería implementarlo aquí con los píxeles, tal y como hace Noita. Y que la arena o el agua solo se calcule junto a lo que tiene próximo, o saber si se acaba de mover para tenerlo en cuenta en el próximo ciclo, ignorar pixeles que no se han movido en el ciclo anterior, etc...
Esa es la teoría, pero traducir eso al código son palabras mayores para mí. De momento lo dejo como está y si veo que la cosa se desmadra ya veré si me interesa meterme a tocar esas cosas o abandonar el proyecto
