RMXP - HBGE (0.0.4)

[Glitchfinder]

Well, if you want to take a look at my input modules, they're located here and here. They're definitely slower than AWorks, but they do everything Aworks Input did without an external .dll file and without breaking the default Input module. (Which means that you can still use the gamepad, if you want to check for that) They're also updated by the default Input module, so that if you're updating Input, you don't need to update them too. Please note that, if my input modules were used in this project, the versions made for this project would be subject to the project license and not my own.

As for Aworks, here's something I received a few days ago in response to some queries I sent vgvgf's way:

Actually, is it all right if I modify and re-release the Aleworks pack? I think I see other ways it could be improved upon. (Such as a fix to the write line script, so it gets accurate line measurements) It would keep the same name, and, if you chose, the same license. I would just continue to modify and add to the pack as time went on.

Yes, you can. My scripts haven't any license, so you can modify them at will. If you have any question about something in my scripts, don't hesitate to ask, I'll help you.

 

[Calibre]

Sorry to stick my non-scripting nose in but I was just curious... in leymans terms, how much of a radical difference the final product would be for the game devs amongst us? I mean from using the RMXP's engine as it is to this?

What differences will there be? Will it improve the speed and fluidity etc? I assume the algorithms will be rewritten, is it just things like that?

Also, for obvious reasons I understand you won't want to quote a timespan here until completion but are we talkings months, years or decades?

Sorry I'm providing no answers, just questions! I'd like to have an input from a Game Developers point of view!

 

[SephirothSpawn]

Ok first, here's the plan I have for the project to explain my answer:

Phase 1: Build our library - Our current phase is to build our library. Essentially, collecting as many tools as we can for the internal structure for this project.
Phase 2: Build our data structure - Once we get to this phase, I will be creating a topic for "elements of a RPG" topic where we will list all the different types of objects and such and then re-create those objects in Ruby classes.
Phase 3: Build session classes (Game_X) - Our next step will be to create classes that contain unique data for each session, like Game_ in RMXP.
Phase 4: Building graphics interfaces - this will be heavily customizable. The idea here is to separate the functionality from the visual appearance. I will hold a "build a GUI contest" where people can submit there own layouts for windows and scenes and the best will be made into the project.

Once this is done, a usable demo will be completed that can completely replace your default Scripts.rxdata. The project will still be under constant update. The idea here is to make one master script package that's like a test bed of all scripts released for it all tied into 1 project. Then makers who use this project will have all the tools for them at there disposal and won't have to search for a script to add. So as new scripts are added that comply with the standards and regulations of the project, they will be added to this demo.


So now to answer your questions:

Q: how much of a radical difference the final product would be for the game devs amongst us? I mean from using the RMXP's engine as it is to this?
A: This will be all optimized code that maximizes performance. It will also include a lot more to work with than the default XP database editor (via. expansion database editor this project will feature). For scripters, more tools than ya can shake a stick out, speeding up the scripting process.

Q: What differences will there be? Will it improve the speed and fluidity etc? I assume the algorithms will be rewritten, is it just things like that?
A: Performance will be optimized. As well, having the functionality of scripts separated from the visual, more customization. Algorithms will be also easier to be modified as these will be in configuration sections vs. placed within the rest of the code, having to hunt it down.

Rather than loading all these scripts and placing them in the editor, as that would create hundreds of sections to where the scroll-bar would just be a couple pixels, the only scripts placed within the editor will be the configuration. The scripts will be included from .rb files. This will allow us to add functions easier by simply dropping .rb files into a Scripts directory. All sections within the editor will just include categories for config. The idea here is to hide the scripts as much as possible while making setup easier.

Thanks for the questions. They help us all by making us look at our direction and planning and can only help us all move in the direction.

I would like to have Phase 2 completed by the end of April. Phase 3 will take the greater portion of May and phase 4 shouldn't take that long at all, considering its just laying out windows and scenes, and our goal is to put as much functionality in our top-level classes.

 

[Calibre]

Hey Seph, nice to see you active here again!

Thanks for your answers, I think I am with you now. I'm actually just starting to try to get to grips with scripting languages so this will be interesting for me to follow. I'll definately try and lend my support from the end user perspective.

