Save-Point

I have uploaded a maintenance version of HiddenChest a few minutes ago so I would recommend people that downloaded any version of it like last night to get the newest release for your own games' safety. Nah, your games won't get corrupted or anything else, it was just me that was falling asleep and made a couple of minor mistakes while editing the source files. Don't worry! I have fixed them already!

It is curious how some stuff that seems to no longer be needed, ends up being called by a piece of code that I skipped editing. Now that I replaced some file with its original and untouched and pristine and boring and... OK, you got the idea, it works just as expected. Curiously this bug did not show up in the Linux version but only in Windows releases. O_O

Side notes: What a crazy night! I solved it while being kind of sick, not the night before when I was feeling better...

Yeah, it's just another of my weird headings, I know. The curious thing about it is that it does make a lot of sense once you learn about what those manifests are. Let's start on how Linux finds its dependencies alias all the binary source files it requires to let the application run on such system.

The Linux Way

All Unix like OS's seems to follow the same logic, they depend on stuff like rpath to find default or custom so files on any specific location. You set rpath information and the application will look for it wherever the binary executables is located.

There is no real need to edit the $PATH global variable at all.

The Windows aka Nightmare Mode Way

In Windows (any version) you just can't depend on rpath to find dynamic libraries or dll's because nothing like that ever existed!

What do you do then?  

You either have to place all dll's in the same directory as the executable file. (A gross style according to some emotionless South American forumer!)

You can compile some Manifest file, a pseudo XML file that will include "minimal" bloatware stuff only to tell the darn executable it can also look for dll's in a custom location without editing %PATH% manually.   Sadly that's not the end of it. If your compiled manifest file includes illegal characters, nothing will ever warn you about it!! Nothing tells you that's a bug!!   Still, you need to add another XML file also named a manifest to let your executable look for all the files you listed there.

Well, you can still edit the global %PATH% variable on windows, but you need to make sure the new path you are gonna add is located before it will read the default path for dll's. In few words you need to prepend it to the list of semi colon separated list of paths. Usually you wouldn't tell the average Windows user like the simple Lani to do that, especially if it's just for RGSS games.

---

In both cases, Linux and Windows, you can install the so's or dll's, but there's a risk of polluting your OS with different versions of common libraries, which is highly undesirable!!  

---

The thing is that I only needed to update the binary executables for all Windows versions, guys!

You're right, I didn't need to waste so much time pasting information that's just won't make sense to the simple Lani kind of users.

Do you remember I mentioned this a couple of days ago?

kyonides Wrote:I also added hidden module functions for the Audio module that will let me... *us* call common sounds like the buzzer like this:


Audio.play_buzzer

Does it remind you of VX Ace? Of course, it does! I did it on purpose. I just thought it was easier to call Audio.play_decision than stuff like $game_system.se_play($data_system.decision_se)

There is also an Audio.play_se("any_se") method as well to avoid using the corresponding $game_system method.

Still, I got to warn you that buzzer and the other SE aren't defined by default. To define them paste a code like the one below:

Code:

Code:

module Audio
  @buzzer = RPG::AudioFile.new("MyBuzzer")
  @ok = RPG::AudioFile.new("MyOKorDecision")
  # the rest of the commonly used SE
end

The decision SE is called @ok but it gets called as either Audio.play_decision or Audio.play_ok. It is the only exception here.

