<- 1  -   of 75 ->
^^
vv
List results:
Search options:
Use \ before commas in usernames
yep.. the dolphin team needed a good way to analyze Nintendo-binaries themselves.. so the debugger functionality was simply rolled into the emulator
I like to comment on that cmdl to obj converter. I tried to do the same, but I couldn't convert 32-bit vertex positions. They end up horrible... my code is like this

Code:
for (int i = 0; i < vertexCount; i++)
            {
                if (shortPositions == false)
                {
                    float xpos = cmdl.ReadInt32(); //This is the part I am talking about
                    float ypos = cmdl.ReadInt32();
                    float zpos = cmdl.ReadInt32();

                    vertexArray[i] = "v " + xpos.ToString() + " " + ypos.ToString() + " " + zpos.ToString();
                }
                else
                {
                    float xpos = ((float)Endian.SwapEndian16(cmdl.ReadInt16())) / 0x2000;
                    float ypos = ((float)Endian.SwapEndian16(cmdl.ReadInt16())) / 0x2000;
                    float zpos = ((float)Endian.SwapEndian16(cmdl.ReadInt16())) / 0x2000;

                    vertexArray[i] = "v " + xpos.ToString() + " " + ypos.ToString() + " " + zpos.ToString();
                }
            }

Reading them as little endian does not make a difference. I hope someone got an idea why its hard to read, I like to use OpenTK and make a sort of model viewer and then make obj to cmdl.
Float vertex positions shouldn't require any converting. It should work correctly if you just read them as Big Endian 32-bit values.
Well, I am getting this for example -2,268437E+08, that should mean that I am doing something wrong because its a large number. and indeed you read it as ReadBEFloat but I noticed that there is actually a weird conversion going on floatSwap2(readfloat fstream), which makes it a string and does something with it, its very vague...
that's a Maxscript workaround. You can load the data the same way as a long as long as you load it into a float.

I'm not sure what the original file data is so it's hard to tell what's going wrong with that value, but endian swapping it seems to result in a more reasonable value of -213
I lost that example but here
1,085263E+09 : this is the first data
40 AF CC D0 : this is it in hex
1085263056 : should be ok right?

this is read in little endian. but nothing works, thats why I gave up on this.
Edit history:
Aruki: 2015-04-29 02:06:17 pm
Aruki: 2015-04-29 02:05:41 pm
Aruki: 2015-04-29 02:05:36 pm
Aruki: 2015-04-29 02:03:52 pm
The Wii is big endian. Little endian is incorrect. That value should be 5.493752.

1085263056 is the decimal value of 0x40AFCCD0... in other words, it's being read as a long, not a float. I assume ReadInt32 returns a long, so basically what's happening there is it's reading the value as a long, then casting the long value to a float. When I said you could read it the same way as a long, I meant you could read it as a 32-bit value, but it still needs to be read into a float, not a long. So you need to write a ReadFloat function that does basically the same thing as ReadInt32, but returns a float.

quick example - this is how my fileIO setup handles longs/floats; you can see it's the exact same code but with a long in one and a float in the other:

Code:
long CInputStream::ReadLong()
{
    long Val;
    ReadBytes(&Val, 4);
    if (mDataEndianness != IOUtil::SystemEndianness) IOUtil::SwapBytes(Val);
    return Val;
}

float CInputStream::ReadFloat()
{
    float Val;
    ReadBytes(&Val, 4);
    if (mDataEndianness != IOUtil::SystemEndianness) IOUtil::SwapBytes(Val);
    return Val;
}
oke I absolutely do not understand that example, but whatever I do, it will just take the int and past a , into it. there doesn't really seem to exist a way to convert an int into float, because its already using the conversion functions, atleast in c#. However, the shorts works fine, so I don't understand why the same trouble doesn't exist with shorts.
Edit history:
Aruki: 2015-04-29 02:32:54 pm
Because the shorts are supposed to be integers. The floats aren't. Is there no ReadFloat function?

