Hello, please don't misunderstand about "resize window", I don't want a custom resolution script that have many in google (yeah, I already search many about this :( ) , what I want is resize the rendering resolution, if you already played pokemon essential, you will know what I am saying:

I'd call this function "Zoom", wouldn't you?
I've been looking for this too, been hoping DerVV would incorporate it into ABS somehow, or maybe I j6st need a compatible script.

If Pokemon Essentials does it, why not just take the script out of that?

This is more of a combination of both.

The resolution scripts, when in a windowed environment, set the size of the window borders and does math to see how many tiles/pixels the window can hold. However, you're not looking for an increase in the number of tiles, so in this case... only the window resize.

A zoom effect takes the material and increases its proportions to fill the prescribed area. However, it doesn't affect window border areas.

I've never handled or understood the zoom effect myself. What I have seen usually entails increasing the size of the player sprites themselves as the sprite class does have a .zoom_x and zoom_y code within. However, I have not been able to discern how to accomplish that with map tiles. Nor have I seen anything in the window class to deliver any form of zoom to a window as you have created in the mockup.

EDIT: Pokemon Essentials is an RMXP project? Unfamiliar with anything PokeMon ( by intent ).

Well, there is this for starters: http://www.gdunlimited.net/forums/topic/...-or-event/

and someone mentions it here too: http://forum.chaos-project.com/index.php?topic=12368.0

Well, I mentioned that making a sprite zoom was easy. Knowing scripts as I do, and the second thread's mention of the SDK, I think I know the second script which had a full-range map zoom. Unfortunately, the one which I'm familiar rewrote the graphics system, so no basic script could be extracted. Half the work is in a .dll.

What he want's isn't sprite zoom, it's making the window bigger and scaling the DirectDraw viewport to fill it. It is just a couple of win32api calls.

I wouldn't quite say a couple. If one could simply use a couple to increase the zoom factor of the viewport, a zoom script would have been made in no time. Insofar as MGC's Neo Mode7 that accomplished this, he practically rewrote the entire Graphics engine, though it still only affected the mapping and sprites.

That is "zoom" which is different than what we are talking about. finalholylight just wants a bigger picture.

You increase the size of an image within a paint program... the size of the text with Wordpad using that %%% option in the corner... by zooming in. Zooming in this manner, by this context, is the increase in size of the material being seen. So we are talking the same.

When graphics are presented, they are drawn to the viewport. It acts as the canvas for what the player sees. Transparent, you can overlay multiple viewports, as you could see by looking at the Spriteset_Map or Spriteset_Battle classes... Three or four viewports working in tandem. The size of the images within are rendered in real time, and presented as they are drawn. However, viewports have no 'stretch-to-fit option.

BUT, a rewrite of the Viewport class to include a stretch-to-fit or 'select-an-area-to-fit' set of options would be sweet... if anyone knew how to do that. The former could work with resolution that increases the game's window's size real nice while the latter could zoom in on a portion and increase the size for the whole window (hopefully not squishing the image too bad).