Glitchfinder & avarisc's RGSS3 Abuse Thread

[Glitchfinder]

Glitchfinder & avarisc's RGSS3 Abuse
A home for information regarding Glitchfinder and avarisc's experimentation with RGSS3 in RPG Maker VX Ace.

What is this thread for?

• This thread is for Glitchfinder and avarisc to share information about their adventures with high-end abuse and bypassing of the RPG Maker VX Ace scripting system. While there will be no guarantees made for quality, content, or general likeability, there are a few things that can be stated up front:
  
  
  • We will not be sharing our code
    • While unfortunate, this is a byproduct of the fact that we do have plans for what we're working on. Keep in mind that although we won't do things for you, we're perfectly willing to describe how we accomplished various aspects of what we show off in this thread.
    Nothing shown off in this thread should be considered final
    • The projects that avarisc and I work on together have a habit of changing pace, direction, and setup very, very rapidly. We move from idea to idea like chipmunks on crack, and in many cases that results in things being constantly created, tossed aside, pulled back in, rewritten from scratch, etc. As a result, anything can and likely will change before, after, and possibly during the time-frame we are showing it off.
    This thread is for discussion
    • We're posting our work like this for one reason, and one reason only: we want feedback on it. If you like something, tell us why. If you dislike it, call us out on it and tell us what we did wrong. If you think we're just two crazy programmers eating paint chips in backwoods Alaska, tell us what we're doing wrong so we can show you what we hid behind door number three.

What can I find in this thread?

• Lots of stuff, ideally. There will be an index of important posts below, but it's likely that the whole thread will be filled with discussion. That is, assuming it doesn't turn into a barren wasteland with just the two of us spouting nonsense at the landscape. If you have time, look around for something you find interesting. If there's nothing here that interests you, feel free to toss some ideas at us. Trust me when I say we've probably had crazier ones at some point or another.
  
  Important Posts
  • Current progress on a replacement for the RGSS .dll files.

 

[aphadeon]

So, I'll kick this off with some day-0 content. Long story short, we decided to make a game in RPG Maker because of our long history with it, and the fact that it's undeniably a fun engine to work in, due to the strict limitations and vast opportunities to get around them.

So. First up, addressing a couple major shortcomings in the engine. Resolution was first, as VX Ace has a hardcoded maximum resolution. One informal rule we're trying to observe is to avoid hacking at the RGSS dll, making this challenge a fun one. Once that was accomplished, I went looking for a 16:9 resolution. Problem being, Ace freaks out if the resolution is not a multiple of 32, in both directions. So I had to find a 16:9 resolution in which both width and height were multiples of 32, and came up with 1024 x 576.

Of course, changing resolution means transitions didn't work. So, Glitchfinder pulled out his trusty transition DLL/script, and made a couple upgrades to get it working smoothly in VX Ace. While he worked on that, I was doing a bit of research, got bored, and decided to play with unique ways to use the typical RPG Maker XP-style transitions. I found a fun technique for blurring and coloring a desaturated graphic to create an unusual fade effect. It's different enough I feel the need to stress that this graphic would work with the vanilla RMXP transition system, it doesn't rely on anything other than the typical system.

Here's a vid of the resolution, aspect, and transition.

http://www.youtube.com/watch?v=LCqgXFkusVk

Our project is currently dubbed "Project Z". Name pending. Don't mind the placeholder title graphics.

Since then, I jumped into getting OpenGL rendering so I could play with hardware accelerated 3d. I also reimplemented the Tilemap in C++, rendering via OpenGL. Still a few touchups to be done, but that will likely be present in the next video.

I'm currently working on polishing the tilemap, porting event rendering to c++, designing a more inclusive dll, and writing a custom replacement for the executable.

So yeah, just your basic first steps.

[EDIT] I almost forgot to mention I've got a new UI in progress. Here's an early alpha screen of it in action:

 

[Linkgx]

The only thing i feel that needs to be added here is 2 things........... Pie & Mountain Dew. nuff said

 

[aphadeon]

The only thing i feel that needs to be added here is 2 things........... Pie & Mountain Dew. nuff said

