Jump to content

Newest Update to Sharp Ocarina (we *think* it is hardware compat now)


haddockd
 Share

Recommended Posts

Thanks to Airikita for the code and xDan for the guidance:

 

Alrighty!

 

Look at my last post for latest build

 

Source here:

https://github.com/haddockd/svn.git

 

Change made:

private ulong SetRenderMode(uint C0, uint C1)
        {
            return (SetOtherMode(GBI.G_SETOTHERMODE_L, GBI.G_MDSFT_RENDERMODE,
29, (C0) | (C1))-4);
            // edit: subtract flag 4 to avoid map overlapping - Airikita
        }
  • Like 3
Link to comment
Share on other sites

private ulong SetRenderMode(uint C0, uint C1)
        {
            return (SetOtherMode(GBI.G_SETOTHERMODE_L, GBI.G_MDSFT_RENDERMODE,
29, (C0) | (C1))-4);
            // edit: subtract flag 4 to avoid map overlapping - Airikita
        }

May I comment on this?

 

First, you probably shouldn't do the subtraction inside the SetRenderMode function, but rather change the parameters of the calls to SetRenderMode, so that C1 already enters the function with 4 subtracted, so ex. SetRenderMode(0x1C, 0xC81049D4); instead of SetRenderMode(0x1C, 0xC81049D8);

 

Second, is the resulting 0x4 even a valid flag for SetRenderMode? It doesn't appear to be according to the SDK's GBI.h:

 

/* G_SETOTHERMODE_L gSetRenderMode */

#define    AA_EN        0x8

#define    Z_CMP        0x10

#define    Z_UPD        0x20

#define    IM_RD        0x40

#define    CLR_ON_CVG    0x80

#define    CVG_DST_CLAMP    0

#define    CVG_DST_WRAP    0x100

#define    CVG_DST_FULL    0x200

#define    CVG_DST_SAVE    0x300

#define    ZMODE_OPA    0

#define    ZMODE_INTER    0x400

#define    ZMODE_XLU    0x800

#define    ZMODE_DEC    0xc00

#define    CVG_X_ALPHA    0x1000

#define    ALPHA_CVG_SEL    0x2000

#define    FORCE_BL    0x4000

#define    TEX_EDGE    0x0000 /* used to be 0x8000 */

 

You sure that's the correct way to fix this and won't cause issues elsewhere?

 

Maybe I'm reading this all wrong, too, and you're not even doing what I'm thinking you are, and are actually right about this...

 

Link to comment
Share on other sites

Well, I don't know where you even call it for one. I can check into this, but your methods are a maze to me.

Fixes can still be made.

 

EDIT: yes... I found the 0x1C, but are you not setting this as something else elsewhere?

 

EDIT2:

 

/* Generate SetCombine/RenderMode commands */
                if (IsTranslucent == true)
                {
                    /* Translucent surface */
                    Helpers.Append64(ref DList, SetCombine(0x167E03, 0xFF0FFDFF));
                    Helpers.Append64(ref DList, SetRenderMode(0x18, 0xC81049D8));
                }
                else if (ThisTexture.HasAlpha == true)
                {
                    /* Texture with alpha channel */
                    Helpers.Append64(ref DList, SetCombine(0x127E03, 0xFFFFF3F8));
                    Helpers.Append64(ref DList, SetRenderMode(0x18, 0xC8103078));
                }
                else
                {
                    /* Solid surface */
                    if (Obj.Groups[Group].MultiTexMaterial != -1)
                        Helpers.Append64(ref DList, SetCombine(0x267E04, 0x1FFCFDF8));
                    else
                        Helpers.Append64(ref DList, SetCombine(0x127E03, 0xFFFFFDF8));
 
                    Helpers.Append64(ref DList, SetRenderMode(0x18, 0xC8113078));
                }

You had 0x1C, where 0x04 was a flag to ignore depth compare on maps.

I already tested this on hardware with this minor change to all the parts.

Link to comment
Share on other sites