The only thing that sounds a bit worrying my end is will the average developer understand how to further implement scripts into this that may not be included in what you guys have done? This whole RB thing + Configuration in editor is foreign to me right now.

Timespan wise that sounds great, sooner than I was expecting! I really hope you see all your current projects I've noticed through!

Good Luck.

 

[SephirothSpawn]

I'm probably making it sound more complicated than what it really is. You will basically add scripts in just like you always have. Just this core library will use .rb files (of course scripts can too). Say you have something like the following. I'll use my triple triad as its an example of a big script, uses a data structure and lots of constants for options. Normally, your code would look like this:

 

module TripleTriad

  tons_and_tons_of_constants

end

 

class TripleTriad::Card

  blah_blah_blah

end

 

hundreds_of_lines_to_make_cards_which_is_customized_hundreds_of_lines_away_from_top_of_script_or_another_section

 

class TripleTriad::Player

  blah_blah_blah

end

 

just_like_with_cards_make_player_objects_data_struct_hundreds_of_lines_away_from_top

Now, instead I am aiming for something like this:

HBGE.require_script('Scripts/TripleTriad')

 

module TripleTriad

  constants

end

 

now_card_making_is_here_any_methods_and_functions_in_TT_module_are_hidden_as_well_as_the_card_class

 

now_make_players

It's basically just a way to "hide" as much information as possible so you can get to the setup. The require_script function is something I am working on that will pass through all files in the directory and include them.

Its with this require_script that will allow people to hide their scripts and allow developers to get to the setup easier. It also allows someone to make a new function for a class, like Array, just make a new Array_function.rb file and for me to add it into the project with ease.

On the subject, I tinkered with require for a second, but I couldn't get it to work for some damn reason. I have something like:
$: << Dir.getwd
require "Scripts/array_find.rb" and its saying I have a syntax error at line 0. I tried $LOAD_PATH in place of $: and still... am I doing something wrong here with this?

I have the 0.1 update just about ready. Been adding in all those old MACL stuff in there, made a new Graphics module (to support > 640x480), modified the Input module (via. AWorks), etc. I'll post the 0.1 once I get it all finalized and get the require thing fixed. Then will be starting on all the Data structure things and finalizing the DSG (hello unlimited database editor tabs). We will do that until the end of April. Then on to phase 3.

 

[Calibre]

All sounds great mate, but I'd suggest making sure when you get to the end you spell out in very simple terms everything this baby will be capable of! I don't want any of your guys hard work to be missed out on for lack of knowing or understanding. I'm sure you have all your bases covered. This sounds like something that should replace 100% of all RM new games.

I'm very interested in this graphic module... I don't understand it, but I'm very interested! 640 x 480 limitation is my biggest turn off for using RM at the moment. Will this graphics module be relatively Plug and Play? So basically if I make higher resolution tiles I can display at 1024 x 768 by default, or am I way off here?

On the subject, I tinkered with require for a second, but I couldn't get it to work for some damn reason. I have something like:
$: << Dir.getwd
require "Scripts/array_find.rb" and its saying I have a syntax error at line 0. I tried $LOAD_PATH in place of $: and still... am I doing something wrong here with this?

:

 

[Gust]

On the subject, I tinkered with require for a second, but I couldn't get it to work for some damn reason. I have something like:
$: << Dir.getwd
require "Scripts/array_find.rb" and its saying I have a syntax error at line 0. I tried $LOAD_PATH in place of $: and still... am I doing something wrong here with this?

To require from the game directory I use
$LOAD_PATH << "."
require "Scripts/your_dir/script"

Is that what you want?

 

[Glitchfinder]

I have the 0.1 update just about ready. Been adding in all those old MACL stuff in there, made a new Graphics module (to support > 640x480), modified the Input module (via. AWorks), etc. I'll post the 0.1 once I get it all finalized and get the require thing fixed. Then will be starting on all the Data structure things and finalizing the DSG (hello unlimited database editor tabs). We will do that until the end of April. Then on to phase 3.