Afraid those are for donors only.

 

[Xilef]

Awww no code? I look forward to reading the methods used though :D

 

[aphadeon]

Don't mind discussing parts of it. Decided to withhold code, at least for the time being, for two reasons. First, to protect commercial viability should we decide to employ it, and second, because its more fun to guide than to give. If you have questions, I'm sure either of us would be happy to drop hints or point you in the right direction.

Besides, if I give you an idea and you do it better, I can quietly improve my own to save face :p

 

[aphadeon]

So far today I got a replacement Game.exe working. Had some fun with it, set up file details (publisher, version, description, etc). Also got hooks for RGSS's ruby functions (such as rb_define_class). I did end up downgrading to RGSS300 (from RGSS301) for now because I was able to find offsets for more functions that way (and had to spend less time digging for missing pieces). I'll reupgrade once I get some more time to tinker with a debugger.

I set up a very early framework for a replacement RGSS dll, but that will be a longer running experiment.

I'd like to hand out some demos to get first hand feedback, toying around with some security/cypher ideas now so that I can do so without giving away all our secret mojo sauce. In fact, I'll probably announce a reward in the next couple days if someone can circumvent said security. I'm trying not to go "heavy" so much as "unusual" for script protection.

For tonight, I'll probably work on porting my DLL tilemap class to the executable, where I can embed the class directly in RGSS rather than relying in Win32API. I doubt the gains will be significant, but it feels more professional

Worth noting, I code c++ for the gcc compiler. This is lovely because my hope is to release cross platform once I get the DLL rewritten. However, it also means that so far, everything I've found related to RPG Maker is *extremely* Visual Studio biased, and pretty much has to be rewritten from scratch. If nothing else, I'm getting a more comfortable workspace set up for this kind of stuff.

So, no epic screenshots today, but by being boring for a moment, hopefully we'll get demos alongside them in the near future.

 

[Xilef]

Worth noting, I code c++ for the gcc compiler. This is lovely because my hope is to release cross platform once I get the DLL rewritten.

