Save-Point

Recent Changes

• Added New Methods to Audio Module:
  • default_bgm_loop & default_bgm_loop=
    
  • default_bgs_loop & default_bgs_loop=
    
  • bgs_playing? & bgs_stopped? & bgs_paused? & bgs_loop? & bgs_loop=
    
  • bgm_paused? & bgm_loop? & bgm_loop=
    
• Splash Screen can now be as small as 320x240 or as big as your final game window!
  
• Removed Audio's bgm_loop & bgm_no_loop methods
  
• Removed Default Splash Screen, keeping the window invisible until it is time to display the title screen
  This prevents the engine from displaying 2 splash screens in a row
  
• Removed Terms module that nobody used
  
• Updated BGMNoLoopXP Ruby Script
  
• Updated README & LEEME Files
  

Here is a sample script you can use as your custom splash screen.
Don't forget to read the notes embedded in the script!

Game::SplashScene Script
(Using this module & its nested class is mandatory indeed.)

Recent Changes

• Created Mouse Module
  Moved most of the mouse related methods and properties from the Input module except for click-oriented methods
  
• New Mouse Methods: no_target? & target?(object) & target=
  
• Added Input.press_left_click? & press_right_click? & Improved Input.press?(Input::MouseLeft) or MouseRight response
  
• Added Window#draggable? & draggable= & mouse_target? methods for all RGSS-based engines
  
• Updated ClickableWindowXP Ruby Script
  
• Removed Boost Program Options Library
  

The Explanation

What this update accomplishes is to replicate the usual Windows or Plasma or GTK mouse + widget behavior that allows you to move that widget everywhere until you stop pressing the mouse button. Well, now you can do something like that by dragging Window objects all around the game screen.  It won't lose the link until you stop pressing Input::MouseLeft... or Input::MouseRight if the latter is your favorite button.

By default all windows are NOT draggable BUT you can change that by calling:


...depending on where you want to trigger it, namely inside or outside that specific window.
The internal window's areas won't matter as long as that window remains as the current  mouse's target.

The previous system depending just on specific areas and that could let to a serious disappointment once the mouse moved faster than the target window.

Now the ClickableWindowXP script lets you experience all that freedom at the tip of your index finger.

Recent Changes

• New Feature: Draggable Sprites!
  New Methods:
  • mouse_target?
    
  • drag_condition
    
  • drag_condition=
    
  • drag_always?
    
  • drag_color?
    
  • draggable?
    
  • draggable=
    
• ClickableWIndow XP has now become ClickableWidget XP
  • Mouse Hover Implemented!
    There are a couple of rules that you must follow to make this work natively:
    
  • @base_name should have been defined
    
  • @hover_name should be defined
    
  • @hover_filetype is also needed
    
  • @hover_hue is 0 by default
    

MIDI based error report:

Current state of test project:  RGSS1 scripts, no custom scripts in play.  Merely events as defined.
Version: hiddenchest win64 20240608 - 1.1.80 with DLLs supplied within.
Sound Fonts individually tested: GMGSx.SF2, GM4_Orch.SF2, Final_Fantasy_7_PSX_SF


THE SETUP:
I have a simple demo that obviously begins playing ye classic "064-Slow07" Title music that is the default. When selecting a new game, it enters a map with AutoChange off and no music selected for the map.  But after displaying a little startup message with a 60-frame pause, I use a contemporary PlayBGM Event command to begin another RTP classic: "058-Slow01".

THE REACTION:
After leaving the title screen and entering the map, the game does perform the 60 frame pause as defined. However, a final split-second 'blast' from the Title Screen music plays before switching over to the map music.

TEST 2:
I remove the title music from the Title screen.  After the 60-frame delay, the map music from the map event played without an issue.

TEST 3:
After returning the default Midi Title Music, I replaced the music launched in the field map to an MP3 file.  There was no  split-second 'blast' from the Title Screen music before the mp3 music played.

TEST 4:
Reversed Test 3, replacing the Midi Title Music with an MP3, but returned the Midi Map Music. There was no split-second 'blast' before playback.

TEST 5:
I decided to keep the Midi Theme at start.  But I removed the event and set the map properties to play "058-Slow01" on autoplay.  The split-second 'blast' returned.

TEST 6:
With the Midi Theme in place, I removed the autoplay music and created two map events the player needs to trigger:
   @>Fade Out BGM: 1 sec.
   @>Wait: 60 frame(s)
   @>Play BGM "{SELECTION}"
Each event had a different Midi file, but after the 60 second wait, each had a resulting 'pop' from the previously played Midi file, even when going back and forth between each event.

TEST 7:
Using the same events, I switched one of the events to play MP3 music. The MP3 music, on start, had no split-second 'blast. But when the other event that began midi playback was triggered, it played a blast from the title screen, the midi music from the title screen apparently still in memory and not cleared by the mp3 playback.


OPINION:
In layman's terms, it appears that past midi-music is not being properly cleared before the next midi piece actively begins playback. It is Midi to Midi exclusive, regardless of any other audio played between.


Yes, I have a Final Fantasy VII sound font. The default title music sounds funny with it.

Recent Changes

• Quick Fix: Stop or Close Stream if it is Not Looped
  
• Removed Audio.default_bgm_loop & #default_bgs_loop
  It was duplicating code for no good reason
  
• Renamed Audio.bgm_loop? as #bgm_loop to make it compatible with the bitwise or assignment |= operator
  

Note on the Quick Fix

I will not claim it is a perfect solution for the issue Wulfo reported this week. In the worst case scenario, you would still be able to notice a minimal, almost imperceptible beep before the internal player starts playing the next MIDI stream.

The after-effect midi-music 'pop' still appears, playing arguably LESS than the previous pop.  I think you cut the previous pop effect in half.  Still, it is present.

I have a bit of an event code that does work at eliminating the pop...

AGAIN, ONLY IF THERE ARE STILL USERS OF MIDI OUT THERE!!!
Again, only if you are using midi.  And this won't really work with auto-changing BGM in the Map Properties for Midi users.

Changes since my last post:

• Fixed the contents of the XXD files the engine needs for evaluating the RGSS2 and RGSS3 modules during the MRI setup process.
  This happened AFTER the custom game had been configured via parsing the Game.ini file.
  The RGSS1 module has been working fine for the last couple of releases, thus remaining intact.
  
• Widened the error screen area to fully display long game titles there.
  
• Fixed Window#height= method / Window#set_height function.
  
• Fixed same ME not playing more than once that caused RGSS3 games to crash.
  Other games would simply mute or ignore the Midi ME and keep processing the rest of the given commands.
  
• Fixed Audio.bgm_play Argument Type Checks for RGSS1 and RGSS3
  
• Added RPG::BGM Missing Methods & pos Value
  

Is there any chance to optionally add SDK support to this? I tried to run the standard version of Mr. Moo ABS on this, but it is currently impossible due to the SDK. The problem is exactly the same on the XPAce engine version. The only question is whether it can be solved using this software or do I need to rewrite the Mr. Moo script?

As for the smoothness of this engine, you have my approval. Good job! :)

The RPGMaker SDK has nothing to do with the incompatibility with HiddenChest, but the other scripts within that utilize the Win32API to handle keyboard and mouse interaction, let alone f0tz!baerchen's antilag.

This is intentional as it is being designed cross-platform for both Windows and Linux environments, and Linux does not have any Win32 API.  As such, neither f0tz!baerchen's antilag nor Aleworks input will function.

I never saw an anti-lag that ever used the Win32API until I saw THIS thing.

And insofar as input, HiddenChest has its own full keyboard and mouse support.  So the actual "Mr.Mo's ABS V5.5" script you have is what needs adapting:

From line 149 in your edition of MrMo...

to

And then continue throughout it with said updates.

There is a list of the available 'Full Keyboard Support' keys on the first page of this thread.

Still, there is a problem with the SDK, specifically with overriding methods via super functions instead of aliasing. HiddenChest super function is a main problem and I don't really know why. But yes with input is also problem to solved. So I must find a way to remove all SDK module and rewrite inputs.