One reason I was trying to avoid the AWorks input was because it completely destroys the original module. That means you can't use the original module for stuff like game controllers anymore. It also requires a patch to fix events. As for your Graphics module, do you know how to add to the default module without breaking it?

 

[DeM0nFiRe]

In my opinion, the whole thing with trying to change the way that scripts are included with one another is a bad idea. In your example, the TripleTriad script would have been just fine if it was broken up into multiple files. A card is not a player, and therefore they should not have occupied the same file, or in this case script entry. I hope you at least plan to not break the original way, right?

As for require, AFAIK Ruby just does an in-place evaluation. at the line that you put require. I think you'd get pretty close to what require does if you wrote it so that it loads the given file into a string and eval's it right there.

As for graphics, did you replace the RMXP renderer, or just put the functions to resize the window? RMXP's default renderer is just GDI, so it's using software rendering. On my old P4 3.06Ghz HT 1024 x 768 was like 15 FPS, even if there were no sprites or anything else in the scene. Even just clearing that many pixels is difficult for it (It has to clear pixels one by one). I'm sure most people have better processors than that, but it's still something to watch out for.

 

[DeM0nFiRe]

Alright, so I took a look in eval.c of the Ruby 1.8.6 source code, and for .rb files, require does just what I said. So you can emulate that aspect of require with just a simple eval() of the contents of the file you want to require. As for .so objects, I forget whether Enterbrain just undefined the ruby method "require" or whether they legit gimped the C function rb_require. I do not have RMXP installed, so I can't do it myself, but the first thing I would try is to write a DLL which redefines the ruby function require to call rb_require. If that doesn't work, then I would take a look at the rb_require file in eval.c of the ruby source code and recreate that function and define the ruby function "require" to call your recreated function.

 

[SephirothSpawn]

All sounds great mate, but I'd suggest making sure when you get to the end you spell out in very simple terms everything this baby will be capable of! I don't want any of your guys hard work to be missed out on for lack of knowing or understanding. I'm sure you have all your bases covered. This sounds like something that should replace 100% of all RM new games.

I'm very interested in this graphic module... I don't understand it, but I'm very interested! 640 x 480 limitation is my biggest turn off for using RM at the moment. Will this graphics module be relatively Plug and Play? So basically if I make higher resolution tiles I can display at 1024 x 768 by default, or am I way off here?

Good to see some support for this. I hate the 640x480 resolution as well. It is so tiny. And yes, this will support any resolution such as 1024x768. It works just like in VX "Graphics.resize(width, height). If you used Sewlyn's Resolution system, if you ever performed a transition, only the original 640x480 area would be effected. Via. the screenshot script (which is now located in the Graphics module as snap_to_bitmap), transitions can be performed at any resolution. The only real difficulty I am having is creating a fast enough process that makes transformations via. Transition files happen more quickly. I wrote a transform method for the Sprite class, but it checks bitmaps on both files and actually takes awhile since the bitmap.get_pixel and set_pixel are slow. Works, just need to come up with a faster method.

