Save-Point

Well, MKXP had blocked the font outline feature except for RGSS3 based games. HiddenChest unblocked it for all installments of RGSS. So I wonder if you are just making a request for letting the outline get activated by default, but some people might not like that. Or are you asking for a Game.ini type of setup that allows you to activate it from the very beginning?

Actually, HiddenChest has implemented the concept of areas. It's basically another Rect like method used for mouse clicks. I don't recall it's exact name off the top of my head, still, you should be able to find it in the README.md file.

EDIT

The Bitmap, Sprite and Window classes now support mouse clicks! Well, they indirectly do it... You got to set the @area array with every single x, y, width and height dimensions first. Usually you do that in the Window_Selectable and its child classes refresh method. The following script calls might be used in scene scripts:
Bitmap#alpha_pixel?(x, y) - It's not just for clicks!
Sprite#mouse_above? alias Sprite#mouse_inside?
Sprite#mouse_above_color? - It will ignore pixels with alpha value set at 0.
Window#mouse_above?(command_index) alias Window#mouse_inside?(command_index)

(08-30-2023, 07:46 PM)kyonides Wrote: [ -> ]Actually, HiddenChest has implemented the concept of areas. It's basically another Rect like method used for mouse clicks. I don't recall it's exact name off the top of my head, still, you should be able to find it in the README.md file.

It was not a case of rectangular areas. It was a case of trigger? release.

When I use Input.trigger?(Input::C), a traditional call, the input module recognizes the call and obviously returns true. But it also ensures that the call will not immediately become triggered a second time unless the user had released the button. This is different than the call of Input.press?(Input::C) where it will return 'true' for as long as the user keeps his finger on the button.

BUT... when it came to the use of the built-in mouse options, it appears that trigger? had issues. For if one actually used the mouse to activate anything with Input.trigger(Input::MOUSELEFT), the usage of the left mouse button would indeed be triggered. BUT, any subsequent attempts to use the left mouse button would be ignored. Likewise, if you used Input.trigger(Input::MOUSERIGHT) to enter the main menu from field map and decided to right-click a second time in 'any' instance, the right mouse button too did not work.

HOWEVER, this issue has been fixed in the newer editions of HiddenChest, so it's no longer a problem.

(08-30-2023, 07:46 PM)kyonides Wrote: [ -> ]Well, MKXP had blocked the font outline feature except for RGSS3 based games. HiddenChest unblocked it for all installments of RGSS. So I wonder if you are just making a request for letting the outline get activated by default, but some people might not like that. Or are you asking for a Game.ini type of setup that allows you to activate it from the very beginning?

Blocked? Well, it is more likely a case of the font class defined per compatible engine.

• RPGMaker XP had neither SHADOW nor OUTLINE.
  
• RPGMaker VX was the first to introduce SHADOW
  
• RPGMaker VXAce was the first to introduce OUTLINE and OUTLINE color

In essence, MKXP may have been 'adapting' the font features depending upon which engine you wished to emulate.

I do not see any reason why you shouldn't be congratulated for allowing one to use Shadow and Outline in HiddenChest. But upon running the default scripts, or any scripts, Outline is already turned on, this without calling either Font.default_outline = true or self.contents.font_outline = true which should instead be the case for their use.

The original developer should not need to use a command to disable outline when it wasn't required in the first place. And obviously not part of any INI file.

And getting the pictures system fixed of course. Something must have changed between the older Hires edition and the one now in play.

Warning!

Don't expect any changes in the code or port for Windows platform in the near future. I've been quite busy as of late.

---

Well, after checking what you did on that script of yours,  I definitely thought it was a matter of areas or rectangles and how they interact with mouse clicks there.  How would I know that it was about the clicks themselves.  Yet, I do think I had described some issue with it some time ago and had even sent some PM's to Melana asking her whether or not she could confirm that mouse clicks worked again as intended.

I suspect it could have been the same old "you haven't unplugged your gamepad" kind of issue that made me think there was a need to alter the mouse clicks. Again, I'm just trying to recall every single detail of a long forgotten issue and its followup discussion.