Well, now the latest version of HiddenChest (for Linux 64 bit and Windows 32 and 64 bit OS's) sets all those SE values for you at the very beginning. This means you only need to call stuff like Audio.play_buzzer to let the player know he or she or the pet dog did something wrong!  

For custom SE you would need the Audio.play_se("SEfilenameWithoutExtension") script call then. Keep in mind this is valid for XP games, other versions use the Sound module instead.

If you got any ideas you might want to get included in hiddenchest by default, don't wait anymore and go post them here!

Of course, I will have to double check how complicated it would be to implement them in the engine...

Haha, I'm so behind on the times and this is such a great gift to humanity!

Haven't tested this yet but there are a lot of old things I've half implemented which have been giving me problems. Resolution problems, input problems, tilemap problems, cross-compatibility problems, enough things to make me want to rip my hair out lol. The Frankenstein project I have put together dealing with all these features isn't 100% stable, not because I can't do it but because I've got a million other things going on. In other words...

It sounds like, with what you and ancurio have done, I might unimplement some things and migrate to this instead. I've tried with multiple scripts, I've tried utilizing SFML and Ruby, JRuby, Java, etc. I've tried a lot of things but I'm assuming this probably works better than what I'm currently standing here with. If you can't tell, I'm excited!

Thank you ahead of time, I'm getting ready to check this out right now!

How to Use

Hiddenchest features RGSS stuff, there are just few other additions beside the basics for any RGSS version, except that RGSS 1 also includes several RGSS 3 features now as I have mentioned before. The only part that might be confusing at the beginning would be the conf file, but it does include comments explaining its settings. F1 opens the gamepad (and keyboard) section, F2 shows the fps.

To install you just need the hiddenchest 32 or 64 bit version and the dll_bit_here_full zip file, unzip the executable snd a directory in the game project's root directory, then uncompress the dll zip contents in the dll_bit_version_ directory. At the end you would need to click on your preferred executable, either some exe or _console.exe. The 800 or hires suffixes just indícate the maximum resolution available, hires still starts at 800 * 608 px but can be increased up to 1280 * 800 px.

It seems I managed to increase the weather sprites, add a default RPG::Cache method for loading Faces, and add a brand new method called module_attr_accessor. What does this method do? It lets you create getter and setter methods for any instance @variable you create in a module! If you know what attr_accessor does for a class, then you will understand the module_attr_accessor does the same job for a module!

Since I am not 100% it works on any support OS but Linux, where I have been fiddling with it for a while, I cannot say I am ready to release it for the masses or gangs or the four alley cats that follow this thread.

You may get up to 200 400 weather sprites!

Now scripters should be able to use the module_attr_accessor feature like this:


Then you should be able to access the instance variable by calling:

MyModule.my_instance_variable

or sets its value with the script call

MyModule.my_instance_variable = 2450

---

Most of the so called new features actually belong to RGSS3, but I preferred to make them available for RGSS1 (XP games) as well. Others are exclusive to HiddenChest!

I should have explained this earlier but it is never too late to provide the following instructions:

Formats:

InstanceOfAClass#method_name
i.e. my_sprite.mirror_y = true

SomeModule.method_name

Classes

Sprite#width and Sprite#height
Sprite#wave_amp and Sprite#wave_amp=
Sprite#wave_length and Sprite#wave_length=
Sprite#wave_speed and Sprite#wave_speed=
Sprite#wave_phase and Sprite#wave_phase=

Bitmap#gradient_fill_rect
Bitmap#blur and Bitmap#radial_blur

Font#out_color and Font#out_color=
Font#outline and Font#outline=
Font#default_out_color and Font#default_out_color=
Font#default_outline and Font#default_outline=

Modules

Graphics.width and Graphics.height
Graphics.resize_screen(new_width, new_height)
Graphics.fullscreen and Graphics.fullscreen=

RPG::Cache.face(filename_no_extension_no_folder)

* Exclusive Features *

Classes

Bitmap#text_width("string")
Bitmap#text_height("string") # Usually the same as Bitmap#height...

Sprite#flip and Sprite#flip= (aliases of Sprite#mirror and Sprite#mirror=)
Sprite#mirror_y or Sprite#flip_y
Sprite#mirror_y= or Sprite#flip_y=

Font#outline_color and Font#outline_color=
Font#default_outline_color and Font#default_outline_color=
Font#underline and Font#underline=
Font#strikethru and Font#strikethru=
Font#strikethrough and Font#strikethrough=
Font#default_underline and Font#default_underline=
Font#default_strikethru and Font#default_strikethru=
Font#default_strikethrough and Font#default_strikethrough=

RPG::Weather#sprite_max and RPG::Weather#sprite_max=

Modules


Graphics.dimensions #=> [width, height]
Graphics.save_screenshot
Saves a snapshot in the Screenshots directory located in your game project folder even if it doesn't exist.

Audio.bgm_pos and Audio.bgs_pos
useful for setting up a new song or background sound at a different position.

Terms.critical_hit and Terms.critical_hit=
(critical_hit will be used by RPG::Sprite during animations, especifically battle animations.)

Backdrop.keep_bitmap # Makes a copy of the game screen
Backdrop.blur_bitmap # Makes a blurred copy of the game screen
Backdrop.bitmap # Access to the bitmap created with any of the previous script calls
Backdrop.clear_bitmap # Clear that bitmap

Audio.play_se(filename_no_extension_no_folder, optional_volume, optional_pitch)
Audio.play_buzzer
Audio.play_ok or Audio.play_decision
Audio.play_cursor
Audio.play_cancel
Audio.play_shop
Audio.play_equip

Scripts module to let you keep track of your custom scripts and the order in which they were loaded.

Tonight or early this morning, I have uploaded two different custom map resolution fixes for XP and VX. The first script is ye old friend that has been with us since the early releases of this engine, the VX version is the newcomer here. I just recently noticed how necessary it was to adapt VX to higher resolutions so I started working on it and recently finished the script. It did not take as long as it did when I crafted the XP version. Of course, it does not mean it fixes everything, but you could say it is a good start indeed. Regarding VX Ace it seems it does not need any help from any custom script, still, I could be wrong so bug reports would be welcome, guys.

As of today it is only available as a separate Ruby file with rb extension. You can download it from your preferred online file hosting service and open it with any text editor.

Hi!

So, i discovered this thread a few days ago, never heard of it before, tested the standard mkxp and your fork named HiddenChest with some sample projects.
May i ask... what is this mad wizardry?

Not only does games run more smooth with this new executable, they are running so much better when it comes to performance and running actual code. This is madness! For example, the standard event collision detection build by enterbrain is slow and poor coded as hell. With ancient 1.8 Ruby you get a terrible slow and stuttering game with 15 - 20 fps while having ~100 Events just set to random move with no additional code or custom scripts.
With HiddenChest i get stable fps, be it 40, 60, 120 or whatever you set. No slow downs, no stuttering. And all this already with the poor collision code from enterbrain. Amazing! Now imagine, how good regarding performance your game can become when you customize only the collision detection a bit and so on.

Really brilliant. But i have some question:

1. Is it possible to deactivate Keys like F1, F2, F12 and so on? I know there are already some Script, which can do this. But is your new executable also able to do this via some script commands without further customization? I ask because I like to think about some custom option menu where you can let the player customize the controls instead of using some popup menu via F1. Furthermore the player should not be able to reset the game via F12 for example.

2. Is it possible to change the values you can set in the config file ingame, via some script commands? Again, i like to think about an option menu where the player may activate/deactivate vsync, change resolution etc.

3. How restricted am I, as a developer, to distribute RPG Maker XP (or VX etc.) games running with the mkxp/HiddenChest executable? Is it only non commercial or also commercial? Is it legal or does it hurt some EULA from Enterbrain?

Thank You!

greetz