Custom Resolution? #103
Comments
|
The names of the config entries in Changing the resolution to anything higher than that is a hack which exploits implementation details of Enterbrain's Player engine. In mkxp, the RGSS1 In the future I might add a direct non-standard method to the |
|
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? Thank you for your attention and sorry for any inconvenience. |
|
@RyanBram 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 |
|
Hi, Jonas. Thanks for the answer.
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. 👍 |
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.
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
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'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. |
Dear lord 🤣 |
|
Hi Jonas.
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?
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.
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.
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.
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. 😄 |
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.
Win32 API.
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.) |
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.
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).
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
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. |
|
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? |
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.
The text was updated successfully, but these errors were encountered: