fearDarkie escribió:djlogan83 escribió:
pamonti escribió:Con @eboke a muerte. Viendo el vídeo de teletienda. Qué bajeza la del señor mayor del sombrero. Lo que llega a hacer y decir uno por dinero. Pero oye, le va bien y tiene sus fans y esbirros. Y encima le pagan una casa comprándole la morralla a precio de oro. Es un cara dura, pero astuto. Se lo ha montado bien. Es el telecinco de tarde de los videojuegos.
Benzotto escribió:Además, el canal elegido fue el de Eboke, que casualmente estuvo alojando directos sobre PCFútbol 8 en su canal en el momento en el que se presentó el proyecto (directos dando detalles), siendo hasta cierto punto, un canal de difusión oficial del proyecto y con el favor de HP desde hace más de un año. Impidiendo incluso que el vaquero haga un vídeo reaccionando (cosa que hace todo cristo y es una dinámica habitual de creadores de contenido y no perjudicaría a Eboke, salvo la parte que parece que sigue deseando tener el favor de HP a pesar del trato a los usuarios de este foro en PCFutbolmanía). Así que por mi parte, siento la misma simpatía por el vaquero que por Eboke, solo que parece que Eboke cae mejor porque es usuario de aquí.
Faubert69 escribió:Sigo sin entender como eboke puede tener haters, el tio contesta siempre educadamente y con la verdad. Además hizo un directo muy decente.
(Eboke dimisión)
eboke escribió:Cabrones.
PD: Os quiero.
Benzotto escribió:Claro que ha sorprendido para bien, se esperaba ya crasheo en el menú y un poco más parecido a la rueda de prensa. Que se haya podido jugar un partido con semejante sopa de asset lo podría calificar como un milagro a la altura de los que aparecen en la biblia.
VengerDD escribió:Benzotto escribió:Claro que ha sorprendido para bien, se esperaba ya crasheo en el menú y un poco más parecido a la rueda de prensa. Que se haya podido jugar un partido con semejante sopa de asset lo podría calificar como un milagro a la altura de los que aparecen en la biblia.
Se ve que no sabes de programación, al igual que todos los que dicen que el juego no crashea o que no peta. El juego SÍ crashea y SÍ se peta, lo que pasa que ahora habrá implementado excepciones al código de las funciones (a saber si en todas o solo en algunas de ellas) o habrá pedido en el código al propio Sistema que se encargue de ellas, y eso hace que no salga ninguna pantalla de error como las que salían antes y que hacía que el juego se cerrase. Pero ¿tu has visto que en el juego hay partes en donde no responde como por ejemplo cuando se intenta cargar partida, o cuando intenta construir algo en la ciudad y no pasa nada, o cuando guarda o carga la ciudad deportiva y se queda bloqueado al 99%, o cuando tienes que pulsar varias veces en una opción y no ocurre lo que tiene que ocurrir y el juego no hace nada ni reacciona con ningún tipo de mensaje o icono de que esté procesando algo?. Todo eso son excepciones controladas y déjame decirte que por mucho que se controlen está bien porque el juego no se cierra, pero ¿de qué sirve si el juego a partir de ahí ya no va a poder continuar funcionando correctamente?.
Manejo de excepciones
Lo dicho, dejad de desinformar los que no sabéis de programación porque así le hacéis un favor al desarrollador y a los que creen que todavía esto tiene solución porque son fallitos de nada.
tonicab escribió:Es evidente que si lo retrasa indefinidamente la gente va a demandarle la pasta por lo civil o por lo criminal.
Así que esta huida hacia adelante es ganar tiempo y que no lo demanden o denuncien.
Evidentemente el juego no va a salir salvo que quiera sacar un churro.
VengerDD escribió:Benzotto escribió:Claro que ha sorprendido para bien, se esperaba ya crasheo en el menú y un poco más parecido a la rueda de prensa. Que se haya podido jugar un partido con semejante sopa de asset lo podría calificar como un milagro a la altura de los que aparecen en la biblia.
Se ve que no sabes de programación, al igual que todos los que dicen que el juego no crashea o que no peta. El juego SÍ crashea y SÍ se peta, lo que pasa que ahora habrá implementado excepciones al código de las funciones (a saber si en todas o solo en algunas de ellas) o habrá pedido en el código al propio Sistema que se encargue de ellas, y eso hace que no salga ninguna pantalla de error como las que salían antes y que hacía que el juego se cerrase. Pero ¿tu has visto que en el juego hay partes en donde no responde como por ejemplo cuando se intenta cargar partida, o cuando intenta construir algo en la ciudad y no pasa nada, o cuando guarda o carga la ciudad deportiva y se queda bloqueado al 99%, o cuando tienes que pulsar varias veces en una opción y no ocurre lo que tiene que ocurrir y el juego no hace nada ni reacciona con ningún tipo de mensaje o icono de que esté procesando algo?. Todo eso son excepciones controladas y déjame decirte que por mucho que se controlen está bien porque el juego no se cierra, pero ¿de qué sirve si el juego a partir de ahí ya no va a poder continuar funcionando correctamente?.
Manejo de excepciones
Lo dicho, dejad de desinformar los que no sabéis de programación porque así le hacéis un favor al desarrollador y a los que creen que todavía esto tiene solución porque son fallitos de nada.
eboke escribió:Cabrones.
PD: Os quiero.
DaNyPoNs8 escribió:Gracias por hacernos ver qué la basura que nos ha enseñado Héctor, en realidad lleva más basura interna oculta que disimula que no salga más mierda a la luz.
Vaya mierda de juego.
VengerDD escribió:Benzotto escribió:Claro que ha sorprendido para bien, se esperaba ya crasheo en el menú y un poco más parecido a la rueda de prensa. Que se haya podido jugar un partido con semejante sopa de asset lo podría calificar como un milagro a la altura de los que aparecen en la biblia.
Se ve que no sabes de programación, al igual que todos los que dicen que el juego no crashea o que no peta. El juego SÍ crashea y SÍ se peta, lo que pasa que ahora habrá implementado excepciones al código de las funciones (a saber si en todas o solo en algunas de ellas) o habrá pedido en el código al propio Sistema que se encargue de ellas, y eso hace que no salga ninguna pantalla de error como las que salían antes y que hacía que el juego se cerrase. Pero ¿tu has visto que en el juego hay partes en donde no responde como por ejemplo cuando se intenta cargar partida, o cuando intenta construir algo en la ciudad y no pasa nada, o cuando guarda o carga la ciudad deportiva y se queda bloqueado al 99%, o cuando tienes que pulsar varias veces en una opción y no ocurre lo que tiene que ocurrir y el juego no hace nada ni reacciona con ningún tipo de mensaje o icono de que esté procesando algo?. Todo eso son excepciones controladas y déjame decirte que por mucho que se controlen está bien porque el juego no se cierra, pero ¿de qué sirve si el juego a partir de ahí ya no va a poder continuar funcionando correctamente?.
Manejo de excepciones
Lo dicho, dejad de desinformar los que no sabéis de programación porque así le hacéis un favor al desarrollador y a los que creen que todavía esto tiene solución porque son fallitos de nada.
VengerDD escribió:Se ve que no sabes de programación, al igual que todos los que dicen que
LonelySoulGamer escribió:DaNyPoNs8 escribió:Gracias por hacernos ver qué la basura que nos ha enseñado Héctor, en realidad lleva más basura interna oculta que disimula que no salga más mierda a la luz.
Vaya mierda de juego.
No no es así para nada. Las excepciones son algo total y completamente imprescindible en cualquier programa. No es basura interna dentro del código para disimular nada.VengerDD escribió:Benzotto escribió:Claro que ha sorprendido para bien, se esperaba ya crasheo en el menú y un poco más parecido a la rueda de prensa. Que se haya podido jugar un partido con semejante sopa de asset lo podría calificar como un milagro a la altura de los que aparecen en la biblia.
Se ve que no sabes de programación, al igual que todos los que dicen que el juego no crashea o que no peta. El juego SÍ crashea y SÍ se peta, lo que pasa que ahora habrá implementado excepciones al código de las funciones (a saber si en todas o solo en algunas de ellas) o habrá pedido en el código al propio Sistema que se encargue de ellas, y eso hace que no salga ninguna pantalla de error como las que salían antes y que hacía que el juego se cerrase. Pero ¿tu has visto que en el juego hay partes en donde no responde como por ejemplo cuando se intenta cargar partida, o cuando intenta construir algo en la ciudad y no pasa nada, o cuando guarda o carga la ciudad deportiva y se queda bloqueado al 99%, o cuando tienes que pulsar varias veces en una opción y no ocurre lo que tiene que ocurrir y el juego no hace nada ni reacciona con ningún tipo de mensaje o icono de que esté procesando algo?. Todo eso son excepciones controladas y déjame decirte que por mucho que se controlen está bien porque el juego no se cierra, pero ¿de qué sirve si el juego a partir de ahí ya no va a poder continuar funcionando correctamente?.
Manejo de excepciones
Lo dicho, dejad de desinformar los que no sabéis de programación porque así le hacéis un favor al desarrollador y a los que creen que todavía esto tiene solución porque son fallitos de nada.
No voy a defender a este individuo porque me la suda, ni me se lo merece. Pero el tema programación si me interesa. No quiero ser mal pensado, pero dices que no desinformen y tu desinformas al personal, ya tienes a uno que ha picado en lo que has soltado(arriba tienes la cita). NO sé, algo me falla en esto o no lo he entendido bien o no te has explicado bien o algo de ambas. Quiero que nos expliques a los que si sabemos de programación, como tratas tu las excepciones en eso que tu llamas funciones pero que son métodos porque C# esta orientado a objetos y dentro de las clases como sabrás no se llaman funciones sino métodos. (Ya que hablas habla con propiedad).
Quiero saber que propones tu hacer con una operacion de I/O sin esas "excepciones" que dices que "si petan y crashean" el sistema cuando estan tratadas. Iluminanos a los que sabemos de programación que haces tu con las excepciones cuando accedes a la base de datos del juego. Por poner un ejemplo. Me genera mucha curiosidad, porque hablas de ellas como si fuesen un puto demonio que esconde maldades, cuando cualquiera que sepa algo de programación sabe que son imprescindibles en un programa medianamente complejo.
Creo que al menos estaremos de acuerdo en que una excepcion trata un error que evita la finalización prematura del codigo que se esta ejecutando (dicho de otro modo programa). No voy a entrar en detalles de Excepciones en tiempo de ejecución, Controladas y del sistema porque no viene a cuento ni vamos a extendernos. Asi que me choca que dijas que tratando las excepciones "si que petan y si que crashean" los procesos (Hilos o lo que lo ejecute). No sé explicanos a los que si sabemos de programación que cojones quieres decir con eso.
Porque da la impresión de que hablas del tratamiento de excepciones como si fuese una puta lacra que ralentiza el programa. Cuando eso no es así. No es el tratamiento de excepciones lo que ralentiza nada (como mucho hace lo opuesto a lo que dices) evitar que reviente el proceso (o hilo) que ejecute ese código. Lo que ralentizará el proceso es la pésima implementación del código hace de estas operaciones bloqueates (como acceso a base de datos o I/O), no las excepciones que hay que implementar por cojones en todas esas operaciones de las que hablas. Una carga de un fichero implica una excepcion de I/O (Input/Ouput) (entrada/salida) que hay que tratar si o si siempre en todo lenguaje de programación. Porque si falla el acceso al recurso es normal que el proceso termine prematuramente con un error no controlado.
Porque como sabrás una operacion de ese tipo (i/O) es bloqueante, lo que hace que la cpu tienda a dar prioridad a otro hilo (o proceso) mientras esta ejecutando el código. Asi que de por sí es normal que se ralentice el juego. De ahí que la gente que hace videojuegos con buenas prácticas de UI /UX ponga pantallas con esa informacion (barras de carga, etc) que informan al usuario. (No me extraña que alguien centrado en back-end como H.P: obvie este tipo de cosas... pero eso es otro tema).
No voy a entrar en si el código es una mierda o no, porque no puedo leerlo (aunque me encantaría). Pero como cualquier programador sabe no es problema de las excepciones que pueda tardar más o menos en ejecutarse, sino de una pésima implementación en código de los procesos de I/O o acceso a base de datos. Eso sin obvíar que de por sí ya son operaciones bloqueantes, que como bien dices requeire de informar al usuario. Y como se hace en muchos juegos informar mendiante una pantalla de carga con su barra, un loader o lo que sea (si quieres hacer buenas prácticas de UI/UX). El acceso a bases de datos puede, en determinados contextos, puede hacerse con una carga previa que puede requerir de algun hilo en parallelo (por uno de los multiples sistemas de concurrencia que hay) que a su vez pueden requerir de excepciones. No culpemos a las excepciones del codigo que haga esta gente, que no tienen culpa de nada y son total y completamente imprescindibles en un programa de estas caracteristicas. De hecho si cometió un error fue no haberlas implementado en su momento, en vez de a posteriori. Esa sería la chapuza, no el tratar las excepciones. ¡¡¡Que manda huevos tener que explicar esto!!!
LonelySoulGamer escribió:DaNyPoNs8 escribió:Gracias por hacernos ver qué la basura que nos ha enseñado Héctor, en realidad lleva más basura interna oculta que disimula que no salga más mierda a la luz.
Vaya mierda de juego.
No no es así para nada. Las excepciones son algo total y completamente imprescindible en cualquier programa. No es basura interna dentro del código para disimular nada.VengerDD escribió:Benzotto escribió:Claro que ha sorprendido para bien, se esperaba ya crasheo en el menú y un poco más parecido a la rueda de prensa. Que se haya podido jugar un partido con semejante sopa de asset lo podría calificar como un milagro a la altura de los que aparecen en la biblia.
Se ve que no sabes de programación, al igual que todos los que dicen que el juego no crashea o que no peta. El juego SÍ crashea y SÍ se peta, lo que pasa que ahora habrá implementado excepciones al código de las funciones (a saber si en todas o solo en algunas de ellas) o habrá pedido en el código al propio Sistema que se encargue de ellas, y eso hace que no salga ninguna pantalla de error como las que salían antes y que hacía que el juego se cerrase. Pero ¿tu has visto que en el juego hay partes en donde no responde como por ejemplo cuando se intenta cargar partida, o cuando intenta construir algo en la ciudad y no pasa nada, o cuando guarda o carga la ciudad deportiva y se queda bloqueado al 99%, o cuando tienes que pulsar varias veces en una opción y no ocurre lo que tiene que ocurrir y el juego no hace nada ni reacciona con ningún tipo de mensaje o icono de que esté procesando algo?. Todo eso son excepciones controladas y déjame decirte que por mucho que se controlen está bien porque el juego no se cierra, pero ¿de qué sirve si el juego a partir de ahí ya no va a poder continuar funcionando correctamente?.
Manejo de excepciones
Lo dicho, dejad de desinformar los que no sabéis de programación porque así le hacéis un favor al desarrollador y a los que creen que todavía esto tiene solución porque son fallitos de nada.
No voy a defender a este individuo porque me la suda, ni me se lo merece. Pero el tema programación si me interesa. No quiero ser mal pensado, pero dices que no desinformen y tu desinformas al personal, ya tienes a uno que ha picado en lo que has soltado(arriba tienes la cita). NO sé, algo me falla en esto o no lo he entendido bien o no te has explicado bien o algo de ambas. Quiero que nos expliques a los que si sabemos de programación, como tratas tu las excepciones en eso que tu llamas funciones pero que son métodos porque C# esta orientado a objetos y dentro de las clases como sabrás no se llaman funciones sino métodos. (Ya que hablas habla con propiedad).
Quiero saber que propones tu hacer con una operacion de I/O sin esas "excepciones" que dices que "si petan y crashean" el sistema cuando estan tratadas. Iluminanos a los que sabemos de programación que haces tu con las excepciones cuando accedes a la base de datos del juego. Por poner un ejemplo. Me genera mucha curiosidad, porque hablas de ellas como si fuesen un puto demonio que esconde maldades, cuando cualquiera que sepa algo de programación sabe que son imprescindibles en un programa medianamente complejo.
Creo que al menos estaremos de acuerdo en que una excepcion trata un error que evita la finalización prematura del codigo que se esta ejecutando (dicho de otro modo programa). No voy a entrar en detalles de Excepciones en tiempo de ejecución, Controladas y del sistema porque no viene a cuento ni vamos a extendernos. Asi que me choca que dijas que tratando las excepciones "si que petan y si que crashean" los procesos (Hilos o lo que lo ejecute). No sé explicanos a los que si sabemos de programación que cojones quieres decir con eso.
Porque da la impresión de que hablas del tratamiento de excepciones como si fuese una puta lacra que ralentiza el programa. Cuando eso no es así. No es el tratamiento de excepciones lo que ralentiza nada (como mucho hace lo opuesto a lo que dices) evitar que reviente el proceso (o hilo) que ejecute ese código. Lo que ralentizará el proceso es la pésima implementación del código hace de estas operaciones bloqueates (como acceso a base de datos o I/O), no las excepciones que hay que implementar por cojones en todas esas operaciones de las que hablas. Una carga de un fichero implica una excepcion de I/O (Input/Ouput) (entrada/salida) que hay que tratar si o si siempre en todo lenguaje de programación. Porque si falla el acceso al recurso es normal que el proceso termine prematuramente con un error no controlado.
Porque como sabrás una operacion de ese tipo (i/O) es bloqueante, lo que hace que la cpu tienda a dar prioridad a otro hilo (o proceso) mientras esta ejecutando el código. Asi que de por sí es normal que se ralentice el juego. De ahí que la gente que hace videojuegos con buenas prácticas de UI /UX ponga pantallas con esa informacion (barras de carga, etc) que informan al usuario. (No me extraña que alguien centrado en back-end como H.P: obvie este tipo de cosas... pero eso es otro tema).
No voy a entrar en si el código es una mierda o no, porque no puedo leerlo (aunque me encantaría). Pero como cualquier programador sabe no es problema de las excepciones que pueda tardar más o menos en ejecutarse, sino de una pésima implementación en código de los procesos de I/O o acceso a base de datos. Eso sin obvíar que de por sí ya son operaciones bloqueantes, que como bien dices requeire de informar al usuario. Y como se hace en muchos juegos informar mendiante una pantalla de carga con su barra, un loader o lo que sea (si quieres hacer buenas prácticas de UI/UX). El acceso a bases de datos puede, en determinados contextos, puede hacerse con una carga previa que puede requerir de algun hilo en parallelo (por uno de los multiples sistemas de concurrencia que hay) que a su vez pueden requerir de excepciones. No culpemos a las excepciones del codigo que haga esta gente, que no tienen culpa de nada y son total y completamente imprescindibles en un programa de estas caracteristicas. De hecho si cometió un error fue no haberlas implementado en su momento, en vez de a posteriori. Esa sería la chapuza, no el tratar las excepciones. ¡¡¡Que manda huevos tener que explicar esto!!!
realcnk escribió:LonelySoulGamer escribió:DaNyPoNs8 escribió:Gracias por hacernos ver qué la basura que nos ha enseñado Héctor, en realidad lleva más basura interna oculta que disimula que no salga más mierda a la luz.
Vaya mierda de juego.
No no es así para nada. Las excepciones son algo total y completamente imprescindible en cualquier programa. No es basura interna dentro del código para disimular nada.VengerDD escribió:Se ve que no sabes de programación, al igual que todos los que dicen que el juego no crashea o que no peta. El juego SÍ crashea y SÍ se peta, lo que pasa que ahora habrá implementado excepciones al código de las funciones (a saber si en todas o solo en algunas de ellas) o habrá pedido en el código al propio Sistema que se encargue de ellas, y eso hace que no salga ninguna pantalla de error como las que salían antes y que hacía que el juego se cerrase. Pero ¿tu has visto que en el juego hay partes en donde no responde como por ejemplo cuando se intenta cargar partida, o cuando intenta construir algo en la ciudad y no pasa nada, o cuando guarda o carga la ciudad deportiva y se queda bloqueado al 99%, o cuando tienes que pulsar varias veces en una opción y no ocurre lo que tiene que ocurrir y el juego no hace nada ni reacciona con ningún tipo de mensaje o icono de que esté procesando algo?. Todo eso son excepciones controladas y déjame decirte que por mucho que se controlen está bien porque el juego no se cierra, pero ¿de qué sirve si el juego a partir de ahí ya no va a poder continuar funcionando correctamente?.
Manejo de excepciones
Lo dicho, dejad de desinformar los que no sabéis de programación porque así le hacéis un favor al desarrollador y a los que creen que todavía esto tiene solución porque son fallitos de nada.
No voy a defender a este individuo porque me la suda, ni me se lo merece. Pero el tema programación si me interesa. No quiero ser mal pensado, pero dices que no desinformen y tu desinformas al personal, ya tienes a uno que ha picado en lo que has soltado(arriba tienes la cita). NO sé, algo me falla en esto o no lo he entendido bien o no te has explicado bien o algo de ambas. Quiero que nos expliques a los que si sabemos de programación, como tratas tu las excepciones en eso que tu llamas funciones pero que son métodos porque C# esta orientado a objetos y dentro de las clases como sabrás no se llaman funciones sino métodos. (Ya que hablas habla con propiedad).
Quiero saber que propones tu hacer con una operacion de I/O sin esas "excepciones" que dices que "si petan y crashean" el sistema cuando estan tratadas. Iluminanos a los que sabemos de programación que haces tu con las excepciones cuando accedes a la base de datos del juego. Por poner un ejemplo. Me genera mucha curiosidad, porque hablas de ellas como si fuesen un puto demonio que esconde maldades, cuando cualquiera que sepa algo de programación sabe que son imprescindibles en un programa medianamente complejo.
Creo que al menos estaremos de acuerdo en que una excepcion trata un error que evita la finalización prematura del codigo que se esta ejecutando (dicho de otro modo programa). No voy a entrar en detalles de Excepciones en tiempo de ejecución, Controladas y del sistema porque no viene a cuento ni vamos a extendernos. Asi que me choca que dijas que tratando las excepciones "si que petan y si que crashean" los procesos (Hilos o lo que lo ejecute). No sé explicanos a los que si sabemos de programación que cojones quieres decir con eso.
Porque da la impresión de que hablas del tratamiento de excepciones como si fuese una puta lacra que ralentiza el programa. Cuando eso no es así. No es el tratamiento de excepciones lo que ralentiza nada (como mucho hace lo opuesto a lo que dices) evitar que reviente el proceso (o hilo) que ejecute ese código. Lo que ralentizará el proceso es la pésima implementación del código hace de estas operaciones bloqueates (como acceso a base de datos o I/O), no las excepciones que hay que implementar por cojones en todas esas operaciones de las que hablas. Una carga de un fichero implica una excepcion de I/O (Input/Ouput) (entrada/salida) que hay que tratar si o si siempre en todo lenguaje de programación. Porque si falla el acceso al recurso es normal que el proceso termine prematuramente con un error no controlado.
Porque como sabrás una operacion de ese tipo (i/O) es bloqueante, lo que hace que la cpu tienda a dar prioridad a otro hilo (o proceso) mientras esta ejecutando el código. Asi que de por sí es normal que se ralentice el juego. De ahí que la gente que hace videojuegos con buenas prácticas de UI /UX ponga pantallas con esa informacion (barras de carga, etc) que informan al usuario. (No me extraña que alguien centrado en back-end como H.P: obvie este tipo de cosas... pero eso es otro tema).
No voy a entrar en si el código es una mierda o no, porque no puedo leerlo (aunque me encantaría). Pero como cualquier programador sabe no es problema de las excepciones que pueda tardar más o menos en ejecutarse, sino de una pésima implementación en código de los procesos de I/O o acceso a base de datos. Eso sin obvíar que de por sí ya son operaciones bloqueantes, que como bien dices requeire de informar al usuario. Y como se hace en muchos juegos informar mendiante una pantalla de carga con su barra, un loader o lo que sea (si quieres hacer buenas prácticas de UI/UX). El acceso a bases de datos puede, en determinados contextos, puede hacerse con una carga previa que puede requerir de algun hilo en parallelo (por uno de los multiples sistemas de concurrencia que hay) que a su vez pueden requerir de excepciones. No culpemos a las excepciones del codigo que haga esta gente, que no tienen culpa de nada y son total y completamente imprescindibles en un programa de estas caracteristicas. De hecho si cometió un error fue no haberlas implementado en su momento, en vez de a posteriori. Esa sería la chapuza, no el tratar las excepciones. ¡¡¡Que manda huevos tener que explicar esto!!!
O no has entendido al compañero o no lo has querido entender.
Una cosa es manejar una excepcion y otra cosa es no reaccionar a una excepcion, permitir que el codigo continue como pueda y asi evitar excepciones no controladas porque no sabes que la provoca.
En el try/catch puedes poner codigo que maneje lo que esta pasando, o dejarlo vacio para mirar para otro lado, que es lo que se ha hecho en la demo, para que la gente no vea que se rompe por todos lados.
Me hace gracia que pienses que en esa demo haya codigo asincrono.
LonelySoulGamer escribió:DaNyPoNs8 escribió:Gracias por hacernos ver qué la basura que nos ha enseñado Héctor, en realidad lleva más basura interna oculta que disimula que no salga más mierda a la luz.
Vaya mierda de juego.
No no es así para nada. Las excepciones son algo total y completamente imprescindible en cualquier programa. No es basura interna dentro del código para disimular nada.VengerDD escribió:Benzotto escribió:Claro que ha sorprendido para bien, se esperaba ya crasheo en el menú y un poco más parecido a la rueda de prensa. Que se haya podido jugar un partido con semejante sopa de asset lo podría calificar como un milagro a la altura de los que aparecen en la biblia.
Se ve que no sabes de programación, al igual que todos los que dicen que el juego no crashea o que no peta. El juego SÍ crashea y SÍ se peta, lo que pasa que ahora habrá implementado excepciones al código de las funciones (a saber si en todas o solo en algunas de ellas) o habrá pedido en el código al propio Sistema que se encargue de ellas, y eso hace que no salga ninguna pantalla de error como las que salían antes y que hacía que el juego se cerrase. Pero ¿tu has visto que en el juego hay partes en donde no responde como por ejemplo cuando se intenta cargar partida, o cuando intenta construir algo en la ciudad y no pasa nada, o cuando guarda o carga la ciudad deportiva y se queda bloqueado al 99%, o cuando tienes que pulsar varias veces en una opción y no ocurre lo que tiene que ocurrir y el juego no hace nada ni reacciona con ningún tipo de mensaje o icono de que esté procesando algo?. Todo eso son excepciones controladas y déjame decirte que por mucho que se controlen está bien porque el juego no se cierra, pero ¿de qué sirve si el juego a partir de ahí ya no va a poder continuar funcionando correctamente?.
Manejo de excepciones
Lo dicho, dejad de desinformar los que no sabéis de programación porque así le hacéis un favor al desarrollador y a los que creen que todavía esto tiene solución porque son fallitos de nada.
No voy a defender a este individuo porque me la suda, ni me se lo merece. Pero el tema programación si me interesa. No quiero ser mal pensado, pero dices que no desinformen y tu desinformas al personal, ya tienes a uno que ha picado en lo que has soltado(arriba tienes la cita). NO sé, algo me falla en esto o no lo he entendido bien o no te has explicado bien o algo de ambas. Quiero que nos expliques a los que si sabemos de programación, como tratas tu las excepciones en eso que tu llamas funciones pero que son métodos porque C# esta orientado a objetos y dentro de las clases como sabrás no se llaman funciones sino métodos. (Ya que hablas habla con propiedad).
Quiero saber que propones tu hacer con una operacion de I/O sin esas "excepciones" que dices que "si petan y crashean" el sistema cuando estan tratadas. Iluminanos a los que sabemos de programación que haces tu con las excepciones cuando accedes a la base de datos del juego. Por poner un ejemplo. Me genera mucha curiosidad, porque hablas de ellas como si fuesen un puto demonio que esconde maldades, cuando cualquiera que sepa algo de programación sabe que son imprescindibles en un programa medianamente complejo.
Creo que al menos estaremos de acuerdo en que una excepcion trata un error que evita la finalización prematura del codigo que se esta ejecutando (dicho de otro modo programa). No voy a entrar en detalles de Excepciones en tiempo de ejecución, Controladas y del sistema porque no viene a cuento ni vamos a extendernos. Asi que me choca que dijas que tratando las excepciones "si que petan y si que crashean" los procesos (Hilos o lo que lo ejecute). No sé explicanos a los que si sabemos de programación que cojones quieres decir con eso.
Porque da la impresión de que hablas del tratamiento de excepciones como si fuese una puta lacra que ralentiza el programa. Cuando eso no es así. No es el tratamiento de excepciones lo que ralentiza nada (como mucho hace lo opuesto a lo que dices) evitar que reviente el proceso (o hilo) que ejecute ese código. Lo que ralentizará el proceso es la pésima implementación del código hace de estas operaciones bloqueates (como acceso a base de datos o I/O), no las excepciones que hay que implementar por cojones en todas esas operaciones de las que hablas. Una carga de un fichero implica una excepcion de I/O (Input/Ouput) (entrada/salida) que hay que tratar si o si siempre en todo lenguaje de programación. Porque si falla el acceso al recurso es normal que el proceso termine prematuramente con un error no controlado.
Porque como sabrás una operacion de ese tipo (i/O) es bloqueante, lo que hace que la cpu tienda a dar prioridad a otro hilo (o proceso) mientras esta ejecutando el código. Asi que de por sí es normal que se ralentice el juego. De ahí que la gente que hace videojuegos con buenas prácticas de UI /UX ponga pantallas con esa informacion (barras de carga, etc) que informan al usuario. (No me extraña que alguien centrado en back-end como H.P: obvie este tipo de cosas... pero eso es otro tema).
No voy a entrar en si el código es una mierda o no, porque no puedo leerlo (aunque me encantaría). Pero como cualquier programador sabe no es problema de las excepciones que pueda tardar más o menos en ejecutarse, sino de una pésima implementación en código de los procesos de I/O o acceso a base de datos. Eso sin obvíar que de por sí ya son operaciones bloqueantes, que como bien dices requeire de informar al usuario. Y como se hace en muchos juegos informar mendiante una pantalla de carga con su barra, un loader o lo que sea (si quieres hacer buenas prácticas de UI/UX). El acceso a bases de datos puede, en determinados contextos, puede hacerse con una carga previa que puede requerir de algun hilo en parallelo (por uno de los multiples sistemas de concurrencia que hay) que a su vez pueden requerir de excepciones. No culpemos a las excepciones del codigo que haga esta gente, que no tienen culpa de nada y son total y completamente imprescindibles en un programa de estas caracteristicas. De hecho si cometió un error fue no haberlas implementado en su momento, en vez de a posteriori. Esa sería la chapuza, no el tratar las excepciones. ¡¡¡Que manda huevos tener que explicar esto!!!
Jota182SP escribió:A sido pero enseñar que seguir haciendo ghosting.... quien lo hubiera pensado.
freakstyler escribió:
11 horas despues:
Gelion escribió:Jota182SP escribió:A sido pero enseñar que seguir haciendo ghosting.... quien lo hubiera pensado.
Creo que es el mensaje más ininteligible que he leído nunca en un foro. Felicidades.
30 de abril
17 de mayo
7 de junio
24 de junio
Semana del 15 al 21 de julio
5 de agosto
7 de agosto
12 de agosto
6 de septiembre
12 de septiembre
13 de septiembre
Antes de dos semanas
24 de octubre
En 1 o 2 días
1 de noviembre
3 de noviembre
15 de noviembre