Running C within Ruby on Ace

Discussion in 'Learning Ruby and RGSSx' started by Spoopy, Jan 12, 2017.

  1. Spoopy

    Spoopy Web Developer, PHP, NodeJS, RubyOnRails, Sass, HTM Veteran

    Messages:
    78
    Likes Received:
    43
    Location:
    Cape Town
    First Language:
    English
    I'm still learning RPG Maker in my spare time, when I'm not busy with C++, OpenGL and SDL2. I was wondering if anyone has managed to run C within Ruby on Ace. The reason I ask is to try do some dirty hacks to run OpenGL or at least WebGL through Ruby on RM. It's only for experimental reasons. I've done it before with Javascript and even PHP for web applications. Does anyone here know if it is possible and if so, should a custom DLL be written to support it?
     
    #1
  2. Zeriab

    Zeriab Huggins! Veteran

    Messages:
    1,200
    Likes Received:
    1,253
    First Language:
    English
    Primarily Uses:
    RMXP
    The RGSSx based RPG Makers does unfortunately not support extension libraries, so you are pretty much left with tedious way of creating your own DLLs and communicating with them through either Win32API or DL. Note: DL is VX Ace only


    I do hope you manage to create a OpenGL or Direct3D rendered view on top of the RGSSx player view and manage to keep it there with it being moved around and manage full screen/window mode toggles.


    Please do let me know if you manage that. I would be very interested in your solution :D
     
    Last edited by a moderator: Jan 12, 2017
    #2
  3. Spoopy

    Spoopy Web Developer, PHP, NodeJS, RubyOnRails, Sass, HTM Veteran

    Messages:
    78
    Likes Received:
    43
    Location:
    Cape Town
    First Language:
    English
    @ZeriabI don't think I want to sit with a hex editor to reverse engineer things. I've seen the mode-7 hacks for Ace, and know it is software based. I never touch DirectX, only OpenGL, I think the easiest would only to have post processing effects, as for rendering, i'd guess some hacks, such as the character moves around in one spot while the rest of the world moves around it based on user input, just not sure how to translate/layer that from the back buffer to the front. It kind of makes me wish that I wasn't a delinquent in high school and focused more on getting that Computer Science degree. I'll do some research on it and post what I find. Too bad I can't get my hands on Michael Abrash's graphics programming black book, it's old but could give good insights, after all he did do the graphics for Quake and ID's assemblers. Zeriab, do you think it is worth the time and effort to try hack it?
     
    #3
  4. Kes

    Kes Global Moderators Global Mod

    Messages:
    20,590
    Likes Received:
    10,510
    First Language:
    English
    Primarily Uses:
    RMVXA
    I don't think this is General Discussion.  It's probably more appropriate in one of the scripting forums.  Does Scripts in Development sound like what you want to do?
     
    #4
  5. Andar

    Andar Veteran Veteran

    Messages:
    28,327
    Likes Received:
    6,438
    Location:
    Germany
    First Language:
    German
    Primarily Uses:
    RMMV
    @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...
     
    #5
  6. Spoopy

    Spoopy Web Developer, PHP, NodeJS, RubyOnRails, Sass, HTM Veteran

    Messages:
    78
    Likes Received:
    43
    Location:
    Cape Town
    First Language:
    English
    @AndarI agree with you that it would be a lot slower on the performance side, however it is possible to convert C within other languages to run on Interpreters and JIT compilers. My tests with OpenGL in Javascript and PHP used ARB from old OpenGL 2, it loaded a scene with a camera and spinning monkey model "Suzanne" from Blender, framerate were at 200-300 fps with random drops to 15 fps. The size of code and time spent writing it was not worth the effort, especially have to write ' "std::cout << "Shader could not be loaded: \n" ', for every new line of code, thee quotations and newlines....


    It's interesting that Ace uses an interpreter, so I'm guessing the games get compiled down to bytecode, which is fine for 2D applications. I've experienced extreme performance and resource usage issues with bytecode in the past, specifically with Java application, the main issue was user input delays and random frameticks, it may just have been the framework I was using. Ok for slow pace games, not great for games such Arena Shooters.


    The legal issues is not worth the pain, I remember how some shader injectors was threatened by lawsuits in the past. I would never use injectors or hooks for any commercial product. In my case it would be more for personal education use. It's good that MV made the open source move, it is going to help innovate RM and also bring in more users. Wish I was around to see what Enterbrain and Kadokawa did.
     
    #6
  7. Zeriab

    Zeriab Huggins! Veteran

    Messages:
    1,200
    Likes Received:
    1,253
    First Language:
    English
    Primarily Uses:
    RMXP
    Uhm… I never talked about reverse engineering. I am talking about creating a custom DLL which you communicate with through a script. As for how to technically build your own DLL here's two topics I found with a quick search on Win32API. Note that a forum update or something destroyed the formatting for the code in the first link






    @Kes My recommendation is Learning Ruby and RGSSx


    @Andar C interpreters is a thing. Consider picoc and Ch


    Related you also have stuff like Valgrind


    *hugs*


     - Zeriab
     
    #7
    Marsigne likes this.
  8. Kes

    Kes Global Moderators Global Mod

    Messages:
    20,590
    Likes Received:
    10,510
    First Language:
    English
    Primarily Uses:
    RMVXA
    @Zeriab Good thinking.  Thanks.  Not being a scripter myself I'm a little uncertain where to put script related things at times.


    @Spoopy


    I am, therefore, moving this to Learning Ruby and RGSSx
     
    #8

Share This Page