HiddenChest RGSS Player Executable

[kyonides]

A Long Awaited Update?

Normally, you would need to open the hiddenchest.conf Configuration file to enter the name of your game project. Thus it would be capable of finding the corresponding RGSSAD or RGSS2A or RGSS3A compressed file. That happened because MKXP's developer Ancurio was TOO LAZY to do it automatically.

But don't worry  guys! Now HiddenChest version 1.1.59, I mean, 1.1.46 for Linux will find the file on your behalf!

How is it possible? Well, it has a lot to do with a weird bug I had found in Ubuntu's Ruby development package. It forced me to look for a way to do the Dir#glob search in C++ code instead.

One of its great benefits is that it will recognize which RGSS version your game is running on without any external help.

I don't know when I will be able to update the GitHub code.

[kyonides]

Modifications Are Unavoidable!?

Well, I didn't expect to update the engine, but, there's always a but, I was trying to play some game that depended on another engine. Since I couldn't stay put, I had to check out whether or not my own engine could handle it. The sad truth was that it couldn't.

What happened there was that they had included weird methods like Graphics.delta, System.platform and System.user_language. I couldn't find any reason why I shouldn't include them as well, leading me to the moment when I simply looked for ways to implement them as well. One of those method simply made me rename an existing module and the other one forced me to include some new SDL2 header file to grab that information from the current OS.

Then another of those strange moments took place. I realized that there were games like Warcraft that simply told you that pressing ANY button  would let you go to the next scene. I already had a method, namely Input.trigger_any?(button1, button2, etc.) that could do something similar but not identical.

 What if I could fully implement it in HiddenChest?

So I took a moment to analyze the Input class in C code and found out it would be extremely easy to add that desired feature!  Obviously, defining the corresponding Ruby binding function for the Input module was a piece of cake!

This means that now we have several new methods:

• Graphics.delta (N microseconds)
  
• System.platform ("Windows" or "Linux")
  
• System.user_language ("en" or "es" or "de" or "fr" or "ja")
  
• Input.trigger_any? (For gamepads, mice and keyboards)
  
• Input.trigger_buttons?(btn1, etc.) (the old Input.trigger_any? behavior)
  

One day I'll be able to update my GitHub code to include all of the latest additions and other changes made to HiddenChest's source code.

[kyonides]

Source Code Updated!

Well, I didn't really add anything visually appealing in this occasion, but I finally updated the GitHub repository as promised!
 The only thing is that I needed to upload it to a different repository because I no longer have access to my old email account. Yeah, it's a big Ooops  indeed!
Unsurprisingly, my new repository is named kyonides/hiddenchest_linux just in case you wanted to know that.

The few updates made to the source code to make it partially compatible with another fork of mkxp have been included by default.

[kyonides]

Source Code Updated Again!

 

This time I focused on replacing several of the popup windows that you would normally see on the vanilla versions of RGSS with game screen wide error messages that happen to also save the screenshot in the local Screenshots directory. How convenient!

I know that it is not as novel as it might have been like 2 or 3 years ago  but I simply had not fully implemented them at the time. They were more like part of the improved code for its Linux only version. It is not that hard to compile the published code on Windows if you have got some experience with that process.

The Story

This is what happened back in the days. I was experimenting with the code to be able to create a separate library or binary source code for Linux. The reason was a complain a Spanish speaking RM user made back then who strongly defended the use of libraries instead of incorporating the code directly into the executable as it happens by default. On Linux that worked perfectly for it is not as demanding as its Windows counterpart.

The problem was that people like him actually wanted to use its features as a complement of vanilla RM.   No wonder why they ended up using another mkxp fork months or years later for their own projects.

[Mel]

Nah, the zoom is kind of incorporated in mkxp and HiddenChest from the beginning, just change some settings in the hiddenchest.conf file and you get... a permanent zoom

Just out of interest: what exactly do I need to change there to achieve a permanent zoom?

[kyonides]

No, it has no zoom per se. The only thing mkxp offered was an issue that would only arise the moment you incorrectly change the dimensions of the drawing area but not the actual window size. In few words, you could only make it look smaller and only by mistake.

Another fork of mkxp might have achieved it, but I haven't had time to fully study the code because they'd have made changes in several C++ classes to enable it. Even I cannot guarantee you that changing the window's dimension in game won't make their projects crash. I faced that a couple of times already in my own fork, but gladly found out what was causing it: the default system that stores and displays all of the tiles of the different maps you make. I was able to make it adaptable, yet, I don't know if they might have rewritten it partially or in full.

There are caveats we all would have to consider depending on how you would use the so called zoom and the window's dimensions.

[kyonides]

Create Custom Screenshot or Sprite Files

In the latest version of the Linux Port of HiddenChest, you are now able to call Bitmap#write by passing a "FileName" string to it as its sole parameter.

Code:

self.bitmap.write("filename")

Then I noticed that forcing the file extension to be the same as the Screenshot's might not be very convenient for the average game developer. Thus I made just another change to the CRuby code.

Now you can pass your preferred file extension!

Code:

self.bitmap.write("filename", "png")

Don't worry pals! The engine will add the "." that keeps the filename and the extension together.

The update also include a new extra Ruby script.

