[Review] Goldaryn Multiple Resolution Kit

[Draycos Goldaryn]

Goldaryn Multiple Resolution Kit
Versions: 1.10, 1.10-SDK, 2.1, 2.1-SDK
By: Draycos Goldaryn

Introduction

Over the years, People have wanted to build their RMXP games in resolutions other than the default 640x480. At first, it was impossible, then, with the help of a dll he wrote himself, Selwyn created a script that allowed you to change the resolution. It was then discovered, that the hidden classes severely limited the playability of a resized RMXP. Rewrites of these hidden scripts began to crop up. Eventually, it was made possible to play a RMXP game at different resolutions, but Transitions would not work properly, unless you used a smaller resolution. Also, most people would have to hunt for the individual script rewrites and piece them all together. Not to mention there was still a couple of bugs left in the original Resolution script. Not to mention the fact, that if not done properly, when a player pressed Alt+Enter, the game would switch into fullscreen/windowed mode and be back at the 640x480 resolution.

This was my quest for the last 4 years:
Build a system that allows for resolutions both less than and greater than 640x480 that works completely as the original, if not better. Well, a few weeks ago, my computer went to the crapper, and all my work on all my rmxp projects was gone. I had to start all over again. I scoured the web and this site for my original scripts. I found a few new methods that didn't exist before, and one or two that got lost or buried. I pieced this all together and I finally realized my goal. Here it is, my Multiple Resolution Kit. It is too good to keep to myself. So I have decided to share it with all of you. Just one thing to note: When I had put a system together before, higher resolutions would lag and the fps would drop from 40 to 20. However, for some reason, now, my fps seems to stay between 30 - 40. I thought it was because I have a better computer now (from pentium4 512mb winxp to pentium dual core 2 1gb ram windows 7) but when I tried it on my son's computer, I got the same results. just a tad bit of lag during transitions.

Let me know how it works for you.

Features

• Support for Resolutions both less than and greater than 640x480
• Disabling of the built-in Alt-Enter to Fullscreen function.
• Maps fill the screen at higher resolutions
• Fogs and panoramas fill the screen at higher resolutions
• Transitions fill the screen at higher resolutions
• The default transitions, both the fade and transition graphics, work at all resolutions.
• 2.0 and 2.0-SDK and above support dynamically changing the resolution during the game!
• maybe more, just can't remember

Screenshots

Coming soon...

Demos

Spoiler: Requires Aleworks Input and Keys Module (included)

G-MRK-1.9-SDK
G-MRK-1.9
G-MRK-2.0-SDK
G-MRK-2.0

Spoiler: Requires Glitchfinders Key Input Module (Included)

G-MRK-1.10-SDK
G-MRK-1.10
G-MRK-2.1-SDK
G-MRK-2.1

Script

Required Scripts:
SDK 2.4 (SDK versions)
1.9 and 2.0 Require Aleworks Input Module and Keys Module
1.10 and 2.1 Require Glitchfinder's Key Input Module

Due to the number of script versions and the fact that this page keeps hanging whenever I try to include them, the scripts will have to be extracted from the demos. I apologize for any inconvenience this may cause.

Instructions

Place my script below the SDK (if required) and Aleworks Input modules or Glitchfinder's Key Input module.
Change the following variables to set the desired default Resolution:

Version 1.9 and 1.9-SDK:
in Game_Window: WIDTH and HEIGHT

Version 2.0 and 2.0-SDK:
in Game_Settings: @resolution (note, this can be and is overwritten when a player changes the resolution in Scene_Settings)

FAQ

Q: Does it have to depend on the SDK? Can't you make it non-SDK?
A: I prefer using the SDK and adapt all scripts I use for it, however, I feel nice, and so I have made a non SDK version as well. Especially seeing how much the SDK has fallen out of favor lately.

Q: Now go for a VX version
A: Unfortunately, I don't know how to bypass VX's habit of scaling the graphics to the new resolution, not to mention I haven't bought it, won't buy it, and don't want to pirate it, and my trial has expired.... VX users can suffer with the built in multi resolution functions it already has. lol

Q: Which script should I call in order to change the resolution in game?
A: using version 2.0 or 2.0-sdk you call

Game_Window.change_resolution(width, height)

to change the resolution in game. Just replace width and height with your desired width and height in pixels.

Q: My menu didn't get resized!
A: Actually, it is resized. Every scene has been resized. The only thing that really needs to be done is for the windows/graphics used in the scene to either be resized and/or rearranged to fit the new resolution(s). As such, I recommend using custom menus.


Compatibility

Should be compatible with most scripts that don't change the resolution or overwrite the methods overwritten in this kit. For the non-SDK versions, anything that overwrites the update methods in any Scene class needs to be placed above this.

Known Issues:

