- Aug 24, 2019
- Reaction score
- First Language
- Primarily Uses
Multiplication is relevant when talking about asset conversion, but you actually weren't supposed to convert VXA assets to RMV. (You can still do so, but you have to multiply up to the number that has both as denominator, which would be 96. So to get from VXA to MZ, you'd multiple by 300% 32->96 and then divide that by 2. Size increase is done via nearest neighbor, but for the decrease you have to go with bilinear or bicubic interpolation. The result is okay, but not the same quality level. But even at 64, you wouldn't have a decent result either, because you'd just have doubled the pixels for every pixel, leading to assets that will feel as if they don't appropriately use the pixels they have)Can i ask question, that was bothering me since MV's release?
Why one tile became 48x from 32x, but not 64x?
I mean, main theory, that i heard was "We had not enough space in one tile for RTP!", but...
One good man said, that there is one principle of pixel graphics, that about scaling: "Multiplying must be done on proper multiplicity (1x, 2x, 3x)."
So... 32x can be just 64x, right?
I am also created several maps for Doom and Half-Life 1, so i know that fact, that one or both two sides of texture must have size == power of 2 (8x, 16x, 32x, 64x, 128x, 256x, 512x and etc.).
And here we go again with 64x...
But as result we have 48x, that is scale == 1.5x of VXA tile (32x -> 48x).
To be honest, this is pain in the back to scale VXA tiles to MV (Adobe Photoshop or Waifu2X can grant different, but not ideal results and there is always some graphical artifacts like pixels and lines, that are off).
Someone can tell me, that there is some packs just for MV, but what if i have them already for VXA?
Don't take my post as personal attack or something and thank you already for your honest answer.
The main reason why they shied away from 64, I think, is two-fold:
1. 64 tiles & chars are a lot more bigger than 32 and thus require more detail to make use of the added pixels. So making a 64 chair in your tileset, for example, would require more work than a 32 chair.
2. Size. 32x32 has a total of 1024 pixels drawn on the canvas. 64x64 is twice the size in length & height, but quadruple the file size! 4096 pixels are drawn on the canvas.
That effectively means that any tileset in 64 size would require 4 times the loading times and engine ressource than a 32 tileset. And MV, from what I've heard, was already just barely scraping past issues with the number of pages for the tileset. So a 64 tileset would've very likely lead to bloated filesize of all assets and would've caused issues with RMV.
In fact, you can - if you load bitmaps via JS in RMV - already come across issues where files that are too large and can't be loaded in time - forcing you to preload or to update the scene when the image has been loaded.
So you'd probably end up with loading times before every scene change, since every tileset would require quite a bit of time to preload.
And in order to make the editor itself work...you'd probably have to force tilesets to be smaller and scrap 1 or 2 pages.
Little known fact: if you have too many tilesets in your RMV editor...your editor can crash while the JS tileset data is open, corrupting your entire tileset data, forcing you to either load from backup if you have one, or do the whole thing anew.
(How do I know? That's exactly what happened to me.)
That's because the editor has serious issues when you have a lot of images or animations loaded in your database, which you may recognize by how saving becomes very slow, opening the database also no longer is instant, and when you've got too much of it...the editor goes haywire and crashes.
This also extends to other parts of the editor, btw.
If you're using a bust plugin and you're loading bustsheets made of multiple busts into the face image browser when selecting the face in a dialogue conversation, if that image is too big (around 7000x7000 or so) it simply cannot deal with the filesize of the image and your editor crashes.
If you managed to assign that bustsheet to a character via other ways and got it written into your JS DB, it'll actually corrupt the entire database insofar as it becomes impossible to open the database without crashing. The only way to resolve that problem is to directly use notepad++ or similar to edit the JS DB file of your actors and remove the file directly inside the JS code.
Bigger files cause BIG issues. Bigger project sizes, more workload, and lots and lots and lots and lots and lots of engine issues that'll drive users insane.