Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - ForeverZer0

Pages: [1] 2 3 ... 149
Holy hell, I have absolutely no recollection of every created that. I will look in my dropbox and fix link. Never fixed them after Dropbox changed all their crap around.


Oi! I actually found it.

New Projects / Re: [Ruby] FMOD Low-Level API Wrapper
« on: March 23, 2018, 09:59:51 PM »
Nice. If now somebody could pull the samples out of XP, we'd finally have a worthy MIDI audio replacement. xD

Added a generic Audio module as an example to get started with. Even in its basic form, already far more capable than RMXP.
  • Backwards compatible
  • Tempo changing
  • Adding DSP effects
  • Frequency changing
  • Pause, seek, etc. functions

I did not yet implement checking if sound is disabled via the properties of RMXP. I can add that snippet as well soon, as it is little complicated reading the registry keys.

New Projects / Re: [Ruby] FMOD Low-Level API Wrapper
« on: March 23, 2018, 08:06:15 PM »
MIDI control is native to FMOD, I am not 100% sure if uses its own, or just chooses based on the platform. Considering FMOD is used on about every kind of hardware and video game console out there, I imagine it probably uses its own for consistency. The documentation is a little light on the actual internal codecs, etc. and how they work.

It does have great MIDI support built-in, though, per MIDI channel gain, sound fonts, etc.

These methods in the Sound class deal with MIDI volumes, etc.
(click to show/hide)

New Projects / Re: [Ruby] FMOD Low-Level API Wrapper
« on: March 23, 2018, 12:24:18 AM »
I am not really pleased with the structs or enum implementation.

For structs, inheriting from is a little bit of a no-no, since you are also creating an anonymous class that never gets used. I used it as a bit of shortcut to writing all the attr_accessors and initializers manually, but it is not really the best practice to do that.

As far as the Enum class goes, I had a perfect idea to implement that better, using simple symbols or integers, without the need of enclosing it within the parent enum class, but now that it is so far integrated, it is going to be a painful change to alter all of the methods that use en enum, which is a few hundred.

And still more documentation with examples. I have spent far more time documenting than even writing code, getting really sick of it, lol.

New Projects / [Ruby] FMOD Low-Level API Wrapper
« on: March 22, 2018, 11:52:32 PM »
I was in need of a good audio API when working on a C# application, and was unable to find an existing library that fit my needs, so I ended up making my own using the FMOD Low-Level API (the predecessor to the legacy FmodEx). After working with FMOD, and learning the ins-and-outs of how it worked, I saw the potential for making a Ruby port as well. Searching online turned up very little as far as any type of wrapper that could ever be considered close to complete, and only had the basic functionality of FMOD implemented. This including existing RPG Maker scripts that wrapped the basic functionality of the old FmodEx, but nothing more. This prompted me to write my own wrapper.

Being my programming experience begin with Chaos Project and old Ruby 1.8.2, I decided to write in a way that would remain compatible with old versions of Ruby, and foregoing using any Ruby gems or functionality that didn't exist in Ruby 1.8.2, and decided to stick with using Win32API to wrap the FMOD functions, and didn't allow myself the convenience of using a new library like Fiddle of FFI to make things simple.

Currently, the project is approaching the alpha stage. Nearly ALL core functions are implemented, but there has been no in-depth testing yet, and there are still a few mostly uncommon functionalities that need worked on. I have spent A LOT of time making documentation for it, as it is a huge API that definitely has a learning curve. If you don't believe me, see the spoiler.

(click to show/hide)

In the future, I will be releasing this as a gem, but as it stands now, the project can be loaded into RPG Maker with a simple "require", and built upon that. I may even create a basic Audio module rewrite with this codebase in the future, but if anyone else feels like doing it, feel free to check out the code and build upon it for RPG Maker Audio module.

  • Support for 20+ audio formats "out of the box", including all the RPG Maker standards (.mp3, .ogg, .mid, .wma, ect.) with support for more via a plugin system using existing FMOD plugins libraries
  • All basic playback control (play, pause, resume, seek, volume, etc, etc.) that you would expect of any audio player.
  • 20+ built-in effects for sound, including pitch shifting, flange, advanced reverb environments, multi-band parametric equalizer, chorus, tremolo, oscillator,  and many, many more.
  • Streaming of all audio formats, not just MP3
  • Full 3D and 2D support, with distance/directional based sound, each with own reverb environment.
  • Support for custom speaker setups, full surround sound support for up to 12 speakers.
  • Driver selection.
  • Supports music tags (ID3, etc) if that's your thing...
  • Much, much more.

As I stated above, this project is still in its infancy, but already far surpasses any existing audio API that I could find for the Ruby language, and because I love you all, I kept it compatible with RPG Maker XP and above.

This post is meant to a preview for a full release, and I would recommend not to port it as it currently is in a completed project. As so much yet is untested to any passable standard, lacks complete protection against segmentation faults, etc.



FMOD DLL (Required)


Source - Github

Getting Started

Download the scripts, place unzipped directory in RPG Maker project folder along with the downloaded FMOD dll.
Open script editor, add the line:
Code: [Select]
require File.expand_path('lib/fmod')
Just to give you idea to get started, snippet to play a sound:
Code: [Select]
sys = FMOD::System.create
sound = sys.create_sound('My Audio File.mp3')

Things to remember, the documentation, which is posted above, is currently lacking a lot of examples, so feel free to download the help file from FMOD's website, which can still be helpful on how to do things until the examples are created.

