User Tag List

Página 5 de 6 PrimerPrimer 123456 ÚltimoÚltimo
Resultados 61 al 75 de 82

Tema: Programando en MSDOS con VGA

  1. #61

    Fecha de ingreso
    Sep 2006
    Mensajes
    5,334
    Mencionado
    31 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    781
    Agradecer Thanks Received 
    766
    Thanked in
    Agradecido 556 veces en [ARG:2 UNDEFINED] posts
    Es que el scroll por hardware lo único que hace es cambiar la dirección y el pixel por donde empieza a dibujar la pantalla, no te mueve nada, ves los mismos datos pero como ha empezado a leer en otra dirección de memoria ves los datos desplazados.

    ¿A la hora de dibujar un tile en el mapa como lo dibujas? Porque no es como un sprite que tengas que "hacer mascara" para los pixels transparentes. Tal vez la parte lenta este a la hora de representar el mapa o parte de el en pantalla.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  2. #62

    Fecha de ingreso
    Sep 2005
    Mensajes
    11,890
    Mencionado
    185 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    264
    Agradecer Thanks Received 
    650
    Thanked in
    Agradecido 459 veces en [ARG:2 UNDEFINED] posts
    Uso BennuGD... o Fenix, según lo antiguo que sea el cacharro.
    El problema está en que usa un "blitter" propio, que se encarga de dibujar todos los gráficos (sprites, mapas, scrolls, modos7...) en una única SDLSurface, y aunque está bien programado, es un proceso que se repite con cada gráfico, y se hace todo en la segunda capa más alta (la más alta sería el código Fenix/Bennu, la segunda la del motor en C, y ya por debajo SDL), con lo que se pierde mucho rendimiento y, en palabras de uno de los desarrolladores "no se aprovecha toda la potencia y propiedades de SDL" en favor de una mayor compatibilidad. Por eso se está intentando portar Bennu a OpenGL, pero es un proceso lento y, a día de hoy, una guerra de un solo hombre.

    Si a eso le sumas que el motor mío de scroll tileado se hace en la capa más alta de código, el resultado es una GP2X o una Wiz que a duras penas puede mover un scroll de 24x18 procesos, o que repinte un gráfico de 320x240 a cada frame. Por eso buscaba una forma de usar el scroll, que haría las veces de "scroll HW", con un mapa que se dibujase de forma cíclica, pero en cuanto tenía que repintar más de 40 tiles de 16x16, el uso de "procesos" se volvía más eficiente... al menos, en las pruebas que he hecho... Pero llevo tiempo sospechando que la pérdida de rendimiento no viene por el tema del scroll, ni del número de procesos, ni de lo bien que yo optimice mi código... Como si el propio blitter, al tener que dibujar tantos "sprites" con transparencias, se volviera extremadamente ineficiente.
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  3. El siguiente usuario agradece a Drumpi este mensaje:

    fbustamante (09/07/2020)

  4. #63

    Fecha de ingreso
    Sep 2006
    Mensajes
    5,334
    Mencionado
    31 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    781
    Agradecer Thanks Received 
    766
    Thanked in
    Agradecido 556 veces en [ARG:2 UNDEFINED] posts
    Es que para los decorados/mapa no necesitas dibujarlo como un sprite, con hacer el equivalente a un "memcpy" seria suficiente. Claro que si eso no esta metido en el BennuGD/Fenix pues estas perdiendo el tiempo haciendo cosas de mas.

    Tal vez lo mejor sea meter funciones nuevas para manejar una capa hecha por tiles. Supongo que por eso algunos juegos que he visto hechos en fénix los decorados eran un bitmap enorme.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  5. #64

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    2,739
    Mencionado
    79 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    162
    Agradecer Thanks Received 
    406
    Thanked in
    Agradecido 244 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Drumpi Ver mensaje
    Claro, a eso voy, a las rutinas de dibujado. Yo pensaba que tal vez el scroll por HW haría las tareas de "dibujado", pero si es algo que depende del código, hay que ser imaginativo y reducir el número de operaciones.
    Es el problema que tengo en mi scroll tileado, especialmente con uno de los que diseñé para Wiz, que se parece mucho a este problema, sobre todo porque las primitivas de dibujado sobre un mapa son relativamente lentas. Quería comprobar si alguna técnica de los 70-90 me podría servir para optimizar el código.
    Drumpi, eso ya lo resolví en Fénix / Bennu hace la tela,

    Busca el hilo con la demo técnica de la fase 3 de Viaje al Centro de La Tierra. Es un scroll de dos capas con tiles de 16x16, en Fénix. En GP2X F200 a 200MHz corre a 90 fps

    NeoGeo tiene la solución a tu problema, la forma en que se hace el scroll para esa máquina da muy buenos resultados en Fénix /Bennu

  6. #65

    Fecha de ingreso
    Sep 2005
    Mensajes
    11,890
    Mencionado
    185 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    264
    Agradecer Thanks Received 
    650
    Thanked in
    Agradecido 459 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    Es que para los decorados/mapa no necesitas dibujarlo como un sprite, con hacer el equivalente a un "memcpy" seria suficiente. Claro que si eso no esta metido en el BennuGD/Fenix pues estas perdiendo el tiempo haciendo cosas de mas.

    Tal vez lo mejor sea meter funciones nuevas para manejar una capa hecha por tiles. Supongo que por eso algunos juegos que he visto hechos en fénix los decorados eran un bitmap enorme.
    No, no hay memcpy en Fenix/Bennu porque es un lenguaje de alto nivel. Hay algunas funciones para acceder al buffer de gráficos, y... bueno, sí que hay una función, creo, para copiar una serie de bytes en una zona de memoria, pero no recuerdo si no lo usé por ser demasiado avanzado o porque al final tenía el mismo rendimiento.
    De todas formas, no pierdo el tiempo, al contrario, tengo que intentar evitar hacer la mayor cantidad de operaciones, y usar lo más que pueda del nivel que tengo justo debajo para eso, para mejorar el rendimiento. Si lo dejo como está, pues no irá a la velocidad adecuada.

    Cita Iniciado por masteries Ver mensaje
    Drumpi, eso ya lo resolví en Fénix / Bennu hace la tela,

    Busca el hilo con la demo técnica de la fase 3 de Viaje al Centro de La Tierra. Es un scroll de dos capas con tiles de 16x16, en Fénix. En GP2X F200 a 200MHz corre a 90 fps

    NeoGeo tiene la solución a tu problema, la forma en que se hace el scroll para esa máquina da muy buenos resultados en Fénix /Bennu
    Mmmm, si no recuerdo mal, tu opción era crear un mapa grande y usar alguna de las funciones MAP_PUT para ir poniendo los tiles y luego usar el scroll de Fenix ¿no?
    Si era eso, esa opción no me sirve, porque mis mapas sobrepasan por mucho el tamaño máximo de un mapa, y gastaría cerca de 10MB en una sola capa (el nivel 3 de "ese" juego eran más de 300x25 tiles de 16x16, no recuerdo bien las cifras). Mi actual método me permite crear mapas casi infinitos, con un consumo de menos de 1MB de RAM (el 80% es el tamaño del FPG con los tiles ), y sin ninguna carga recuerdo haber conseguido velocidades de 65fps en GP2X F100 y de 95fps en Wiz sin overclock.
    Con el scroll que te comento, dibujando en un mapa en un scroll cíclico, he conseguido mejoras de rendimiento notables en PC, y más o menos se nota en las portátiles, pero cuando les he puesto el resto del código encima, no había diferencia ninguna... e incluso diría que iba más lento.

    Ahora, si era otra forma, lo siento, pero sólo recuerdo esa, una dll de scroll que nunca se portó a otras plataformas diferentes de PC y poco más ^^U

    No sé, ya me rendí en su momento: probé eliminando los collision, probé eliminando los enemigos, y creo que hasta quitando el scroll, y por alguna razón, seguía yendo lento.
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  7. #66

    Fecha de ingreso
    Oct 2012
    Mensajes
    190
    Mencionado
    1 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1
    Agradecer Thanks Received 
    77
    Thanked in
    Agradecido 30 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por masteries Ver mensaje
    También queda dibujar sprites y no redibujar todo el espacio que ocupaban, sólo los tiles que hayan quedado al descubierto, necesario para utilizar sprites de gran tamaño.
    Eso no se me había ocurrido...

    Cita Iniciado por Drumpi Ver mensaje
    ¿qué pasa cuando el salto es mayor? ¿Cuando se avancen 14 pixels de golpe?
    No pasa nada... ves toda la VRAM sin modificar, restos de sprites y de basura...

    Cuando entras a un mapa nuevo, o te teletransportas, te toca dibujar todo el buffer de la VGA y esconderlo poniendo toda la paleta de colores en negro.

    Cita Iniciado por masteries Ver mensaje
    en MegaDrive lo que haces es dibujar uno sólo de los tiles de 8x8 , de los 4 que componen un tile de 16x16; y dibujas 1 tile, o 2, o 3... dependiendo de si has avanzado 1 pixel, 2, 3...
    Esas maquinas estilo MegaDrive, Snes... etc solo funcionan en una especie de modo texto, pero con 16 colores por celda, lo único que hacen es cambiar una fila o columna de celdas (y cada celda solo esta definida con uno o dos bytes que definen el nº de carácter).

    Eso se puede hacer en VGA, porque el scroll por hardware pixel a pixel funciona también en modo texto. Lo que pasa es que cada celda solo tiene dos colores, como el zx spectrum,(el fondo y el color del texto) y además tienes que cargar caracteres modificados a la VGA si quieres hacer algo parecido a un juego, (se puede pero yo aún no he sido capaz).
    Despues podrias simular un sprite modificando las celdas, como hacen los juegos del spectrum.

    Cita Iniciado por Drumpi Ver mensaje
    el resultado es una GP2X o una Wiz que a duras penas puede mover un scroll de 24x18 procesos.
    ¿No hay nada remotamente parecido a OpenGL para esos cacharros aunque no esté portado directamente?

    Si usas algo parecido a OpenGL, puedes funcionar casi como una consola típica o un modo texto, solamente dibujas un plano hecho de cuadrados y vas cambiando la coordenada de textura de cada uno, para definir que tiles tienen, así hice yo un mini motor de prueba y es rápido para procesadores lentos, funcionaba en un windows con OpenGL 1.0 y CPU de unos 400Mhz, y a penas consumía CPU.

    Cita Iniciado por masteries Ver mensaje
    Drumpi, eso ya lo resolví en Fénix / Bennu hace la tela
    Bueno entonces casi sobra mi ultimo párrafo, pero lo dejo ahí por si alguien lee esto y le da por el OpenGL.
    Última edición por mills332; 09/07/2020 a las 18:32

  8. #67

    Fecha de ingreso
    Sep 2009
    Ubicación
    Málaga
    Mensajes
    2,992
    Mencionado
    81 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    4,098
    Agradecer Thanks Received 
    688
    Thanked in
    Agradecido 376 veces en [ARG:2 UNDEFINED] posts
    Bueno. Que conste que a mí la conversación me parece interesante, aunque pille sólo la mitad.

    Hace más el que quiere que el que puede.

    Proyectos: Wizor (100%). Bennu File Manager (100%). Remake gráfico Echo 99%.

  9. #68

    Fecha de ingreso
    Sep 2005
    Mensajes
    11,890
    Mencionado
    185 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    264
    Agradecer Thanks Received 
    650
    Thanked in
    Agradecido 459 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por mills332 Ver mensaje
    Si usas algo parecido a OpenGL, puedes funcionar casi como una consola típica o un modo texto, solamente dibujas un plano hecho de cuadrados y vas cambiando la coordenada de textura de cada uno, para definir que tiles tienen, así hice yo un mini motor de prueba y es rápido para procesadores lentos, funcionaba en un windows con OpenGL 1.0 y CPU de unos 40
    Los motores Fenix y BennuGD usan SDL por compatibilidad, y siempre en modo software. Eso ha permitido que se haya portado a múltiples máquinas casi sin cambios y de forma inmediata: Windows, Linux, GP2X, Wiz, PSP, PS2, Wii, Dreamcast, Ouya, Android...
    Hay un proyecto para crear una versión de BennuGD en OpenGL, pero SplinterGU es el único que lo está desarrollando y no tiene demasiado tiempo libre, así que alguien que le ayude le vendría bien

    Cita Iniciado por fbustamante Ver mensaje
    Bueno. Que conste que a mí la conversación me parece interesante, aunque pille sólo la mitad.
    Pues lo que no pilles, lo preguntas, así aprendes y disfrutas
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  10. El siguiente usuario agradece a Drumpi este mensaje:

    fbustamante (10/07/2020)

  11. #69

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    2,739
    Mencionado
    79 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    162
    Agradecer Thanks Received 
    406
    Thanked in
    Agradecido 244 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Drumpi Ver mensaje
    Los motores Fenix y BennuGD usan SDL por compatibilidad, y siempre en modo software. Eso ha permitido que se haya portado a múltiples máquinas casi sin cambios y de forma inmediata: Windows, Linux, GP2X, Wiz, PSP, PS2, Wii, Dreamcast, Ouya, Android...
    xD He leído eso y me parto. El caso de esa máquina es muy particular, porque las SDL están implementadas sin tener en cuenta muchas historias del hardware, necesarias pero no imprescindibles, y por tanto las SDL rinden y funcionan ahí como el ****. Lo más que pude hacer, es parchear aquello que sí sabía y también tuve que reescribir las SDL_sound, porque ahí o tiras de interrupciones y DMA o lo llevabas claro para reproducir sonidos de forma decente.

    Y aún es un parcheo pobre, porque los juegos originales usan la CPU de PS1, presente en PS2, para implementar el mezclador de audio y encolar la reproducción de sonidos; se permiten comprimir el sonido y todo... pero no tengo ejemplos de cómo hacer eso

    Falta demasiada documentación y ejemplos en PS2 Por ejemplo en PS2 no hay gestión de memoria implementada, los malloc existen, pero cuando descargas algo de la RAM, eres tú mismo el que tiene que desfragmentar la memoria, para que puedas volver a cargar cosas; en los juegos comerciales se lo implementan ellos.

    El de DreamCast tengo entendido que también petardea un poco por asuntos parecidos,

  12. #70

    Fecha de ingreso
    Sep 2005
    Mensajes
    11,890
    Mencionado
    185 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    264
    Agradecer Thanks Received 
    650
    Thanked in
    Agradecido 459 veces en [ARG:2 UNDEFINED] posts
    Ya, pero la cosa es que estás mencionando problemas del port de SDL, no de Fenix o BennuGD
    Siempre se ha dicho "si hay un port de SDL, se puede portar Fenix", pero claro, el port de SDL tiene que estar bien hecho, tener en cuenta todas esas cosillas HW/SW del aparato...

    El problema es portar SDL. Una vez hecho, el port, en teoría es sencillo... no inmediato porque hay que hacer ciertos cambios, como cierto mapeo de botones, ajustar los tiempos para sincronizar los FPS... depende del bicho al que vaya. Yo pude compilar BennuGD para GP2X y lo único que tuve que cambiar fue la constante del OS-ID, un par de botones mal mapeados, y listo, el resto fue casi copiar las cosas de Wiz.
    Y claro, hice dos versiones porque hubo dos versiones de SDL: las del firm oficial y las del Open2X. Con el firm oficial funcionaba de lujo, pero algo más lento porque eran SDLs más antiguas, y el firm Open2X iba mejor, pero el sonido se desfasaba medio segundo, pero ya no me puse a investigar por qué.
    Y eso es lo que le achaco a la versión de RG350, que hay un par de botones mal mapeados (A y B, al parecer), que el OS-ID es el de Linux (por lo que no puedo saber si estoy ejecutando en PC o en la consola), y la versión que es bastante antigua. Tampoco que BennuGD venga integrado en el firm sin posibilidad de cargar una versión más moderna desde la SD.

    Pero es eso, la mayoría de problemas de DC es por el port SDL, o al menos, creo que los problemas que había poco tenían que ver con la parte de Bennu.
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  13. #71

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    2,739
    Mencionado
    79 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    162
    Agradecer Thanks Received 
    406
    Thanked in
    Agradecido 244 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Drumpi Ver mensaje

    Pero es eso, la mayoría de problemas de DC es por el port SDL, o al menos, creo que los problemas que había poco tenían que ver con la parte de Bennu.
    Efectivamente, es un problema de los drivers para el hardware que está debajo, que no están bien hechos.
    Esas máquinas como no tienen un S.O. con los drivers, si no que los tienes que incluir tú mismo en el juego / programa, pues el curro necesario es para alucinar xD

    El mezclador de audio (bueno es un driver para el adaptador de audio) que tuve que escribir para la PS2 y su port de Bennu, está casi reaprovechado 1:1 para el STE
    Última edición por masteries; 13/07/2020 a las 19:59

  14. #72

    Fecha de ingreso
    Sep 2005
    Mensajes
    11,890
    Mencionado
    185 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    264
    Agradecer Thanks Received 
    650
    Thanked in
    Agradecido 459 veces en [ARG:2 UNDEFINED] posts
    Vale, pero no me digas que BennuGD no es fácil de portar a PS2, si todo el problema es de SDL, porque me dejas por mentiroso sin razón

    La idea de SDL es la de abstraer al código del HW o del SW que hay debajo. Claro que, si debajo no hay drivers, ni SO ni na de na, pues hay que implementarlo
    Así que, si ya tienes las SDL... o parte de ellas en el STE, ya estás tardando en portar BennuGD Ya sólo falta el port al frigorífico ese del anuncio y a la Pokemon Mini.

    Por cierto, muchas gracias por el curro de portar Bennu (y SDL) a PS2. Te lo dije en su día, pero nunca está de más repetirse Es bueno para el ego y las endorfinas esas
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  15. #73

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    2,739
    Mencionado
    79 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    162
    Agradecer Thanks Received 
    406
    Thanked in
    Agradecido 244 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Drumpi Ver mensaje
    Por cierto, muchas gracias por el curro de portar Bennu (y SDL) a PS2. Te lo dije en su día, pero nunca está de más repetirse Es bueno para el ego y las endorfinas esas
    Tampoco es un port tan bueno; me habría gustado usar la CPU de PS1 para el tema del audio (es lo que hacen los juegos comerciales), pero no sé cómo hacerlo... y luego está el problema de cargar datos en memoria y descargarlos, que las funciones load y unload de Bennu no tienen su respaldo; cuando haces un unload los datos se descargan, pero la memoria no se desfragmenta y si descargas y cargas muchas cosas... al final te quedas sin memoria disponible, porque ésta queda como un queso gruyere.


    Los juegos comerciales implementan ellos mismos sus funciones "malloc y free"; y lo hacen usando otra vez la CPU de PS1, y tampoco sé cómo hacerlo...

    Al final lo único que descargo cuando uso Bennu en PS2 es lo último que metía en memoria; el enorme .wav con la música... así no se queda fragmentada la memoria.


    Por cierto, en el ST y el STE no estamos teniendo estos problemas al hacer free; tal vez estas implementaciones vienen en la ROM de la máquina; es triste que PS2 lo único que tenga es un kernel en tiempo-real como el de un microcontrolador, y ni funciones ni leches... Una falta de doc. / ejemplos muy grande, o la falta del SDK comercial, más bien esto último.

  16. #74

    Fecha de ingreso
    Sep 2005
    Mensajes
    11,890
    Mencionado
    185 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    264
    Agradecer Thanks Received 
    650
    Thanked in
    Agradecido 459 veces en [ARG:2 UNDEFINED] posts
    Recuerdo que en su momento se solía decir que era muy difícil programar para PS2, y creo que para PS3. Los detalles los desconozco, pero lo suyo es que haya algún tipo de documentación, aunque no sea la oficial.
    Pero bueno, no creo que a estas alturas te venga nadie con exigencias. Supongo que se hacía así para que la gente pudiera aprovechar el 100% de la máquina, sin depender de un SO, un firm o algo por debajo que se dedique a consumir recursos, al fin y al cabo, es una consola y no es multitarea.
    Está bien saber lo de la memoria, para tener cuidado cuando se haga un juego para ella, no vaya a a ser que por aprovechar la memoria y andar cargando y descargando nos quedemos sin
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  17. #75

    Fecha de ingreso
    Dec 2004
    Mensajes
    27,685
    Mencionado
    179 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    110
    Agradecer Thanks Received 
    1,906
    Thanked in
    Agradecido 1,208 veces en [ARG:2 UNDEFINED] posts
    Entradas de blog
    11
    Lo de ps3 era porque estaba "mal diseñada", pues no es lo mismo un porcesador multicore que tener un monocore con varios SPEs. Mientras que un multicore es relativamente facil de programar (cada core hace una cosa), en un procesador monocore con varios SPEs, el core principal es el que reparte el trabajo entre los hilos de los SPEs, por lo que es muy facil provocar un cuello de botella si no se programa con cuidado.
    Google stadia es un fracaso, google stadia funciona mal, google admite su fracaso con stadia la latencia es el problema intrinseco de stadia, el público abandona google stadia, stadia mal.

Página 5 de 6 PrimerPrimer 123456 ÚltimoÚltimo

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •