Custom Resolution?

[LozMov]

I have tried MKXP in my project, it works flawlessly. However, after I set the width and height in MKXP.conf, the game screen has been stretched, and that makes the image fuzzy. How can I use a bigger resolution? I used Custom Resolution(http://forum.chaos-project.com/index.php/topic,7814.0.html) before. Since MKXP doesn't support Win32API, this script won't work.

[Ancurio]

The names of the config entries in mkxp.conf are unfortunately a bit misleading; they don't control the screen size but the window size. The window size is independent of the resolution the game renders in, which is fixed to 640x480 in RGSS1, and can be changed within 1x1 to 640x480 in RGSS2 and 3 via Graphics.resize_screen.

Changing the resolution to anything higher than that is a hack which exploits implementation details of Enterbrain's Player engine. In mkxp, the RGSS1 Tilemap class can only render correctly at the normal 640x480 resolution, but the RGSS2 and 3 class is able to render at any resolution. If you want a non-standard resolution, you will have to compile a modified version of mkxp with the limitation lifted. The limitation is hardcoded in src/graphics.cpp in "Graphics::resizeScreen`.

In the future I might add a direct non-standard method to the MKXP module for circumventing the limit in order to ease porting of resolution hacks.

[RyanBram]

Hi, Jonas.

May I ask you to make future MKXP (and its prebuilt binary) supporting larger resolution by default than what is supported by official RGSS engine? Today, most of game is created with widescreen in mind and it doesn't really good to see black border when playing RPG Maker game. I just want to make Ace game with resolution wider than 640 to make it nicer to look. For me MKXP is two things, an open implementation of RGSS, but also an improvement for it at the same time.

Thank you for your attention and sorry for any inconvenience.

[Ancurio]

@RyanBram mkxp is an open reimplementation of RGSS, it's not an improvement of it. The FOSS nature allows you to change it to fit your needs though.

If at some point there appear lots of RMVX(A) games that use resolutions above what RGSS natively allows, I might add an extension to make the porting process easier. But this doesn't appear to be the case at the moment.

You can hide the black bars by stretching the game screen to fill the window by setting fixedAspectRatio=false in the config.

[RyanBram]

Hi, Jonas. Thanks for the answer. I don't want to sound stubborn, but if you don't mind I just want to share my perspective.

1. Many open implementation project, also do improvement. Eg. There are save state, shader, dynamic IPS patch support, and internal resolution improvement from many emulator project, even though such features don't exist in original hardware/implementation. They gave additional features, because those features will not contradict with the goal to become open implementation. Same as extending the resolution for RGSS, it will not make MKXP incompatible with original RGSS because it can easily solved in mkxp.conf (e.g EXTENDING RESOLUTION = true/false) to set it back to original resolution.

2. Original proprietary RGSS implementations will not received any update, because the latest maker use Javascript instead of Ruby. But referencing from MV, maximum internal resolution has been increased, so it is save to assume that if RPG Maker goes to RGSS 4 instead of Javascript, the developer will also apply same improvement;

3. The people who ask for extending internal resolution for RGSS player do exist, but very few of them aware of MKXP existence, so I doubt you will see many of them asking about it in this repository. I still heard in the official forum random user ask about extending RGSS internal resolution and even several years ago ever exist .dll to fulfill the demand although it doesn't exist anymore because it is unstable and because MV already exist.

After all, just take my comment as a grain of salt, because as non programmer, I didn't even know how to tweak MKXP source code even it is an open source project. And I am using RGSS instead of MV not because I didn't have MV, but because when comparing both Maker, the lost for leaving older maker is too much (MIDI, better performance, more stable engine than MV, smaller size distribution for PC comparing RGSS Player with NWJS) than benefit that I get from migrating to latest Maker, especially because there is MKXP that can extend its limitation

Just for additional information: Ruby 2.6 and next will have JIT, so hopefully it can make Ruby speed competitive to Javascript.

Thank you very much for creating MKXP. :+1:

[Ancurio]

Many open implementation project, also do improvement. Eg. There are save state, shader, dynamic IPS patch support, and internal resolution improvement from many emulator project, even though such features don't exist in original hardware/implementation. They gave additional features, because those features will not contradict with the goal to become open implementation.

I think this might be a source of misunderstandings. mkxp is not an emulator (as RGSS / RPG Maker is not a hardware console), it is an engine.

Same as extending the resolution for RGSS, it will not make MKXP incompatible with original RGSS because it can easily solved in mkxp.conf (e.g EXTENDING RESOLUTION = true/false) to set it back to original resolution.

Yes, it will. If a game is written for a high-resolution supporting mkxp build, that same game will no longer run under Enterbrain's implementation. For every "extension" to RGSS that I've added to mkxp, I only did so because a significant number of games were already using the same functionality via Win32 calls. It was a compromise.

Original proprietary RGSS implementations will not received any update, because the latest maker use Javascript instead of Ruby. But referencing from MV, maximum internal resolution has been increased, so it is save to assume that if RPG Maker goes to RGSS 4 instead of Javascript, the developer will also apply same improvement;

Yes. RPG Maker VXA and lower are dead systems, and I don't believe new games should be developed in them. The engine is objectively bad, it has many issues like fixed time steps and Windows dependencies that are completely unacceptable in todays world. It was never my goal to extend the life of those Makers, I just wanted a way to preserve and make cross-platform the already existing games. Never in my life did I anticipate people forking my engine and building entirely new games on top of it, but that's another beauty of FOSS and I don't mind. This doesn't mean I intend for mkxp to become a general purpose improvement for the RPG Maker ecosystem however.

The people who ask for extending internal resolution for RGSS player do exist, but very few of them aware of MKXP existence, so I doubt you will see many of them asking about it in this repository. I still heard in the official forum random user ask about extending RGSS internal resolution and even several years ago ever exist .dll to fulfill the demand although it doesn't exist anymore because it is unstable and because MV already exist.

It's unfortunate that Enterbrain/Degica pulled back the .dll for high resolution even though it was kinda working? AFAIK they wanted to promote MV instead, which is fine, because MV solves the cross platform issue completely by being based fully on free technologies.

My advice to you would be: find someone to change the handful of lines it takes to unlock higher resolutions and maintain that mkxp build for you.

[Ancurio]

Just for additional information: Ruby 2.6 and next will have JIT, so hopefully it can make Ruby speed competitive to Javascript.

Unlike ordinary JIT compilers for other languages, Ruby’s JIT compiler does JIT compilation in a unique way, which prints C code to a disk and spawns common C compiler process to generate native code.

Dear lord :rofl:

[RyanBram]

Hi Jonas. The following is just for showing some of my objections about your answer above, not for convincing you into doing what I want. Feel free to answer it or just ignore it if you don't need further discussion.

I think this might be a source of misunderstandings. mkxp is not an emulator (as RGSS / RPG Maker is not a hardware console), it is an engine.

Emulator is just example, in fact that some other open implementation also do improvement. What does make an emulator and an engine should difference in term of adding new features? They will not improve only if the author decided not to add improvement over it, not because they are classified as an engine or an emulator.

Yes, it will. If a game is written for a high-resolution supporting mkxp build, that same game will no longer run under Enterbrain's implementation

I don't understand why somebody should look back to Enterbrain's implementation if he already decided to extend its limitation? Just replace it with MKXP and problem is solved. Extending resolution doesn't mean that original resolution will not be supported anymore. As long as original implementation is still supported, for me it is still compatible. The only thing that shouldn't be added to MKXP is that if the additional feature will make MKXP incompatible with the editor, such as adding fancy 3D feature , using 48x48 tileset instead of 32x32, or using Javascript instead of Ruby unless there is also open implementation for the editor. Because MKXP itself is replacement for the RGSS player. The same case also apply for MV. As long as the project can be edited using default editor, we are freely to use Electron, Phonegap, and even Firefox or Safari as alternative for default NW.js player as long as we are aware with their specific limitations (e.g file format support).

Yes. RPG Maker VXA and lower are dead systems, and I don't believe new games should be developed in them. The engine is objectively bad, it has many issues like fixed time steps and Windows dependencies that are completely unacceptable in todays world.

I am not using default engine for creating new game. I use MKXP and ask my scripter to put MKXP in mind when creating their script. I use VX Ace only for the editor and its basic class. And fortunately most notable scripts also compatible with MKXP. Saying VX Ace as dead system makes project like RPGXP that use MKXP as it heart sounds like wasting of time, and I cannot agree with that.

AFAIK they wanted to promote MV instead, which is fine, because MV solves the cross platform issue completely by being based fully on free technologies.

Which parts of RGSS that don't based on free technologies? Ruby? Vorbis? Theora? JPG? PNG? Which one? The only part that I am aware is only the RGSS player itself which already replaced by MKXP. So currently there is no difference between VX Ace and MV in term of using free technologies.

My advice to you would be: find someone to change the handful of lines it takes to unlock higher resolutions and maintain that mkxp build for you.

Yeah, thank you very much for the advice. I already consider about doing that, although I should admit that I don't really like forking an open source project only for adding tiny feature. For me, open source is more about collaboration with common goals than forking over and over without limit. That's why if something can be discussed first, I prefer doing that instead of just forking it.

Once more, thank you very much for creating MKXP. 😄

[ReinUsesLisp]

I don't understand why somebody should look back to Enterbrain's implementation if he already decided to extend its limitation

Half of my computing is done through an Intel Atom N455 running GNU/Linux. It has a bad GPU (other adjectives may be used). MKXP uses an OpenGL ES 2.0 like API to render on screen. That GPU supports it, but in a terrible way. What I'm trying to say is that there are still practical reasons to use Enterbrain's RGSS instead of MKXP like minimal hardware requeriments.

The only part that I am aware is only the RGSS player itself which already replaced by MKXP.

Win32 API.

Saying VX Ace as dead system makes project like RPGXP that use MKXP as it heart sounds like wasting of time, and I cannot agree with that.

I won't talk nor reply about RPGXP more than the following paragraph because it would be off-topic. That aside, its main purpose of existance (once it's finished) is to be able edit forks of RGSS within a flexible editor (something an old propietary editor can't). Of course this is an use of MKXP, not it's purpose of existance. IMO editing MKXP mainstream for every (newly developed) game particular needs is a bad idea.

If it helps you, I once wrote a prototype of a tile-based engine when Vulkan API was first released. It used RGSS's resources and a fixed resolution of 1280x720. Characters were too small compared to the screen's size.

Now take a look at Sonic Mania (for instance). It uses higher-resolution sprites and tiles than the Genesis games, not just a bigger canvas. Doing that in RGSS would require an entire restructuration not just of itself but RTP's scripts aswell.

P.S.: Editing RPG::Tilemap size is fairly trivial but it has the previous issue. (I made it once but the source is lost.)

[Ancurio]

What does make an emulator and an engine should difference in term of adding new features? They will not improve only if the author decided not to add improvement over it, not because they are classified as an engine or an emulator.

Nobody writes new games for emulators. There is no porting process. The things emulators do are just enhancement meant to make existing games better, not features for new games to take advantage of.

Also, is there a single 2D emulator that enhanced the resolution / aspect ratio of games? It wouldn't make any sense as the games were written with the targeted hardware in mind.

I don't understand why somebody should look back to Enterbrain's implementation if he already decided to extend its limitation?

The only limitation I sought to extend was openness and platform-independence, and even that one has its limits (a lot of RPG Maker games were made with a PC and keyboard in mind, which eg. translates badly to mobile platforms).

The only thing that shouldn't be added to MKXP is that if the additional feature will make MKXP incompatible with the editor, [...]

This is really the crux of the problem; you like the editor a lot, which is why you're using it over other software like Game Maker or Unity, but you don't like the fact that the engine is limited. An engine project based on mkxp could result in that improved Player.exe replacement you're looking for, but mkxp is not it.

Which parts of RGSS that don't based on free technologies?

Font rendering (both GDI and standard Windows fonts like Arial, Times New Roman etc.), Midi playback (de facto due to the standard Windows soundfont being "expected"), mp3/wma audio, and everything that Win32 brings with it. There might be more I forgot about.

[daiaji]

RGDirect uses DX9 to reconstruct the RGSS graphics system, which improves a lot of performance, do not know whether mkxp has a similar plan, such as using Vulkan to reconstruct the graphics system?