The documentation is not compiled, but can simply be unzipped and opening the "index" file within, which will open it in your browser.

FMOD object's need disposed! Once you are done using a sound, system, etc, call dispose or release on it to free the underlying handle. Obviously this behavior would be taken care of automatically when ported to RPG Maker. This is a developer's API, not an end-user product.

Below is generic audio module I wrote real quick just as an example as an example. It is already far more capable than the built-in Audio, but really more intended as just boiler-plate code.
(click to show/hide)

Script Requests / Re: Conditional Branch addon
« on: March 22, 2018, 09:43:01 PM »
@F0: If you're so opposed to it, then just combine the two as
Code: [Select]
$game_system.playing_bgm && $ == "TRACKNAME"There's nothing stating you can't use and/or in Conditional Branch scripts.

I am not opposed to anything, lol, and I am as guilty as anyone in the community of trying to make everything a "one-liner" back when I wrote RGSS scripts. Over the years I have obviously learned more as everyone has, and cringe at some of the stuff I wrote that I was clever at the time, and I am sure years from now I will feel the same of my current code as I learn more.

I just found the convention of trying to compact every little bit of code into the shortest possible number of characters/lines a bit odd,
even when at the cost of performance, which is typically the reasoning behind trying to make compact code. Some irony there.

This is not an issue unique to RGSS, but looking back, it does seem to hold some greater measure in the community that it is somehow "better" if two different snippets do the same thing, but one is shorter than the other.

Obviously this is a case-by-case basis, and there is no "rule" that doesn't have plenty of exceptions, but just stating an observation. The above example is a somewhat poor example, and would merely be a micro-optimization that holds no sway over the whole at all.

I am against enforcing any type of standard (I still remember SDK...), but I am for "good coding practice", even when it may be inconvenient for the situation. I wish I would have known things I know now about Ruby when I wrote scripts, but alas, that time has passed  :P

I am far, far from being masterful, but I have recently picked Ruby back up as a hobby, and realizing the error of my ways back then. I would suggest to anyone who is a performance fanatic to really delve deep into the Ruby C API, and really see whats going on behind the scenes with each line in your Ruby script.

Script Requests / Re: Conditional Branch addon
« on: March 22, 2018, 08:59:33 PM »
It is less efficient using the one line with a rescue as opposed to using two lines.

It goes against Ruby coding practice to use rescue for anything other than when it is needed, for catching exceptions, which should be "exceptional". A BGM playing or not I don't think is really that exceptional of an event that couldn't be handled other ways.

The reasoning is that "rescue" in Ruby is a somewhat expensive operation, as it it builds an entire stacktrace by iterating through the call stack that it would not normally be doing.

Back when I coded for RGSS, I was guilty of the community's strange convention that "shorter, compact code is always better", but in reality, it is not the case at all. I have spent a lot of time digging around the C side of Ruby the past few months, and realized that there are many, many things that are the standard convention in the RM community, but are actually bad practices, and are not even conventional in Ruby.

Probably should have split this topic off before blabbering on...

EDIT: I do realize that in this particular situation, it hardly matters, as I don't imagine it is invoked often enough to matter, and it is an unneeded micro-optimization, but I speak more on the global scale of simply better coding practices.

At a glance, looks like you could simply delete the branch for 8_DIR or whatever its called at the beginning of the jump method.

General Discussion / Re: See With Your Ears - Video
« on: February 23, 2018, 07:10:17 AM »
Not long ago, I actually was dabbling back into Ruby and made a complete wrapper around the newest version of the FMOD low-level API, the modern version of the legacy FMODex. Well, not 100% complete, but complete as far as anything that would ever be used in a 2D game, including all the DSPs for effects, reverb, playback control, etc.

It was not specifically intended for RPG Maker, was built for compatibility for Ruby 1.9+, and relied heavily upon Fiddle for interop, which won't work with RM, but an older version of it before I upgraded used all Win32API calls. I only made the transition do to hitting a wall with delegates for callback functions, since Ruby has no mechanism for that in older versions, but everything else *should* be compatible. It's quite large, spread across a lot of .rb docs, but if anyone wants the old code to port over, they are welcome to it.

Welcome! / Re: Hello...
« on: January 30, 2017, 09:46:14 PM »

Welcome! / Re: Time for some Alexis action!
« on: November 21, 2016, 05:42:09 PM »

Welcome! / Re: Hi I'm Mip and I'm making a game
« on: July 23, 2016, 10:56:37 PM »

Welcome! / Re: Hellew o/
« on: July 05, 2016, 01:09:10 PM »

A couple of years ago I made a dll that performs all sorts of manipulations on bitmaps. Never did complete it totally, and it is written in C# with .NET Framework, but much of the methods could be easily translated to another language. You can at least see examples of how the pointers to the bitmaps are handled, etc.

Welcome! / Re: I'm back
« on: May 19, 2016, 02:44:13 AM »

Welcome! / Re: Hi all!! Starmage here!
« on: May 19, 2016, 02:42:18 AM »

Welcome! / Re: I come in peace
« on: May 17, 2016, 12:46:27 AM »

Welcome! / Re: Olá! :)
« on: May 14, 2016, 05:52:09 AM »
Portugal? Never heard of it.

Script Troubleshooting / Re: Using switches to alter menu commands
« on: February 06, 2016, 01:42:48 AM »
You don't need to lock topics, they can remain open.

Pages: [1] 2 3 ... 149