My goal in creating this script was to create a system that allowed the user to set the screen size to something other than 640 x 480, but not have make huge sacrifices in compatibility and performance. Although the script is not simply Plug-and-Play, it is about as close as one can achieve with a script of this nature.FeaturesNote these were written at the time of v0.93. The following may not be entirely true for the later versions.

Totally re-written Tilemap and Plane class. Both classes were written to display the map across any screen size automatically. The Tilemap class is probably even more efficient than the original, which will help offset any increased lag due to using a larger screen size with more sprites being displayed.

Every possible autotile graphic (48 per autotile) will be cached for the next time that tile is used.

Autotile animation has been made as efficient as possible, with a system that stores their coodinates, but only if they change. This greatly reduces the number of iterations at each update.

Option to have the system create an external file to save pre-cached data for autotiles. This will decrease any loading times even more, and only takes a second, depending on the number of maps you have.

User defined autotile animation speed. Can change with script calls.

Automatic re-sizing of Bitmaps and Viewports that are 640 x 480 to the defined resolution, unless explicitely over-ridden in the method call. The graphics themselves will not be resized, but any existing scripts that use the normal screen size will already be configured to display different sizes of graphics for battlebacks, pictures, fogs, etc.

Option to have a log file ouput each time the game is ran, which can alert you to possible errors with map sizes, etc.

#===============================================================================# Custom Resolution# Author: ForeverZer0# Version: 0.93# Date: 12.18.2010#===============================================================================## Introduction:## My goal in creating this script was to create a system that allowed the user# to set the screen size to something other than 640 x 480, but not have make# huge sacrifices in compatibility and performance. Although the script is# not simply Plug-and-Play, it is about as close as one can achieve with a # script of this nature.## Instructions:## - Place the "screenshot.dll" from Fantasist's Transition Pack script, which # can be found here: http://www.sendspace.com/file/yjd54h in your game folder# - Place this script above main, below default scripts.# - In my experience, unchecking "Reduce Screen Flickering" actually helps the# screen not to flicker. Open menu with F1 while playing and set this to what# you get the best results with.## Features:# # - Totally re-written Tilemap and Plane class. Both classes were written to# display the map across any screen size automatically. The Tilemap class# is probably even more efficient than the original, which will help offset# any increased lag due to using a larger screen size with more sprites# being displayed.# - Every possible autotile graphic (48 per autotile) will be cached for the# next time that tile is used.# - Autotile animation has been made as efficient as possible, with a system# that stores their coodinates, but only if they change. This greatly reduces# the number of iterations at each update.# - System creates an external file to save pre-cached data priorities and# autotiles. This will decrease any loading times even more, and only takes a# second, depending on the number of maps you have.# - User defined autotile animation speed. Can change with script calls.# - Automatic re-sizing of Bitmaps and Viewports that are 640 x 480 to the # defined resolution, unless explicitely over-ridden in the method call.# The graphics themselves will not be resized, but any existing scripts that# use the normal screen size will already be configured to display different # sizes of graphics for transitions, battlebacks, pictures, fogs, etc.# - Option to have a log file ouput each time the game is ran, which can alert# you to possible errors with map sizes, etc.## Issues/Bugs/Possible Bugs:## - Graphic related scripts and your graphics will need to be customized to# fit the new screen size, so this script is not for everyone.# - The Z-axis for the Plane class, which is used for Fogs and Panoramas has# been altered. It is now multiplied by 1000. This will likely be a minor # issue for most, since this class is very rarely used except for Fogs and# Panoramas, which are already far above and below respectfully.# - Normal transitions using graphics cannot be used. With the exception of# a standard fade, like that used when no graphic is defined will be used.# Aside from that, only special transitions from Transition Pack can be# used.## Credits/Thanks:# - ForeverZer0, for script.# - Creators of the Transition Pack and Screenshot.dll# - Selwyn, for base resolution script##===============================================================================# CONFIGURATION#===============================================================================

SCREEN = [1024, 576] # Define the resolution of the game screen. These values can be anything # within reason. Centering, viewports, etc. will all be taken care of, but it # is recommended that you use values divisible by 32 for best results.

UPDATE_COUNT = 8 # Define the number of frames between autotile updates. The lower the number, # the faster the animations cycle. This can be changed in-game with the # following script call: $game_map.autotile_speed = SPEED

PRE_CACHE_DATA = true # The pre-cached file is mandatory for the script to work. As long as this is # true, the data will be created each time the game is test-played. This is # not always neccessary, only when maps are altered, so you can disable it to # help speed up game start-up, and it will use the last created file.

RESOLUTION_LOG = true # This will create a log in the Game directory each time the game is ran in # DEBUG mode, which will list possible errors with map sizes, etc.

def ox=(ox) # Set the origin of the X-axis for all the sprites. @ox = ox @layers.each {|sprite| sprite.ox = @ox } end

def oy=(oy) # Set the origin of the y-axis for all the sprites. @oy = oy @layers.each {|sprite| sprite.oy = @oy } end

def dispose # Dispose all of the sprites and viewports. @layers.each {|layer| layer.dispose } end

