Max Resolution Breaker

Well, like everyone already did one day, I was looking for some solution about the low screen size (640x480) limitation from VX ACE.


The best one so far was the Fullscreen ++ from zeus81 and it I believed won't infringe the EULA or the rules for a commercial game.


However, I found this one too, even if it is a little suspicious: http://pastebin.com/sM2MNJZj


I tried to look around and search for some clues about it but can't find nothing, even the author is anonymous. So I came here just to ask:


This kind of script infringe something? Is it possible to use without problem?


I tested the script and it works amazing, even with Fullscreen++. I'm even surprised about it modified nothing a single RM file.

It's legit. The author most likely figured out what controls the dimensions and explicitly modified the values at those addresses.


Good thing you've found it as it solves a lot of people's problems.

Neither of those breach the EULA. They are just scripts. Neither actually requires decompiling/recompiling or changing the exe.

I think it would be good to know who actually wrote that second script you link to.

Oh god. God bless that anonymous scripter than.

Even as a new user here, I'm a old Maker from the Don Miguel RPG Maker 2000 days, and If existed one thing that the community can't solved it WAS these things about the 640x480 on VX Ace.

Well, time to work. I'll enjoy myself developing some arts and HUDs for my new (not so) big screen.

Thanks all for the fast reply !

Reminds me of Assembly...except in Ruby.

There's also some quirks with the second script, which you can see everytime the screen transfers from scene to scene.

It looks like the 640x480 block starting from top left fades oddly between transfers.

Google came up with a result..


http://aluxes-loves-eric.tk/133/modified-rgss301-dll-for-640x480-resolutions


But it looks like that commenter also stumbled across the snippet from an anonymous poster.

@Jet

I tried to find, but even who posted the script didn't said anything about the script.

http://aluxes-loves-eric.tk/133/modified-rgss301-dll-for-640x480-resolutions

This is the original link from where I found.

Apparently the author is some guy from the deepweb (as I understand for "tor")

Sorry for my bad understand of english, but what the poster is saying isn't about SOME GUY who posted it on tor?

I think that the "Terv" guy who posted it isn't the author.

You also can't enter the default fullscreen mode, though using Zeus' script in conjunction may work.

From what I saw, it was an unidentified quest who came up with and posted the script and later was posted by Terv.  I wouldn't give Terv credit since they didn't write it.  If anything, use it and juts give credit to "Unknown Scripter".

I've combined "Unknown Scripter"'s code along with Esrever's code for dealing with the viewport when the map is smaller than the screen size when the modified DLL was posted


You can find it here: http://www.rpgmakervxace.net/topic/100-any-chance-of-higher-resolution-or-larger-sprite-support/page-2#entry7997


I've put the script under


http://himeworks.com/2013/10/25/unlimited-resolution/


The issue with the scene changing is not resolved, though I have no idea how to deal with it either.

You mean pressing alt+enter? I don't seem to have an issue with that.

Even with Zeus script the default full screen won't function properly. But at least in my game it is disabled by default and the screen is controlled by a in game menu config system. So it is okay.

I'm still testing things like how many events the new size can handle befores it can lag, but for now its kay to me

Really? It doesn't do anything when i use ALT+Enter, and when I set it to boot into fullscreen the whole thing crashes.

Well, here the same thing happens

Also, Good job, Tsukihime! Thanks for the combined scripted, I was also searching the old Esrever code to get some ideas about the viewport too.

Anyway, I think it's needless to say but apparently the script only can handle sizes multiples of 32 or it crashes

Actually that crash is hardcoded

wt.last + ht.last == 0 || fail('Incorrect width or height')Comment that out and you can have weird dimensions like 700x700However, if your resolution is not a multiple of 32, you'll find weird things going on when you scroll the map. Maybe that's why that check is there.

Sorry, you're right, it doesn't do anything for certain dimensions.

I just happened to be testing with 1024x768 and 1280x960

It looks like you need to have a "standard" resolution or something...and it seems my video card doesn't accept 544x416 as full-screenable resolution after I insert the script lol

It looks like you can only use the default fullscreen if you have a 4:3 aspect ratio for your game's resolution, anything doesn't work.

Zeus' fullscreen works fine though, no matter the resolution. 

I'm still curious about the issue I brought up earlier, with the odd scene transfers.

Edit: I was right in that the odd transfer is 640x480 in resolution which leads me to believe that Graphics.transition may also have been hard coded to that limit. That would mean fixing it would entail writing one's own Graphics.freeze and Graphics.transition

This is interesting.

Go to Scene_Base

def post_start #perform_transition Input.updateendAnd see what happens...Following from that, undo the change, then check this

def terminate #Graphics.freeze dispose_all_windows dispose_main_viewportendAnd see what happens...The second change actually resolves the issue, but we lose our beautiful animations...

So now we have basically two problems.

 

The transfer thing looks like only "fade and refresh" the original hardcoded resolution of the .exe.

Maybe this have some address like the one who de "Anonymous Author" edited by script to control the sizes.

An workaround is to put a picture or a fade over the whole screen when you have a transfer, so the whole screen got black instead of just 1/4.