john_smith_account

Sorry I couldn't respond, my life kinda sucks right now. XDaniel's post of the short expalinsion of the fix is about all I've done. I completely understand the problem, and this fix is the best you can do. The UV size *IS* the problem. Anything you did in Sharp Ocarina it's self to fix it would acutally be incorrect. The correct solution, and probably the way nintendo handled it, would be to restain the UV size within the modeling software used to design the levels. That is not an option here obviously, since we didn't design the modeling software we use, and can't modify it. I personally would rather Sharp Ocarina not implament any "cheap" fixes. Following my tip for Google Scetchup, starting any room design at 0,0,0 and then making it a group before moving it works wonders. A little simple math, and a guide line pluggin an I can assure you your design will come out error free 100% of the time. It's not an error in Sharp Ocarina, it's just a limit in the N64 map format. As is the preview funtion lets you see if the error is present. An error warning could be added for building the map, alerting you to the error but allowing you to ingore it if you want. But I can't think of a correct way to fix it in SO. And I'm oppose to an incorrect fix.

I grieve for you XDaniel, I know your pain.... No, seriously, I do. It was around 2009 that we here in the states experienced our own death of the FTA, namely KU Band satalite TV. For us it was Galaxy 18 at 123°W. A majority of the programming worth watching on American Free to Air was provided on this single satelite by the company Equity Broadcasting. When Equity Broadcasting went bankrupt around 2009, a majority of the worth while programming dissappear. Good memories. If not for the crappy movie channel ThisTV, I may never had seen truly awful crap like the cult classic, Mazes and Monsters, a movie warning you of the evils and dangers of pen and paper RPG gaming. True FTA recievers have no future in the US anymore. Sad.

Countdown 10...

I know some of that is from the movie, but I'm pretty sure some of that is Scramble City footage too.

ID Confirmed It's him! Welcome back Dark_Link-77!!! It ain't been the same without you.

DL77, after all this time... Sorry, I don't buy it. Greetings pending ID check, see shoutbox.

I like, very much.

[rant] ENGLISH, SPEAK ENGLISH!!! [/rant] Na, I'm just kidding. It's just fun to act angry over stuff like that some times.

Well this is an alpha release. Reading further up in this very post will get you all the info you need right now. I'll put together a decent readme later. For now the scene # is in the file name. 51_Cutscene_00.txt Is scene 0x51, hyrule field. Cutscene is 0. Use the scene list from ZLE/ZLE2/ZAP2 or the wiki to find out which scene is which.

Thank you Sanguinett. Your expectations might be a little high compared to the current quality of this tool... http://www.mediafire...784ths2f8vqcvld It's a start though. !IMPORTANT! READ BEFORE USING DO NOT REMOVE OR ALTER THE HEADER LINE: 'Header Command @ You can add/remove/alter any commented out line EXCEPT this one. I know it's commented out, but the program currently uses it to identify cutscene files. I'll fix it in a later release. The address supplied in this line is were the cutscene data will be written to. Other than that the tool is very dumb. All it does is check for the address at the start of the .txt file, and write whatever data it finds in the .txt file to the ROM supplied in the romname.ini. Still it's very useful, the .txt files produced by the discombobulator: .Breaks the data down in a much easier to read format than trying to work this stuff up in a Hex editor. .Allows you to add comment lines by proceeding them with ' .Comments aids in directly mapping out cutscene data .It allows for easy cut and paste of lines from other cutscenes .You can use Demo Camera to make all new camera data you can simply cut and paste in Rest is up to you right now. Comments welcome. More later.

I wasn't expecting a response that fast! I'll get it zipped up and posted.

Here's a simple demo of what this tool can do. If someone would upload a youtube video of the patch below in action, then I I'll release the tool. http://www.mediafire...f8vi401dap7p4m2 1. Apply the .pff patch(yeah, yeah I know we're not suppose to be using .ppf anymore but, I didn't have the time to find the new patching tool) 2. Run Cutscene 01 of Hyrule Field. I could have gotten the cutscene a little more polished, but I didn't see the point. It shows that you can edit existing cutscenes with minimal effort. The tool is nothing fancy. Also, I could use some feedback on how best to break down cutscene listings for the easiest editing.

