Glitchfinder & avarisc's RGSS3 Abuse Thread

[Xilef]

I've used FBO to FBO hardware copying as part of some GL 3.0 work (Where the extension you have found is made as part of the standard), I ended up falling back to standard FBO practice because I had performance problems where some GL 3.0 compliant drivers would still fall back to a software solution for buffer to buffer drawing, it really isn't worth it, I'd say go with rendering across 100%, the compatibility problem still exists for relevant machines (My 2012 laptop with an NVidia dedicated mobile GPU still falls back to software with many GL3.0 calls).

 

[aphadeon]

Figures. I can understand why vendors wouldn't be in any particular hurry to implement an obsolete operation.

Also, a couple notes on hue changes. First, a selfish observation: I don't need it for our current project, at all. Unfortunately, you were spot on- I either up the requirements to an absolute minimum of OpenGL 2.0 (it currently stands at 1.1 even with other projected features considered), or I go with the slow get/set pixel.

I think I will go with the latter for a few reasons. First, done optimally, it would still be slightly faster than vanilla's. Second, it maintains the 1.1 base requirement. Third, is that in my extended DLL (I'll be branching the DLL as soon as I hit reimplementation) I will have a higher GL version requirement, and could easily implement this and far superior techniques using a simple shader. (I mean really, who would use hue shifting when you can use selective palette transmutations or even a damned rainbow glow). Fourth, is that this feature was already too slow to call every frame- I highly doubt theres a common script in existence that does so. As it's not used for an animated effect, there's no harm to fire it one-off, even if it were just as slow.

Thanks for lending your experience here. I have a lot of "all around" experience, but have yet to try any form of hardware accelerated blitting, so I'm glad to have someone around who's tried it.

Edit: I officially have no idea why Win32API is crapping out. It works, all the way through, then seems to cause ruby's internals to hemorrhage or something. I've traced every line of my code, it's not in the code itself. It's obviously in the code between the code. I don't do this often, but I think I need sleep.

Edit 2: I suck at sleeping. Seriously. Well, I think I demystified msgbox and msgbox_p's formatting. That closes the internal global functions section. Other than audio, everything else depends on the bitmap implementation. Guess that's up next.

Edit 3: Figured out the Win32API issue - turns out it was due to optimization. Anyway, it's working fine now.

Did anyone notice that's not the vanilla editor in the first screenshot?

 

[aphadeon]

IT RUNS!

Still missing a couple small details, like audio and and rendering. But a significant milestone no less. Now just have to fill in the blanks.

(And yes, it IS running the title screen at that point. The amount of error fixing I had to do to achieve this much was intensive.)

And so, the assault on rendering begins.

 

[Xilef]

So why are you building a custom editor for this as well? Is it because you want to use your own packing format as rgssad has some rules that come with it?

Getting something to run without error after writing tons of classes to fill the gaps is an awesome feeling, well done. I remember how happy I was to get a GL triangle drawn onto the secondary background image of the title in VXA :U

Is your custom EXE just a light-weight replacement or is there the dependency that we discussed earlier? What's really attractive is the idea that anyone can drop in a DLL, change the INI and automatically get hardware accelerated graphics, even on RGSS3 games that were released before this project began.

 

[aphadeon]

It's just a light weight replacement, but at the moment the DLL appears to be missing an export that the vanilla EXE looks for? I'll get that figured out once I get it operational.

Before you get too anxious, we haven't decided on terms of release yet, as we'd like to release our (likely commercial) game before we hand over the fire to everyone. It may be more of a small (per project license) release until that time. That said, we've always been willing to reward those who can impress us, so if a person or project does that, we'd be happy to back them And we may release the "core only" replacement DLL early, that is, one that doesn't expose new features but should increase overall performance significantly.

TL;DR? We don't know exactly what/when/how we're going to do with this yet.

As for the editor, it's not exactly a custom editor. Well, more accurately, not *entirely* custom. Found an open source Chinese project that had a lot of nice features, and half worked. So I grabbed source, translated it, and have been making improvements ever since. The layout is FAR superior to vanilla (and actually, about any other program I personally use). As for the reason, there are 3. First, it already had manual map tile layering, akin to XP's. This is a must for my mapping needs, as I'm using taller characters than the single-tile VX Ace default, and the single tile smart tiles really don't lend themselves to this style. Second, this editor uses an epic setup for database tab configs, letting me expand and even add new tabs in a mere minute or two. And third, is because the project in progress here is going to be rather intensive in several ways, having the ability to make changes wherever they are most convenient to use, whether that's the EXE, the DLL, the data structure, or the editor is a very nice ability to have.

Update: The graphics class is coming along, painfully. I have it rendering and processing Windows messages (WM_CLOSE, etc) smoothly now. I feel silly for not having known how to swap buffers without glut (or another API such as Allegro). Spent HOURS scouring GL docs for how to do it, before I figured out its a Windows API and not a GL one that handles it, lol. Soon as Graphics is done, Bitmap is up next. And of course, I didn't bother to include the limitation on resolution - moreover, I've added Graphics.set_resolution - this is noteably different from resize_screen, in that it sets the resolution the game is rendered at without resizing the screen. So you can call resize_screen to get your desired window size, immediately followed by set_resolution to set the render size. It will be scaled using GL_NEAREST (a fairly pixel-art-friendly filter).