edit: after looking up how this works in C#, it looks like the float reading function is called ReadSingle. Use that.
I get other numbers, so I guess it works. But I still stick with the endianness. I always read in little endian (or in big endian) however it only works when I swap the bytes. How should I swap the bytes from a single? is it the same as an 32-bit integer? or a 64-bit integer?
A float is 32-bit. If you were reading a double then it would be 64-bit.
I figured out that you cannot swap a single, it also shows with scientific notations, which are annoying.
The precision doesn't matter, if it's a Big Endian value over 1 byte it needs to be swapped.
It does matter if we're talking about -how- you swap them
Edit history:
Antidote: 2015-04-30 01:58:04 am
All you do with a swap is reverse the bytes. In C# it's as simple as using the BitConverter.GetBytes method to get an array of bytes, then using Array.Reverse, and finally BitConverter.ToSingle with the array as the argument.
holy shit, Thank you, Antidote. You saved my day, it works now properly. for some reason Convert.ToSingle(int) didn't work correctly, but reading the bytes into a single does work.
Because converting an int to a float will give you a float with the value of the int, not a float with the hex representation of the int. Good that it's working.
Right now I'm working on configuring 0-00 to work nicely in widescreen in Dolphin. I've been modding the FRME files for the HUD to adjust them to 16:9. Trying to avoid stretching things as much as possible.



The Combat Visor is pretty much done. Need more adjustments for X-Ray and Thermal and I haven't tried looking at some of the miscellaneous frames yet (main menu, map screen, pause menu, morph ball HUD).

Also, I made this code to fix frustum culling issues. I didn't want to use the existing code because they disable the culling entirely. Which is good for VR, but way overkill if you just want widescreen. So here's a code that extends the frustum range, but still allows for culling to happen offscreen. This works because the CFrustumPlanes constructor takes the aspect ratio as a function parameter. This code patches in an instruction that forces the game to always load 2.0 as the aspect ratio value.

Code:
043452A8 C342CB78
This also prevents some slowdown, no? Nice work :)
Not that it matters that much for me at the moment, but out of curiosity: Does anyone have any idea what RIML in the Material Section of CMDL files is?
It seems to be a subsection of PASS, but it seems to be doing nothing special with the texture specified, or am i wrong?

I am currently trying to convert the material sections to .mtl files to be used inside the .obj file.
RIML isn't in Prime 3. Must be one of the new pass types they added in DKCR... so I couldn't really tell you what it is without looking at it unfortunately. Antidote might know if he's looked at DKCR materials but I think he's mostly focused on MP3.
Edit history:
Antidote: 2015-05-02 04:39:48 am
Antidote: 2015-05-02 04:38:37 am
RIML is similar to the RFLD/RFLV pair. If it has an animation at all it usually has a mode 0 animation, occasionally a mode 2 (scroll)

Also @Jesse, np, glad my aging C# knowledge was helpful!
Edit history:
Antidote: 2015-05-02 05:00:43 am
Antidote: 2015-05-02 05:00:08 am
Antidote: 2015-05-02 04:49:36 am
Quote from Parax:
Because converting an int to a float will give you a float with the value of the int, not a float with the hex representation of the int.

Parax, I'm sorry, but I have to point out that that makes absolutely no sense. When you convert an int to a float you ARE converting it to a float with the int's hex representation, all a hex representation is is a base 16 representation of a base 10 value. Swapping between endianess is a bit different than just passing one value to another, but it's not very complicated. As I stated before, it's just a simple matter of reversing the bytes.

Big endian systems store the most significant byte first, little stores it last. So 01 23 45 67 converted to big endian becomes 67 45 23 01, simple as that.

What Jesse was trying to do in using Convert.ToSingle(int) was this:
float val = (float)(01 23 45 67);

Which is wrong, but a very easy mistake to make for someone not used to the nuances of system byte sex. Admittedly I was extremely confused over this exact matter just a few years ago. It's a confusing issue, but mind bogglingly simple once you grasp the concept.

EDIT:
Also, it's extremely important to note that a float is simply an int with some very specific rules that you must follow, for a more technical look into how a single or double precision float works, look up IEEE 754 which specifies exactly how floats work on modern systems.
Parax, that widescreen hack looks freaking amazing!  I can't wait to try it out :D
Edit history:
Aruki: 2015-05-02 10:10:01 am
Ermm, I don't code in C# so maybe I don't understand how this works, but I looked up the documentation for ToSingle and it seems to do exactly what I said. https://msdn.microsoft.com/en-us/library/06d3c2st(v=vs.110).aspx

What I meant is: for example, if you feed it ToSingle(0x3F800000), you will get a float value of 1065353216.0, not 1.0. That's not due to endianness, that's the decimal equivalent of that hex number. The way I understand it, the way Jesse was trying to read the floats is equivalent to reading them into an int and then casting it to a float.