DFPSR

DFPSR

Una biblioteca moderna de reproducción de software para C ++ 14 usando SSE/Neon creado por David Forsgren Piuva. Si está buscando la última moda convencional, busque en otro lado. Esta es una biblioteca para el software de calidad destinado a desarrollarse durante varias décadas y sobrevivir a sus nietos con un mantenimiento mínimo. Al igual que tallar su legado en piedra, se necesita más esfuerzo para dominar la habilidad, pero da un resultado más robusto al no confiar en una biblioteca lejana. Experiencia máxima del usuario y dependencia mínima del sistema.

Antecedentes del creador

Dxomark World Record en estabilización de video digital de la industria móvil. Trabajó con una visión robótica crítica de seguridad para el control de tráfico de aeropuertos civiles. Conferencias de optimización en diferentes compañías en las industrias móviles, médicas y de juego. Trabajó con optimizaciones en GPU, CPU, DSP, ISP, FPGA y ASIC.

La optimización necesita buenas herramientas para ahorrarle tiempo

La parte más importante sobre la optimización del código es comprender los algoritmos altos y las bajas limitaciones de hardware, porque no puede permitir que un científico diseñe el algoritmo y un programador optimizarlo sin espacio para cambios en el ensamblador escrito a mano (el error más común). El diseño del algoritmo no se realiza hasta que tenga una buena compensación entre calidad y rendimiento con todas las optimizaciones establecidas. El ahorro de tiempo a costa de calidad en un lugar puede compensarse aumentando la calidad a un costo más bajo en otro lugar para aumentar la velocidad y la calidad. Cuanto más rápido pueda crear una vectorización casi óptima de un algoritmo, más rápido podrá iterar el proceso de diseño. Piense en lo que realmente está aproximando. ¿Es su objetivo dibujar tantos polígonos perfectamente rectos como sea posible, o es el objetivo de aproximar una forma compleja del mundo real utilizando cualquier técnica?

El sitio web oficial: dawoodoz.com

Cómo se verán tus juegos usando la representación de la CPU isométrica

Luz dinámica en tiempo real con sombras fundidas basadas en profundidad y mapeo normal a 453 cuadros por segundo en 800x600 píxeles que se ejecutan en la CPU. Las resoluciones más altas romperían el estilo retro y en realidad se verán peor, pero queda mucho tiempo para la lógica del juego y los efectos adicionales. Al representar previamente los modelos 3D para difundir imágenes, las imágenes normales y de altura, leer los datos es mucho más eficiente en el caché en las CPU modernas que el uso de una perspectiva libre. Esto también permite tener más triángulos que píxeles en la pantalla y realizar actualizaciones pasivas de geometría estática. Los modelos 3D de baja deterioro se utilizan para lanzar sombras dinámicas.

La representación 3D tradicional con polígonos también es compatible

La representación 3D no es tan rápida como la representación 2D o isométrica en la CPU, pero a menudo alcanza 60 Hz en 1920x1080 píxeles para gráficos bajos en deterioro. Para un nivel de detalle más alto y más características, se recomienda copiar y modificar la tubería de renderizado para que se codifique solo para las características que desea y luego simplifique las matemáticas para su motor de representación específico, como se hace para el ejemplo de Sandbox, solo se necesitan colores de vértices para los colores pequeños sin perspectiva.

¿Por qué utilizar un renderizador de software de código abierto cuando las GPU son tan rápidas?

• La robustez utilizando un renderizador de software probablemente no arruinará su sistema al cometer un error, a diferencia de las API de gráficos para la GPU que son propensas a las pantallas azules.
• Determinismo Si funcionó en una computadora, probablemente funcionará igual en otra computadora con pequeñas diferencias entre los sistemas operativos. Sin embargo, OpenGL tiene cero características restantes si elimina todo lo que tiene un error en cualquier implementación del controlador.
• Bajo sobrecarga Cuando desea una baja resolución para el estilo visual o la visión robótica, también podría mantenerlo mínimo con un renderizador de software estáticamente vinculado cuando la GPU sería más lenta.
• Depuración fácil Cuando todos los datos se procesan en un renderizador de software, es mucho más fácil ver qué salió mal durante la depuración.
• Fácil de modificar, no hay límites de hardware que no sean los ciclos y la memoria de la CPU, por lo que puede modificar toda la tubería de representación copiando y pegando el código.
• Pixel exacto 2D en lugar de hacer soluciones extrañas sobre los polígonos, un renderizador de software le permite trabajar con píxeles enteros para empezar.

