- Reason:RMXP's audio player does not have the "resume" function to start a file from a different position than the starting one. Attempts to create this system never went further than playing the file from a different position, but without looping.- What is needed to create this:Good understanding of WinAPI and audio control. Also a new MIDI synthisizer needs to be created to create the same changed MIDI sound like RMXP. An implemenation for .wav/.mp3/.ogg might be easier.- Does an implementation already exist?No.- Have I ever attempted doing this?Yes, but failed. I never came past the missing repeat after starting a file from another position than start.- Will I ever attempt doing this (again eventually)?Maybe.

- Reason:Due to the internal definition of RMXP's "Tilemap class" and the impossibility to use a "scewed 3D" sprite, this system can only be realized by using a bitmap that is constantly recalculated and redrawn. But this causes extreme lag which makes it possible to create the script, but it would be unuseable. Another problem would be the rewrite of the internal Graphics module if an attempt was made by using a 3D rotated sprite.- What is needed to create this:A complete rewrite of the Tilemap class, a 3D view handling system that is actually useable due to no or little lag.- Does an implementation already exist?No.- Have I ever attempted doing this?No.- Will I ever attempt doing this (again eventually)?No.

It's not too hard, it's just a matter of knowing how to do it. If you don't know how to do it (majority of people), then it's "impossible". And you don't have to be massively intelligent, you just need some experience. Blizz-ABS wasn't made by a genius either and neither was RMXP and neither was Windows. The two latter were actually made by not just one person. -_-

You can say the same for the audio module rewrite. The basic is a custom audio API for Windows made by somebody completely else. All the scripter did was created a so-called bridge between the DLL methods and functions and RMXP. You don't have to be a genius for that. Just knowing how to call DLL functions from RMXP is pretty much the only knowledge you need along with the knowledge how the audio calls were made.

The rotating Mode 7 is a different story. If I am not wrong, the DLL was created by the scripter. But yet again, the basic knowledge you need is how 3D rendering works. Neo Mode 7 still lags on my PC, there's probably no work around that. It's running at around 20 fps when I have both CPU cores at 1.2GHz. Note that I am talking about a non-rotated view.

Don't get me wrong, I'm not turning down those works. Somebody with the knowledge to even make them probably has enough understand that he made them the way they should have been made. In any case those script are great additions to the RM community. I am considering of using both the custom audio module and the rotating Mode 7 in my own game. The former will be most probably there and the latter only if the lag is low enough when I combine the script with my world map slicer and my other anti-lag systems.

MGC

QuoteThe rotating Mode 7 is a different story. If I am not wrong, the DLL was created by the scripter. But yet again, the basic knowledge you need is how 3D rendering works.

Actually, I don't know how 3D rendering works. I just used a pencil and a sheet of paper to find the correct mathematical formulas.However it is right that I am prouder of my New Mode 7 than the Neo, because the former was coded in pure RGSS and it was a real challenge.

QuoteNeo Mode 7 still lags on my PC, there's probably no work around that. It's running at around 20 fps when I have both CPU cores at 1.2GHz. Note that I am talking about a non-rotated view.

Quote from: MGC on October 01, 2008, 05:54:14 pmActually, I don't know how 3D rendering works. I just used a pencil and a sheet of paper to find the correct mathematical formulas.However it is right that I am prouder of my New Mode 7 than the Neo, because the former was coded in pure RGSS and it was a real challenge.

That IS how 3D rendering works. xD Coordinates in a virtual cartesian system with 3 dimensions are projected onto a virtual plane which involves coordinate transformation and pixel color determination. I personally find RGSS easier to work than with C++. But C# must really be the easiest of them all, at least in my opinion. Well, of course, if you have the right headers and includes, C++ can turn out easier than RGSS.

No, I haven't. I didn't have much time, but really wanted to take a look at it so I only downloaded the demo and tried it out. I haven't changed any configurations of the script or messed around with it otherwise. Good to know that there is an additional filter.

MGC

QuoteI personally find RGSS easier to work than with C++. But C# must really be the easiest of them all, at least in my opinion. Well, of course, if you have the right headers and includes, C++ can turn out easier than RGSS.