Ughhhh, ignore my post, but also don't use the SetRenderMode function - 0x1C and, for example, 0xC81049D8 appear to simply be wrong as its parameters. The values are correct and come right from the game, but they're incorrect as parameters for that function. Just have the program insert the raw command, ex. 0xE200001CC81049D8, into the display list instead, like Helpers.Append64(ref DList, 0xE200001CC81049D8);

  • Like 1
Link to comment
Share on other sites

I made a few small changes as well. Updated first post with new build.

 

Please feel free to test this and report any issues but keep in mind in order to get issues fixed, we need you to do some homework to help us out in exactly what the issue is :)

 

Who knows...together maybe we can get a perfectly working SO 

Link to comment
Share on other sites

Ughhhh, ignore my post, but also don't use the SetRenderMode function - 0x1C and, for example, 0xC81049D8 appear to simply be wrong as its parameters. The values are correct and come right from the game, but they're incorrect as parameters for that function. Just have the program insert the raw command, ex. 0xE200001CC81049D8, into the display list instead, like Helpers.Append64(ref DList, 0xE200001CC81049D8);

lol, it's fine xdaniel. We fixed it. It might be incorrect, but it works well now.

I don't think I could have figured it out without haddockd's previous fix, because it did make a difference too.

 

I think it was just SO confusing until recently. So I can see how such a tiny problem could have been a hassle.

We don't need to make any other confusing changes.

 

====================================================

 

EDIT:

-------

Currently working on an animated texture feature... will need to test a bit before I can validate it.

I will also need to add some code to add the animation value when injecting the binary into ROM.

Link to comment
Share on other sites

There was also some minor tweaks:

  1. Fixed the order of the FC and E2 commands to be placed before the D9 commands (something I noticed in other maps.. it MIGHT make a difference for something. Just a precaution)
  2. And the room tab, for the offset entered to inject the room into rom... the textbox only allowed 4 digits to be entered. I lengthened it to the proper size of 8 characters.

And yes... animated textures with notes on how to activate them. The rest is up to the modder, because 0x31 isn't the only possibility.

 

I may work on setting up the interleave settings for bank 2, but it seems like just entering in bank 2 requires the proper value for the scene entry too.

 

I will likely need to add the ability to select a scene to replace from a list if I do that, so it won't be an extra add-on that is simple.

 

Maybe even cutscene creation... but don't hold me on that one. I'm not familiar with OpenTK...

Also, I will need more documentation on cutscenes to work with.

Link to comment
Share on other sites

You are going to have to help us out significantly more than that. We know nothing about your map, settings, etc. Also have you ever gotten any maps to load on your EverDrive? What other mods does your ROM have?

 

Describe for us how you created your map. Also how many polygons do you have total for the map?

Link to comment
Share on other sites

Sorry about that. The map has 1625 faces, 2965 tris total. It has multiple object groups, if that happens to mean anything. When I imported it, I did nothing but load the map into SharpOcarina, reposition Link's spawn point, and inject it. It's set to inject over the default 117, I didn't mess with that. I've never attempted to load a map on actual hardware until today since I was under the impression that it was impossible. It loads just fine on Project 64, but that probably isn't saying much.

Link to comment
Share on other sites

Sorry about that. The map has 1625 faces, 2965 tris total. It has multiple object groups, if that happens to mean anything. When I imported it, I did nothing but load the map into SharpOcarina, reposition Link's spawn point, and inject it. It's set to inject over the default 117, I didn't mess with that. I've never attempted to load a map on actual hardware until today since I was under the impression that it was impossible. It loads just fine on Project 64, but that probably isn't saying much.

Did you set the offsets correctly? Did it import to the correct location in ROM without overwriting something important?

Send me a link to the binary of the scene and room that is the culprit... it could also be a possible increment issue.

Link to comment
Share on other sites

I just realized that SO doubles the size of room files (zmaps) and adds an extra display list underneath the legitimate one.

Not only that, but the 2nd set of DLists is completely malformed, and not even in format.

 