It's a little better than that. Zelda64 Cutscene Discombobulator is done. It can now both dump and label cutscene data, and reinsert modified cutscenes. I plan on releasing it after I finish a demo cutscene. I'll want feed back on how to break down the data for easiest editing. Ok, I know I'm getting lazy(er) but can anyone give me a formula or some pseudocode to calculate this?

Ive got a cutscene tool worked up now. It dumps the cutscene into an easier to edit format: I've paired it with a tool to reinsert modified cutscenes. Right now I'm working on a modified cutscene to show off what it can do. I'll release the tool after that.

OK, my seizure induced by this vid just ended. I thought it was funny.

More "commands' as promised. Found it while working on ZB2. End Cutscene (drop back to normal gameplay?) 00 00 00 03 00 00 00 EE 00 0C xxxx yyyy EE:Number of listings xxxx : Ending Frame yyyy: Ending Frame repeated Light source? 00 00 00 04 00 00 00 EE I didn't bring my notes on 04 "actors" with me, but it does seem to create an actor which effects lighting. Which brings me to an important development. Most unknowns fit within the Cutscene actor format of 00 00 00 AA 00 00 00 EE where AA : Actor Number EE: Number of listings So, I've made a tool that pulls cutscenes apart. The working title is Zelda64 Cutscene Discombobulator in honor of the Super Mario Brothers 2 level editing tool. Here's a sample of what it does so far: 'Header Command @ 8DA0 0000001000000BB8 'Actor # 15 @ 8DA8 0000001500000001 000100000BB8000000000000000000000000000FFFFFFFDE000000000000000FFFFFFFDE000000000000000000000000 'Actor # A @ 8DE0 0000000A00000001 000500000BB80000560B000000000B2900000000FFFFFDAE00000B2900000000FFFFFDAE000000000000000000000001 'Cutscene Exit @ 8E18 000003E80000000100010235023F023F 'Camera Position @ 8E28 000000010001000004430000 00000000427000000ADF00DBFE2C00FA 00000000427000000ADF00DBFE2C0000 00000000427000000ADF00DBFE2C0000 00000000427000000ADF00DBFE2C0000 FF000000427000000ADF00DBFE2CF050 'Camera Position @ 8E84 000000010001008205880000 00000000427000000ADF00DBFE2C9748 00000000427000000ADF00DBFE2C2A90 00000000427000000ADF00DBFE2C65F0 00000000427000000A600056FE803FAA 00000000424BFFF70A0D002FFEC70000 000000004237FFF20A0D002FFEC7FFFF 000000004237FFF20A0D002FFEC70000 000000004237FFF20A0D002FFEC73C18 FF0000004237FFF20A0D002FFEC741DC 'Camera Position @ 8F20 000000010001017C09890000 00000000427000000B68003AFD8F9748 00000000427000000B68003AFD8F2A90 00000000427000000B68003AFD8F65F0 00000000427000000B68003AFD8F3FAA FF000000427000000B68003AFD8F0000 'Camera Position @ 8F7C 00000001000101C206D70000 00000000427000000A8F0028FE899748 000000004235998B0A8F0028FE892A90 000000004235998B0A8F0028FE8965F0 000000004235998B0B6E002FFDF43FAA 000000004235998B0D09003EFCE10000 000000004235998B0EDA000AFBAAFFFF 0000000041A4CC7E0EDA000AFBAA0000 FF00000041A4CC7E0EDA000AFBAA3C18 'Camera Rotation @ 9008 000000020001000004600000 0000001E427000000B100081FDEE9748 0000001E427000000B100081FDEE2A90 000003E8427000000B100081FDEE65F0 0000001E427000000B100081FDEE3FAA FF00001E427000000B100081FDEE0000 'Camera Rotation @ 9064 000000020001008205A50000 0000002D427000000B100081FDEE9748 0000002D427000000B100081FDEE2A90 0000002D427000000B0F0081FDEF65F0 0000002D425E66620AB80056FE413FAA 0000002D4237FFF20A66003DFE870000 0000001E4237FFF20A66003CFE87FFFF 000003E84237FFF20A66003CFE870000 0000001E4237FFF20A65003CFE883C18 FF00001E4237FFF20A65003CFE8841DC 'Camera Rotation @ 9100 000000020001017C099C0000 0000001E427000000B09000EFDBB9748 0000001E427000000B09000EFDBB2A90 000003E8427000000B09000EFDBB65F0 000003E8427000000B09000EFDBB3FAA FF000014427000000B09000EFDBB0000 'Camera Rotation @ 915C 00000002000101C206F40000 0000001E4235998B0AEC0035FE489748 0000001E4235998B0AEC0035FE482A90 000000464235998B0AEC0035FE4965F0 00000046420D99810BCB0036FDB63FAA 0000004641DCCC8C0D66003AFCA30000 000003E841A666180F35FFF4FB6EFFFF 0000001E41A4CC7E0F33FFF6FB6F0000 FF00001E41A4CC7E0F32FFF7FB703C18 'Actor # 2E @ 91E8 0000002E00000001 000100000A6C00000000000000000000FFFFFFC00000003500000000FFFFFFC000000035000000000000000000000000 'Actor # 3E @ 9220 0000003E00000003 00010000000300000000000000000B1F0000012CFFFFFDB700000B1F0000012CFFFFFDB7000000000000000000000000 00040003004900000000000000000B1F0000012CFFFFFDB700000B1F0000002DFFFFFDB700000000C069249200000000 000400490BB800000000000000000B1F0000002DFFFFFDB700000B1F0000002DFFFFFDB7000000000000000000000000 'Text Command @ 92B8 0000001300000008 FFFF00000064FFFFFFFFFFFF 1024006400780000FFFFFFFF FFFF00780118FFFFFFFFFFFF 1091011801720000FFFFFFFF FFFF01720186FFFFFFFFFFFF 1092018601B80001FFFF1026 FFFF01B801C7FFFFFFFFFFFF 102701C702210000FFFFFFFF 'Actor # 56 @ 9320 0000005600000001 004C00B400B5000000000000000000000000001D0000009F000000000000001D0000009F000000000000000000000000 'Actor # 57 @ 9358 0000005700000001 004C00000001000000000000FFFFFF990000000000000070FFFFFF990000000000000070000000000000000000000000 'End of Cutscene Marker @ 9390 FFFFFFFF Everything so far works like an actor, or is one of the known commands like camera, text, exit, ect. If we use the debug camera for easy replacement of camera sequences, and someone posts the information actor animations again, total customized cutscenes will be possible. Maybe even simple.