¿Por qué usar este renderizador de software?

• Dependencias mínimas del sistema Todo lo relacionado con una API de sistema específica se coloca en un módulo de envoltorio separado que integra el mínimo de características esenciales que deberían ser fáciles de integrar en los sistemas operativos futuros. A diferencia de otros renderizadores de software, este no requiere ningún controlador de gráficos, ya que puede obtener el mismo rendimiento utilizando múltiples subprocesos cargando el lienzo en un hilo de fondo cuando la mayoría de los núcleos están inactivos de todos modos.
• No hay binarios, toda la biblioteca se compila automáticamente del código fuente. Incluso el sistema de compilación se está compilando antes de construir su proyecto. Esto se asegura de que nadie en el futuro tenga que revertir los binarios centenarios de ingeniería cuando intente construir su programa, y ​​también lo hace mucho más seguro contra el malware cuando todo se puede inspeccionar en un código legible.
• La vinculación estática de toda la biblioteca está vinculado estáticamente con su programa, como si hubiera escrito el código usted mismo. Solo se basan en las API del sistema central que han sobrevivido durante décadas como dependencias, sin controladores de GPU, sin capas de medios externos. Todo, desde cómo codificar los caracteres Unicode y representar fuentes hasta cómo existirá un polígono contra un búfer de profundidad dentro de su programa C ++ compilado para obtener la máxima confiabilidad y determinismo. El sistema de compilación permite vincular estáticamente las bibliotecas estándar C ++ cuando sea posible.
• Cree su software Legacy Make que las generaciones futuras puedan transferir, compilar y ejecutar de forma nativa sin la necesidad de emuladores o ingeniería inversa de controladores gráficos patentados.

Características en esta biblioteca

