Quick Pick



Oct 24, 2015

AFK

Hi guys,

As you may have noticed, I've been away for, uh, quite a while. No particular reason to this, I'm just quite busy (I'm a divorced father of two young kids if you have to know) and, well, game-making doesn't seem as thrilling to me as it used to. Sooo basically I'm posting today to say goodbye for an indefinite period of time. I'm not closing this blog because I want people to be still able to access my contents even though I'm away - but on the other hand I won't be active here until further notice. I know I'm going to leave some users disappointed because I've received lots of requests for help in the past months that I let pile up, and if I'm addressing one I'm going to address them all, and this is too much for me right now. I also saw lots of nice comments I'm not going to give individal replies to, but be assured I read them and it meant a lot to me.

So, thanks to all of you faithful and casual readers for your support and feedback and positive thoughts. I hope I was able to provide enough contents and help to leave good memories wherever I have posted too. I'll be thinking back of my experience as an amateur scripter with a smile on my face - and who knows, maybe we'll meet again in the future, here or elsewhere.

Take care.

Dec 31, 2013

Daily Life Project (part 1 - time and lighting)

It feels a bit strange that, after all this time, I finally get to repost the script that started this blog, a long while ago, long before I had made myself a name - that is, long before the ACMS. :p The loop is getting looped, and it feels like a nice parting gift with all of my faithful RMXP followers.

The Daily Life project initially is my own attempt as a day/night system. If you would like a day/night system and...
  • you think most of those look ugly or otherwise unrealistic
  • you would like to control the flow of time
  • you would like to make variations on events based on the time of the day or day of the week
OR
  • if you would like a realistic, dynamic lights system
Then it is exactly what you need.




Features



Event-controlled time.

  • time does not advance automatically - unless you command it to with a parallel event. You get to control how time changes with game variables, down to the second.


  • a wide range of variables and switches allows you to set event to appear/occur only at specific times - specific hours and/or days in the week and/or months and/or years...


Natural-looking day and night.
  • progressive transition between dawn, day, dusk and night
Progressive change in daylight on a summer solstice
  • progressive change of daytime duration according to the season (daytime lasts longer in summer)
Progressive change in daylight on a winter solstice
  • fading overlay effects according to time of the day (sunbeams at noon and haze at night)
  • events named "Shadow" automatically fade out as night gets closer
  • day/night can be disabled when inside closed spaces, and luminosity set manually
Closing the curtains forces the luminosity to zero despite the fact it is noon

Realistic, dynamic lights
  • any number of light sources can be set and blend naturally into each others
  • real-time calculation allows light sources to flicker and even move around
  • adjustable radius and strength
  • lights tear through darkness but do not overlay ambient light




Known issues



  • This script is known to make the interpreter lag, depending on the user's machine. It is not the script's fault. RPG Maker's graphic engine has such poor performances, that how the script works will necessarily confront it to its limits sooner or later. It is pointless to ask me for an optimization, since there's absolutely nothing more I can do to address this issue. However, here are a few guidelines to avoid lagging:
  1. More light sources mean more calculations - do not make too many of them
  2. Map scrolling requires recalculation at each frame - avoid making maps that exceed the screen size
  3. Having light sources flicker or move around also requires frequent reclaculation - do not overuse those effects
  4. The darkening overlay which gives the illusion of night is arranged in small blocks. The DARKNESS_PRECISION constant in the Constants - Custom entry controls the size of said blocks - the smaller they are, the better the quality and the worse the lagging. It is set to 2 by default, which I found to be the best quality/performance ratio. Setting it to 1 will make the overlay appear blocky but will cut the load in quarter.
  5. The DARKNESS_FRAME_SKIP constant in the Constants - Custom entry allows to force the calculations to wait for a set amount of frames, thus effectively cutting the load. It is set to 0 by default (no skipping) but you can set it to small numbers (like 4 or 5) so that the overlay does not appear too jumpy, and you gain a little performance boost.



Download



The following link provides a script bundle meant to be used along with the Script Manager. Terms of use and instructions are provided within. Please credit me if you use it in your own project. A nice comment is always appreciated.


The following link provides a demo for said script.

Dec 29, 2013

The Variables Binder or How I Made Something Easy Even Easier

Faithful users of my works know that I like event-controlled system, when appliable. For example, my Balloon Messages System relies not on clumsy commands input in messages or stuff like that, but rather on regular switches and variables, which are easier to handle. Those switches and variables are then read by the scripts which in turn do their job. To achieve this, the scripts have to know which switches/variables were appointed to this or that purpose, because from one project to another, a same switch/variable may very well have a different ID - like, if I use switches #2 and #3 in my demo, they might already be allocated, and you'd like to use other ones instead.

Up to now, you had to manually set up constants for that purpose. You had to choose free switches/variables in your project editor, then you had to open the script where the constants were set and replace each of them with the ID you'd chosen, and then it was all cool and easy. That was, until I decided I was too lazy to do the manual part anymore. I decided it was not that hard for the scripts to find the matching switches/variables after all and they could very well do it on their own. From that decision, a new script was born. Behold... here's the Variables Binder!



So what does it do?

Basically, automate the process of binding switches/variables as set in the project editor with the scripts. Say you install the Balloon Messages System to your project, you run it just after, then return to your project editor and poof! a couple of variables and switches which control this system have installed themselves in free slots, saving you the trouble of naming them manually. From then on, those switches/variables will automatically be recognised by the script you've just installed and you don't need to worry about that anymore. So, in short, it's simple as 1-2-3.



Any recommendations?

The Variables Binder will never ever mess with switches/variables which already have a name so it's absolutely safe to use on a project you have already started a while ago - however, it decides whether a switch/variable is free based on whether its name is empty or not, so make sure all of the switches/variables you're using at this time have a name, otherwise you could get surprises.

You can see that your newly named switches/variables have got a tag before their name. This makes it easier to see which variables group together, but it also works as an identification code. That is, you're free to rename the switch/variable as long as you keep its tag intact.

If you were already using one of my event-controlled scripts prior to the arrival of the Variables Binder, please make sure the variables you've set manually have the exact same name (without the tags) as in the original demo, since when the tag is absent, the Variables Binder will identify them based on their name, and automatically add the matching tag - so you end up with the exact same settings as if starting a fresh new project with the scripts' latest version.

If the switches/variables have not been installed prior to the Variables Binder's first launch, it will claim the first free slots it can find, so you might want to have several of them in a row so that they don't get scattered. Also, make sure you have set the maximum number of items so that there's enough room for the newcomers in the first place!



What if I still want to set the variables manually?

If you're not satisfied with the Binder's automated setup for whatever reason, there's nor problem at all. Just cut/paste the name of the variable you want to move to another slot. Since the setup is dynamic, the script will recognize the newly named variable as if it had set itself up on the next time you run the game.



Where can it be found?

The Variables Binder is part of the latest version of my Common pack. You should re-download it to ensure compatibility with my future scripts.

Aug 25, 2013

Surprise on the Moon!

Hello folks,

Recently I was announcing I'd lost some significant contents that was supposed to help me complete the oh-so-awaited update to the Script Manager. This led me to question some choices I had made at the time, since I was to remake them anyways. And so, I'm pleased to announce that I've AT LAST succeeded at making the Script Manager as versatile and powerful as I wished it to be. Though it's not quite the all-in-one utility I had in mind at first, I think it's all better as it is now.

From now on projects are going to be hybrid, meaning you can run them as regular projects using their featured copy of the scripts they use, or run them using the Script Manager, with no modification whatsoever. For example, when I release a new script, you can try it out downloading it as a plugin and launching your project with the Script Manager - this will read the newer version you've downloaded instead of the older one from your script editor, without replacing it, so your game still runs the same as before. Additionally I've made a tool to export scripts from your projects (read scripts from the script editor and export them as .rb files, so that they can easily be used along with the Script Manager), as well as another one aimed at importing the .rb files used by the Script Manager into your script editor, all of this automated of course.

I will not be going more into detail tonight, I was merely to excited about this new achievement to wait any longer to let you know. I will be replacing all of my Script Manager-dependant demos with hybrid demos you can run as they are in the following days. As of right now only the newer version of the Ballon Messages Demo is available for download. You can try it out, check that it does actually run on its own, and have a look at the scripts inside its script editor, all of them imported automatically from external .rb files. :)