Woah, I didn't know this topic was here! I think I can lend a hand. I don't know what method you're using to test this stuff, but I can tell you how I've been doing it. I'll also say mapping out of more cutscene camera data may be a waste of time. But more on that later in the post. First... First off, I got the wiki version of this posting, and the 01 camera data got me going in the right direction. That said, I think your 00000002 information is incorrect. following that: ww00 [????] [????????] [xxxxyyyyzzzz] [????] ww = ? FF on last entry xxxx = x position yyyy = y position zzzz = z position The camera will look towards the coordinates specified. I don't think X,Y,Z is camera position, I think it's camera rotation. Camera data appears to be paired off into 2 sections, 1 for coordinates(00000001), and 1 for rotation(00000002). It's a lot less obvious in the in game cutscenes, but is more dirrectly observed in cutscenes recorded and saved with the Demo Camera. The pairings get VERY messy in the in game cutscenes though since the data is split up, and the frames for camera position can be completely independent from the frames for camera rotation. That and the rotation data doesn't translate directly, it's something along the lines of +4 for every degree of rotation. Worse yet the number is signed. Here's my method for mapping. Method: Nothing special, but I've been using Demo Camera sequences to test with. I make a sequence, and save it to the memory card plugged into controller 3. I open the memory card file in hex editor, and examine the recorded sequence. If you follow the Debug ROM guide(is it still around?) you can follow all the advanced camera tricks, and map out the values. But like I said, mapping of all cutscene camera data may not even be necessary. For the purposes of Zelda's Birthday 2, I plan on recording my cutscenes in demo camera, and inserting them over the camera data of existing scenes. So I'd be less concerned with the camera, and concentrate more on the other "commands" There may be more to replacing existing camera in cutscene data than just simple cut and paste. Since as I said the camera position, and rotation do not appear as 1-for-1 listing within the in game scenes. Some null or do nothing filler "commands" could make up the difference in inserting different camera data into existing cutscenes. I've found another "command" which I'll post later. Other than that, I don't have much to add yet.