• Sistema de compilación C ++ totalmente automático No más listas largas de archivos fuente en su proyecto. El sistema de compilación incluido encontrará encabezados incluidos y sus archivos fuente correspondientes automáticamente. Solo dígale que se arrastre desde Main y déjelo descubrir el resto automáticamente. Se manejan diferentes backends para bibliotecas al incluir el encabezado del proyecto de la biblioteca, diciendo qué backend usar para cada plataforma. Las sumas de verificación se utilizan solo para construir lo que ha cambiado, por lo que no es necesario crear una biblioteca estática para partes de su código.
• Dibujo 2D Píxel Exacto Dibujo Estándar llamadas para líneas, rectángulos, copia de imagen continua, dibujo de imagen filtrada alfa, dibujo tamponado de profundidad y dibujo de plantilla.
• 3D renderizado aproximadamente equivalente a Direct3D 7 con muestreo de textura bi-lineal, mipmapping, mapas de luz y filtrado alfa cuando se usa fuera de la caja, pero puede modificarse para ser más como el 3D Direct 3D 9 si aplica el sombreado a las texturas (puede usar SIMD con la lectura múltiple y estar programada basada en la distancia de visualización).
• Sistema de oclusión La recopilación de tareas de representación para múltiples hilos también contiene una rejilla de oclusión donde se pueden dibujar formas de oclusión para omitir el dibujo de triángulos, objetos o grupos completos si su motor implementa una fase ancha para las pruebas de sacrificio y oclusión. Esta oclusión totalmente dinámica se puede combinar con optimizaciones estáticas para juegos específicos utilizando información sobre qué regiones se pueden ver desde cada ubicación de la cámara.
• Recorte lejano opcional Debido a que esta API de gráficos solo usa búferes de profundidad de punto flotante para perspectiva, no es necesario normalizar los valores de profundidad para cualquier representación basada en enteros. Esto permite seleccionar una distancia de clip infinita al crear su cámara, si puede permitirse la representación de toda la escena a la vez.
• Capa de medios Platforma Claus de medios diseñada para la robustez. ALSA y WinMM Backends para el control total sobre la mezcla de sonido, sin tener que llamar a cualquier cosa específica del sistema. Window Management utiliza múltiples subprocesos para cargar el lienzo, para que no necesite controladores de gráficos GPU y grandes dependencias solo para cargar el resultado. Utiliza una ventana sin frontera para la pantalla completa, para que pueda acceder fácilmente a otros programas si recibe un correo electrónico importante o un mensaje instantáneo en segundo plano. La mejora de la CPU se realiza en la CPU para funcionar con cualquier resolución de pantalla sin confiar en los controladores de gráficos que podrían dar a los píxeles la interpolación incorrecta o ni siquiera existir. Las capas de medios más antiguas diseñadas para pantallas CTR pueden causar errores de frecuencia fuera de rango cuando no se instalan controladores gráficos y la pantalla no acepta la selección arbitraria de la resolución. Utiliza un ícono del cursor invisible para ocultar el mouse, de modo que un programa de bloqueo no quite el cursor al tratar de matar el proceso.
• Marco de interfaz de usuario gráfico Cargue una interfaz visual en su ventana utilizando una sola línea de código que lee un archivo o cadena de diseño. Obtenga manijas genéricas para componentes usando nombres o una combinación de nombre e índice. Agregue eventos adjuntando las funciones LAMBDA a las devoluciones de llamada de componentes y ventanas.
• Los temporizadores obtienen los segundos de doble precisión desde la primera llamada al temporizador, para que no tenga que preocuparse por los errores de medianoche cuando se restablezca la hora del día.
• La capa de abstracción SIMD use Simd.h para generar automáticamente intrínsecos SSE, AVX y neón a partir de sintaxis matemática totalmente legible. Su código vectorizado se verá como una implementación de referencia y una compilación para una arquitectura de destino desconocida generará operaciones escalar que aún pueden dar un impulso de rendimiento al escribir su algoritmo con operaciones básicas que con mayor frecuencia se admiten directamente en el hardware de la CPU, accediendo a la memoria alineada con líneas de caché, manteniendo la ventana de instrucciones repleta de tareas y lo que es muy fácil para el autocompilador de la memoria similar con el futuro de las ventanas de las instrucciones.
• Los punteros seguros usan SafePointer.h para captar más errores diciéndole a su puntero en qué parte de una asignación puede funcionar. No deja una sobrecarga en la versión de lanzamiento, por lo que siempre puede reemplazar su puntero sin procesar con SafePointer y saber que recibirá un mensaje de error informativo con el nombre del puntero y la información detallada cuando sucede algo malo.
• Las cadenas usan UTF-32 para almacenar caracteres en la memoria para asegurarse de que todos los algoritmos funcionen con caracteres no latinos (compatibles con los literales de cadena U ""). Guardar a los archivos predeterminados a UTF-8 (almacenamiento compacto) con BOM (diciendo explícitamente qué formato se usa) y finales de línea CR LF (para que los archivos de texto codificados en cualquier lugar puedan leerse en todas partes). Utiliza buffers de memoria compartida automáticamente para permitir la división en una lista de cuerdas sin inundar el montón con pequeñas asignaciones.
• Buffers Todos los archivos se guardan y se cargan a través de objetos de búfer. Esto asegura que todos los formatos de archivo que diseñe solo tengan que preocuparse por cómo codificar los bytes, las pruebas de regresión serán fáciles al no implicar efectos secundarios externos del sistema de archivos, y cualquier archivo puede inclinarse en su cuenta utilizando el equivalente de búfer de una función de guardado.
• Gestión de archivos aproximadamente equivalente a STD :: Files System de C ++ 17, pero funciona con C ++ 14, usa los mismos tipos de cadena y readableString en todas las plataformas, y puede corregir automáticamente los separadores de carpetas entre / (Posix) y (MS-Windows).
• La gestión de procesos puede iniciar otras aplicaciones y realizar un seguimiento de su estado, para que pueda llamar a una aplicación como una función que escribe el resultado en archivos.

Resumen de licencias

Esta biblioteca utiliza principalmente la licencia de código abierto de ZLIB, pero también incluye la biblioteca de imágenes STB para guardar y cargar imágenes, que tiene una licencia dual permisiva (MIT / Unicence). Debido a que la biblioteca de imágenes STB se puede usar como dominio público, no tiene ningún efecto legal en el uso de la biblioteca en su conjunto bajo la licencia de código abierto ZLIB. Todo el código fuente incluido con todas sus licencias permite el uso comercial y no comercial, incluida la modificación no revelada del código fuente. Si no está redistribuyendo el código fuente, entonces no tiene que decirle a nadie que use esta biblioteca, porque un endoso sincera no tiene valor.

