Chaos Project

With the discover of how to export methods from managed .NET assemblies, and now the discover of how to manipulate RGSS Bitmaps from within a managed .NET assembly, I can now do all sorts of things that I have only dreamed of before, using my favorite programming language: C#.

For the past few days, I have been working on a library to use in conjunction with script that can add all sorts of various improvements and enhancements to RPG Maker. So far I have implemented a few general "utility" methods, and have been focusing a lot on extending the Bitmap class.

So far, this is what I have:

What I was hoping to get from this thread was some feedback and ideas on other things that could be implemented. I already have a few ideas that I already have plans for, or have already begin implementing, which I will list here, but please feel free to share your thoughts.



[/list]

Quote from: ForeverZer0 on July 14, 2014, 05:25:55 pm

• Tilemap rewrite to finally make a good custom resolution system without the performance loss and graphical errors

I love you so fucking much, dood. <3

Quote from: ForeverZer0 on July 14, 2014, 05:25:55 pm

• Setting the resolution


• Added methods to get/set the saturation, brightness, contrast, and gamma


• Save a bitmap as *.jpg, *.png, *.gif, or *.bmp


• Implemented draw_arc function


• Implemented draw_line function


• A "snapshot" function that returns a copy of the current client area of the game as a Bitmap

I need this in my life

If you can manage to get networking to work without lag, AND, really easy to implement to the non-scripter scripters (basically, those of us that can read a script, kind of understand it, troubleshoot it on our own, but don't write our own and need help sometimes), well, then I would probably send you  a nice little chunk of whatever profit is made off of any game I make with your stuff in it. You never cease to amaze me sir.

<3

question, why would you need a bitmap from a .psd?

Will Do:

• tilemap with zoom & tone change features


• bitmap anti aliasing


• get bitmap from *.psd & *.tiff function

Maybe In the Future:

• Networking

Probably Not:

• get bitmap from *.psd & *.tiff function


• draw_3d (from 3dmax / blender) function

As far as 3D goes, I highly doubt. It would be easier to simply add RGSS support to an existing 3D game maker.

these are all off the top of my head, feel free to choose which ones you want:

lighting / shadows
particle effects
animated color fills (invert, rainbow, etc.)
HUD (because it updates every frame performance can be an issue in Ruby)
outlines / tooltips (think quest icons from MMORPGs, teammate outlines from Left4Dead, etc.)

Well I look forward to that tilemap rewrite 'cuz I've been having difficulties trying to find a universal implementation that works for both XP and XPAce. But I'm pretty sure it's the sprites that are the problem of performance, not the bitmaps.

ah, I forgot to include mouse wheel function to suggestion
http://www.mundorpgmaker.com.br/forum/index.php?topic=10055.0

Quote from: Zexion on July 14, 2014, 06:47:40 pm
question, why would you need a bitmap from a .psd?

because I think it probably will save time, instead save as png for every edit, you can save the file as it is for just CTRL + S

Quote from: ForeverZer0 on July 14, 2014, 06:58:36 pm
*.psd &

oh well....

This is REALLY epic!

actually that's probably not an impossible idea. if you can use window hooks and manipulate bitmaps than you should be able to change the window icon.

Yeah, its an easy thing. I think there is even a simple API function for it.

There is. You can load the icon image and get its handle like this:



And then just change it.



In other words: This can be done with play Win32API. And you have to get the window handle. And constants are not there in Ruby so you have to use their numeric values.

After a little looking into it, adding support for opening *.psd files is going to be added.
Obviously due to the size of *.psd files it will be slower to open them than a *.jpg or *.png, but at least for debugging purposes it can be used.

EDIT:
Implemented loading Bitmap's using from *.psd format. It was actually much simpler than I anticipated.

For some reason, the edits I make to fix the BB code in the OP do not save, and the formatting is off, so I apologize.

* DOUBLE POST *

Mwahahaha. Basic particle system now working. Not a single loss in frame-rate.

That is sick f0. KK20 and I used an existing particle system which caused a noticeable drop in frames in maps that used it.
Also, what exactly do you mean by HUD? Is there some kind of default HUD that I'm not aware of xD ?

Quote from: Zexion on July 19, 2014, 03:31:05 pm
That is sick f0. KK20 and I used an existing particle system which caused a noticeable drop in frames in maps that used it.

It's all about how the drawing is implemented. Directly accessing the memory of bitmaps without any converting, using buffers, and drawing all once is what I have found successful. I am not working with actual Bitmap objects, but merely the area on the RAM where they are located. They are simply stored as a long line of bytes, where every 4 bytes is a color in BGRA format, so knowing that, a lot of manipulation can be done without any casting/converting. I haven't used anything other than GDI for a lot of drawing methods, and I simply copy the C# Bitmap's memory into the place of RGSS's Bitmap's memory.

Quote from: Zexion on July 19, 2014, 03:31:05 pm
Also, what exactly do you mean by HUD? Is there some kind of default HUD that I'm not aware of xD ?

No, there is no existing HUD, but I could probably implement some sort of API to handle the drawing of a HUD.

Ah that sounds like the complicated stuff that kk20 is doing. I know nothing of casting D:

Quote from: ForeverZer0 on July 19, 2014, 03:55:40 pm
No, there is no existing HUD, but I could probably implement some sort of API to handle the drawing of a HUD.

Ah I see. Combined with your bitmap methods, this could replace my entire HUD xD