I'm too old school to give useful input. That said, unless you're selling something, or just want to show off I've always liked the clean look,

Not true! I've been pestering you on IRC for days now. Are you ever on by the way? And XDaniel I pester on every release of Sharp Ocarina, but I promise to be better in the future about that.

I figured out what I was doing wrong. Anyone you're getting UV errors, or making simple maps just to avoid errors might try this: http://core.the-gcn.com/topic/675-sharpocarina-zelda-oot-scene-development-system/page__pid__19041__st__300#entry19041

And, proper technique solves all my UV errors so far! The UV errors I was getting seem to be avoidable in Sketchup by following some simple rules in modeling. You can even fix old maps. Mind you it is harder to fix a map after the fact, but it's still not that hard to do. Here's my new method for modeling in SketchUp: 1. Make a rectangle at the 0,0,0 axis. 2. Make the rectangle a group. 3. If you're making a dungeon or other multiple map scene, move the rectangle(group) to were you wish to start modeling a room. Why does it work? My guess is that UV's, and maybe coordinates with the groups are relative to where the selected polygons were initially made into a group. I really haven't tested enough to know for sure though. I based this method entirely on observing how OZMAV handled dumping maps from the game to .obj format. Forgive me if this should have been obvious, and correct me if I'm wrong in any points. If this proves out, I'll refine the method and post it in the modeling tips topic.

RETRACTION Ok, I'm eating my words here. Though a cheap UV fix would be helpful for ease of use, I'm starting to think it isn't work the effort of coding... It might be good for newcomers, but... I may have a fix allready, so... I'm sorry for the trouble. *walks away quietly*

It's a different problem than the UV's simply being too large. That was the entire point of my post. The errors in my maps seems to be cause by polygons crossing UV boundaries, as described above. PLACEHOLDER: *Sigh*, fine I'll be back with solid data. Guess I need an example. http://www.2shared.c...mF5Y/ERROR.html Sorry about the crappy file host, I'm on the library's WIFI. I'll start with an error free entry from the OBJ. You'll notice I repeated the same texture UV's a few times to prove the error isn't in the UV size. To really drive the point home, I made a somewhat ridiculus mapping on the first poly. All examples were prepared using TIG's exporter with the x1000 modification. You can find it at the start of the Map Modeling Tips Topic. g ERROR_Main-BIG1 usemtl BIG1 v 1000.0 0.0 1000.0 v 0.0 0.0 0.0 v 0.0 0.0 1000.0 v 1000.0 0.0 0.0 vn 0.000000 1.000000 0.000000 vn 0.000000 1.000000 0.000000 vn 0.000000 1.000000 0.000000 vn 0.000000 1.000000 0.000000 vt 1.000000 -1.000000 vt 0.000000 0.000000 vt 0.000000 -1.000000 vt 1.000000 0.000000 f 122/122/122 123/123/123 124/124/124 f 123/123/123 122/122/122 125/125/125 Now I may not have this exactly right, but UV's get multiplied up to values the N64 can use. So Sharp Ocarina's numbers will be something like: vt 10,000 -10,000 vt 0 0 vt 0 -10,000 vt 10,000 0 You can open the SketchUp file and see it for yourself HUGE UV's no errors. Now my math my be off, but you should be able to see what I'm getting at. The UV mappings only have a 16-bit signed range(-32768 to 32767). After that, they "wrap around" back to -32768 (or is it 0?, Xdaniel a little help.) The type of "random" errors I was getting was not from the UV mapping being too big, it was because it crossed the wrap around. As showen with the mapping for material BIG1, you can have large mappings without errors. If I'm correct, any mapping has values that cross 32767, 98302, 163837 and -32767, -98302, -163837 will get errors. That is you're fine as long as you start and finish your mapping within these ranges, but even a modest UV mapping will get messed by starting on one side, and connected to the other side of these bounderies. Now, let get right to errors. I'm not going to bother working the math on the UV's. I don't understand the conversion really, but I'm sure I understand the problem. If I'm in error on any point, feel free to correct me. g ERROR_Main-ERROR3 usemtl ERROR3 vt 10.000000 -100.000000 vt 0.000000 -90.000000 vt 0.000000 -100.000000 vt 10.000000 -90.000000 g ERROR_Main-ERROR2 usemtl ERROR2 vt 96.000000 -20.000000 vt 95.000000 -10.000000 vt 95.000000 -20.000000 vt 96.000000 -10.000000 g ERROR_Main-ERROR1 usemtl ERROR1 vt 91.000000 -10.000000 vt 90.000000 0.000000 vt 90.000000 -10.000000 vt 100.000000 0.000000 vt 92.000000 -10.000000 vt 93.000000 -10.000000 vt 94.000000 -10.000000 vt 95.000000 -10.000000 vt 96.000000 -10.000000 vt 97.000000 -10.000000 vt 98.000000 -10.000000 vt 99.000000 -10.000000 vt 100.000000 -10.000000 I'd really have to know more about UV's and SharpOcarina to be any more help. Sorry. Xdaniel, good luck.