In my opinion RGSS is easier than Java or C#, because the syntax is very "user friendly". But the drawback is the bad performance.

QuoteI don't think I congratulated you on the scripts yet, great work.

In practice an extra coordinate is introduced which enables you do to the projection with multiplying various matrices together. The computer is good at multiplying and there is hardware support for this. So yeah, speed is the reason.You can perfectly fine achieve the same results with linear algebra. It's just not as fast. (I don't know how have done the projection.)

Good work on the script MGC ^^

What I really would love would be C# with Java's well-functioning library.I want to test an algorithm quickly I prefer Ruby since you can write the code very pseudo-code like.Well depending on the algorithm in question I may prefer a logical or functional language over Ruby, but otherwise it's Ruby.

MGC

QuoteYou can perfectly fine achieve the same results with linear algebra. It's just not as fast. (I don't know how have done the projection.)

Here's the source code of my dll :http://www.mediafire.com/file/ymmmmdhzfzi/MGCmode7.cppI just used basic trigonometric functions for each pixel in the screen.It works with integer values to increase the speed (I also added multiple copies for each option in order to minimize "if" statements in loops).

Quote from: Blizzard on January 07, 2008, 08:54:15 pmI have seen people ask too many timess for some very simple (or not so simple) scripts, but yet are impossible without rewriting half of RMXP's engine (NOT SCRIPTS!). Here is a list of scripts and my personal rating from 1 to 10 how hard it would be to be made, the reasons and some other stuff.

BGM continues after battle (9/10)

- Reason:RMXP's audio player does not have the "resume" function to start a file from a different position than the starting one. Attempts to create this system never went further than playing the file from a different position, but without looping.- What is needed to create this:Good understanding of WinAPI and audio control. Also a new MIDI synthisizer needs to be created to create the same changed MIDI sound like RMXP. An implemenation for .wav/.mp3/.ogg might be easier.- Does an implementation already exist?Yes.- Have I ever attempted doing this?Yes, but failed. I never came past the missing repeat after starting a file from another position than start.- Will I ever attempt doing this (again eventually)?No.

Mode 7 (7/10)

- Reason:A few implementations so far were successful, but due to heavy lag and high bug factor mostly unusable. The only useable implementation would be a complete change of RMXP's "Tilemap class".- What is needed to create this:A complete rewrite of the Tilemap class and a change of sprite handling.- Does an implementation already exist?Yes, there are 2, one is pretty good.- Have I ever attempted doing this?Yes, I have tried to decrease the lag in mewsterus' Mode 7 script and failed. The implementation was not suited for improvement.- Will I ever attempt doing this? (again eventually)No.

Rotating Mode 7 (10/10)

- Reason:Due to the internal definition of RMXP's "Tilemap class" and the impossibility to use a "scewed 3D" sprite, this system can only be realized by using a bitmap that is constantly recalculated and redrawn. But this causes extreme lag which makes it possible to create the script, but it would be unuseable. Another problem would be the rewrite of the internal Graphics module if an attempt was made by using a 3D rotated sprite.- What is needed to create this:A complete rewrite of the Tilemap class, a 3D view handling system that is actually useable due to no or little lag.- Does an implementation already exist?Yes.- Have I ever attempted doing this?No.- Will I ever attempt doing this (again eventually)?No.

Changed Resolution (6/10)

- Reason:The problem on itself is not a big one and several scripts already exist. The problem is RMXP itself. Since the map does not work with bigger resolutions, RMXP's "Tilemap class" would need to be rewritten to support it. Eventually many other scripts would need to be edited. Also, this would cause problems with various menu systems from custom scripts as well as CMSes themselves. The last problem would be lag. Bigger screen means bigger sprites and more stuff to be updated.- What is needed to create this:Understanding of WinAPI. Understanding of all RTP scripts. Ability to improve RTP scripts in a way of lowering the lag by decreasing algorithm complexity (NOT SIMPLE OPTIMIZATION!).- Does an implementation already exist?Yes.- Have I ever attempted doing this?No.- Will I ever attempt doing this (again eventually)?No.

Feel free to ask for my rating for any type of script. I will try to explain as good as I can.