def map_data=(data) # Set the map data to an instance variable. @map_data = data # Clear any sprites' bitmaps if it exists, or create new ones. @layers.each_index {|i| if @layers[i].bitmap != nil # Dispose bitmap and set to nil. @layers[i].bitmap = @layers[i].bitmap.dispose end # Create new bitmap, whose size is the same as the game map. @layers[i].bitmap = Bitmap.new($game_map.width*32, $game_map.height*32) } # Draw bitmaps accordingly. refresh end

# Call the resolution, setting it to a global variable for plug-ins.$resolution = Resolution.new

Below are two types of v0.96b, which addresses some bugs and entirely changes the way the tilemap is drawn.Normal VersionDLL-less Version* With the DLL-less version, there is no need to put 'screenshot.dll' in your project folder

LiTTleDRAgo modified the existing script further to bring the script to v0.97. Download it:HERE!Instructions

Place the screenshot.dll from it in the game folder if using v0.93 or Normal version.

(OPTIONAL) Because larger resolutions do not change the positions of windows in scenes, LiTTleDRAgo created a script that centers these windows to make them look more visually appealing. Get it here.

Any further instructions are in the script.

Compatibility

This script is not going to be for everyone obviously. A bigger screen means bigger chance of lag. Custom scripts will need to be made to have windows for your CMS, CBS, and other scenes fill the screen properly.

I have created a second thread for numerous compatibility fixes. You can also make requests for new ones.Go here to view the post.Credits and Thanks

ForeverZer0, for the script.

Creators of Transition Pack and screenshot.dll

Selwyn, for base resolution script.

KK20, for v0.94 (and above) and the Tilemap rewrite (many hours and pages of notes went into this to make it one of the most realistic rewrites out there)

LiTTleDRAgo, for using some methods from his Core Engine script to make a DLL-less version and continued support/contributions by editing the existing script and creating compatible add-ons

Author's Notes

Please report any bugs/issues/suggestions. KK20 will be happy to fix them.EDIT: KK20 will no longer be providing support. He has moved on to XP Ace Tilemap.Enjoy!

« Last Edit: May 31, 2015, 08:59:57 PM by KK20 »

Logged

I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

@blizz:I admit it is just an assumption. To be quite honest, I am not exactly sure how the default Tilemap works. From what I can see (at my current scripting level), I can't see how it could be much more efficient, if is using standard RGSS scripts.

@wizered:I can't seem to reproduce the problem. If you can upload me an example project that it does it in, I will be happy to look into it. The script is not quite finished yet, and it is very possible that there are some bugs left to track down.

Logged

I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Well Zero, an impressive performance. I'm proud to have my soul owned by you :L. Anyway, I'd suggest making it so the window enlarges to the point that it's fullscreen, but doesn't overlap the taskbar.

One thing to try is to restart your computer after putting in the screenshot.dllI know Ryex had a similar issue with the WeatherCreator not reading the display.dll, but after he restarted, it worked fine. This is just an idea, but it is worth a try. Like I said, it will not do it for me, and is likely an issue with your PC's settings that I am not aware of.

Also, ensure that the dll is named exactly as this, and all downcase, although I'm not sure if it matters:

screenshot.dll(Never used the marquee before, just trying it out )

« Last Edit: November 25, 2010, 08:32:41 PM by ForeverZer0 »

Logged

I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

I'm not a very good scripter and I don't claim to be, but is it possible that the reason we are getting the error is that Resolution.new is not being called? When I put Resolution.new in the self.snapshot area, it does this

(click to show/hide)

I'm not quite sure if this is how the script was intended to work. The only problem is that it randomly gives an "undefined method +" error, although I don't know if that is my fault.

I would say "yes" its the script right away, but not everyone is having this problem. I'm not going to take offense at that by the way. I don't know of a scripter who has never had bugs/problems with their scripts. I know I have had my share .

But anyways, the fact that some experience it, while others don't, with the only difference being the hardware and PC settings kind of narrows it down. I would love to be able to help you, I don't like having scripts out there that don't work, but I personally cannot get it reproduce the error, and the best I can do is make educated guesses at what it could be.

The script makes calls using the Win32API module to make low-level calls to functions on your computer, which any number of priviledge levels, parental controls, etc. could effect, along with basic configuration settings. All of these are factors that I cannot foresee, nor account for in the script.

Uh-oh. I may have forgot to include the method to call it. Resolution.new does need called. My bad.I updated the instructions.

« Last Edit: November 25, 2010, 08:59:30 PM by ForeverZer0 »

Logged

I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Call it in Main, before processing begins, not in snapshot. It needs called before the game starts, not during every transitions. I updated the post and instructions. They are a little more clear. It was my fault I forgot to mention that it needed called. Left that part out.

Logged

I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

I see from your pic that the resolution is changing. So what exactly is the problem, and when exactly is the problem occuring? During transitions? Just walking around? I'm sorry, but I am lost on this one...

Logged

I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

I was thinking about using your Tilemap class in CP if it was more efficient. That's why I'm asking. I think the best way to test it would be a raw test on a couple of bigger maps with quite a number of events to see which one works better. Also, careful with the memory.