Out Sourcing Graphical Effects to a DLL, possible?

[Phoenixia]

Hi,

It's been a long time since I've programmed, used RMXP, or posted here, but I've been thinking about game making in my free time as a hobby and had a question about rgss. I know that a lot of graphical effects (like lights, shadows, etc.) can be laggy because of how rmxp handles graphics; thus, I wanted to know if you could make a dll that would add effects to the graphics right before they hit the screen? Even more generally, would it be possible to write something to replace "Graphics" in rgss by calls to a dll or would this, basically, be like replacing the whole hard coded portion of rmxp (except the editor)? Anyways, it's been a long time since I've messed with any of this, so I apologize if these questions are nonsensical, or poorly phrased; if they are doable, could somebody point me in the direction of some info on how to get started with them, I'm looking for a project to fill up a little free time (more for learning purposes than anything else)

Finally, thank you, whoever you happen to be, for reading this and any thoughts or suggestions; I've always found this to be an awesome community and while I've never been a big poster, I've learned a lot by lurking around and reading

 

[BlueScope]

Outsourcing (I like the pun in that) some methods or others, regardless of what they're doing (meaning graphical drawing, calculations or whatnot) is very possible. The obvious difference is that you have to write them in C now, though, as DLLs don't work with Ruby too well :p But yeah, you will get a significant boost in performance by doing that.
As for how to get started with this: I only know the very very rough basics, so I'll leave this to someone else... but iirc, Glitchfinder has written up a somewhat-tutorial-ish guide to this... or am I remembering things way wrong? ^^

Now, replacing the whole script library and base of RMXP would mean to create the whole base engine yourself. Getting that to work with RPG Maker probably doesn't make too much sense, simply because the whole structure (script editor to database to map editor) is layed out for the default scripts, and would probably require reverse-engineering of the actual program to get it to work without doing too many mumbo-jumbo to your codebase, tuning down performance again after all.
That being said, even if reverse-engineering and modifying it would be easy, at that point you can just start programming your own game maker engine from scratch, because that is what you'd have to do.

Now for the part of the post I'm highly unsure about, so take everything from here with a grain of uncertainty:
The Graphics module, being a 'hidden script', should theoretically be a C-written piece of code already. What's causing the slow graphic drawing is more of the interaction between the components of the program than the actual way Graphics is written. Therefore, as long as all other components stay the same, loading it from a DLL instead of the regular way shouldn't give you too much improvement really, if anything.

 

[Phoenixia]

Thank you very much for your response

I've been toying with idea of doing lighting effects, and some other graphic stuff this way, and wanted to make it as unlaggy (not a word, but I'm sleepy) as possible. Too, it seems like you'd have a lot more control doing it this way, which is one of my biggest problems with rmxp, you can only do so much with the tools they give you.

Also, it's very interesting what you said about why the graphics run so slowly; I don't know much about the graphical side of programming, so it's hard for me to wrap my head around some of it (I'm much more from the theoretical side of comp science, so bitmaps and such scare me enough to want to mess with them.)

I'll have to look for that tutorial, hopefully it's somewhere easy to find; I'm fairly positive I've seen it before, oddly...

Again, thank you for your help

*On a very big tangent:
I've been toying around with creating methods of path finding that exploit being a finite map of regular polygons on a plane (so, obviously, applicable to rmxp). The coolest one's I've come up with, thus far, require using a datafile based off of the map to inform movement; the datafile is about 200kb for a 50 x 50 map(maybe substantially smaller), but once made, the move algorithm used is about as expensive as what rmxp uses by default, which is really cheap. At any rate, it should be able to guide as many events as you want with near shortest paths (within a few %, if not ==) and would not cost anymore than having those events use the basic rmxp method (which is very cheap). I was wondering if that is something that would be useful to people in the rmxp community, or if the current path finding scripts out there already solve this issue?

Three points I couldn't fit in the above nicely:
1.) Complexity and map size have minimal impact on the speed, but do have some on the data file size (not much though).
2.) My idea is not doing something like 'store a bunch of partial good paths', or precalculate everything, or anything like that; for large maps that would get out of hand and be unwieldly.
3.) I'm going on two hours of sleep out of the last fifty due to work, so if this is rambling or nonsensical, I apologize.

Any rate, curious to hear your thoughts, if you have any on the subject

 

[BlueScope]