Have fun!

Aug 20, 2013

Even More News From The Moon

Hey guys,

Today I wanted to complete the update I'd promised a loooong time ago on the Script Manager, but I realized I had failed to update my backup copy with the latest version of my works. Fortunately not everything was lost, but I have a lot of catching up to do and I must confess this sad event has killed the little courage I was able to gather. So probably still no update before a while.

Regarding OpenRGSS, a friend of mine helped me through the process of writing the C code I need, but now we're stuck at the compilation step, which really seems to be a pain with Ruby in a general manner. Also, I'm considering dropping SDL as OpenRGSS's backbone and replacing it with SFML at the suggestion of a community mate, but I still need to investigate its features and of course, to install it succesfully before making a decision. This would mean rewriting the low-level engine, but hey, life is an eternal starting over.

So, lately, I feel the urge to create something, but nothing seems to go right. Anything for me to do, anybody?

Jul 10, 2013

More News From The Moon

Hey guys,

I know many of you await news from the OpenRGSS project. Sadly I haven't been any further than what you have seen already. The main reason for this is that I'm stuck with technical issues. Simply put, there are things I will not be able to implement in Ruby, not because I cannot do it, but because Ruby is very slow and even with optimal programming, some processing-heavy functions slow down the engine too much. So, I would need to implement some of it in C++, which is Ruby's "parent" language. The problem is that I don't know the first thing about C++. So, if anyone who is knowledgeable about C++ happens to pass by, your help would be very much appreciated on those issues, it's mostly about investigating the Ruby/SDL gem's source code and helping me with syntax and stuff - nothing too time-consuming, really. Also, if you know someone who might be able to help me, please do spread the word. As soon as I get past those lil' setbacks, I can resume OpenRGSS's development.

