Preserved forum archive. This topic stores the original first post and locally mirrored RPG Maker Web attachments when available. It is posted by the BMMPlay archive account, not by the original creator.
Original Source
- Original title: kode xchange
- Original author: IceDragon
- Original date: November 15, 2013
- Source thread: https://forums.rpgmakerweb.com/threads/kode-xchange.19997/
- Source forum path: Game Development Engines > Ruby Game System (RGSS) Scripts > RGSSx Scripts In Development
Summary
KODE-XCHANGE .. Introduction Welcome to my code exchange thread. Or maybe I should call it snippet dump? .. What Is This?
Archived First Post
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
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
lib/core/viewport.rb
lib/sprite/sprite.rb
.. 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...
.. 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
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.
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.
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.
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.
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:
or even better:
Thats 1 line less, and quite a few characters as well.
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
Code:
sprite.dispose_allQ: "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
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
Downloads / Referenced Files
Log in to download
Log in, then follow the RPG Maker Developers Group to see these download links.
Log in to downloadLicense / Terms Note
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 Spoiler
Creator Claims / Removal
If you are the original creator and want this listing reassigned, edited, or removed, join BMMPlay and contact the moderators with proof that matches the original RPG Maker Web profile, linked GitHub, itch.io page, or another public creator identity.
Replies (0)
No replies yet.
0
replies
1
view
Topic Summary
Loading summary...