Have a test render.
Currently tacked into Graphics.update in place of actual viewport/sprite/plane rendering (for the moment).
If you see an issue with the blue corner, it's a color profile issue, and does not affect the actual game, only screenshots of it.



Edit: Before anyone complains about my CCW winding (lol), I had been having some issues with rendering and had reversed it for testing purposes. All drawing will be done CW when applicable (though sprite renders will likely be reversible, with backface culling off, to emulate GDI behaviour).

 

[aphadeon]

Anyone happen to know offhand the file extension priority for RGSS in loading images and audio files?

Edit:
First successful visual on the title screen. Clearly some more tinkering to do. Good news is, this should be a case of "fix one, fix them all".

 

[Xilef]

Looks familiar to my first attempts at the post processor having it flipped and in the corner.

In my case it was an FBO UV issue

 

[aphadeon]

In my case its an issue of scaling to pow2 Apparently I fudged the math somehow (thats what I get for trying to do this bitwise) Disabling resampling to pow2 fixes it completely, but has the issues we discussed before. Working on the math now, lol.


EDIT:

Yeah! That's more like it.
Thanks to Xilef for talking me through debugging it! Helped a lot.


Next up, the Window class.

 

[Glitchfinder]

I don't exactly qualify this next video as abuse, so much as simply cheating. I'm very good at cheating filter effects via overlays, and this one is a decent variant of NTSC static:

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

For reference, that is a set of three overlays. One is a standard scanline pattern to represent the issues of a CRT screen. The second is a plane featuring a horizontal bar pattern that is four pixels in height. The third is a moving plane featuring a diagonal bar pattern that is 4 pixels in height. (The bars are at a 45 degree angle, and the pattern moves via an oscillator.)

 

[aphadeon]

I was rather excited to see a scrolling fog effect with the new DLL. Had to walk away from it for a day to let my head clear. Plane is officially complete, leaving just some bitmap tinkering, window, font, and audio. Bitmap is "mostly working", just a few more maths to smooth out. Then of course, a lot of side by side comparisons and fine tuning.

I had some fun playing with the signal filters that glitchfinder introduced (and it's understated in his description, but the noise was significantly increased for the video, or else it wouldnt have been noticeable). Also tinkering with a few other "deliciously lo-fi" effects, as I'd like to capture a genuine feel of nostalgia. All the effects to that end will be rather subtle, unnoticeable to all but the most attentive. The end result, I hope, will simply be that it "feels" reminiscent of days long past.

Also, tried the display scaling out, definitely a nice feature to have.

 

[Ellie]

Hi, I've been following this intently but always feel like an idiot responding :crazy: ; do you think this'd be better in Extending RPG Maker or left here? I'm not sure. Either way, looking exceedingly good.

 

[aphadeon]

Personally, I'd say left here, as ultimately its more of a showcase/discussion thread - as of now we don't have any planned releases other than the game that will result of it. Knowing us, we're bound to release other parts of it sooner or later, but that isn't part of the current agenda. If it were under the other thread, in my opinion, that would be a bit misleading, as it seems like a place to expect released extensions.

 

[Xilef]

It's currently discussion territory with no plans for a release, so in my opinion it can go in either forum.

Perhaps change the title and content of first post to make it more clear, though?

 

[aphadeon]

I expect the conversation will become more game-specific than rpg-specific as we progress. Which is why we chose this category. Not really sure how to make the present state of things much clearer...

 

[Nuri Yuri]

Are you still using the RGSS DLL for the ruby implementation ?
(It's a good solution for the moment because the ruby library won't load in a C++ project and with VS we need some additionnal libraries :<)

It's an interesting projet :3

 

[Glitchfinder]

That list on the previous page is actually our progress towards a full reimplementation of the RGSS DLL. In terms of loading a Ruby library in a C++ project, avarisc and I have done that before, so it wasn't exactly near the top of the list in terms of difficulty.

 

[Nuri Yuri]

The reimplementation term is ambiguous for me x)

(I tried three ways to load the ruby and only using LoadLibrary/GetProcAddress worked fine so it was difficult ^^')

 

[Glitchfinder]

We're not planning to use the official RGSS dlls. Instead, we're coding our own, from scratch. The basic idea behind it being that it's easier to start over than it is to hack our way through the existing mess to put in the features we want.

 

[Nuri Yuri]

Okies. I wasn't sure it was that ^^
I agree that's easier to do it from scratch :3

 

[aphadeon]

Given that we have the experience necessary to do it, it's easier for us.
Glitchfinder gets most of the credit for getting Ruby linked with our C++ project, I did run into some personality issues (a gcc thing) when I tried my hand at it. Once linked though, it's just a matter of including headers and wrapping a few things for convenience.

I am cheating at the moment - the core classes are implemented in Ruby, and extended with C++, rather than being purely in C++. (For example, ruby holds an invisible @fbo_id for the Bitmap class, rather than that being purely C++ side). I expect that should this ever be released for public use, I'll finish porting them over entirely for ease of understanding if nothing else. (Performance gain is marginal, seeing all the heavy lifting is done C++ side as is).

Pretty fun, I have an ruby_main.rb sitting in the project root. For now it just gets included as a Windows resource, and is loaded and executed internally. So while the hidden classes are still "hidden", the craftier users could get to it with a resource editor and make adjustments. Note that will probably change for game release, for obvious reasons, but will likely remain in any source release, should we decide to do one (so that people unfamiliar with C++ can still peruse the hidden classes, without having them completely exposed to end users).