Divídelo al menos en una decena de funciones... aunque el propio código, debiera determinar cuantas. Pero que sean manejables.

Puedes seguir teniendo una función pública y el resto las defines privadas, de modo que solo sean llamadas desde tu función pública (si es ese el caso).

Sin embargo, no entiendo que si es un motor de juegos, deba tener una única función.
Probablemente en la llamada deba recibir muchos parámetros y al caso podrías pasar la mayoría a propiedades donde verificas que su valor sea aceptable... luego que se invoque la función solo revisas si hay conformidad con las propiedades recibidas antes de ejecutar la función. Esa revisión podría recaer en otra función que debuelva un buleano, para saber si puede continuar o debe abortar (porque algo falla en los parámetros), ...también toda la funcionalidad extra de señalar el error y la causa podría delegarse a una función aparte (la misma que verifica, por ejemplo).

También cuesta entender que se supone que esperas que un posible usuario deba entender que hace tu motor de juegos si solo contiene una única función.

El caso es que diviendo tu función en varias, tendrás más probabilidades de que no alcances límites que establezca el compilador en su tabla de símbolos...
Un modo de paliar límites en variables en agruparlas en estructuras, arrays, etc... según convenga al caso...
Por ejemplo si tienes variables como estas: int Rojo, int verdeManzana, int ocre, int marino, int lila... mejor una enumeración de tipo color, luego basta una sola variable que recibe el valor  que a cada momento se precise.

...en realidad particionar dicha función en varias (aunque no recurras a más de una clase) lejos de complicar el código debería facilitar su simplicidad. Aunque sean funciones espagueti, será siempre mejor que una macro función espagueti.

De todos modos si pones un puñado de líneas (pongamos 100), uno puede hacerse idea del típo de codificación que estás haciendo y orientar con más precisión el camino a tomar...

Lo ideal sería crear clases, pero si no te apetece al menos, si crear otras funciones que son llamadas exclusivamente desde esa. Por ejemplo, las interpolacones... crea una función para interpolar que recibe como parámetros una imagen o un array de bytes, ancho y alto d eorigen ancho y alto final, método de interpolación, etc... incluso ésta si ofreces varios métodos según calidad, puede llamar invidualmente a ca una que trata un método específico, por ejemplo una bilineal, otra bicúbica, etc...
Lo mismo si quieres trabajar con luces, briilo, contraste, saturación etc... sácalas como funciones.

El compilador tiene una serie de límites, el de variables totales del programa no creo que se supere, pero quizás algún compiador no espere que una sola función alcance 1Mb. (por ejemplo), lo habitual es que una función no supere las 2000 líneas de código, que ya queda una función larga... lo habitual es que esas 2000 líneas sean las que tienen un móulo repartidas entre 15 funciones (por ejemplo)...

No debes considerar que si tu función llama a otras 20 para hacer su tarea suponga una sobrecarga de tiempo. Aunque una llamada a una función supone cierta carga, solo se aprecia su sobrecarga cuando se ejecutan en un bucle largo.

En fin divide tu función en cuestiones funcionales... además a futuro, lo vas a agradecer, porque el mantenimiento o una ampliación luego será más sencillo, y no penoso como creo que te va a resltar.
Al estar dividido en funciones, cada una queda aislada, entra algo y devuelve algo, y el como haga lo que haga a otra función no le importa, los cambios que hagas en ella no atañe al resto mientras siga recibiendo y devolviendo lo mismo que antes... (mantener en vigor sel contrato).
Cuando tienes una macrofunción... un simple cambio, puede suponer que afecte a 300 líneas de código repartidas entre esas miles, tardarás más en localizar cada punto (y asegurarte que no te olvidas de ninguno), que en modificar el propio código.

El tiempo se tiene que perder escribiendo código... no buscando y revisando que un cambio aquí, no afecta allí y allí y allá...

"Divide y vencerás" decían los romanos, en programación eso se traduce sobretodo en productividad....