Most scenes are not rewritten for multiple resolutions.
Message Windows are off screen at the lowest resolution provided.
Can't seem to change the y of message windows, at any resolution...
Scene_Settings doesn't display well in lowest resolution.

Most of these can be fixed with custom scripts.
As a special service and part of my support for this kit, If you would like a specific scene adapted to the new resolution, I will create a patch for you. These patches will be made only by request. I do have other projects to work on as well. The information I need from you is: the script of the scene you want adapted, which version of my kit you are using, and possibly the desired resolution(s).

Update:
Aleworks Input dll (and possibly Glitchfinder's transition.dll) requires a C++ library. If you receive and error related to a missing dll: MSVCR100.dll, you must download and install the Microsoft Visual C++ 2010 Redistributable Package, the download is just 4.8MB in size and can be found here.

Credits and Thanks

The following people need credit if you use this script:

• vgvgf - Aleworks Input (if used)
• Selwyn - Plane rewrite, and display.dll
• Cremno - NoF1, NoF12, and No Alt-Enter dll
• Glitchfinder - Transition.dll and Key Input Module (if used instead of Aleworks)
• HBGames.org - screenshot.dll (I don't know the original person who wrote it, but I got it from here.)
• poccil - Tilemap rewrite
• SDK team - SDK
  and last but not least:
• Draycos Goldaryn - the whole Kit and Kaboodle

I would like to thank the following people, without whom this script would not be possible:
Cremno
Selwyn
Glitchfinder
Me(tm) (I tried to use his tilemap, but decided against it)
vgvgf
poccil (I originally used his tilemap and switched back to it)
Trebor777


Author's Notes

Wow, it took three years to get this script perfect except for transitions, then my computer wiped it all out and in about two weeks i had the script redone, and better than before. Sometimes it pays to go "Back to the drawing board."

Post any requests here. As a special service and part of my support for this kit, If you would like a specific scene adapted to the new resolution, I will create a patch for you. These patches will be made only by request. I do have other projects to work on as well. The information I need from you is: the script of the scene you want adapted, which version of my kit you are using, and possibly the desired resolution(s).

Also, as stated, I did not notice any drop in frame-rate on my computer, but let me know what you experience. If you try this out, let me know what fps you experience as well as your os and basic computer specs, Thank you.

Terms and Conditions

free to use in any project, even commercial. If used, please give me a link to the game as I want to see it implemented. if it is a commercial game, I want a free copy :haha:. Also make sure I (and everyone listed above) get proper credit.

 

[gRaViJa]

I jizzed my pants when i saw this, but when i tried to play the demo it's says a .dll is missing: MSVCR100.dll

Anywya, if this does work i'll jizz my pants again!

 

[Draycos Goldaryn]

Oh yes. Thank you for reminding me of this. I came across the same error. It is related to how vgvgf wrote his dll. To fix it, you must download and install the Microsoft Visual C++ 2010 Redistributable Package, the download is just 4.8MB in size and can be found here.

I will add this information to my first post.

And you might want to keep a dry pair of pants at hand. :haha:

 

[mouse_std]

Cool script :fap:
but does it have to depend on sdk?
can use this to make a soccer game :biggrin: or other game that use wide range of view :

 

[Draycos Goldaryn]

Give me a few days and I might make a non-sdk version. I have noticed the declining interest in SDK. I just prefer it due to the Scene_Base which doesn't come default in RMXP.

I'll also look to creating patches for other Input scripts, or even one that doesn't require any input rewrites, to avoid the issue with Aleworks' Input dll requiring the Visual C++ Runtime Distributable to be installed on the user's computer.

Other things in planning: A Dynamic Multiple Resolution System, in other words, the user can go into a settings menu and choose the resolution he/she would like to play at and the script will change and adjust accordingly. The biggest change would be having to rewrite more of the tilemap class to use an instance variable instead of a constant.

Also, as I haven't rearranged any menu scenes, save/load scenes, or the battle screen, if you use any custom scripts for these (most do) if you want help converting them to multiple resolutions, post the script here and any external files, or a link to the topic and I will write a patch for it to work with this kit.

 

[BlueScope]

Looks like you took a very similar approach to what I did back in the days as for the base structure. I'm yet to actually test it (since I'm at work right now), but at least from the scripting side, it doesn't look too bad.
Do you plan to change resolution at runtime, btw? You used variables instead of constants for something that could actually use constants better, which is why I'm asking. Would sure be a nice feature...
Also, is it necessary for your script to disable F1 and F12? Looks like something you took out because of personal preference, however if your scripts works perfectly without it, you might wanna take that part out and make it a seperate script/redirect people to Cremno's script.

 

[Draycos Goldaryn]

Very observant you, yes, I am planning to add the ability to change resolution at runtime. Before I do though, are method names allowed to contain capital letters? I ask because the Tilemap uses constants where methods would work better for a dynamically changing resolution. I would much prefer changing just a few lines instead of everywhere those constants may appear in that script.

And no, it is not neccessary, I only included those functions because if you try to find Cremno's script in his topic, it's not there. I actually had to extract it and his dll from a completed project of someone else. I did a Google search for cremno, nof12, rmxp and found a project which included him in their credits, downloaded it and extracted it.

Maybe I will remove those two unneeded functions from this script in the next release.

 

[BlueScope]

Method names are allowed to contain capital letters for all I know, at least from a technical point of view - using them isn't exactly good scripting style though, and since you have only a single script block, using Search And Replace won't take more than a couple of seconds

 

[Draycos Goldaryn]

true. ok, next version should be up by end of tomorrow, and non-sdk sometime after that.

EDIT:

There has been a delay on the release of the next version. I had dynamic resolutions completed, but during extensive testing/playing around I found many errors mostly with Selwyn's Plane rewrite. I am in the process now of giving it almost a complete overhaul. Once I get all these bugs worked out, it will be included in my script instead of with it, as it will have too many edits to be left out.

Anyway, the next release will be a quadruple release. Fixed resolution (both SDK and non SDK) and Dynamic Resolutions (again, SDK and non-SDK). Fixed Resolutions will have a version number of 1.x and 1.x-SDK (where x = the number of edits/corrections from 1.0). Dynamic Resolutions will have a version number of 2.0 and 2.0-SDK.

 

[Draycos Goldaryn]

Massive Update!!!

The script has been updated 4 times! Now there are four versions available. Please see the first post for details!

Now you don't have to use SDK if you don't want to....

Also, version 1.9 keeps the static resolution for those who want that, version 2.0 offers two ways to change the resolution in-game!

Enjoy, and don't forget to leave feedback!

-Draycos Goldaryn

 

[BlueScope]

Now go for the VX version :D

(on a side note, good work! XD )

 

[Draycos Goldaryn]

VX... Unfortunately, I don't know how to bypass VX's habit of scaling the graphics to the new resolution, not to mention I haven't bought it, won't buy it, and don't want to pirate it, and my trial has expired.... VX users can suffer with the built in multi resolution functions it already has. lol

in response to your side note, Thanks. Honestly, i think this is the shortest of your reviews I've yet to see. Are you certain there isn't something I can improve?

 

[Glitchfinder]

Actually, if you used my input scripts, you might find that you have a more dependable set of input without a required .dll file and without the extra load provided by AleWorks. (Just search for them on the forums, my site isn't up to date) I also noticed you used my old .dll file, which is pretty neat, considering the fact that I wasn't expecting that to go anywhere. I might potentially look into vague again sometime in the near future, if I get enough free time.

 

[Draycos Goldaryn]

I will try out your input scripts. As for using your dll file, That was actually the key to me deciding to release this script. I did not want to release unless I could get the default transitions working instead of my old cheap workarounds of fading to/from a solid color, or using a transition graphic with alpha levels and fading it in/out and your dll made this possible. I would love if you were able to look into vague again, so that the default transition would be completely fully functional. but it isn't required.

This works, just as it is, better than I could ever have expected and hoped for. Thank you.

 

[mouse_std]

Amazing :lol: finally sdk free :biggrin:
if the screen's too big the fog kindda cut in the lower screen,
but overall ,great achievement :thumb:

 

[Draycos Goldaryn]

what resolution did you try when the fog "kinda cut in the lower screen?" and can you post a screenshot of the issue?

EDIT:
Because that should have been fixed with my edit of Selwyn's Plane rewrite. What it does now is, finds out how many times the fog will tile before it is bigger than the screen, it then multiplies that by two and sets the bitmap to that size, tiling it over the whole thing. Then, when you move, if you reach half way, the bitmap jumps, but not so you notice, this way you should never, ever see the edge of the bitmap.

 

[Glitchfinder]

Hey, just popping in to mention that you might want to take a quick look at this thread. It highlights one of two problems with AInput. Specifically, it highlights an issue regarding how the .dll was compiled that causes some computers to crash the game when they try to load it. One other issue I thought I should mention is that AInput tends to crash on load if a gamepad is plugged into a computer. (A gamepad is pretty much any form of input aside from mice, keyboards, and trackballs, which the computers can take normally. For example, a steering wheel or game controller)

Also, my last post in the thread includes a link to an edit I made of this kit so that it would work on his computer, by removing dependencies on AInput and subbing in my own scripts.

 

[Draycos Goldaryn]

Ah, yes. if you look above, this is actually related to a similar issue regarding how AInput.dll was compiled, or code it references.

Aleworks Input dll requires a C++ library. If you receive and error related to a missing dll: MSVCR100.dll, you must download and install the Microsoft Visual C++ 2010 Redistributable Package.

I was getting the same error mentioned in that thread and can't remember how I got the one actually mentioning the msvcr100.dll but i did and I googled it and found a commercial game that gives the same error and they gave the solution.

thank you for the edit, i have been planning to replace ainput with yours, i've just been busy reinstalling windows as i have upgraded to new computers and windows 7 64 bit. also, as a side note, I see you included your mouse input module in the 'required scripts' section of the demo, but i don't believe my kit requires the mouse :tongue: .

I'll update and load an "official" version sometime soon.

 

[Glitchfinder]

Ah, yes. if you look above, this is actually related to a similar issue regarding how AInput.dll was compiled, or code it references.

Aleworks Input dll requires a C++ library. If you receive and error related to a missing dll: MSVCR100.dll, you must download and install the Microsoft Visual C++ 2010 Redistributable Package.

I was getting the same error mentioned in that thread and can't remember how I got the one actually mentioning the msvcr100.dll but i did and I googled it and found a commercial game that gives the same error and they gave the solution.

thank you for the edit, i have been planning to replace ainput with yours, i've just been busy reinstalling windows as i have upgraded to new computers and windows 7 64 bit. also, as a side note, I see you included your mouse input module in the 'required scripts' section of the demo, but i don't believe my kit requires the mouse :tongue: .

I'll update and load an "official" version sometime soon.

Hey, no problem. Check out my last response in the request thread regarding the redistributable though, since it needs mentioning. Anyway, in that post, I mentioned PM'ing something to you, but I think I'll put it here instead.

I have an old resolution script sitting on my site, but it's actually not the full kit I was working on at the time I posted it. Rather, I actually cut out an entire feature of the kit, due to the fact that it seemed a bit unnecessary to me at the time. Specifically, the original version of the script involved the ability to "deflate" sprites, tilemap, etc. to half their size, to force things like double-sized GBA graphics back to their normal resolution. Most of the things it resized actually had a native zoom ability, making it easy to do. However, I'm not sure if your custom tilemap and plane classes have that. That being said, I'd be willing to throw the original code your way if you're interested in adding that feature to your script. Just keep in mind that one reason I cut it out is because I tied it directly to screen size, meaning that when I put it to half size, it also cut the screen size to fit. Not that it's a bad thing or anything.

Edit: Actually, I just realized that I had a couple of neat little tricks in there, too. For example, I figured out exactly how the creators of RMXP calculated the static value they ended up using as the y value of the default title screen's command window. I'm pretty sure I also set it to properly move message windows, although I'm not entirely certain. That being said, you might want to add a mention that the placement of enemies in RMXP's default battle system is determined entirely within the editor, unless you actually changed that somewhere. (Which presents the problem that you can't use a larger-than-default battle screen to its full potential)

 

[Draycos Goldaryn]

Hey, no problem. Check out my last response in the request thread regarding the redistributable though, since it needs mentioning.

Interesting, I may have to experiment a little now that I've had a complete fresh install of windows and haven't installed the redistributable yet... I'll have to find out which dll is giving me the error.

I have an old resolution script sitting on my site, but it's actually not the full kit I was working on at the time I posted it. Rather, I actually cut out an entire feature of the kit, due to the fact that it seemed a bit unnecessary to me at the time. Specifically, the original version of the script involved the ability to "deflate" sprites, tilemap, etc. to half their size, to force things like double-sized GBA graphics back to their normal resolution. Most of the things it resized actually had a native zoom ability, making it easy to do. However, I'm not sure if your custom tilemap and plane classes have that. That being said, I'd be willing to throw the original code your way if you're interested in adding that feature to your script. Just keep in mind that one reason I cut it out is because I tied it directly to screen size, meaning that when I put it to half size, it also cut the screen size to fit. Not that it's a bad thing or anything.

Actually, I think I would be interested in that. It would make moving to 320x240 a lot more aesthetically pleasing.

Edit: Actually, I just realized that I had a couple of neat little tricks in there, too. For example, I figured out exactly how the creators of RMXP calculated the static value they ended up using as the y value of the default title screen's command window. I'm pretty sure I also set it to properly move message windows, although I'm not entirely certain. That being said, you might want to add a mention that the placement of enemies in RMXP's default battle system is determined entirely within the editor, unless you actually changed that somewhere. (Which presents the problem that you can't use a larger-than-default battle screen to its full potential)

cool. yes, the message window does need to be fixed as it doesn't even show up in the smallest resolution. As for the enemy placements, so far I haven't changed any of that as I haven't rescaled the battle screen yet... only the viewports. I'll take a look into it.

On a side note, the updates are taking me longer, had a car accident and have spent the last two days at the hospital. the update will be uploaded as soon as I can find the time to reinstall rmxp and work on it.