While I'm there, I would like to share my feelings regarding something which has been bugging me. I know the Script Manager has rendered the installation of my scripts less intuitive, especially since I have still not released the update like I had promised a while ago. Still, as open to criticism as I might be, I do not accept comments like "I don't understand the first thing about your site, make another tutorial". I can understand your frustration and I'm honored you absolutely want my scripts in your games, but I am not a company, I am not making business out of scripting, I have not sold anything to you and I am not an after-sales service either. I have made those scripts for the sake of making them, and nothing forces me to share them in the first place. I might as well shut this blog down tomorrow and close my MediaFire account just because I feel like it, and keep my own scripts to my own self, and there would be nothing to lose as far as I'm concerned. Because I share my creations does not mean I have pledged to have them work perfect in each and every one's games. If you address me without the slightest "please" or are implying that I did a poor job, you're welcome to look for scripts elsewhere and I will definitely not mind you not using mine, really. People who have no respect for others' works do not make games I like to play, anyways,

So, basically, if you have no consideration for me, don't expect me to have consideration for you and your game, either. And don't come bragging about how you will never use my scripts to punish my arrogance, because frankly I don't care. People who have addressed me in a friendly, respectful manner, can testify I sympathize with others' issues and often do my best to help them while there's nothing for me to gain in return. The others can keep on asking and complaining as long as they like.

Sorry about this little digression, nothing has changed towards my faithful readers, and I'll make sure to let you know it as soon as I have solved my C++ issues.

Take care in the meantime.

May 20, 2013