It features 2 new method calls for Sprite_Character that allow you to save the whole character's bitmap or just the current frame.

As a consequence of touching the code pertaining to the Settings module, a couple of old instance variables got new names. The reasoning behind this is to use a single nomenclature that makes them compatible with other existing variables that had Screenshot related values to hold there.

So instead of using Settings.image_format, you now need to call Settings.shot_format instead.

Do you need to know which file extensions are supported?

That's quite easy to find out indeed!

Code:

Settings.shot_formats

It will return an Array with both of the supported screenshot file extensions.

[DerVVulfman]

There appears to be issues with graphic rendering insofar as the usage of the Show Pictures/Move Pictures system.  When implementing a simple event system that takes five images from the Graphics\Pictures folder and merges/blend them into a single image within the center of the screen (a little warning/advert of sorts), I receive a strange flickering with your system. However, I looked at ReGaL and last executable builds of MKXP and had no issues. Videos presented below:

Correct RPGMaker and MKXP rendering:  [attachment=1953]

Improper with HiddenChest:  [attachment=1950]

There's a severe limit to upload-size with .mp4 files. Hence the short video lengths.

  Oddly, I should note that using OBS to record these images, I found that OBS saves a 4 second video with RPGMaker XP or MKXP as a 4MB sized mkv file. But using the same setup with OBS, a HiddenChest recording of the same 4 second length results in a mere 1.6MB mkv video using the 64bit h640.exe. This is curious indeed.


Insofar as the event code that should properly render, it is quite a simple Parallel Process Event:

@>Set Move Route: Player
:               : $>Wait: 100 frame(s)
@>Show Picture: 1, 'WARNING', Center (-1000,-500), (800%,800%), 0, Normal
@>Show Picture: 2, 'WARNING', Center (1000,-500), (800%,800%), 0, Normal
@>Show Picture: 3, 'WARNING', Center (-1000,500), (800%,800%), 0, Normal
@>Show Picture: 4, 'WARNING', Center (1000,500), (800%,800%), 0, Normal
@>Show Picture: 5, 'WARNING', Center (320,240), (800%,800%), 0, Normal
@>Move Picture: 1, @40, Center (320,240), (100%,100%), 64, Normal
@>Move Picture: 2, @40, Center (320,240), (100%,100%), 64, Normal
@>Move Picture: 3, @40, Center (320,240), (100%,100%), 64, Normal
@>Move Picture: 4, @40, Center (320,240), (100%,100%), 64, Normal
@>Move Picture: 5, @40, Center (320,240), (100%,100%), 64, Normal
@>Wait: 20 frame(s)
@>Move Picture: 5, @20, Center (320,240), (100%,100%), 128, Normal
@>Wait: 80 frame(s)
@>Erase Picture: 1
@>Erase Picture: 2
@>Erase Picture: 3
@>Erase Picture: 4
@>Erase Picture: 5
@>Control Self Switch: A =ON
@>

Obviously, there is a second page set to execute when Self-Switch A is turned on.

Seeing that this is done with nothing more than default event commands, this should not even be an issue. However, it is.  And below is a sample RMXP project with that event code you can test.

TEST DEMO: [attachment=1954]


OOOH, and curious. Rather than using the MKXP.Conf file which is essentially an .ini file, why hasn't anyone thought to just put the same initialization variables into Game.Ini and just be done with it? That's for ANYONE that incorporated the MK base.

[kyonides]

Well, I didn't really change how the original conf file worked except for changing its filename and adding just a couple of new settings. They're optional so the conf file doesn't include them by default last time I checked.

Could I change it so the engine reads the Game.ini file instead?
 Yeah, I guess it's possible. Other MKXP based engines actually do some fun stuff with JSON key value pairs, the equivalent of Ruby Hashes. I guess I would have to choose between one of those implementations in the (not so near) future.

Yeah, your clips seem to prove there is something wrong going on while moving the pictures on screen. The curious thing is I can no longer reproduce it with HiddenChest version 1.1.51 for Linux. It runs smoothly now.

I do remember that a previous version of my engine really had some issues with it, even on Linux, when trying your Lani arrests Aluxes demo because of the warning pictures you usually include in your demos. I downloaded the demo you provided me here, tested it on version 1.1.51 for Linux and it centers properly and you can read the message with no issues before disappearing.

 I suspect there is a hidden bug in the old Windows port of my engine that I would eventually need to address. Yet, it won't be that easy because I need to setup my Linux and Windows partitions in such a way that I can build the engine either with GNU compiled DLL's or with Windows 7 or 8 ones. I hate the latter because that would force me to download TONS of GB only to compile stuff for Windows.  It would require at least 5 GB at least, up to 30+ GB.  

Time will tell.

[DerVVulfman]

Well, I will say that the older HiddenCheat_Hires port for Windows doesn't have the graphics issue. I know of it thanks to Melana. However, it has issues with Mouse functionality which you had corrected with the current edition. A hybridization between the two would be great. Sometimes a step back takes you forward.

Waiting for an update. OH, and I posted a script showcasing mouse functionality that works with the current edition of (at least the 64-bit Windows of) HiddenChest.

And ... um... outlines around text by default?