Using an artificial intelligence model from the company, I created this code that contains the logic needed to run the game at a stable 60 FPS, with a refresh rate of 16.66 ms.

code:



credits

Phantom

FPS map Elbland 24FPS :(

FPS map Elbland 24FPS :(

The main issue is a performance bottleneck, not FPS throttling. When FPS drops, it's because the RenderMainScene() function (which draws everything on the screen) or Update() functions (such as physics and game logic) are taking too long to complete.

Fixed time step: The code calculates a lag and then executes a while loop (lag >= MS_PER_UPDATE). This loop ensures that all game logic (g_PhysicsManager.Move, MoveMainScene, etc.) updates exactly to MS_PER_UPDATE (16.66 ms) each time. This keeps the game simulation consistent, even if rendering is delayed.

The bottleneck: The drop to 24 FPS on the Elbeland map means that the time it takes to render the scene (RenderMainScene) plus the time to execute the while loop once is significantly longer than the target of 16.66 ms. Increasing the FPS limit won't speed up these slow functions; it will just tell the program to attempt to render more often, which is already failing.

The most likely cause is the number of objects or the complexity of rendering in the Elbeland map, which makes RenderMainScene() very slow.

The right way to fix the problem
To improve performance and maintain stable FPS, you need to optimize the code itself.

Analyze the code: The first step is to identify the exact cause of the performance drop. Use a profiler to see which functions are consuming the most time in Elbeland. It's most likely RenderMainScene() or g_PhysicsManager.Move().

Optimize rendering:

Level of Detail (LOD): Render simplified versions of distant objects or don't render them at all.

Textures and models: Use smaller textures, optimize models, or implement instance rendering for repeating objects like trees or grass.

Occlusion Culling: Don't render objects that are hidden behind others.

Optimizing Game Logic:

Spatial Partitioning: Instead of checking each object against all others for collisions or updates, use a grid or quadtree to check only nearby objects.

Dynamic Performance Scaling: A more complex, but effective, solution is to dynamically adjust the game's detail based on performance. For example, if the FPS drops below 60, you could reduce the number of visual effects, particles, or dynamic lights.

In short, changing the FPS target is a superficial solution. To properly solve the problem, you need to find the specific parts of the code that are causing the performance issues in Elbeland and optimize them. The game loop with the lag variable is already doing its job by separating the game logic from the rendering. The problem is that the computer can't keep up with what you're asking of it in that particular map.

Google translate:

El problema principal es un cuello de botella en el rendimiento, no la limitación de FPS. Cuando los FPS bajan, es porque la función RenderMainScene() (que dibuja todo en la pantalla) o las funciones Update() (como la física y la lógica del juego) están tardando demasiado en completarse.

Paso de tiempo fijo: El código calcula un lag y luego ejecuta un bucle while (lag >= MS_PER_UPDATE). Este bucle asegura que toda la lógica del juego (g_PhysicsManager.Move, MoveMainScene, etc.) se actualice exactamente a MS_PER_UPDATE (16.66ms) por vez. Esto mantiene la simulación del juego consistente, incluso si el renderizado se retrasa.

El cuello de botella: La caída a 24 FPS en el mapa de Elbeland significa que el tiempo que tarda en renderizar la escena (RenderMainScene) más el tiempo para ejecutar el bucle while una vez, es significativamente mayor que el objetivo de 16.66ms. Aumentar el límite de FPS no acelerará estas funciones lentas; solo le dirá al programa que intente renderizar más a menudo, lo cual ya está fallando.

La causa más probable es el número de objetos o la complejidad del renderizado en el mapa de Elbeland, lo que hace que RenderMainScene() sea muy lenta.

La forma correcta de solucionar el problema
Para mejorar el rendimiento y mantener FPS estables, necesitas optimizar el código en sí.

Analizar el código: El primer paso es identificar la causa exacta de la caída de rendimiento. Usa un profiler para ver qué funciones están consumiendo más tiempo en Elbeland. Es muy probable que sean RenderMainScene() o g_PhysicsManager.Move().

Optimizar el renderizado:

Nivel de Detalle (LOD): Renderiza versiones simplificadas de objetos distantes o no los renderices en absoluto.

Texturas y modelos: Usa texturas más pequeñas, optimiza los modelos o implementa el renderizado de instancias para objetos repetidos como árboles o pasto.

Occlusion Culling: No renderices objetos que están ocultos detrás de otros.

Optimizar la lógica del juego:

Particionamiento espacial: En lugar de comprobar cada objeto contra todos los demás para detectar colisiones o actualizaciones, usa una cuadrícula o un quadtree para verificar solo los objetos cercanos.

Escalado dinámico del rendimiento: Una solución más compleja, pero efectiva, es ajustar dinámicamente el detalle del juego según el rendimiento. Por ejemplo, si los FPS bajan de 60, podrías reducir el número de efectos visuales, partículas o luces dinámicas.

En resumen, cambiar el objetivo de FPS es una solución superficial. Para resolver el problema correctamente, necesitas encontrar las partes específicas del código que están causando los problemas de rendimiento en Elbeland y optimizarlas. El bucle de juego con la variable lag ya está haciendo su trabajo al separar la lógica del juego del renderizado. El problema es que el ordenador no puede seguir el ritmo de lo que le estás pidiendo en ese mapa en particular.

FPS map Elbland 24FPS :(

The main issue is a performance bottleneck, not FPS throttling. When FPS drops, it's because the RenderMainScene() function (which draws everything on the screen) or Update() functions (such as physics and game logic) are taking too long to complete.

Fixed time step: The code calculates a lag and then executes a while loop (lag >= MS_PER_UPDATE). This loop ensures that all game logic (g_PhysicsManager.Move, MoveMainScene, etc.) updates exactly to MS_PER_UPDATE (16.66 ms) each time. This keeps the game simulation consistent, even if rendering is delayed.

The bottleneck: The drop to 24 FPS on the Elbeland map means that the time it takes to render the scene (RenderMainScene) plus the time to execute the while loop once is significantly longer than the target of 16.66 ms. Increasing the FPS limit won't speed up these slow functions; it will just tell the program to attempt to render more often, which is already failing.

The most likely cause is the number of objects or the complexity of rendering in the Elbeland map, which makes RenderMainScene() very slow.

The right way to fix the problem
To improve performance and maintain stable FPS, you need to optimize the code itself.

Analyze the code: The first step is to identify the exact cause of the performance drop. Use a profiler to see which functions are consuming the most time in Elbeland. It's most likely RenderMainScene() or g_PhysicsManager.Move().

Optimize rendering:

Level of Detail (LOD): Render simplified versions of distant objects or don't render them at all.

Textures and models: Use smaller textures, optimize models, or implement instance rendering for repeating objects like trees or grass.

Occlusion Culling: Don't render objects that are hidden behind others.

Optimizing Game Logic:

Spatial Partitioning: Instead of checking each object against all others for collisions or updates, use a grid or quadtree to check only nearby objects.

Dynamic Performance Scaling: A more complex, but effective, solution is to dynamically adjust the game's detail based on performance. For example, if the FPS drops below 60, you could reduce the number of visual effects, particles, or dynamic lights.

In short, changing the FPS target is a superficial solution. To properly solve the problem, you need to find the specific parts of the code that are causing the performance issues in Elbeland and optimize them. The game loop with the lag variable is already doing its job by separating the game logic from the rendering. The problem is that the computer can't keep up with what you're asking of it in that particular map.

Google translate:

El problema principal es un cuello de botella en el rendimiento, no la limitación de FPS. Cuando los FPS bajan, es porque la función RenderMainScene() (que dibuja todo en la pantalla) o las funciones Update() (como la física y la lógica del juego) están tardando demasiado en completarse.

Paso de tiempo fijo: El código calcula un lag y luego ejecuta un bucle while (lag >= MS_PER_UPDATE). Este bucle asegura que toda la lógica del juego (g_PhysicsManager.Move, MoveMainScene, etc.) se actualice exactamente a MS_PER_UPDATE (16.66ms) por vez. Esto mantiene la simulación del juego consistente, incluso si el renderizado se retrasa.

El cuello de botella: La caída a 24 FPS en el mapa de Elbeland significa que el tiempo que tarda en renderizar la escena (RenderMainScene) más el tiempo para ejecutar el bucle while una vez, es significativamente mayor que el objetivo de 16.66ms. Aumentar el límite de FPS no acelerará estas funciones lentas; solo le dirá al programa que intente renderizar más a menudo, lo cual ya está fallando.

La causa más probable es el número de objetos o la complejidad del renderizado en el mapa de Elbeland, lo que hace que RenderMainScene() sea muy lenta.

La forma correcta de solucionar el problema
Para mejorar el rendimiento y mantener FPS estables, necesitas optimizar el código en sí.

Analizar el código: El primer paso es identificar la causa exacta de la caída de rendimiento. Usa un profiler para ver qué funciones están consumiendo más tiempo en Elbeland. Es muy probable que sean RenderMainScene() o g_PhysicsManager.Move().

Optimizar el renderizado:

Nivel de Detalle (LOD): Renderiza versiones simplificadas de objetos distantes o no los renderices en absoluto.

Texturas y modelos: Usa texturas más pequeñas, optimiza los modelos o implementa el renderizado de instancias para objetos repetidos como árboles o pasto.

Occlusion Culling: No renderices objetos que están ocultos detrás de otros.

Optimizar la lógica del juego:

Particionamiento espacial: En lugar de comprobar cada objeto contra todos los demás para detectar colisiones o actualizaciones, usa una cuadrícula o un quadtree para verificar solo los objetos cercanos.

Escalado dinámico del rendimiento: Una solución más compleja, pero efectiva, es ajustar dinámicamente el detalle del juego según el rendimiento. Por ejemplo, si los FPS bajan de 60, podrías reducir el número de efectos visuales, partículas o luces dinámicas.

En resumen, cambiar el objetivo de FPS es una solución superficial. Para resolver el problema correctamente, necesitas encontrar las partes específicas del código que están causando los problemas de rendimiento en Elbeland y optimizarlas. El bucle de juego con la variable lag ya está haciendo su trabajo al separar la lógica del juego del renderizado. El problema es que el ordenador no puede seguir el ritmo de lo que le estás pidiendo en ese mapa en particular.

This is exactly what I said when we were talking about optimizing and leaving the client at 60 fps without drops, but the mu gurus are saying that there's no need to optimize anything, that the game can be brought to 60 fps and kept without making many changes. Pff

El gran problema de Mu es que usan una version obsoleta de OpenGL, y al dia de hoy hasta las Season 20 siguen utilizando la misma versión. Ni Webzen quiere migrar a versiones mas nuevas de OpenGL por el dolor de eggs que es el codigo.
Yo estoy porteando a OGL 4.3 la 97d y me quemo la cabeza, imaginate la 5.2 que tiene el triple de codigo

El gran problema de Mu es que usan una version obsoleta de OpenGL, y al dia de hoy hasta las Season 20 siguen utilizando la misma versión. Ni Webzen quiere migrar a versiones mas nuevas de OpenGL por el dolor de eggs que es el codigo.
Yo estoy porteando a OGL 4.3 la 97d y me quemo la cabeza, imaginate la 5.2 que tiene el triple de codigo

XD confirmo

El gran problema de Mu es que usan una version obsoleta de OpenGL, y al dia de hoy hasta las Season 20 siguen utilizando la misma versión. Ni Webzen quiere migrar a versiones mas nuevas de OpenGL por el dolor de eggs que es el codigo.
Yo estoy porteando a OGL 4.3 la 97d y me quemo la cabeza, imaginate la 5.2 que tiene el triple de codigo

quiero suponer que ya para el 2010 ya tenian version bastante avanzada y cambiar todo eso ya era un gran reto xd 

El gran problema de Mu es que usan una version obsoleta de OpenGL, y al dia de hoy hasta las Season 20 siguen utilizando la misma versión. Ni Webzen quiere migrar a versiones mas nuevas de OpenGL por el dolor de eggs que es el codigo.
Yo estoy porteando a OGL 4.3 la 97d y me quemo la cabeza, imaginate la 5.2 que tiene el triple de codigo

quiero suponer que ya para el 2010 ya tenian version bastante avanzada y cambiar todo eso ya era un gran reto xd

Si porque es mucho codigo y tambien porque OpenGL 1.x es completamente distinto a las versiones con shader (OpenGL >= 2.0). Para utilizar correctamente versiones con shader, se tiene que hacer una 'cola' de vertices, texturas, estados de OpenGL y un par de cosas mas - el concepto de programacion es completamente distinto entre modo inmediato (1.x) vs shader (>= 2.0), un ejemplo basico: cambiar el motor y todo el circuito electrico de un vehiculo - tenes el esqueleto (ruedas, puertas, etc) pero lo primordial que impulsa y controla el vehiculo se tiene que cambiar entero; esto es lo mismo, tenes el codigo para animaciones, efectos, etc. pero el motor grafico se debe cambiar por otro que funciona de una manera completamente distinta.
Por eso sin sources es imposible optimizar y llegar a  unos estables 60fps, va mas alla de unos simples hooks - se tiene que reestructurar completamente el codigo y eso es unicamente posible con sources

El gran problema de Mu es que usan una version obsoleta de OpenGL, y al dia de hoy hasta las Season 20 siguen utilizando la misma versión. Ni Webzen quiere migrar a versiones mas nuevas de OpenGL por el dolor de eggs que es el codigo.
Yo estoy porteando a OGL 4.3 la 97d y me quemo la cabeza, imaginate la 5.2 que tiene el triple de codigo

quiero suponer que ya para el 2010 ya tenian version bastante avanzada y cambiar todo eso ya era un gran reto xd

Si porque es mucho codigo y tambien porque OpenGL 1.x es completamente distinto a las versiones con shader (OpenGL >= 2.0). Para utilizar correctamente versiones con shader, se tiene que hacer una 'cola' de vertices, texturas, estados de OpenGL y un par de cosas mas - el concepto de programacion es completamente distinto entre modo inmediato (1.x) vs shader (>= 2.0), un ejemplo basico: cambiar el motor y todo el circuito electrico de un vehiculo - tenes el esqueleto (ruedas, puertas, etc) pero lo primordial que impulsa y controla el vehiculo se tiene que cambiar entero; esto es lo mismo, tenes el codigo para animaciones, efectos, etc. pero el motor grafico se debe cambiar por otro que funciona de una manera completamente distinta.
Por eso sin sources es imposible optimizar y llegar a  unos estables 60fps, va mas alla de unos simples hooks - se tiene que reestructurar completamente el codigo y eso es unicamente posible con sources

en un mes o unos 15 días te migras adecuadamente el sistema de batches para optimizar los recursos y quitar el cuello de botella, (obstaculo) es que necesitas invertir ese tiempo real en ordenar y organizar

la pregunta del millon, es dificil?.... NOOO, solo es tardado, lo ideal es implementar una logica de engine con estructura solida

- Core / Sistema
Manejo del loop principal.
Tiempos (deltaTime, timers).
Logging / debug.
Configuración (archivos, rutas, parámetros).

- Módulos de motor
Input: teclado, mouse, gamepad.
Graphics/Renderer: dibujar sprites, modelos 3D, UI.
Audio: efectos de sonido y música.
Physics: colisiones, movimiento, gravedad.
Resource Manager: carga de assets (texturas, modelos, scripts).
Scene/World: contiene entidades y lógica del juego.

- Gameplay Layer
Entidades (Player, Monster, Projectile).
Componentes (salud, posición, inventario).
Sistemas (AI, combate, quests).

- Utilidades
Math (vectores, matrices, interpolaciones).
Time (nuestro TickCounter).
Helpers (string, archivos, paths).

de esa manera sería mucho más fácil solo hacer cambios directos, pero al estar todo alborotado es tardado estar migrando adaptando, y cambiando, aunque haya funciones especificas para estados de opengl y cambios de memoria, no deja de tener memoria sulta, y estado que jamas se revierten, llegando a ser pesado en ocasiones consumiendo mas recursos de los normal, mas carga de memoria, no hay control en liberacion de estados, memoria, y datos directos, incluso la conexicon con el servidor es tan obsoleta que en muchos casos genera lag, realmente es facil llegar a 60fps, lo dificil es hacerlo estable

El gran problema de Mu es que usan una version obsoleta de OpenGL, y al dia de hoy hasta las Season 20 siguen utilizando la misma versión. Ni Webzen quiere migrar a versiones mas nuevas de OpenGL por el dolor de eggs que es el codigo.
Yo estoy porteando a OGL 4.3 la 97d y me quemo la cabeza, imaginate la 5.2 que tiene el triple de codigo

quiero suponer que ya para el 2010 ya tenian version bastante avanzada y cambiar todo eso ya era un gran reto xd

Si porque es mucho codigo y tambien porque OpenGL 1.x es completamente distinto a las versiones con shader (OpenGL >= 2.0). Para utilizar correctamente versiones con shader, se tiene que hacer una 'cola' de vertices, texturas, estados de OpenGL y un par de cosas mas - el concepto de programacion es completamente distinto entre modo inmediato (1.x) vs shader (>= 2.0), un ejemplo basico: cambiar el motor y todo el circuito electrico de un vehiculo - tenes el esqueleto (ruedas, puertas, etc) pero lo primordial que impulsa y controla el vehiculo se tiene que cambiar entero; esto es lo mismo, tenes el codigo para animaciones, efectos, etc. pero el motor grafico se debe cambiar por otro que funciona de una manera completamente distinta.
Por eso sin sources es imposible optimizar y llegar a  unos estables 60fps, va mas alla de unos simples hooks - se tiene que reestructurar completamente el codigo y eso es unicamente posible con sources

en un mes o unos 15 días te migras adecuadamente el sistema de batches para optimizar los recursos y quitar el cuello de botella, (obstaculo) es que necesitas invertir ese tiempo real en ordenar y organizar

la pregunta del millon, es dificil?.... NOOO, solo es tardado, lo ideal es implementar una logica de engine con estructura solida

- Core / Sistema
Manejo del loop principal.
Tiempos (deltaTime, timers).
Logging / debug.
Configuración (archivos, rutas, parámetros).

- Módulos de motor
Input: teclado, mouse, gamepad.
Graphics/Renderer: dibujar sprites, modelos 3D, UI.
Audio: efectos de sonido y música.
Physics: colisiones, movimiento, gravedad.
Resource Manager: carga de assets (texturas, modelos, scripts).
Scene/World: contiene entidades y lógica del juego.

- Gameplay Layer
Entidades (Player, Monster, Projectile).
Componentes (salud, posición, inventario).
Sistemas (AI, combate, quests).

- Utilidades
Math (vectores, matrices, interpolaciones).
Time (nuestro TickCounter).
Helpers (string, archivos, paths).

de esa manera sería mucho más fácil solo hacer cambios directos, pero al estar todo alborotado es tardado estar migrando adaptando, y cambiando, aunque haya funciones especificas para estados de opengl y cambios de memoria, no deja de tener memoria sulta, y estado que jamas se revierten, llegando a ser pesado en ocasiones consumiendo mas recursos de los normal, mas carga de memoria, no hay control en liberacion de estados, memoria, y datos directos, incluso la conexicon con el servidor es tan obsoleta que en muchos casos genera lag, realmente es facil llegar a 60fps, lo dificil es hacerlo estable

es como todo juego es mas iben un reto para el mismo usuario casi ningun juego te anda fijo 60 fps siempre va  tener variables entorno efecto etc sumandole que el usuario tal si juega una cafetera se va a ver mas afectado optimizar el juego 100% que llegue a 60fps  fijo eso solo lo tendria que hacer una persona desde la craciones obj effect etc para saber manejar la optimizacion un simple obj o texture, te puede tumbar los fps al menos un 20% a 50% todo depende del usuario casi siempre.

El gran problema de Mu es que usan una version obsoleta de OpenGL, y al dia de hoy hasta las Season 20 siguen utilizando la misma versión. Ni Webzen quiere migrar a versiones mas nuevas de OpenGL por el dolor de eggs que es el codigo.
Yo estoy porteando a OGL 4.3 la 97d y me quemo la cabeza, imaginate la 5.2 que tiene el triple de codigo

quiero suponer que ya para el 2010 ya tenian version bastante avanzada y cambiar todo eso ya era un gran reto xd

tuvieron dinero para hacer eso para pagarle un buen programadores y terminar eso tiempo record pero no se cual fue su "IDEA" a no se que hace 15 años no habia alguien con esa capacidad de lograr eso, ahora creo que menos con una version s20 que eso debe tener una cantidad de cosas que creo que saldria mas barato crear otro main con otra api
Si porque es mucho codigo y tambien porque OpenGL 1.x es completamente distinto a las versiones con shader (OpenGL >= 2.0). Para utilizar correctamente versiones con shader, se tiene que hacer una 'cola' de vertices, texturas, estados de OpenGL y un par de cosas mas - el concepto de programacion es completamente distinto entre modo inmediato (1.x) vs shader (>= 2.0), un ejemplo basico: cambiar el motor y todo el circuito electrico de un vehiculo - tenes el esqueleto (ruedas, puertas, etc) pero lo primordial que impulsa y controla el vehiculo se tiene que cambiar entero; esto es lo mismo, tenes el codigo para animaciones, efectos, etc. pero el motor grafico se debe cambiar por otro que funciona de una manera completamente distinta.
Por eso sin sources es imposible optimizar y llegar a  unos estables 60fps, va mas alla de unos simples hooks - se tiene que reestructurar completamente el codigo y eso es unicamente posible con sources

El gran problema de Mu es que usan una version obsoleta de OpenGL, y al dia de hoy hasta las Season 20 siguen utilizando la misma versión. Ni Webzen quiere migrar a versiones mas nuevas de OpenGL por el dolor de eggs que es el codigo.
Yo estoy porteando a OGL 4.3 la 97d y me quemo la cabeza, imaginate la 5.2 que tiene el triple de codigo

Yes, my friend, in fact all the high-performance versions I have posted here run on OpenGL 4.3. It was extremely hard work for me to successfully upgrade it. In my opinion, if you are using a reversed/decoded version, it’s almost impossible—the amount of work required is enormous. And even after you manage to upgrade it, you still need to apply a series of improvements before the FPS can become more stable

de esa manera sería mucho más fácil solo hacer cambios directos, pero al estar todo alborotado es tardado estar migrando adaptando, y cambiando, aunque haya funciones especificas para estados de opengl y cambios de memoria, no deja de tener memoria sulta, y estado que jamas se revierten, llegando a ser pesado en ocasiones consumiendo mas recursos de los normal, mas carga de memoria, no hay control en liberacion de estados, memoria, y datos directos, incluso la conexicon con el servidor es tan obsoleta que en muchos casos genera lag, realmente es facil llegar a 60fps, lo dificil es hacerlo estable

es como todo juego es mas iben un reto para el mismo usuario casi ningun juego te anda fijo 60 fps siempre va  tener variables entorno efecto etc sumandole que el usuario tal si juega una cafetera se va a ver mas afectado optimizar el juego 100% que llegue a 60fps  fijo eso solo lo tendria que hacer una persona desde la craciones obj effect etc para saber manejar la optimizacion un simple obj o texture, te puede tumbar los fps al menos un 20% a 50% todo depende del usuario casi siempre.

diste un punto importante pero medio falso
primero la optimizacion del juego es escencial saber que el cuello de botella no lo genera tu codigo, si logras esto, lo segundo ya recae en el usuario y el entorno en donde ejecuta el juego, cabe recarlcar que la compatibilidad con sistemas operativos, como con tarjetas graficas es de tu responsabilidad (programador), pero si todo esto ya lo haces bien, entonces volvemos a lo mismo la importancia de correr y ejecutar en ordenadores de baja gama es responsabilidad del usuario final, pero si no tienes lo primero, no puedes culpar al segundo