XML talk:TXMB: Difference between revisions

From OniGalore
Jump to navigation Jump to search
(for mipmaps?)
m (link fix, marking dead link)
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== TXMP with height of 224 ==
==TXMP with height of 224==
 
In this page it is given an example of an image with a size of 640x480 made of 128x224 images.
In this page it is given an example of an image with a size of 640x480 made of 128x224 images.


I was reading [http://wiki.oni2.net/XML:TXMP TXMP page] and it says '''"textures' x and y (pixel) dimension must be power of two: 512, 256, 128, 64, etc"'''.
I was reading [[XML:TXMP]] and it says '''"textures' x and y (pixel) dimension must be power of two: 512, 256, 128, 64, etc"'''.


However 224 is not power of two. Why is this size used in the TXMB example? [[User:Script 10k|Script 10k]] ([[User talk:Script 10k|talk]]) 12:49, 29 September 2016 (CEST)
However 224 is not power of two. Why is this size used in the TXMB example? [[User:Script 10k|Script 10k]] ([[User talk:Script 10k|talk]]) 12:49, 29 September 2016 (CEST)
Line 10: Line 9:
:Hypothesis: Textures with mipmaps need to be power of two and splashscreens don't need mipmaps because they are always seems from equal distance.
:Hypothesis: Textures with mipmaps need to be power of two and splashscreens don't need mipmaps because they are always seems from equal distance.
: Maybe it helps to create a statistic with all TXMP. [[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 13:21, 29 September 2016 (CEST)
: Maybe it helps to create a statistic with all TXMP. [[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 13:21, 29 September 2016 (CEST)
==TXMB 640x480 problems==
"The number of columns and rows (TXMPs) is computed at runtime.
Probably the engine checks the horizontal dimension of the TXMPs until the desired x size is reached and then starts a new row.
So it should be possible to create also other TXMB resolutions and TXMP constellations."
The following image isn't mapped correctly by the engine:
<nowiki>https://dl.dropboxusercontent.com/u/143726/temp/IntroImageLevel2Problem.zip</nowiki> (dead link)
The image is composed by the following images:
256x256 | 256x256 | 128x256
256x128 | 256x128 | 128x128
256x64  | 256x64  | 128x64
256x32  | 256x32  | 128x32
Any idea why the image isn't displayed correctly by oni?
The link that I posted contains the original image, oni files and the level2 dat file with the oni files already built in. [[User:Script 10k|Script 10k]] ([[User talk:Script 10k|talk]]) 10:36, 11 October 2016 (CEST)
:Not sure what's going on. Try to use only one row and only one column of non-standard sizes, '''starting with standard max''' and in the end filling the 'holes' with non-standard. --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 21:30, 11 October 2016 (CEST)
::Thanks Paradox. I followed your suggestion, I created an algorithm which first uses 256 sized images to fill the TXMB. When there's a hole (this is, when we can't fit another 256 pixel image) I fill it with the remaining size which don't need to be power 2. This worked and seems that it is creating the same TXMP resolutions that Vanilla oni used. Pseudo code of the algorithm:
<code>
    function getSplitSizes(int sideSize){
        vector splitSizes;
        int remainingSize = sideSize;
        int regularSize = 256;
        while (remainingSize > 0){
            if(remainingSize - regularSize < 0){
                splitSizes.add(remainingSize);
                remainingSize = 0;
            }
            else{
                splitSizes.add(regularSize);
                remainingSize = remainingSize - regularSize;
            }
        }
        return splitSizes;
    }</code>
::C++ code can be found in Vago [http://svn.oni2.net/s10k/Vago/bgImageWizard/bgimagepagefinal.cpp here] ''QVector<int> BGImagePageFinal::getSplitSizes(int imageSideSize)'' function. Look at the uncommented one. [[User:Script 10k|Script 10k]] ([[User talk:Script 10k|talk]]) 12:30, 13 October 2016 (CEST)

Latest revision as of 13:52, 21 August 2020

TXMP with height of 224

In this page it is given an example of an image with a size of 640x480 made of 128x224 images.

I was reading XML:TXMP and it says "textures' x and y (pixel) dimension must be power of two: 512, 256, 128, 64, etc".

However 224 is not power of two. Why is this size used in the TXMB example? Script 10k (talk) 12:49, 29 September 2016 (CEST)


Hypothesis: Textures with mipmaps need to be power of two and splashscreens don't need mipmaps because they are always seems from equal distance.
Maybe it helps to create a statistic with all TXMP. paradox-01 (talk) 13:21, 29 September 2016 (CEST)

TXMB 640x480 problems

"The number of columns and rows (TXMPs) is computed at runtime. Probably the engine checks the horizontal dimension of the TXMPs until the desired x size is reached and then starts a new row. So it should be possible to create also other TXMB resolutions and TXMP constellations."

The following image isn't mapped correctly by the engine:

https://dl.dropboxusercontent.com/u/143726/temp/IntroImageLevel2Problem.zip (dead link)

The image is composed by the following images:

256x256 | 256x256 | 128x256

256x128 | 256x128 | 128x128

256x64 | 256x64 | 128x64

256x32 | 256x32 | 128x32

Any idea why the image isn't displayed correctly by oni?

The link that I posted contains the original image, oni files and the level2 dat file with the oni files already built in. Script 10k (talk) 10:36, 11 October 2016 (CEST)

Not sure what's going on. Try to use only one row and only one column of non-standard sizes, starting with standard max and in the end filling the 'holes' with non-standard. --paradox-01 (talk) 21:30, 11 October 2016 (CEST)
Thanks Paradox. I followed your suggestion, I created an algorithm which first uses 256 sized images to fill the TXMB. When there's a hole (this is, when we can't fit another 256 pixel image) I fill it with the remaining size which don't need to be power 2. This worked and seems that it is creating the same TXMP resolutions that Vanilla oni used. Pseudo code of the algorithm:

   function getSplitSizes(int sideSize){
       vector splitSizes;
       int remainingSize = sideSize;
       int regularSize = 256;
       while (remainingSize > 0){
           if(remainingSize - regularSize < 0){
               splitSizes.add(remainingSize);
               remainingSize = 0;
           }
           else{
               splitSizes.add(regularSize);
               remainingSize = remainingSize - regularSize;
           }
       }
       return splitSizes;
   }
C++ code can be found in Vago here QVector<int> BGImagePageFinal::getSplitSizes(int imageSideSize) function. Look at the uncommented one. Script 10k (talk) 12:30, 13 October 2016 (CEST)