The only other problem is the Tilemap class. I have fixed my last version so its bug free (I hope) (and am working on merging it to allow even more layer's via a program called Tiled) but it is still slower than the default C coded Tilemap class XP uses. I am going to try to learn some C and re-write this class or something to make performance not take a hit when dealing with higher resolutions.

To require from the game directory I use
$LOAD_PATH << "."
require "Scripts/your_dir/script"

Is that what you want

I actually tried that as well, but it still errored. Not sure if I just corrupted my file or what the deal was, but I have a few ideas why its not working.

In my opinion, the whole thing with trying to change the way that scripts are included with one another is a bad idea. In your example, the TripleTriad script would have been just fine if it was broken up into multiple files. A card is not a player, and therefore they should not have occupied the same file, or in this case script entry. I hope you at least plan to not break the original way, right?

Actually, those functions aren't for loading single files. I will have 3 functions, 1 that reads a directory and all sub directory and loads every file through all directories. Such as HBGE.load_library('Scripts/Ruby') and sub-folders with classes and modules with folders in those that it loads each .rb file. Second is just a lower level that reads files within a directory and loads .rb files. Lastly just a single file require.

As for require, AFAIK Ruby just does an in-place evaluation. at the line that you put require. I think you'd get pretty close to what require does if you wrote it so that it loads the given file into a string and eval's it right there.

That's what I was going to end up doing when writing the functions for loading .rb files was using eval. Simple enough.

As for graphics, did you replace the RMXP renderer, or just put the functions to resize the window? RMXP's default renderer is just GDI, so it's using software rendering. On my old P4 3.06Ghz HT 1024 x 768 was like 15 FPS, even if there were no sprites or anything else in the scene. Even just clearing that many pixels is difficult for it (It has to clear pixels one by one). I'm sure most people have better processors than that, but it's still something to watch out for.

I actually didn't touch the default Graphics#update method for the rendering. Every other method can be modified to work for higher resolution without destroying anything. If you are interested, current Graphics module code (I still have some work to do on it)

#============================================================================== 

# ** Graphics

#------------------------------------------------------------------------------

# * Library

#

# Graphics:

# ---------------------------------------------------------------------------

# Graphics.screenshot

# Graphics.snap_to_bitmap

# Graphics.width

# Graphics.height

# Graphics.resize

# Graphics.fullscreen

# Graphics.size

#==============================================================================

 

#==============================================================================

# ** Graphics

#==============================================================================

 

module Graphics

  #--------------------------------------------------------------------------

  # * Screenshot File Directory

  #--------------------------------------------------------------------------

  Screenshot_Dir = ''

  #--------------------------------------------------------------------------

  # * Screenshot (By Andreas21 & Cybersam)

  #

  #   image_type : 0 - bmp, 1 - jpg, 2 - png

  #--------------------------------------------------------------------------

  def self.screenshot(filename = 'screenshot', image_type = 2)

    # Adds File Extension

    filename += image_type == 0 ? '.bmp' : image_type == 1 ? '.jpg' : '.png'

    # Create True Filename

    file_name = Screenshot_Dir + filename

    # Make Screenshot

    API::Screenshot.Screenshot(0, 0, self.width, self.height, file_name, 

      API.hwnd, image_type)

  end

  #--------------------------------------------------------------------------

  # * Snap to Bitmap

  #--------------------------------------------------------------------------

  def self.snap_to_bitmap

    # Take Screenshot

    self.screenshot('snap_to_bitmap')

    # Load Bitmap

    bitmap = Bitmap.new('snap_to_bitmap')

    # Delete Screenshot

    File.delete('snap_to_bitmap.png')

    # Return Bitmap

    return bitmap

  end

  #--------------------------------------------------------------------------

  # * Width

  #--------------------------------------------------------------------------

  def self.width

    return @width == nil ? 640 : @width

  end

  #--------------------------------------------------------------------------

  # * Height

  #--------------------------------------------------------------------------

  def self.height

    return @height == nil ? 480 : @height

  end

  #--------------------------------------------------------------------------

  # * Resize

  #--------------------------------------------------------------------------

  def self.resize(width = Default_Width, height = Default_Height, 

      fs = @fullscreen)

    # Saves Width & Height

    @width, @height = width, height

    # Modify Transition Viewport

    @transition_viewport.dispose

    @transition_sprite.dispose

    @transition_viewport = Viewport.new(0, 0, @width, @height)

    @transition_viewport.z = 99999

    @transition_sprite = Sprite.new(@transition_viewport)

    # Set Resolution

    self.set_resolution(fs)

  end

  #--------------------------------------------------------------------------

  # * Set Resolution

  #--------------------------------------------------------------------------

  private

  def self.set_resolution(fullscreen = !@fullscreen)

    if fullscreen

      API::User32.SetWindowLong.call(API.hwnd, API::User32::GWL_STYLE, API::User32::WS_VISIBLE|API::User32::WS_CLIPSIBLINGS)

      API::User32.SetWindowPos.call(API.hwnd, HWND_TOPMOST, 0, 0, @width, @height, API::User32::SWP_SHOWWINDOW)

      API::Display.Set_Res.call(@width, @height, 4)

    else

      w = @width + (2 * API::User32.GetSystemMetrics(API::User32::SM_CXFIXEDFRAME))

      h = @height + (2 * API::User32.GetSystemMetrics(API::User32::SM_CYFIXEDFRAME)) + 

        API::User32.GetSystemMetrics(API::User32::SM_CYCAPTION)

      x = (@default_size[0] - w) / 2

      y = (@default_size[1] - h) / 2

      API::User32.SetWindowLong(API.hwnd, API::User32::GWL_STYLE, 

        API::User32::WS_VISIBLE|API::User32::WS_CLIPSIBLINGS|API::User32::WS_CAPTION|API::User32::WS_SYSMENU|API::User32::WS_MINIMIZEBOX)

      API::User32.SetWindowPos(API.hwnd, API::User32::HWND_TOP, x, y, w, h, API::User32::SWP_SHOWWINDOW)

      self.update

      API::Display.SetResolution(@default_size[0], @default_size[1], 0)

    end

  end

  #--------------------------------------------------------------------------

  # * Size

  #--------------------------------------------------------------------------

  private

  def self.size

    return API::User32.GetSystemMetrics(0), API::User32.GetSystemMetrics(1)

  end

  #--------------------------------------------------------------------------

  # * Resized?

  #--------------------------------------------------------------------------

  private

  def self.resized?

    return @width > 640 || @height > 480

  end

  #--------------------------------------------------------------------------

  # * Save Default Instances

  #--------------------------------------------------------------------------

  @default_size = self.size

  @width        = self.width

  @height       = self.height

  @fullscreen   = false

  #--------------------------------------------------------------------------

  # * Tranisition Viewport & Sprite

  #--------------------------------------------------------------------------

  @transition_viewport = Viewport.new(0, 0, @width, @height)

  @transition_viewport.z = 99999

  @transition_sprite = Sprite.new(@transition_viewport)

end

 

# Resize

Graphics.resize

What is left is keeping it from changing resolution when Alt+Enter is pressed. I tried quite a few ways for doing this (disabling key enter while Alt is pressed via various API), but couldn't figure it out).

Alright, so I took a look in eval.c of the Ruby 1.8.6 source code, and for .rb files, require does just what I said. So you can emulate that aspect of require with just a simple eval() of the contents of the file you want to require. As for .so objects, I forget whether Enterbrain just undefined the ruby method "require" or whether they legit gimped the C function rb_require. I do not have RMXP installed, so I can't do it myself, but the first thing I would try is to write a DLL which redefines the ruby function require to call rb_require. If that doesn't work, then I would take a look at the rb_require file in eval.c of the ruby source code and recreate that function and define the ruby function "require" to call your recreated function.

Yeah, I ended up writing my own method for requiring files. Thanks for the info. :thumb:

One reason I was trying to avoid the AWorks input was because it completely destroys the original module. That means you can't use the original module for stuff like game controllers anymore. It also requires a patch to fix events. As for your Graphics module, do you know how to add to the default module without breaking it?

Really? I tested it and it still checks the computer keys just fine. I've never had a problem with it at all. I believe there is a function that updates the Input constants when keys are configured when the user presses F1. I think all we would have to do is add something in the something like Input.update to check if a key is pressed (F1 or something) and it would call the function to update constants based off the registry values. Unless I am miss understanding something here... Shouldn't be a problem.

With what I posted above with a re-write of the Graphics module, its more of a update to the Graphics module to include a few more methods and functions (like found in VX). It shouldn't ever become a problem I would think.

 

[DeM0nFiRe]

As for graphics, did you replace the RMXP renderer, or just put the functions to resize the window? RMXP's default renderer is just GDI, so it's using software rendering. On my old P4 3.06Ghz HT 1024 x 768 was like 15 FPS, even if there were no sprites or anything else in the scene. Even just clearing that many pixels is difficult for it (It has to clear pixels one by one). I'm sure most people have better processors than that, but it's still something to watch out for.

I actually didn't touch the default Graphics#update method for the rendering. Every other method can be modified to work for higher resolution without destroying anything. If you are interested, current Graphics module code (I still have some work to do on it)

#============================================================================== 

# ** Graphics

#------------------------------------------------------------------------------

# * Library

#

# Graphics:

# ---------------------------------------------------------------------------

# Graphics.screenshot

# Graphics.snap_to_bitmap

# Graphics.width

# Graphics.height

# Graphics.resize

# Graphics.fullscreen

# Graphics.size

#==============================================================================

 

#==============================================================================

# ** Graphics

#==============================================================================

 

module Graphics

  #--------------------------------------------------------------------------

  # * Screenshot File Directory

  #--------------------------------------------------------------------------

  Screenshot_Dir = ''

  #--------------------------------------------------------------------------

  # * Screenshot (By Andreas21 & Cybersam)

  #

  #   image_type : 0 - bmp, 1 - jpg, 2 - png

  #--------------------------------------------------------------------------

  def self.screenshot(filename = 'screenshot', image_type = 2)

    # Adds File Extension

    filename += image_type == 0 ? '.bmp' : image_type == 1 ? '.jpg' : '.png'

    # Create True Filename

    file_name = Screenshot_Dir + filename

    # Make Screenshot

    API::Screenshot.Screenshot(0, 0, self.width, self.height, file_name, 

      API.hwnd, image_type)

  end

  #--------------------------------------------------------------------------

  # * Snap to Bitmap

  #--------------------------------------------------------------------------

  def self.snap_to_bitmap

    # Take Screenshot

    self.screenshot('snap_to_bitmap')

    # Load Bitmap

    bitmap = Bitmap.new('snap_to_bitmap')

    # Delete Screenshot

    File.delete('snap_to_bitmap.png')

    # Return Bitmap

    return bitmap

  end

  #--------------------------------------------------------------------------

  # * Width

  #--------------------------------------------------------------------------

  def self.width

    return @width == nil ? 640 : @width

  end

  #--------------------------------------------------------------------------

  # * Height

  #--------------------------------------------------------------------------

  def self.height

    return @height == nil ? 480 : @height

  end

  #--------------------------------------------------------------------------

  # * Resize

  #--------------------------------------------------------------------------

  def self.resize(width = Default_Width, height = Default_Height, 

      fs = @fullscreen)

    # Saves Width & Height

    @width, @height = width, height

    # Modify Transition Viewport

    @transition_viewport.dispose

    @transition_sprite.dispose

    @transition_viewport = Viewport.new(0, 0, @width, @height)

    @transition_viewport.z = 99999

    @transition_sprite = Sprite.new(@transition_viewport)

    # Set Resolution

    self.set_resolution(fs)

  end

  #--------------------------------------------------------------------------

  # * Set Resolution

  #--------------------------------------------------------------------------

  private

  def self.set_resolution(fullscreen = !@fullscreen)

    if fullscreen

      API::User32.SetWindowLong.call(API.hwnd, API::User32::GWL_STYLE, API::User32::WS_VISIBLE|API::User32::WS_CLIPSIBLINGS)

      API::User32.SetWindowPos.call(API.hwnd, HWND_TOPMOST, 0, 0, @width, @height, API::User32::SWP_SHOWWINDOW)

      API::Display.Set_Res.call(@width, @height, 4)

    else

      w = @width + (2 * API::User32.GetSystemMetrics(API::User32::SM_CXFIXEDFRAME))

      h = @height + (2 * API::User32.GetSystemMetrics(API::User32::SM_CYFIXEDFRAME)) + 

        API::User32.GetSystemMetrics(API::User32::SM_CYCAPTION)

      x = (@default_size[0] - w) / 2

      y = (@default_size[1] - h) / 2

      API::User32.SetWindowLong(API.hwnd, API::User32::GWL_STYLE, 

        API::User32::WS_VISIBLE|API::User32::WS_CLIPSIBLINGS|API::User32::WS_CAPTION|API::User32::WS_SYSMENU|API::User32::WS_MINIMIZEBOX)

      API::User32.SetWindowPos(API.hwnd, API::User32::HWND_TOP, x, y, w, h, API::User32::SWP_SHOWWINDOW)

      self.update

      API::Display.SetResolution(@default_size[0], @default_size[1], 0)

    end

  end

  #--------------------------------------------------------------------------

  # * Size

  #--------------------------------------------------------------------------

  private

  def self.size

    return API::User32.GetSystemMetrics(0), API::User32.GetSystemMetrics(1)

  end

  #--------------------------------------------------------------------------

  # * Resized?

  #--------------------------------------------------------------------------

  private

  def self.resized?

    return @width > 640 || @height > 480

  end

  #--------------------------------------------------------------------------

  # * Save Default Instances

  #--------------------------------------------------------------------------

  @default_size = self.size

  @width        = self.width

  @height       = self.height

  @fullscreen   = false

  #--------------------------------------------------------------------------

  # * Tranisition Viewport & Sprite

  #--------------------------------------------------------------------------

  @transition_viewport = Viewport.new(0, 0, @width, @height)

  @transition_viewport.z = 99999

  @transition_sprite = Sprite.new(@transition_viewport)

end

 

# Resize

Graphics.resize

What is left is keeping it from changing resolution when Alt+Enter is pressed. I tried quite a few ways for doing this (disabling key enter while Alt is pressed via various API), but couldn't figure it out).

Hehe, well, the good news is, I know how to disable Alt+Enter, and it is a matter of just catching and eating that set of keystrokes in C. I already have a DLL that does it made up for RMXP. If you can be patient, I will try to get RMXP installed ASAP and then I will modify the DLL to do specifically this. Let me know what other input-related things you want to do for it and I can add it in.

Oh, also, I will hopefully soon release my Input Complete script/dll combo, and maybe that can be used instead of Aleworks. Mine is specifically designed to be a drop-in replacement for RGSS Input module. It provides a 1:1 rewrite of all original features, plus it has full mouse, input and joystick/game controller support.

Alright, so I took a look in eval.c of the Ruby 1.8.6 source code, and for .rb files, require does just what I said. So you can emulate that aspect of require with just a simple eval() of the contents of the file you want to require. As for .so objects, I forget whether Enterbrain just undefined the ruby method "require" or whether they legit gimped the C function rb_require. I do not have RMXP installed, so I can't do it myself, but the first thing I would try is to write a DLL which redefines the ruby function require to call rb_require. If that doesn't work, then I would take a look at the rb_require file in eval.c of the ruby source code and recreate that function and define the ruby function "require" to call your recreated function.

Yeah, I ended up writing my own method for requiring files. Thanks for the info. :thumb:

Well, you still don't have .so requiring. Dunno if you want it (Wuuld let you do stuff like include the original Ruby socket library). I might be able to do it if you need it.

Also, for the graphics, it looks like your module only knows that it has been resized if the width and height are greater than 640 x 480. What if it is resized to 320 x 240? Or from 320 x 240 back up to 640 x 480?

 

[SephirothSpawn]

Hehe, well, the good news is, I know how to disable Alt+Enter, and it is a matter of just catching and eating that set of keystrokes in C. I already have a DLL that does it made up for RMXP. If you can be patient, I will try to get RMXP installed ASAP and then I will modify the DLL to do specifically this. Let me know what other input-related things you want to do for it and I can add it in.

Oh, also, I will hopefully soon release my Input Complete script/dll combo, and maybe that can be used instead of Aleworks. Mine is specifically designed to be a drop-in replacement for RGSS Input module. It provides a 1:1 rewrite of all original features, plus it has full mouse, input and joystick/game controller support.

That would be great. The alt-enter doesn't need to be removed, just modified to call the new resize method to toggle fullscreen status. There is no real rush here. If you can get it done within a month, that's all we really need. I would greatly appreciate it.

Input module rewrite sounds great. I guess it has full keyboard support correct? At first I did not like how the Keys module was made separate from the Input module (in Aleworks), but truth be told, I find it beneficial to have a separate module to hold the key constants so they do not interferer with the Input constants (Input C vs. Keyboard C).

Well, you still don't have .so requiring. Dunno if you want it (Wuuld let you do stuff like include the original Ruby socket library). I might be able to do it if you need it.

Also, for the graphics, it looks like your module only knows that it has been resized if the width and height are greater than 640 x 480. What if it is resized to 320 x 240? Or from 320 x 240 back up to 640 x 480?

Personally I have never used .so files, just because my coding experience outside of Ruby is very limited. I have only got into API over the last year, but nothing extensive. Anything you can do to add to this that would allow others benefit would be great.

And as far as resizing testing, I just simply haven't fully finished that aspect. It was a quick a simple conditional I threw in there so if the resolution was greater than what was supported in the transition process, to run the custom process. The only purpose I can see for changing this to support lower resolutions would be to just resize the Transition files, but would that really need to be required? If a person makes a game in a certain resolution, I am sure there transition files will be that resolution and as is, it supports resolutions less than 640x480.

 

[DeM0nFiRe]

Heh, well then in that case, maybe it was just poor nomenclature on that function. Perhaps self.enlarged would work better?

I forget the specifics of the constants in my Input module (It's been a couple months since I looked at it) but I believe the original virtual buttons are the same (Input::C, Input::B) and the others have a KEY_ prefix (Input::KEY_C, Input::KEY_B). The joystick has it's own module, because the joystick has to be done a different way. I believe I currently have those functions in Input::Joystick. I may have only moved internal variables to the other module, I forget.

Also, yes, it has full keyboard support (Currently, I believe about 100 keys have constants, but adding more keys is as simple as defining more constants) full mouse support (Only will understand 3 buttons, so I guess that doesn't quite count as full.) and full gamepad/joystick support (6 axes, 2 POV and 32 buttons. That's what DirectInput understands.) Currently, only one joystick is supported, but I could add support for more for like multiplayer games, but I figure no one plays multiplayer PC games on one PC.

For the .so files, I was thinking not necessary along the lines of people making their own libraries, but re-including RMXP's default library. For instance, some people are trying to make web browsers in RMXP using that RGSS socket library floating around. Net::HTTP (which is removed from RGSS) could be re-included from the Ruby core (the .so files for each of the libraries that were removed can be found in the src directory of the Ruby distribution) However, I am not entirely sure yet how it could be worked in. I don't know if you can hijack ruby through a DLL the way you can a window.

 

[SephirothSpawn]

Updates:

I have the requiring working. I found that XP doesn't like if you put all the default editor classes in .rb files and then try to call them. I am not 100% sure why, but shouldn't case us any problems.

I am currently updating all files to use RDoc formatting. I won't do them all before the next update just so I can get this update posted so others can begin work on it. This is all just to keep formatting minimal while at the same time providing constant documentation on what we got going on here.

Update:

Updated to Version 0.0.4. See main post for details.

 

[Zeriab]

I have fixed the 0.0.4 download link :cute:

 

[BlueScope]

I'm glad this progresses nicely... I tried to get to some scripting once in a while, but I'm kind of busy with the rest of my armful of projects... :blank:

If it doesn't work out for me anytime soon, I guess I'll be only here to nag about how to improve it from a very unique and not quite necessary perfectionist's viewpoint :p But yeah... I'll try!

 

[SephirothSpawn]

That's just what this project needs: perfectionist. Luckily I am a pretty big one myself, but getting a mass opinion on perfection and collaborated input makes this usually more "perfect."

 

[kyonides]

I guess this project is going to be a good one. BTW, I just wanted to tell you there's a small modification anyone can do in this method.

[rgss]  def Math.A(m,n)
    raise ArgumentError.new('Ackermann: No negative values allowed.') if m < 0 or n < 0
    return n + 1 if m == 0
    return Math.A(m - 1, 1) if n == 0
    return Math.A(m - 1, Math.A(m, n - 1))
  end
[/rgss]

[rgss]  def Math.A(m,n)
    raise ArgumentError, 'Ackermann: No negative values allowed.' if m < 0 or n < 0
    return n + 1 if m == 0
    return Math.A(m - 1, 1) if n == 0
    return Math.A(m - 1, Math.A(m, n - 1))
  end
[/rgss]

It's just a very simple thing, I know, but it makes it quite unnecessary to create a new ArgumentError class there.

 

[e]

I'm not sure if you're still working on this, but I would highly recommend using a more recent version of RDoc, as the templating system has been re-designed from scratch and is much, much better now, both in terms of aesthetics and usability.

Use RubyForge's most recent RDoc: http://rdoc.rubyforge.org/