OpenRGSS Progress Report - Sound & Music

I'm still doing a lot of behind the scenes work, so nothing really new since last time except for the addition of sound and music, which was kinda piece of cake as compared to the graphics engine. So this time you get to watch a small video to see how all this blends together (please watch in HD).



Comments in the video say it all I guess. If you listen carefully, however, you might notice that the music sounds a bit different than what you are used to. So you might wonder what I did to those music files to improve their quality. Well, nothing actually, and that leads me to a very interesting fact I'd like to point out.

You have surely noticed that MIDI files (.MID) tend to have poor quality. On the other hand, they are tiny in size, but then many people wrongly assume that there's a link between the two. This is true for sound files, like .WAV of .MP3 files, because the bigger they are, the more information they have, and thus the better the quality. Well then, a MIDI files does not contain sound. It's merely like a sheet music, it just stores what note it's supposed to play at what time using what instrument, and that's the reason why it takes so little space. This is also why you can easily tweak pitch, tempo, volume, instruments... track by track, using the proper editor, while sound files are somewhat "merged", raw sound, with no concept of notes or instruments in the first place.

So you're probably going to wonder, how do I get to hear a MIDI file then? Well, you just need to have a synthetizer to read the sheet music and play it back. It will do so using a sound bank, in which samples for each instrument are stored - meaning, if you followed me, that if you use another sound bank, your MIDI file will start and sound differently all of a sudden. This is very much like using a character font for text - the text data remain the same, but it's rendered differently according to which font you pick. What I previously called sound bank is sometimes referred to as soundfont, by the way.

So the reason why your MIDI files sound bad is because the default synth featured with your system has a crappy sound bank. Get a good synth and they will sound better just like magic, with no addition or tranformation whatsoever to the files themselves. The good news is that it is possible to replace Windows's default synth with another one that supports soundfonts, then you get to choose the soudfont most fitted to your taste and computer performances. The bad news is that MIDI files will still sound crappy in RPG Maker. This is because RPG Maker does call the system synth, but rather uses its own, internal synth, which sticks to the crappy sound bank, and there's nothing you can do about it. But then again, another good news is that, of course, OpenRGSS does call for the system synth to play back MIDI files, which means it does support soundfonts as long as you have a software synth installed, which supports them itself.

For this video, that's exactly what I did - downloaded a software synth (namely Coolsoft VirtualMidiSynth), downloaded a soundfont (Merlin Gold v4.10), set the synth to use the soundfont and use it as default synth for MIDI playback. Now all MIDI music that will play on my system, wherever it might come from (except for RPG Maker of course) will use the soundfont and sound nice. Note that this applies only to MIDI files, though, and that it depends on the user's system - meaning if you install the synth and soundfont to get your MIDI to play nicely, it will still sound as bad as always on the computer of someone who hasn't.

I couldn't resist recording a few pieces using either the RPG Maker playback, or the synth/soundfont combo, so that you can hear the difference. I'd like to insist that those renderings were obtained using the exact same MIDI file with no adds or modifications whatsoever.

RMXP playbackOpenRGSS playback
using VirtulMIDISynth & GeneralUser GS FluidSynth v1.44 soundfont
001-Battle01.mid
RMXP
012-Theme01.mid
RMXP
026-Town04.mid
RMXP
034-Heaven01.mid
RMXP
039-Dungeon05.mid
RMXP
044-Positive02.mid
RMXP
062-Slow05.mid
RMXP
GRABBAG.mid
Duke Nukem 3D
STALKER.mid
Duke Nukem 3D
ALIENZ.mid
Duke Nukem 3D
EXRUM.mid
Monkey Island 2
LARGSTAB.mid
Monkey Island 2
HITGM.mid
War Wind

So, I hope this post shed some light on the MIDI format and gave you a better opinion of it. More progress to be shared soon, so stay tuned and have a nice listening-to-better-MIDI experience in the meantime.