Actually, I think you can do almost anything with RMVXP, the interesting factor is just the scale: You can perfectly do graphical drawing to some extend, but not above it and still serve non-highend PCs, same as you can do pathfinding only for so many events on so big maps.

As for the pathfinding itself, it sounds like an interesting idea you got there... I'm wondering if it'll work out. The only way I can really imagine it is by nodes really, for example in every door, every corridor entrance or exit, or whatnot. The problem is that this method would create specialization (to indoor areas), naturally creating inefficiency somewhere else (outside areas, obviously). You could end up wasting resources even more, trying to apply this to open areas, as the script necessarily has to check for nodes first, and then has to go through the regular A* anyway, assuming that's what you want to use.
Either way, try to go for it... a new pathfinding that's not exclusively A* is really not the last thing the RMs need, and I'd love to see something regarding what you said, even if it's only useable for inside games

 

[Phoenixia]

When I get some time i'll have to write it up and post it. Ultimately, it will use a* on some level, however it avoids nodes. The cool thing is that the computer can compile the datafile optimally, the downside is that it relies on very strict properties of tilings; like each move direction has equal weight and other such. Hopefully, it will work as intended, although the main purpose was to look at algorithms to see how graphs were structured, rather than to use them -itI just happens that this might be useful here to games.

Anyways, im starting to ramble, a bad habit. When I get time and put something together, ill post it.

Finally, thank you for your help, I've come across a lot of your posts through out the forum, all very informative. Have a good night

 

[BlueScope]

Well, I'd definately say that other people should give you some input as well... I'm by all means no pathfinding expert, and if anything, I know my way around A*. The rest is more or less just guessing, and even if I'm right, can't hurt to hear some other people :p

 

[Phoenixia]

Well, if anyone's interested, the basic idea is that there are only so many classes of structure that a connected subregion of the tile map can be. It is possible, for a given tilemap, to arrange a set of structural classes that have the following:

1.) Require a very small ammount of data to record what tiles actually fall in them, usually the difference in memory is quite drastic.

2.) Each class has a highly efficient method of selecting the next move given the goal of reaching another point within the same region.

3.) The geometry of the tilemap implies the existence of a partitioning of subregions, each in one of these classes, so that the number of blocks in the partition is small compared to the total number of passable tiles.

Then, given the graph of subregions, and a little data on what exit points from region to region to use for which end goal, you can apply A* to get your result; or, in a lot of cases, just use a table and precalculate, a lot of human made 100 x 100 maps can be broken into 5 - 10 subregions, meaning you only need to deal with a 100 element table. What makes this method valuable is that movement in any given subregion is cheap.

Ultimately, the trick is find an algorithmic way of selecting structure classes; supposing that you have a robust collection of such classes, which isn't the hardest problem. The two stumbling points:

1.) As the number of classes increases, the number of subsets of classes grows exponentially; thus, to get an optimal (minimal) number of subregions you have to do a tremendous ammount of work. Of course, since reducing a 100 x 100 map down to 10 subregions is sufficent, we don't need to find an optimal solution and we can get away with a much better than exponential average case complexity.

2.) On a more programmatically related note, some classes have a very complicated structure (not in storage terms, but in the logic of finding large regions of that type terms). Thus, it can become very tedious to program all of this up (the data file builder part) and have it work correctly (there are so many weird layers of coordinate changes and stuff with some types that it's headache inducing)

A simple example with only one class would be to break the map into rectangular regions; it is very easy to move about in rectangles. Of course, rectangles alone do not suffice.

Finally, this didn't really fit in above, but is worth noting: the movement methods per class can be employed do that the resulting path will always be a shortest path, but so that the same shortest path is not always selected; thus, making things a tad more realistic looking.

Oh, I guess there is one last thing to point out: this method will not handle dynammic obstacles (like npc's), however, it would not be too hard to deal with dynamic objects since there is not a specific shortest path that must be followed (also, making a few bad moves to avoid a traffic jam is not a big deal since you don't have to recalculate an optimal path, or any such thing, since you will still be in the same region.)

Basically, its reducing the tilemap down to a very small map that codifies its underlying geometry, which is ultimately what controls paths.

Thoughts?

*Since this is getting off the topic of dlls for graphics, how would I change the title of thread? Or should I just leave it as is? Sorry, I rarely post online and don't know the etiquiette. Also, thanks all for your thoughts and time