Assuming that GCC = cross compatibility is rather dangerous. Visual Studio is probably the best thing to come out of Microsoft, I would suggest Visual Studio over WinGCC for any project (And I'd suggest LLVM over GCC where available).

I think you'd benefit moving over to Visual Studio sooner rather than later, the RPG Maker series is pretty much Windows locked entirely right now so there's little reason not to use VS and the performance boost that Visual Studio gives might be of great benefit here.


One thing though, I embedded all of my GL work into the executable and I later regretted it, it may feel more 'professional' (Which is pretty much the reason why I did it) but the truth is you should be targeting the Ruby Win32API crap first and then dealing with embedding into a custom exe as a second deployment target.

If you want to keep things embedded, a VERY nice thing to do is write it with a custom DLL that intercepts the RGSS*.dll loading stage. RGSSSetupRTP is called first, I believe the best option is write a DLL that expects that to be called and then it loads up the real RGSS*.dll and then hook in your classes after Initialize3 is called or at the start of the call for SetupFonts (Initialize3 would make more sense).

That way, you'd be able to do all this within a DLL using embedded Ruby classes and all you'll need to do to get this working is modify the game.ini to point to your DLL instead of the default RGSS (I then suggest expanding the .ini settings so it contains a field for the RGSS*.DLL version that your DLL will load so in the future if you wish to support other RPG Maker versions you can package them all into a single DLL safely.

I'd say this method is more friendly and these days I'd say it's the more professional choice, having the game executable be a nice little addition rather than a dependency and the dependency moved into library space makes way more sense for multiple reasons.

 

[Glitchfinder]

Just so we're clear, you're telling us to drop a mostly-cross-compatible compiler in favor of one that has a long history of defining its own standards, many of which are in direct opposition to what we would need when porting over to other operating systems, and many of which make it incredibly difficult to do so?

I would pick the compiler that makes it easier to cross-compile over the one that makes it easier to make windows code. But, maybe that's because I don't like my compiler making decisions for me or disregarding longstanding C++ standards.

 

[aphadeon]

Assuming that GCC = cross compatibility is rather dangerous.

By itself, that's absolutely true. However I should have been more specific - I've become accustomed to writing cross compatible code, keeping all platform dependencies to a single file to be rewritten for new deployment targets. Dealing with a single compiler for my primary targets simplifies the porting process significantly, for my particular development habits at least. I can see how this is primarily dependent on the developer's own "style", and therefore my comment came across a bit premature.

I think you'd benefit moving over to Visual Studio sooner rather than later, the RPG Maker series is pretty much Windows locked entirely right now so there's little reason not to use VS and the performance boost that Visual Studio gives might be of great benefit here.

I have seen a few of the benefits of Visual Studio, exclusively for Windows targets. Rather, I've had to deal with not having them for some time. However, it's a worthwhile sacrifice in my opinion. Because a piece of this puzzle you might have missed is that RPG Maker is not really "Windows locked" for me- I've now got a good part of the heavy lifting on reimplementing the DLL from scratch. It shouldn't be more than a few days to get the rest of it- but that be optimistic. Regardless, "Windows locked" is a temporary condition, not one I intend to get accustomed to.

One thing though, I embedded all of my GL work into the executable and I later regretted it, it may feel more 'professional' (Which is pretty much the reason why I did it) but the truth is you should be targeting the Ruby Win32API crap first and then dealing with embedding into a custom exe as a second deployment target.

Amusingly, between my last post and this one, I did just that. As I started working on the RGSS DLL rewrite, I came to the same conclusion, that the EXE is best left minimal.

That way, you'd be able to do all this within a DLL using embedded Ruby classes and all you'll need to do to get this working is modify the game.ini to point to your DLL instead of the default RGSS (I then suggest expanding the .ini settings so it contains a field for the RGSS*.DLL version that your DLL will load so in the future if you wish to support other RPG Maker versions you can package them all into a single DLL safely.

Good idea. I had actually written a little "NinjaRuby" header that allows installation of custom extensions in the exact time-frame you described. The multiple version support is not quite within the scope of my goals at this moment, but I'll keep it in mind if we decide to release things for general re-use.

I appreciate the feedback, this is exactly the kind of conversation I was looking for in this thread.

 

[Xilef]

Just so we're clear, you're telling us to drop a mostly-cross-compatible compiler in favor of one that has a long history of defining its own standards, many of which are in direct opposition to what we would need when porting over to other operating systems, and many of which make it incredibly difficult to do so?

I would pick the compiler that makes it easier to cross-compile over the one that makes it easier to make windows code. But, maybe that's because I don't like my compiler making decisions for me or disregarding longstanding C++ standards.

I'm not saying discard cross-compatibility and write just for Windows, you can write code that works cross-platform, cross-compiler, I'm saying going with what your target platform vendor recommends is usually the best option for performance, debugging, API and library support reasons.

And VS has improved in terms of standards compliance (The ridiculous VS #pragma abuse is still around, though), however from experience on a commercial project I've had compliance problems with GCC and it's extensions, luckily some other compilers have a "GCC compatibility mode" but I won't ever say that GCC promotes writing standard compliant code.

 

[Jumping Jack Flash]

But is this legal?

 

[aphadeon]

But is this legal?

While not as clear cut as some would like, from my experience I would say this:
The finished product is legal. This has a couple layers of protection. First is that I'm not reverse engineering code, it's a clean (and likely rather different) implementation of a publicly available specification. Secondly, the primary reason for doing so is to increase compatibility and interoperability, which is in many jurisdictions a legal application of even full-blown reverse engineering.
The only real gray area at the moment was grabbing function pointers for the vanilla dll's rb_* functions - which is no longer a neccessity or feature now that I have a reimplementation. And accessing functions in a dll without in any way tampering directly with the dll is something that could be argued either way.

Bottom line? I think I'll take my chances, if there is any case here (which I doubt) it's a thin one at best. I'm not charging for the distribution of the reimplemented engine, and at this moment in time I'm not redistributing it at all.

Pretty sure if it contains no Enterbrain code whatsoever it's fair game. As for distributing it with data files created by their editor, it's a licensed copy of their editor, so they would only suffer in multiple ways by taking issue with it (loss of my business, loss of reputation, and that's assuming no backlash at snuffing out a cross platform implementation).

So the absolute worst case scenario I expect would be a cease and desist, which I would begrudgingly (and very publicly) comply with.

They offer a tool to make games. I'm making a game with it, and want to do so to the absolute best of my capabilities. I have no reason to believe they would take issue with that.


Quick update:
I've got the dll reimplementation going smoothly. As of now, it initializes its own embedded ruby, runs an internal .rb file to initialize hidden modules, and loads, unzips, and iterates scripts once main begins. All that's left is some cleanup and to add the extensions (Audio, Graphics, etc). It currently gets as far as "Undefined constant: Sprite". lol. Still, getting there

 

[aphadeon]

For anyone interested in DLL progress, I'll keep this up to date to the hour (because why not).

N/A - Not yet runnable

WIP - Runnable skeleton structure, working on functionality

DONE - Combat ready



// NEW RGSS FUNCTIONS                 DONE

stacktrace                            DONE * Simply prints a neatly formatted call traceback

Graphics.set_resolution               DONE * Sets resolution, not window size. Scales difference.



// FUNCTIONS                          DONE

rgss_main                             DONE

rgss_stop                             DONE

load_data                             DONE

save_data                             DONE

msgbox                                DONE

msgbox_p                              DONE



// CLASSES                            WIP

Bitmap                                DONE

Color                                 DONE 

Font                                  WIP

Plane                                 DONE

Rect                                  DONE 

Sprite                                DONE

Table                                 DONE

Tilemap                               DONE * Needs slight edit

Tone                                  DONE

Viewport                              DONE

Window                                WIP

RGSSError                             DONE

RGSSReset                             DONE



// MODULES                            WIP

Audio                                 WIP

Graphics                              DONE

Input                                 DONE

RPG                                   DONE



// DATA STRUCTURES                    DONE

RPG::Map                              DONE

RPG::Map::Encounter                   DONE

RPG::MapInfo                          DONE

RPG::Event                            DONE

RPG::Event::Page                      DONE

RPG::Event::Page::Condition           DONE

RPG::Event::Page::Graphic             DONE

RPG::EventCommand                     DONE

RPG::MoveRoute                        DONE

RPG::MoveCommand                      DONE

RPG::BaseItem                         DONE

RPG::Actor                            DONE

RPG::Class                            DONE

RPG::UsableItem                       DONE

RPG::Skill                            DONE

RPG::Item                             DONE

RPG::EquipItem                        DONE

RPG::Weapon                           DONE

RPG::Armor                            DONE

RPG::Enemy                            DONE

RPG::State                            DONE

RPG::BaseItem::Feature                DONE

RPG::UsableItem::Damage               DONE

RPG::UsableItem::Effect               DONE

RPG::Class::Learning                  DONE

RPG::Enemy::DropItem                  DONE

RPG::Enemy::Action                    DONE

RPG::Troop                            DONE

RPG::Troop::Member                    DONE

RPG::Troop::Page                      DONE

RPG::Troop::Page::Condition           DONE

RPG::Animation                        DONE

RPG::Animation::Frame                 DONE

RPG::Animation::Timing                DONE

RPG::Tileset                          DONE

RPG::CommonEvent                      DONE

RPG::System                           DONE

RPG::System::Vehicle                  DONE

RPG::System::Terms                    DONE

RPG::System::TestBattler              DONE

RPG::AudioFile                        DONE

RPG::BGM                              DONE

RPG::BGS                              DONE

RPG::ME                               DONE

RPG::SE                               DONE



// BUILT-IN RUBY EXTENSIONS           DONE

dl                                    DONE

zlib                                  DONE

single_byte                           DONE

utf_16_32                             DONE

japanese_sjis                         DONE

Win32API                              DONE

Checking off this list should mean that games are playable with it- it does not mean it will be a perfect clone at that point. There will still be vast amounts of testing, edge cases, error handling, abuse handling (like passing Input class as an argument for Bitmap.new, or equally insane stuff), and tinkering/polishing to do, and that's assuming I can dodge the need for any all-out rewrites.

Edit: To answer this question before it's asked, I will not be adding support for .rgssad files. This is primarily for legal reasons. While the format itself is amusingly simple, the spec was not made public by Enterbrain, and moreover, they specifically ask (and nicely, at that) in their help file, that users not tinker with it. I will respect those wishes. That said, alternative (*cough*better*cough*) forms of protection will be implemented.

 

[Xilef]

This is very exciting, the amount of control you'll get from all this is awesome.

Will you be exposing any new kinds of APIs with this? Like a GL screen buffer that we can draw to or any way to extend the behaviour?

I can imagine the animations system benefiting a LOT if it was all hardware accelerated with GLSL access.
Imagine particle systems in RPG Maker! More, imagine full 3D real-time animations :D

One thing that I'm interested in though is how are you composting the maps? I was investigating this myself after you described your method, while I don't know enough to rewrite the tilemap class I had a compositor written that showed something.
Will you be drawing each layer of the map onto their own buffers and then composing them together or will you manage the draw-order yourself and just draw them all onto a single buffer in the correct order? GPU v CPU solution I guess.

Also, with your tilemap are you treating each tile as it's own GL object and drawing squares with the tile texture given? This gives a lot of opportunity for giving certain tiles their own shaders and loading additional textures so we could do stuff like real-reflective water and refracting water for some tiles, or animate tiles with shaders, imagine the water effects for the rain scene...

I guess I'm day-dreaming right now, sorry, I just want to highlight the possibilities with a hardware accelerated tilemapper :U

Per tile shaders, screen post processing, 3D objects, particle systems, real-time lighting engine with normals and dynamic shadows... :thumb: :thumb: :thumb:

 

[aphadeon]

This is very exciting, the amount of control you'll get from all this is awesome.

Indeed, I feel it justifies going a few days out of the way.

Will you be exposing any new kinds of APIs with this? Like a GL screen buffer that we can draw to or any way to extend the behaviour?

All graphical features are being implemented through GL, I will likely add a new module (rather than tampering with the layout/contents of existing modules) to expose some raw OpenGL access. For early stages, it would be entirely at-your-own-risk. The game should already be capable of significantly more, as it will be able to take advantage of hardware acceleration when present (but should function acceptably on middle-aged hardware, so it will be up to game developers to regulate how intensive their games should be). As for ancient hardware, it may or may not work, frankly that's not my target audience. I've kept support for the lowest possible OpenGL version without sacrificing hardware acceleration, that's about all I'm willing to sacrifice for obsolete GPUs.

I can imagine the animations system benefiting a LOT if it was all hardware accelerated with GLSL access.
Imagine particle systems in RPG Maker! More, imagine full 3D real-time animations :D

The addition of a true "z" axis with perspective is my primary encouragement, as I want to use a fun perspective pseudo/somewhat 3d in my game, without resorting to software-rasterized Mode7 scripts that, at no fault to the developers, are simply not of the quality I demand in my own projects.

One thing that I'm interested in though is how are you composting the maps? I was investigating this myself after you described your method, while I don't know enough to rewrite the tilemap class I had a compositor written that showed something.
Will you be drawing each layer of the map onto their own buffers and then composing them together or will you manage the draw-order yourself and just draw them all onto a single buffer in the correct order? GPU v CPU solution I guess.
Also, with your tilemap are you treating each tile as it's own GL object and drawing squares with the tile texture given? This gives a lot of opportunity for giving certain tiles their own shaders and loading additional textures so we could do stuff like real-reflective water and refracting water for some tiles, or animate tiles with shaders, imagine the water effects for the rain scene...

I'm tempted to give you a tour behind the curtain. I set up a screenspace culling system, and render the tiles as polys in realtime. Meaning yes, any number of (even animated) effects would be possible. If we need even more power, I can come up with a scene compiler that can covert each layer (or autotile even) to its own display list. Or, better yet, I could switch to full-on VBO/program pairs (was holding off on that because its both unneccessary and very slightly limiting).

I guess I'm day-dreaming right now, sorry, I just want to highlight the possibilities with a hardware accelerated tilemapper :U

Per tile shaders, screen post processing, 3D objects, particle systems, real-time lighting engine with normals and dynamic shadows... :thumb: :thumb: :thumb:

Daydreaming is what keeps me trudging through it.
[Edit] Don't forget displacement maps.


Has anyone EVER seen single_byte, utf_16_32, or japanese_sjis used in a script?
They're being absolutely miserable to port, and I don't even know their usage to do a proper test.
Update: I *think* I have them installed. Still not sure on usage :\

 

[Glitchfinder]

If anyone is wondering why avarisc is doing all the posting, and seems to be doing all the work, there are reasons. He currently has much more free time than me, which means he gets more time to work on this. I'm also working on a few side projects again (mostly terrain gen stuff for Minecraft), which means I spend less time working directly on this. That said, I'm evidently still the guy who fixes stuff when avarisc breaks it, and I'm apparently better at the arcane art of deciphering programming documentation. Aside from that, I mostly seem to be a yes man at the moment, when I'm present.

On the other hand, I just saved him a ton of work in terms of the Input module. He was about to start hacking away at my old stuff to get it to work, but I tossed him a quickie that makes my Key module act as a full replacement for the Input module. (Without breaking the functionality of the Input module, and without doing anything different with my Key module. It just makes the Input module refer to my script for information.)

 

[aphadeon]

So, the current debate is how to implement Bitmap in OpenGL.

From my experience, I see 3 options, and I don't like any of them.

First, there's Render-To-Texture. The only real problem here is switching render targets potentially dozens of times in a frame, and requires additional steps to set constraints for our "fake blitting".

Second, there's offscreen FBOs. How does FBO differ from render-to-texture? Well, primarily, by extension. That is, there is a driverside extension called Framebuffer_blit- on newer cards, this is hardware accelerated. It does fit the OpenGL 1.1 standard, so it doesn't up our requirements. But on middle-aged cards, this would simply be software blitting. While drivers quite commonly support the feature, only a select few, or current gen cards support FB blitting on a hardware level. This would potentially be the fastest solution for cards that support it, but leaves the rest with little gain over vanilla.

Third, there's something a little more "out of the box". Which is an entirely different operational foundation. Basically, Instead of blitting at all, this method would treat bitmap (in c++, rubyside it would be business as usual) as a container for an internal Drawable class. When you "blit", it would create a new drawable and add it to the container. When you call "clear" it would destroy the drawables currently occupying it. The drawables could then be converted to quads, sorted by a fake (but effective) draw order, and rendered. The downside? Significantly more complicated to implement, and bitmaps that do a lot of blitting would have the potential for lag, as there would now be polys involved. (Though enough blitting to lag would have lagged vanilla too).

Bitmap will likely be the ultimate or penultimate check on the above list due to my indecisiveness. I'd really love some input. Sadly, gone are the ways of Amiga style hardware blitting, so we can choose to do software blitting, or to accelerate this. And if the latter, I have to decide how.

And if someone can come along and prove me wrong, that there is some easy solution, don't worry about my feelings. Lay it on me so I can move on, heh.

 

[Xilef]

You should be using FBOs for Bitmap, no question about it.

The Bitmap class doesn't do resizing, which is the only thing FBOs limit you with, this is certainly the way you should do it.

Switching targets dozens of times in a frame is a problem, however you'd only be switching targets when processing the Bitmap. I can imagine the screen Bitmap being the only thing targeted for a static scene and things like drawing text should be done once at load-time anyway. I think it would work and it will be faster than the current Bitmap class, the only problem is compatibility, supporting anything less than OpenGL 3.0 is pushing it these days and you have plans to support OpenGL 1.1.

I really think it's worth sacrificing GL 1.1 support and going for 2.0 as a requirement, if you machine can't do GL 2.0 then you need to upgrade away from your 10 year old computer.

Here's some ideas:
Bitmap.new( width, height )
Creates an FBO with the dimensions width and height and attaches a colour buffer which is tied to a texture handle.

Bitmap.new( filename )
Opens up the file at filename, reads the dimensions of the file and creates a new FBO of these dimensions. The file is then loaded and drawn to the FBO. I suggest caching the file as a GL texture with the filename and a reference count, each time you make a new bitmap from file increment the reference on the texture and when you destroy the Bitmap decrement the reference and clean up the GL texture when the reference is back down to zero, this should stop multiple GL textures being created for the same image and clean up the memory when the texture is completely absent from any Bitmap.

blit( x, y, src_bitmap, src_rect[, opacity] )
Binds the src_bitmap's FB texture handle as the input texture, targets our bitmap's FBO and renders src_bitmap's texture to the X and Y coords with opacity, using the src_bitmap's FBO width and height for sizing.

stretch_blt( dest_rect, src_bitmap, src_rect[, opacity )
Same as blt but uses rectangles to define the scaling, positioning and clipping.

fill_rect( x, y, width, height, color )
fill_rect( rect, color )
Targets our bitmap's FBO and draws a solid rectangle of color.

gradient_fill_rect( x, y, width, height, color1, color2[, vertical] )
gradient_fill_rect( rect, color1, color2[, vertical] )
Like fill_rect, but the vertices of the rectangle are set to either color1 or color2 depending on if vertical is true or false.

clear
Clears the FBO's colour attachment

clear_rect( x, y, width, height )
clear_rect( rect )
Does fill_rect with a colour of transparent

get_pixel( x, y )
glReadPixels!

set_pixel( x, y, color )
glDrawPixels!

hue_change( hue )
This is the hard one. I would use a large FBO that is global to all Bitmap instances (static in C++) and draw the Bitmaps's FBO to that and record the size of it, I'd then target the Bitmap's FBO and draw back to the Bitmap's FBO with either a hue changing shader.
The alternative is do what RGSS already does; read pixel, write pixel (SLOW!). I guess you have no choice with fixed-function GL.

blur
Same technique as above with a blur shader, or fallback to read pixel, write pixel if no fixed-function GL.
Because blur shaders are 2-pass, there should be two large global (static) FBOs for Bitmap classes, one for rendering pass 1 and one for rendering pass 2.

radial_blur( angle, division )
Same method as blur, but instead of a blur shader you rotate the result each time. division defines how many passes are done between the two static FBOs and angle (Between 0 and 360) is the strength of the radial blur.

draw_text( x, y, width, height, str[, align] )
draw_text( rect, str[, align] )
Hopefully you have a font rendering system in place
Target Bitmap's FBO and draw font to it.

text_size( str )
Returns how big the text will be if it is rendered to the FBO (If the str doesn't fit on the FBO, the text is reduced in size, this returns the reduction amount).


EDIT: If you didn't get the picture from what I am saying; Don't think of doing blitting with OpenGL, it's a waste of time and you might as-well stick with GDI+, draw rectangles, it achieves the same effect and actually uses features of your GPU beyond having it as secondary RAM that requires locking for a slow copy to CPU memory for editing

 

[aphadeon]

If you didn't get the picture from what I am saying; Don't think of doing blitting with OpenGL, it's a waste of time and you might as-well stick with GDI+, draw rectangles, it achieves the same effect and actually uses features of your GPU beyond having it as secondary RAM that requires locking for a slow copy to CPU memory for editing

I get the idea, and it's one I was leaning towards. Just wanted to clarify that FBO to FBO blitting, via extension, happens entirely on the card, without locking, on those cards that do support it. That's the framebuffer_blit extension I mentioned in passing under option 2.
More info on the extension: http://www.opengl.org/registry/specs/EX ... r_blit.txt

FBOs it is, just have to decide whether to use the extension or just render across. I have a few to research and decide, as I'm stuck for the moment on a weird Win32API issue. It's raising a runtime exception between returning from Win32API_Call and resuming the interpreter o.O (I didn't know anything happened between those that could raise an exception. it's puzzling).

Edit: Thanks for describing each function. I was already doing so in my head but it's great to see an example laid out like that.

Edit 2: Texture caching is already handled by an internal class

Edit 3:

no question about it

I've never seen a context where this statement is entirely true :p