@Spoopy I don't think you understand exactly what you're asking for...
The game.exe for Ace is basically an interpreter for RGSS3 - the games are not compiled at all.
And on that interpreter runs another interpreter for event commands, which means that most of a RPG Maker Game is based on a two-level interpreter (which is also the reason for the performance problems unless you have a really powerfull computer).
C code is only effective because it gets compiled - there is a reason why there is no C-Interpreter that I know of, only C-compilers.
What is theoretically possible is that you could script a C-Interpreter yourself to run on the Ruby-Interpreter that is the game.exe.
But this would not only be a massive amount of work (enough to keep a team of professional programmers busy for a year or so), it would also result in code that is extremely slow and laggy.
The problem with the other approach is that the full specifications of the Ace-API are NOT public, they are closed source. And any form of reverse-engineering is forbidden by EULA, making all postings of details on the internet illegal.
To redirect the graphic output to a different DLL can only be legal if you redirect the main function on the scripts and effectively write your own API, requiring a complete rewrite of the entire script engine.
It has been discussed before and the problem is an automatic no-go due to legal restrictions and other problems.
Just for your info: there has been an official try to get better graphics into Ace, done by Enterbrain/Kadokawa who have the entire specifications and the internal code of the Ace-DLL. That try even went into public betatest at one time (don't bother searching, the beta-dll has been removed from all postings).
And the result? Kadokawa decided that it was easier and more effective to create MV with a new, javascript-based opensource engine than to change the Ace-DLL.
Then the betatest was aborted and the beta-dll removed from public
Think about that...