I believe I've found the problem in my maps. I'm posting this publicly on the hopes that if I'm not clear, at least someone might get the jest of what I'm saying. The first(may not be the only) problem is related. It is related to the overflow, but it's probably not what you think it is. I do understand it thoroughly, but may not be able to explain it clearly based on my limited understanding of how you correct the values outside the n64's UV range within SO. Here's my educated guess based on testing. The problem I'm getting isn't from a texture scaled too large, it has to do with the starting and ending ranges of the UV values on a given vertex. Here's what happens. SO seems to somehow correct the values outside the 16-bit signed range(-32768 to 32767). So you can have a vertex with crazy UV's like 120,000,112,000 or similar, and the gets corrected just fine. The problem only seems to occur when you have a vertex that starts within the valid range16-bit range (-32768 to 32767) connected to a vertex(forming a poly) with a corrected(wrapped around?) value. Totally made up numbers but to try to convey the point a poly formed with vertexes having the UV's: 120,000,112,000 and 120,000,112,000 and 110,000,112,000 but a poly with: 30,000 , 30,000 and 30,000 , 30,000 and 33,000 , 33,000 Since it starts in one range, and crosses the wrap around. Yes my UV numbers in the example ARE BS, but I'm just trying to make the point that connected UV values across the "wrap around" value is the definite cause of errors in my maps. (Using TIG's exporter anyways.) Irony: I can't think of an automated solution. It's more a matter of incompatibility between n64's 16-bit mapping and .obj's "infinite?" UV value. It may be better handled by rewriting the .OBJ exporter than adding a fix in SO, I dunno. Conceivably, you could have a check system that catches poly UV's that criss-cross the boundaries by bring the start and finish into a valid range. That is, like in the above example: 30,000 , 30,000 and 30,000 , 33,000 and 33,000 , 33,000 Subtract the lowest value eliminating the crossing of the wrap around: 0 , 0 and 0 , 3,000 and 3,000 , 3,000 It will appear much more neat on looking in game than the wrap around error. At least the UV scaling will be correct. It will work very well on repeating patterns. But it's not technically correct since it won't preserve the the actual UV staring and ending values. Not to mention it will require coding, and may be a hassle for a "fun" project. Still it's a possible solution. If you implement it, may I subject it be added with a option check box. Something along the lines of "Apply wrap around fix"? Then again, maybe I'm the only one getting this error. If you need some real examples, just need me to re-explain the issue, or just think I'm wrong let me know.

Updated my first post on topic to reflect changes in my modeling technique.