kode xchange

Discussion in 'RGSSx Scripts In Development' started by IceDragon, Nov 16, 2013.

  1. IceDragon

    IceDragon Elder Cookie Dragon Veteran

    Messages:
    73
    Likes Received:
    60
    Location:
    Jamaica
    First Language:
    English
    Primarily Uses:
    N/A
    KODE-XCHANGE

    .. Introduction

    Welcome to my code exchange thread. Or maybe I should call it snippet dump?

    .. What Is This?

    Over the course of my time in the IRC, we have a few folks logging on, expressing a few problems, or some feature they'd like in RMVXA or RGSS3, other scripts are just something from projects I've worked on.

    .. Code

    kode-xchange <Dropbox>

    Because the dropbox folder changes so often, and because I'm not always "online",

    I'll just leave the link to the folder here.

    Each snippet is contained in the lib or blib folder:

    lib/

    Contains individual snippets, in sub-folders, the structure should be easy to follow.

    lib/core/ these scripts are usually associated with built-in classes (such as Sprite, Window, Rect)

    lib/module/ these scripts which contain a "module"

    lib/mixin/ these scripts which contain modules intended to be used as "mixin"

    lib/vxa/ these scripts which target the default RMVXA scripts (the ones that ship with a new project)

    lib/sprite/ these scripts target Sprite classes

    lib/window/ these scripts target Window classes

    blib/

    Contains built scripts, which are normally snippets from the lib. These are intended to be used; as is.

    .. Usage

    Please read the LICENSE when and if you plan to use the snippets (though, I don't think you need to..)

    .. Highlights

    lib/sprite/sprite-bug_fixes.rb

    While I was writing sprite-tone_flash.rb, I found that Sprite#tone has really odd behaviour when its initialized from the Sprite itself.

    To describe it? With experience in writing Ruby extensions, I believe that Sprite (the C/C++ code they used) has an internal Tone object.

    when you call #tone, it does something like

    Data_Wrap_Struct(this_sprite, NULL, sprite_free, this_sprite->tone)If you try to duplicate this tone imediately, you'll find that you can have 2 Tone Objects, which point to the same internal Tone. >_> In other words, they use the same Tone pointer.

    This is just my assumption, since I can't really rip apart the RGSS code to get to the bottom of it, I can't say otherwise.

    The fix: initialize the #tone manually before using it.
    lib/core/viewport.rb

    Viewport is probably one the most underestimated classes in RGSS2/3

    Why?

    For one, while its easy to create one, manipulating it is a pain.

    The other, its much easier to just create and position your Objects rather than fighting with Z-Orders.

    But, did you Know?

    "You can move a Viewport after creating it?"

    viewport = Viewport.newviewport.rect # that thing, is your ticket to Viewport enlightenmentviewport.rect.x += 24 Even though it's possible to manipulate the Viewport's position and size using its #rect: this gets clunky, fast. Sure you could just grab the #rect itself and then move it like you normally would as a normal rect, but what if you decide to change the internal rect of the Viewport later? *wink* *wink* *nudge* *nudge* *eh em* #rect=

    The work around is to delegate the #x, #y, #width, #height accessors from the #rect in the Viewport itself.

    So instead of having code *points at the "But, did you Know?" section*

    viewport = Viewport.newviewport.x += 24viewport.y += 24viewport.width /= 2It feels more natural, and you can batch it together with every other Rect like object; EG. Sprite, Rect and Window.Its just cosmetic, but it makes your life a little easier.
    lib/sprite/sprite.rb

    I found Window to be rather boring to use, its not very flexible, and a lot of the functionality was still hardcoded.

    To alleviate my pains; I wrote a Shell class using nothing but Sprites.

    The result: it was much more flexible to say the least, but you quickly get a headache when you have to be doing calls like these all over the place:

    sprite.bitmap.dispose if sprite.bitmap && !sprite.bitmap.disposed?sprite.disposeNow repeat that for 5 or 18 more sprites.Q: "But IceDragon, couldn't you just use a loop for each of the sprites!?"

    A: "Can I use a loop to solve global warming?"

    Obviously that makes no sense: and quite frankly, it really doesn't.

    Its the same problem. And you've now introduced an Array to the problem.

    Well enough of my ranting, the solution was simple:

    A: "Why not have the Sprite dispose its own #bitmap?"

    So instead of hellish code like so:

    sprite.bitmap.dispose if sprite.bitmap && !sprite.bitmap.disposed?sprite.disposeYou only need to say:
    Code:
    sprite.dispose_bitmap_safesprite.dispose
    or even better:
    Code:
    sprite.dispose_all
    Thats 1 line less, and quite a few characters as well.
    .. FAQ

    Q: "Why are you using / instead of \ for path names?"

    A: "My \ is too far away... *obvious lie*"

    Q: "How do I use x script in y project for z feature?"

    A: "Just ask in the topic, and I'll answer you."

    .. Closing Remarks

    I don't have any closing remarks at the moment. So just have fun. If you have any questions, or you'd like to contribute something; feel free to post here, I'm always willing to listen (unless you intend to nag me about politics and or religion)

    .. Scrapyard

    Nothing here but us cookies...

    Android Colors

    droid_red

    droid_green

    droid_blue

    droid_yellow

    Class/Module Name /w Colors

    Audio

    Input

    Graphics

    Keyboard

    Mouse

    Bitmap

    Color

    Font

    Plane

    Rect

    Sprite

    Table

    Tilemap

    Tone

    Viewport

    Window
     
    Last edited by a moderator: Dec 22, 2013
    #1
    Dr.Yami likes this.

Share This Page