Jump to content

Zelda Level Editor 3


john_smith_account
 Share

Recommended Posts

Title says it all.  I've been working al week on the core of ZLE3, basicly a front in for XDaniel's F3DEX2.  The end goal is to make a 100% hardware compatible map converter.  Due to XDaniel's thought fullness on the command line of F3DEX2, I feel I have a really good chance at success.

 

Basicly, the goal of ZLE3 right now is to create a perfect, easy to use tool for both converting the OBJ, and adding headers with all possible options.

 

It's in the very first stages, but don't let that fool you.  ZLE2's first test could only change the name of MAP SELECT.  It got laughed at until 2 weeks later, I released the complete working program.

 

Wish me luck.

  • Like 11
Link to comment
Share on other sites

  • 3 weeks later...

SHIT.  Did you test the patch on an emulators first? 

 

The main reason to start this was because Sharp Ocarina and Hyrule Toolbox don't produce hardware compatable maps.  If it doesn't work on real hardware, there may be no reason to continue ZLE3. 

 

ZLE3 might be over before it ever gets started.

 

Thanks for testing it though Arcaith, better to know now than after many hours programming.  :(

Link to comment
Share on other sites

It ran fine on an emulator, but it hangs on hardware when I try to load the map. AFAIK, the maps produced by Sharp Ocarina run fine on hardware, however you need to make sure it isn't all one mesh or the draw order will be screwed up and Link will be drawn behind all the geometry. It might not be the display lists that are the problem, though. Last I was aware, there were no problems with xdan's most recent command line converter. It might be an issue in the setup of the zmap or zscene, or a pointer problem. You also have to update all the pointer tables for hardware compatibility, as I'm fairly sure that there's more than one table that references file locations.

 

If you can post the offsets for the files in ROM for me, I'll see if I can fix it.

Link to comment
Share on other sites

I just patched the file to one of my Debug ROMS and it works. I used Zelda Edit before I patched the ROM to fix any problems. To patch the file I used the Ppf-O-Matic3 program. I'm also playing it on Nemu64. Using Mudlord's Rice Plugin 6.1.4 for the video plugin. All I got to say is, "works for me". 

 

Edit: Here's an image, http://prntscr.com/4u9end

Edited by Zinc
Link to comment
Share on other sites

I just patched the file to one of my Debug ROMS and it works. I used Zelda Edit before I patched the ROM to fix any problems. To patch the file I used the Ppf-O-Matic3 program. I'm also playing it on Nemu64. Using Mudlord's Rice Plugin 6.1.4 for the video plugin. All I got to say is, "works for me". 

 

Edit: Here's an image, http://prntscr.com/4u9end

I think we're talking about running on actual N64 hardware via a flash cart.

Link to comment
Share on other sites

What are you using to generate collision? I assume it's not a huge problem with the display lists considering you're using xDaniel's Model2N64 command-line tool...

Yep.  But I'll be changing over to latest and greatest version of Model2F3DEX2 for the release version.

 

Conversions by Model2N64, and in turn Hylian Toolbox, overflow the vertex buffer, causing the console to crash. SharpOcarina doesn't do that, but might have other bugs that cause problems on console; not sure if anyone's ever tested maps made using it on hardware.

I see now.  If I would have paid closer attention, I would have realize before hand that this map would not work on real hardware.

 

After I did this...

 

https://www.the-gcn.com/topic/3027-getting-oot-and-mm-maps-into-google-sketchup-format/

 

I had complaints it didn't work on real hardware.  I'm told Model2F3DEX2 creates the *BEST* possible display lists, ones that are closest to the way Nintendo does it.

 

But, all is well.  I'll get Model2F3DEX2 added to the header generator that is ZLE3, and we'll be able to test again.  Sorry requesting a real hardware check when ZLE3 wasn't ready to pass that kind of test yet.  Please don't hold it against me, and I guarantee the next test map will be ready to be tested.

 

Thanks for your help, and support.

Link to comment
Share on other sites

To recap for everyone, display list conversions made by...

  • SharpOcarina: apparently work on hardware, have glitches?
  • Model2N64: crash the hardware, vertex buffer overflow issues
  • Model2N64-CHT / Hylian Toolbox: same as Model2N64, hardware crashes
  • Model2F3DEX2 (Project Mikan): should work on hardware according to various tests

So yeah, only use Model2F3DEX2 if you want stuff to work on the real hardware. Or be prepared to try and manually fix SharpOcarina's bugs, namely the ordering problem Arcaith described; can maybe be fixed by rewriting the mesh header...?

 

Link to comment
Share on other sites

To recap for everyone, display list conversions made by...

  • SharpOcarina: apparently work on hardware, have glitches?

So yeah, only use Model2F3DEX2 if you want stuff to work on the real hardware. Or be prepared to try and manually fix SharpOcarina's bugs, namely the ordering problem Arcaith described; can maybe be fixed by rewriting the mesh header...?

 

Yeah, I just tested SharpOcarina and there is a glitch which make Link disappear when confronted to the map faces (which is less glitchy than I expected but I believe that it's a problem hé hé) :

 

1413267481-01.jpg

 

1413267481-02.jpg

Link to comment
Share on other sites

Yeah, I just tested SharpOcarina and there is a glitch which make Link disappear when confronted to the map faces (which is less glitchy than I expected but I believe that it's a problem hé hé) :

Now, after those screenshots and checking SO's source code again, I'm quite sure that this can easily be fixed by reordering the display list addresses in the mesh header.

 


Comparing how SO generates the mesh header with how mesh header type 00 actually works, SO just writes the addresses of all opaque display lists one after the other, followed by all translucent ones, while it really should be "interleaved", with one opaque display list's address first, then a translucent one, then the next opaque one, the next translucent one, etc., etc., to put it simply. How it actually works - to my knowledge - was not known, or at least not documented until I made that post, so SO obviously does it wrong as it predates that post by two years.

 

If anyone wants to take a stab at fixing SO conversions with that information, be my guest! I'd love to see a map generated by SO running properly on hardware... especially after I've been so critical of my own, old project over the last few years, calling it broken, a pain to work with, and so on, as JSA can probably attest to ;)

Link to comment
Share on other sites

Here are the videos, with two maps that I made for test :

 

 

 

The strange thing here is that Link is always visible (but there is still the translucent blocks problem)

 

(Sorry for the gameplay, I had a HIGH latency while recording)

Link to comment
Share on other sites

  • 4 weeks later...

Now, after those screenshots and checking SO's source code again, I'm quite sure that this can easily be fixed by reordering the display list addresses in the mesh header.

 


Comparing how SO generates the mesh header with how mesh header type 00 actually works, SO just writes the addresses of all opaque display lists one after the other, followed by all translucent ones, while it really should be "interleaved", with one opaque display list's address first, then a translucent one, then the next opaque one, the next translucent one, etc., etc., to put it simply. How it actually works - to my knowledge - was not known, or at least not documented until I made that post, so SO obviously does it wrong as it predates that post by two years.

 

If anyone wants to take a stab at fixing SO conversions with that information, be my guest! I'd love to see a map generated by SO running properly on hardware... especially after I've been so critical of my own, old project over the last few years, calling it broken, a pain to work with, and so on, as JSA can probably attest to ;)

I added xDan's code for this into SO if anyone wants to test. Here is the post with the link:

Link

Link to comment
Share on other sites

  • 2 months later...

First off, good to see you around spinout, and still making us all look like armatures to boot.  :P

 

No, zero progress on ZLE3.  The base program should only take a day or two at most to code, but I'm having very serious personal issues these days.  I've been debating what to do with my open projects, but right now I haven't made any decisions.  When I make my mind up, I'll let everyone know.

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

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