Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Apr 29, 2012 0:24:41 GMT -5
yeah. I saw there was an open source tool that could convert MIDI->AudioSeq, and my rule's if it can be done it can be undone. I'm getting a headache trying to get the plugins to work, so I'm just gonna go back to implementing everything in the app itself, progress was a lot faster that way anyway.
Anyway, thanks for the support!
|
|
|
Post by Cinnamon on Apr 29, 2012 19:42:01 GMT -5
wow... This is looking to be an incredibly useful program. o.o This is looking amazing! Excellent job on this, I can't wait to see it released in a complete version. Also, thank you so much for putting in the time to make this for the community. This tool could make really tedious tasks so much easier.
|
|
|
Post by Cinnamon on Apr 29, 2012 19:42:20 GMT -5
wow... This is looking to be an incredibly useful program. o.o This is looking amazing! Excellent job on this, I can't wait to see it released in a complete version. Also, thank you so much for putting in the time to make this for the community. This tool could make really tedious tasks so much easier.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 1, 2012 14:21:46 GMT -5
Yesterday, I spent the day writing the API to convert vertex/colors/normals/uvs/face into openGL display lists. It won't really aid in viewing zobj or zmap's since display lists have specific commands though, it's intended for the OBJ, SMD, and BLEND importers.
I couldn't find any good documentation on F3DEX2 aside from the basic vertex buffer / draw triangles & quads command on the spinout wiki, so I've spent the morning using Rice's debug plugin with PJ64 to figure out the commands. So far, here's the documentation I've gathered:
01 - Set Vertex Buffer Format: [01 aa ac cc bb xx xx xx] a - where to start writing vertices in vertex buffer c - number of vertices to write * 2 b - bank x - offset
05 - Draw 1 Triangle Format: [05 aa bb cc 00 00 00 00] a - first vertex of triangle * 2 b - second vertex of triangle * 2 c - third vertex of triangle * 2
06 - Draw 2 Triangles Format: [06 aa bb cc 00 dd ee ff] a - first vertex of first triangle * 2 b - second vertex of first triangle * 2 c - third vertex of first triangle * 2 d - first vertex of second triangle * 2 e - second vertex of second triangle * 2 f - third vertex of second triangle * 2
07 - Draw Quad Format: [07 aa bb cc 00 dd ee ff] a - first vertex of top-left corner of quad * 2 b - second vertex of top-left corner of quad * 2 c - third vertex of top-left corner of quad * 2 d - first vertex of bottom-right corner of quad * 2 e - second vertex of bottom-right corner of quad * 2 f - third vertex of bottom-right corner of quad * 2
DA - Set Matrix Format: [DA 00 00 00 ss xx xx xx] s - length of matrix / 112 x - offset
DE - Load Display List Format: [DE 00 00 00 bb xx xx xx] b - bank x - offset
DF - End of Display List Format: [DF 00 00 00 00 00 00 00]
E7 - Sychronize Drawing With Pipe Renderer (Usually Start of Display List) Format: [E7 00 00 00 00 00 00 00]
F2 - Set Tile Size (scale tile?) Format: [F2 aa ab bb nn cc cd dd] a - x1 offset << 2 b - y1 offset << 2 n - tile # c - x2 offset << 2 d - y2 offset << 2
F4 - Load Tile (set tile offset?) Format: [F4 aa ab bb nn cc cd dd] a - x1 offset << 2 b - y1 offset << 2 n - tile # c - x2 offset << 2 d - y2 offset << 2
F5 - Set Tile Properties Format: [F5 tt 00 00 nn 00 00 00] t - image type n - tile #
F6 - Fill Rectangle Format: [F6 aa ab bb 00 cc cd dd] a - x1 offset << 2 b - y1 offset << 2 c - x2 offset << 2 d - y2 offset << 2
F7 - Set Fill Color Format: [F7 00 00 00 aa aa bb bb] a - fill color in 5551 format b - same as 'a'
FD - Set Tile Image Format: [FD tt 00 7F ww xx xx xx] t - image format w - width (in pixels) x - offset
If you have anything you can add to this, please post it here. The more documentation there is, the better support there will be.
|
|
xdaniel
Full Member
[Mo0:0]
Posts: 90
|
Post by xdaniel on May 1, 2012 17:08:08 GMT -5
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 2, 2012 2:36:08 GMT -5
That's not exactly what I was aiming for...It's a more time consuming process to reverse engineer another tool's source code than it is to figure it out with Rice's debug. Thanks anyway.
|
|
xdaniel
Full Member
[Mo0:0]
Posts: 90
|
Post by xdaniel on May 2, 2012 7:35:49 GMT -5
Well, there isn't really any comprehensive documentation besides the function reference in the SDK and even then, that's mainly written for programmers trying to actually use the SDK. Plus, the makeup of macros like LoadTextureBlock - which is comprised of some five or six commands, and is how a texture load should be done - isn't explained in the documentation at all, as far as I can see, only the arguments it takes and such. You need to look into the header files for that.
Besides, isn't using Rice's debug plugin also more or less reverse engineering? You're using it to look at how the game does it, after all.
(EDIT: Reading my post again, it might sound a bit mean, but that's certainly not how it's intended. I hope you don't take it as such.)
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 2, 2012 12:01:29 GMT -5
Nah, I get it. I just don't like using other people's code. The difference is that with Rice's Debug, is displays the name of the command, all 8 bytes in hex, and the value of each field. For me, that's a lot easier to figure out than acquainting myself with someone else's code. Hell, it took me an entire day just to get BMDView2 to build in MSVC11. I'd rather not use someone else's source code anyways because between me and everyone here, all the zobj / zmap / zscene editors written so far are just shitty. They usually contain tons of bugs, won't view half the files you put in them (usually crashing without closing their process), and in the case of one's like OZMAV and early UoT builds, texturing doesn't work so all you get is a shadow for the model.
Anyway, I thought of a new feature - mirrored texture fix - When enabled, all uv coords are divided by 2 and textures are doubled in size, with the other 3 corners being the same image mirrored horizontally and vertically. I figured this would be a good idea because not all versions of OpenGL support mirroring and it fixes texturing issues when exporting models.
|
|
xdaniel
Full Member
[Mo0:0]
Posts: 90
|
Post by xdaniel on May 2, 2012 12:51:22 GMT -5
Sure, I understand and honestly, I prefer not to look at existing source code from the get-go either, but I will once I get stuck on something. There's just one thing I take some offense at: I'd rather not use someone else's source code anyways because between me and everyone here, all the zobj / zmap / zscene editors written so far are just shitty. They usually contain tons of bugs, won't view half the files you put in them (usually crashing without closing their process), and in the case of one's like OZMAV and early UoT builds, texturing doesn't work so all you get is a shadow for the model. May I ask how this is shitty? I give you that support for Majora's Mask is rather limited in all viewers/editors - one reason being MM's extensive use of RAM segments and a limited understanding on how the game sets them up -, but in OoT texturing, combiner emulation, etc. is far from "shitty". The one longstanding rendering bug, that no one has properly fixed yet, is the alpha problems with the pathways and some other elements in the games, which can be seen in the screenshot. If you do manage to fix ex. MM's missing textures or the incorrect pathway alpha, I'd certainly like to learn how you did it. Also, I really don't want to start any arguments (there's been way too many in the Zelda hacking "community", and I'm one of the last persons who'd want to start something) but the way you put this bit just rubs me the wrong way.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 2, 2012 14:31:32 GMT -5
Must be a compatibility thing then, because all I got when I used OZMAV was a black silhouette, no textures.
I haven't heard anything about MM's missing textures, but the pathway alpha could be fixed by dividing display lists among 2 layers consisting of one's that use alpha transparent textures and ones that don't, the one's using the alpha-transparent textures would drawn last to prevent tearing. If all else fails, you could just disable the depth buffer and use raycasting.
Sorry if it offended you, it was just my opinion on the whole deal. Besides, if I'm not mistaken the author of OZMAV was learning OpenGL as he was writing the application, so it isn't really right of me to criticize him.
|
|
xdaniel
Full Member
[Mo0:0]
Posts: 90
|
Post by xdaniel on May 2, 2012 15:07:55 GMT -5
The pathway alpha problem, if I remember correctly because it's been a while, comes from the fact that the combiner setup used for the pathways tries to use an alpha channel that doesn't exist. Or more exactly, its set to use the alpha channel from Texel 0 (IIRC), which is the pathway texture, which however is in a format that doesn't provide an alpha channel, I4 or I8 if I'm not mistaken.
I still am not sure where the game gets the correct alpha channel from, and I've pretty much given up on that, to be honest. Besides that, rendering of textures with alpha channels or translucent surfaces should be working correctly.
And yeah, that problem you're describing with OZMAV is probably down to compatibility, maybe your graphics chipset. Usually the worst that should happen tho is just missing combiner emulation, as that relies on an OpenGL extension for fragment shader support.
Also, you have used OZMAV2 as opposed to the ancient original OZMAV, correct? Because the original one is certainly from a time where the author (which btw, for the most part and with help/code from spinout and cooliscool, would be me) was still learning OpenGL and was... well, quite a mess in many respects.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 2, 2012 18:10:14 GMT -5
If that's what the problem is, then it's not really a problem at all. The author (you?) just didn't know how to use clipping masks. If it's a problem of locating the alpha channel, I have several ideas where it could be if it's not part of the image itself:
* In a separate mask (pathway texture) * For indexed images, it could be a specific color value like 0x00 or 0xFF * The background color (which there is an instruction to set) might be rendered transparent. This is a possibility since some Nintendo consoles such as the GameBoy don't render black.
What was your purpose for using fragment shaders by the way? Does the n64 support multi-texturing?
|
|
xdaniel
Full Member
[Mo0:0]
Posts: 90
|
Post by xdaniel on May 2, 2012 19:07:09 GMT -5
The pathway texture is basically a grayscale texture with one intensity value per pixel, from 0x0 to 0xF for 4-bit, 0x00 to 0xFF for 8-bit. Simply forcing ex. 0x00 or 0xFF to be transparent for this texture type produces missing pixels in other textures of the same format elsewhere. As for multi-texturing (which also ties into the pathway stuff), the N64 has its color combiner which is capable of all sorts of texturing or coloring effects, including just that. Here's an old semi-explanation I posted at The GCN (local copy as I don't assume you're registered there, and you need to be logged in to see most forums/threads). Now, if the pathway alpha is supposed to come from a separate mask - which is possible, considering how the combiner setup specifically looks for alpha information from a texture unit - I cannot tell how or where it's loaded from. And again, IIRC said combiner setup is trying to get the alpha from the texture unit our (alpha-less) path texture is loaded into at the time.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 3, 2012 0:19:09 GMT -5
I guess as it stands, the only way to truly have 100% support would be to emulate the entire n64 itself, in which case ZLE sorta had the right idea hacking into the RAM of running emulators.
I wonder if it would be possible to hack into an emulators RAM, copy the view to an offscreen buffer, and render it in Hylian Cartographer's graphics view...
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 3, 2012 9:54:37 GMT -5
Nah, I wouldn't do that. PJ64 1.5 was pretty buggy, and like I said before I don't wanna use other people's source code in Hylian Cartographer. I've managed to detect if PJ64 is running and tap into it's ram no prob, now it's just a matter of installing an OpenGL API hook for wglSwitchBuffers() and redirecting it to my application so I can render to PJ64's context. I'll post a screenshot when I've finished it.
|
|