That can chew up the RAM easily... for now I suggest modders look at their zmap files for now to see if there's excess. In the meantime I'll be poking at the source.

 

================================

 

EDIT/UPDATE:

--------------------

A fix was made to SO to prevent large files from being saved.

Turns out a method used in the file saving code was just overwriting old data, keeping the file large if it was previously a larger file.

 

This will prevent any errors from missing the excess data and re-importing a huge map if the modder made it smaller than before.

 

I will message Haddockd to re-build it.

Link to comment
Share on other sites

I can't seem to get my SO to show any graphics.

I'll load a collision and non-collision map and nothing shows up.

I'll usually get Unhandled exception index out of range must be non-negative.

 

I know you recommend using an .obj file via Sketchup Pro?

but I think it may be bc i'm using Sketchup8 and a plugin.

even then I still am confused why the current map importer I'm using H.T.

can utilize this difference and SO won't.

 

Why is that?

(forgive my impeding arrogance)

Link to comment
Share on other sites

If you're using Blender (or something else maybe?), the obj file isn't exported correctly for SO to read from properly.

You can convert it with Milkshape by importing it, smoothing the faces (Ctrl+M) and exporting it.

 

I am unsure why it is SO can't read it... but I haven't really looked into it.

 

There might be other obj exporting tools that might work, but I haven't tested much else.

Link to comment
Share on other sites

Airikita already tried to help me with this so I'm not going to ask for anymore help, but I thought it'd be a good idea to at least make it known in the thread for future reference. When I tried importing small maps that were no more than a couple hundred tris, they loaded fine on hardware. However, loading a map that was slightly larger (the one I tested was about 670 tris) it would not load normally. In order to get it running, I had to inject it into the ROM manually via hex editor, but even then half of the collision was missing, and one of the planes was set to transition to Inside the Deku Tree even though I had placed no such exit. Maps larger than the one I just mentioned would not load at all whether via SharpOcarina or manually injecting to the ROM.

Link to comment
Share on other sites

I was starting to think that perhaps if you re-opened SO after saving the file... perhaps it would fix itself then. However this is still an issue with the BinaryWriter class used...

 

I'm sure SO is using the file size, that was opened previously, to determine the offset size... but it should determine the new offsets by the new byte array.

 

Perhaps Haddockd might be able to look into that, might be in the code where my last revision was.

 

It's late for me now, and I have a report to work on this week.

Link to comment
Share on other sites

 

Hey! Nice job! If you would, I have some suggestions for SO.
 
- Change the Music Value so it reads from Hex and not decimal.
- Making a "Shiny" Checkbox next to the Animate and MultiTexture Checkbox
 
Also, is it me or making a group animated literally just makes everything invisible but the skybox once in-game?

 

You need to add the value to the scene you replaced for it to animate, otherwise it will glitch.

I put the information in the ReadMe.txt for a tip on that.

 

I'm not sure what you mean by "shiny" btw...

Link to comment
Share on other sites

I very recently started looking into this sort of stuff. Is any of this useful/wrong: http://wiki.cloudmodding.com/oot/F3DEX2#Command_List

Bleh... it'd be nice if we had proper notes on each command, detailing flags and values for each command, even if we don't have them all.

 

But I get it's such an under-observed data structure because it's so difficult to just test it. It all works differently under various conditions.

Link to comment
Share on other sites

This has everything on the GBI: http://n64.icequake.net/doc/n64intro/kantan/step3/index9.html

 

This one seems to be slightly better: http://n64devkit.square7.ch/

 

Or maybe even this downloadable PDF: http://www.jax184.com/projects/ultra64/Nintendo%20Ultra64%20Programming%20Manual+Addendums.pdf

 

Shit, man: http://level42.ca/projects/ultra64/Documentation/man/n64man/tools/gbi.html

 

Plus, if you have an N64 SDK, you can just peek at gbi.h.

 

But here's a port someone made in C++: https://github.com/emudeveloper/N64-Player--Mupen64plus-/blob/master/main/jni/gles2n64/src/GBI.h

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.