Sigue siendo una beta pública

El tema, la GUI, la fuente y las API de sonido aún están en desarrollo activo y pueden tener cambios significativos antes de que una versión estable 1.0 esté lista, porque algún código es solo un marcador de posición primitivo hasta que la implementación avanzada pueda reemplazarla, y uno debe intentar usar la biblioteca antes de que los problemas de usabilidad se vuelvan obvios. Sin embargo, el búfer, el archivo, la imagen, el dibujo, el filtro, la cadena y el tiempo de las API ya son de versión bastante estable. Puede optar por quedarse con una versión específica para cada nuevo proyecto, mantener actualizado con los últimos cambios o esperar la versión estable 1.0.

Cómo puedes ayudar

• Puerto a Macintosh o Wayland utilizando los mismos principios de dependencia mínima.
• Pruebe esta versión beta y brinde comentarios sobre el diseño antes de que se lance la versión 1.0.
• Cree diferentes tipos de motores de juego con herramientas de código abierto.

Hardware de CPU compatible:

• Intel/AMD usando intrínsecs SSE2 y extensiones opcionales.
• Brazo usando intrínsecos de neón .
• Arquitecturas de CPU desconocidas, sin la vectorización SIMD como una solución alternativa.

Plataformas:

• Linux , probado en Mint, Mate, Manjaro, Ubuntu, Raspberrypi OS, Raspbian (Buster o posterior). Linux Mint necesita el compilador y los encabezados X11, así que ejecute "sudo apt install g ++" y "sudo apt install libx11-dev" antes de compilar. Actualmente, el apoyo X11 y Wayland está planeado para futuras versiones.
• Microsoft Windows , pero más lento que en Linux porque Windows tiene muchos procesos de fondo y roscado y administración de memoria más lentos.

También podría funcionar en:

• BSD y Solaris tienen un código dirigido a las plataformas en Fileapi.cpp para obtener la carpeta de aplicación, pero es probable que falten algunas aplicaciones para ejecutar el script de compilación. Los futuros sistemas compatibles con POSIX solo deben tener unas pocas peculiaridades para resolver si tiene un servidor X11.
• Big-endian es compatible en teoría si permite la macro DSR_BIG_ENDIAN a nivel mundial, pero esto nunca se ha probado en realidad debido a las dificultades para atacar a un sistema tan antiguo con compiladores modernos.

Aún no es portado a:

• Macintosh ya no usa X11, por lo que requerirá un esfuerzo de porte. Macintosh no tiene un enlace simbólico al binario del proceso de ejecución, por lo que recurriría al directorio actual al solicitar la carpeta de la aplicación.

No se dirigirá:

• Teléfonos móviles. Debido a que los cambios constantes que rompen la compatibilidad hacia atrás en las plataformas móviles derrotarían el propósito de usar un marco de larga duración. Las plataformas móviles requieren compiladores de C ++ personalizados, acceso a procesadores de señales, rotación de pantalla, ahorro de batería, saber cuándo mostrar el teclado virtual, los permisos de seguridad, la pantalla completa forzada ... tratar de hacer ambas cosas al mismo tiempo terminaría con compromisos de diseño en ambos fines de diseño de Microsoft Windows 8 o la pantalla de bloqueo Unity de Ubuntu, por lo que sería mejor tomar bits y piezas en una nueva biblioteca construida en diferentes principios de diseño, como los principales de diseño de Microsoft 8 o la pantalla Unity de Ubuntu, por lo que sería mejor tomar bits y piezas en una nueva biblioteca construida en diferentes fines de diseño, como los principios de diseño de Microsoft 8 o la pantalla Unity de Ubuntu, sería mejor que solo tomaría bits y piezas en una nueva biblioteca construida en diferentes fines de diseño.
• Frontends web. Tal envoltura sobre esta biblioteca no podría obtener el poder de Simd Intrinsics para definir sus propios filtros de imagen, por lo que es mejor que se dirija a un lenguaje de sombreado GPU del navegador que es más adecuado para secuencias de comandos dinámicos.