If you mean that MKXP blocked certain features by leaving if or switch case statements in place to prevent you from activating or deactivating the outline in RMXP and VX, then we both agree on that for sure. The same was valid for the Sprite's wave effect methods.

Since VX ACE uses font outline the very beginning, I guess I didn't see the need to disable that feature by default. I repeat, I'm just trying to remember  what should have happened in the past before the hiatus.

This morning, meaning not long ago, I have finished publishing the latest version of HiddenChest's Linux port code to GitHub. And I had a very good reason why I should end up doing such a thing out of the blue.

As I had explained in the What's up RMers? thread, I encountered a nasty  bug of sorts unexpectedly. I didn't realized that I had upgraded the FluidSynth library on my  Linux box in the last few days or weeks.

Such a change lead me to experience awful things... OK, I'll be honest with you, my computer's RAM suffered a lot more than I ever did.

Gladly, I managed to fix that by upgrading the header files of FluidSynth and as a consequence mkxp's SDL_Sound fork had to be ditched. Really, it wouldn't work properly otherwise.

From now on, icculus aka Ryan C. Gordon's official SDL2_Sound has replaced it for good.

There's just one little detail left that I still need to tackle any time soon. I'm talking about a small issue with SE's. BGM's work like they always did , no matter if we're talking about OGG, MP3, WAV or even your good old friend the MIDI.  But, there's always a but here, the dreadful division by zero error had to be prevented in some custom OpenAL wrapper code the old mkxp had included long time ago.

Now I know for sure that I need to list more formats to let the engine guess what a given audio file uses as its estimated sample rate.

I kept working on the Linux port of my engine when I realized that something was terribly off with SDL_Sound 2. That's why I was forced to downgrade to version 1 until I get some feedback on why any SE become a good example of a phone call experiencing some heavy interference or static like crazy.

I have some  suspicions here, but nothing worth mentioning as of now.

Since FluidSynth is now working normally, I decided that it was time to define some sort of code name for this build. Thus, I decided that it would be called NewSynth from now on.
Let's see what other code names I can come up with in the (not so near) future.

Oh yes, as per a  Wulfo's suggestion, I have turned off the delightful outline feature in RGSS 1 and 2 by default.
Don't worry about this, pals!  You still can manually turn it on once again by calling:


...before the game even starts!

Sort of.  What I actually did was looking for a way to fake that API using existing Ruby methods that will let some of your Win32API calls work. Which ones?   Well, they are...

Limited Compatibility:

kernel32

• GetPrivateProfileString
  

user32

• GetWindowText
  
• GetSystemMetrics
  
• GetWindowTextLength
  

Experimental:

kernel32

• GetEnvironmentVariable
  

This doesn't mean it will work with any dll or section.
That's why I'm warning you it's very limited right now.
Most of my efforts were focused on correctly interpreting the Game.ini file.

Really need to get a Windows variant updated since there are likely more Windows users.

This might not affect many people unless you extremely love playing MIDI, but now the fluidsynth library can properly read the chorus and reverb features again.

It just happens that fluidsynth developers decided to break backwards compatibility ever since version 2.0 was released. How? By forcing other developers to change the corresponding function from fluid_settings_setstr that admits a yes or no string as its third parameter to fluid_settings_setint that expects an integer as its last argument.

In regard to Windows...

I finally managed to grab an old copy of the Windows port of the HiddenChest engine. The problem is that can't find references to some of the Boost library modules or some specific functions of OpenAL for the time being.

Hi,

as your posts over the 14 pages contain descriptions of new features, I'd like to ask:

Is there a place with all the new additions documented? Is your (new) linked github repo updated?
And do you have prebuilt binaries for the current version (win/linux)? The links on the github repo take you to a version from 2020.

Thank you.

Most of the details can be found in the Readme.md file. The most recent ones are listed here only.

I do have binaries for Linux for sure, but they will only work on Ubuntu related distros, 22.04 and 24.04 release exclusive.