xdaniel's Random Junk

[Arcaith]

This really shows how far custom maps have come, given that this was all done with the importer :3

[xdaniel]

First of all, that might be a bit difficult, Naxy... I mean, we're living thousands of kilometers apart from each other! XD

 

Second, it's still awhile off, but...

 

 

...it's got a proper name now! And it's an instrument so sharp, it can cut you! ...and yes, that was a lame pun. And the description is unwieldy and overblown, but what the hell.

 

Anyway, before the release there's still some stuff to do, mainly implementing collision types and related information, plus documentation for all the options and settings as well as a little tutorial. Some stuff I've been tinkering with, multi-texturing for one (can sorta make it display two textures mixed ala Hyrule Field's grass, but can't actually load the second texture properly ), I will look into adding at a later date. But yeah, once the things I mentioned are done, there should be no reason to not release a first - for the moment source-less, public testing - build. The second build will have the full source with it and/or it will be posted to a SVN http://core.the-gcn.com/public/style_emoticons/default/thumbsup.gif

[Arcaith]

You are a legend :3 Can you squeeze in texture tiling settings? Pretty please? :3

[xdaniel]

  On 8/23/2011 at 1:18 PM, Arcaith said:

You are a legend :3 Can you squeeze in texture tiling settings? Pretty please? :3

 

Oh, right, almost forgot about that... Per-group setting of clamp/wrap/mirroring will be easy to do, I suppose, that's good? Also, I'm not a legend, and even if I was, I wouldn't be one without everyone who came before me http://core.the-gcn.com/public/style_emoticons/default/thumbsup.gif

[Arcaith]

Yeah, per group works :3

[xdaniel]

 

Ironically, getting the preview to display clamping and mirroring correctly was more difficult than implementing it into the actual conversion. But hey, at least I got to remove some redundancy in the preview rendering in the process...

[Secant]

  On 8/23/2011 at 1:06 PM, xdaniel said:

First of all, that might be a bit difficult, Naxy... I mean, we're living thousands of kilometers apart from each other! XD

http://www.youtube.c...etailpage#t=18s

 

  On 8/23/2011 at 1:06 PM, xdaniel said:

But yeah, once the things I mentioned are done, there should be no reason to not release a first - for the moment source-less, public testing - build. The second build will have the full source with it and/or it will be posted to a SVN

I look forward to implementing Cabin Maze once again with actors without it being such a pain in the ass. \o/

 

Also, just for the record, I think Zeth forgot to mention I was the one who built the field map--mainly for the purposes of testing moving water textures in custom maps--so if you want to give credit to whoever built the map in the about window, that would be me.

 

Also, mirroring/tiling editing. My face basically melted. That will be extremely useful for SketchUp users, since its texture placement utilities are somewhat limited.

[xdaniel]

  On 8/23/2011 at 3:28 PM, Naxylldritt said:

http://www.youtube.c...etailpage#t=18s

 

Maybe you're right, because for one, it's actually only ~1500km between here and Helsinki...

 

  On 8/23/2011 at 3:28 PM, Naxylldritt said:

Also, just for the record, I think Zeth forgot to mention I was the one who built the field map--mainly for the purposes of testing moving water textures in custom maps--so if you want to give credit to whoever built the map in the about window, that would be me.

 

I think he might've mentioned, but I forgot... well, changed it~

 

Anyway, I'll be taking a break from working on this for today, as there's still some real-life stuff to do (you know, grocery shopping and the works).

[Arcaith]

Sweeeeeet :3

[Malqua]

Naxy, does that mean I'll have to do another speed run? http://core.the-gcn.com/public/style_emoticons/default/thumbsup.gif

[xdaniel]

 

 

Very rudimentary, as mentioned in the video description, but it works~

[SanguinettiMods]

xdan, I have an Idea before you release it, Would you be able to make it add "Area Title Overlays", and "Corner Maps"?

[BlackRose]

I'm in total awe xdan. It's literally awesome!

[xdaniel]

SanguinettiMods: While, I believe, I do know how the area title display works, I have no idea about on-screen maps (or the start menu map stuff, while we're at it). Also, while surely needed in a complete mod, I don't think those are too important for this initial release - I guess I will look into those eventually, but for now, sorry.

 

Also, before I (hopefully http://core.the-gcn.com/public/style_emoticons/default/thumbsup.gif) will go to bed for tonight...

 

 

I think all that's left for now before release #1 is adding support for editing the scene's exit list and getting a bit of documentation written. That said, Arcaith, mind if I bundle your test dungeon with the program as some kinda "demonstation material", so that users can see how stuff is done by means of a working project?

[Secant]

The one final detail that's nagged me about custom maps is now finally fixed.

 

...Dammit, languages, why don't you have words that adequately describe the epic that is this program? ;-;

[Arcaith]

Yeah, bundling the map is fine, I made it as a test map, so I'll be glad to see it being used as such

[Zeth Ryder]

What about texture animation? Has this fully been figured out yet? As far as I know, it does have to with partially the Scene table, DE commands, and something to do with the actual scene(which I still have not pinpointed yet)

[spinout]

Well gee it looks like I won't have to write a new map importer - which is probably a good thing, considering how much GUIs and I disagree. I do plan, however, to make a command line tool which will attempt to do an identical import based the generated XML from this application so that *nix people can at least import areas which have been configured with this tool. It would also be rather neat to streamline this stuff in makefiles. As always, excellent work xdaniel.

[xdaniel]

Arcaith: Alright, will add it to the package then, thanks!

 

Zeth: Yeah, I had looked into that as well, and it seems that the RAM segment setup (for those 0xDE DList calls to ex. segment 0x08) is done via assembly, according to a table at 0xBA1544 (ROM) / 0x10D544 (code). Here's my notes of that, maybe someone with MIPS knowledge like spinout or DeathBasket can figure out more?

 

 

  Reveal hidden contents

ROM:BA1498/CODE:10D498 <- texture segment table whatever thingy

 

0200BA18 <- inside deku tree entrance DAY 08

0200CA18 <- inside deku tree entrance NIGHT 08

02012378 <- dodongo entrance DAY 08

02013378 <- dodongo entrance NIGHT 08

02011F78 <- dodongo main hall lava 1 09

02014778 <- dodongo main hall lava 2 09

02014378 <- dodongo main hall lava 3 09

02013F78 <- dodongo main hall lava 4 09

02014B78 <- dodongo main hall lava 5 09

02013B78 <- dodongo main hall lava 6 09

02012F78 <- dodongo main hall lava 7 09

02012B78 <- dodongo main hall lava 8 09

0200BD20 <- thieves hideout ent DAY 08

0200B920 <- thieves hideout ent NIGHT 08

02014C30 <- water temple ent DAY 06

02015830 <- water temple ent NIGHT 06

0200FAC0 <- ice cavern ent DAY 08

0200F8C0 <- ice cavern ent NIGHT 08

0200F8C0 <- gerudo training ent DAY 08

020100C0 <- gerudo training ent NIGHT 08

02005210 <- lon lon barn light DAY 08

02005010 <- lon lon barn light NIGHT 08

02006550 <- lots'o pots left DAY 09

02003550 <- lots'o pots left NIGHT 09

02002350 <- lots'o pots right DAY 08

02001350 <- lots'o pots right NIGHT 08

02014D90 <- forest temple ent DAY 08

02014590 <- forest temple ent NIGHT 08

02018920 <- spirit temple ent DAY 08

02018020 <- spirit temple ent NIGHT 08

02015B50 <- kakariko windows DAY 08

02016B50 <- kakariko windows NIGHT 08

02008F98 <- zoras domain ent DAY 08

02008FD8 <- zoras domain ent NIGHT 08

02009678 <- gerudo fortress cell DAY 08

0200DE78 <- gerudo fortress cell NIGHT 08

02009808 <- goron city ent DAY 08

02008FC8 <- goron city ent NIGHT 08

020081E0 <- lon lon windows DAY 08

0200FBE0 <- lon lon windows NIGHT 08

 

SCENE 0, ydan_scene -> invalid texture address! 08000000 !

SCENE 1, ddan_scene -> invalid texture address! 09000000 !

SCENE 1, ddan_scene -> invalid texture address! 08000000 !

SCENE 3, Bmori1_scene -> invalid texture address! 08000000 !

SCENE 5, MIZUsin_scene -> invalid texture address! 06000000 !

SCENE 6, jyasinzou_scene -> invalid texture address! 08000000 !

SCENE 9, ice_doukutu_scene -> invalid texture address! 08000000 !

SCENE 11, men_scene -> invalid texture address! 08000000 !

SCENE 12, gerudoway_scene -> invalid texture address! 08000000 !

SCENE 76, souko_scene -> invalid texture address! 08000000 !

SCENE 77, miharigoya_scene -> invalid texture address! 09000000 !

SCENE 77, miharigoya_scene -> invalid texture address! 08000000 !

SCENE 82, spot01_scene -> invalid texture address! 08000000 !

SCENE 88, spot07_scene -> invalid texture address! 08000000 !

SCENE 93, spot12_scene -> invalid texture address! 08000000 !

SCENE 98, spot18_scene -> invalid texture address! 08000000 !

SCENE 99, spot20_scene -> invalid texture address! 08000000 !

 

 

  Reveal hidden contents

scene header^(*)!

11111111 22222222 33333333 44444444 ffffffff

 

1=vstart, 2=vend, 3=pstart, 4=pend

f=FLAGS!?

 

aabbccdd

aa==???

bb==segment setup thingys

cc==???

dd==???

 

segment setup table @ ROM:ba1544, CODE:10d544

- 4 bytes per entry, ram address

- entry 1:default, 2:hyrule field, 3:kakariko, etc

--order according to scene header^(*) segment flag

ram address holds mips code; ex. creates db0600xx command for segment setup

 

(* "scene header" should be "scene table", my fault from when I wrote this originally, the rest should be correct tho...)

 

spinout: Dunno if it would help, seeing how it's in C#, but would an "advance copy" of the source help you with writing a command line importer for my scene XMLs? As mentioned, I want to release the source anyway, but only after the first release and in turn implementing whatever (reasonable) ideas, requests and bugfixes people have.

 

Also, more on-topic stuff, a preview of the incomplete documentation:

 

 

  Reveal hidden contents

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

SharpOcarina v0.1 - Zelda OoT Scene Development System

Written in 2011 by xdaniel

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

 

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

0) Table of Contents

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

1) System Requirements

2) User Interface

a) Menus

General Scene Data

c) Transitions & Spawns

d) Collision & Exits

e) Rooms & Group Settings

f) Objects & Actors

3) FAQ

4) Credits & Thanks

 

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

1) System Requirements

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

...are modest. No, really, it should run on pretty much every kinda Windows PC out there. Unlike SayakaGL

or OZMAV2, it doesn't require any fancy shader extensions and such (yet?) and thus the rendering of the

scene preview should be glitch-free on anything that's reasonably modern. What it -does- require is the most

recent version of Microsoft's .NET Framework 4, which, in case you haven't installed it yet, can be found in

their download center.

 

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

2) User Interface

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

The GUI might be a bit intimidating at first, with all the options and stuff it has, but it's bound to become

second nature once you've used it for awhile. There's some quirks to the interface, though. For instance, with

most text boxes you have to press -Enter- after entering your offset, actor number, what have you. If you don't

do this, your changes will not be committed to the scene. Also, outside of camera movement, there is no mouse

control in the 3D preview at all, so you cannot ex. select and drag actors with the mouse.

 

a) Menus

--------

| File |

- New Scene: Creates a new, mostly empty scene. It does automatically add environment settings for all basic

occasions (all times, normal, underwater, rainy), a spawn point for Link at coordinates 0/0/0

and a simple ground collision type.

- Open Scene: Opens a previously saved scene XML and loads all associated data (model files, etc.).

- Save Scene: Saves the current scene to an XML file.

- Save Binary: Asks for a target directory, converts the current scene into separate scene and room files and

saves them to the selected directory.

- Inject to ROM: Converts the current scene and injects it into the given ROM. Remember to set the proper

injection offsets for the scene and each room! Also remember that this -does not- check if

it's overwriting existing data in the ROM!

- Exit: Self-explanatory, I hope.

 

| Options |

- Show Collision Model: When checked, you'll get a transparent red rendering of the collision model overlayed

on top of the room models.

- Show Room Models: The room models will only be rendered when this is checked. Might be useful to uncheck if

you want to look at just the collision.

- Apply Environment Lighting: Gives a very rough representation of lighting when checked, by far not akin to

how it will look in-game. Just leave it off.

- Consecutive Room Injection: When this is checked, in a multi-room scene, you won't need to specify injection

offsets for any subsequent rooms beyond the first. They will simply be injected

right after the previous one. Although, just like the ROM injection function in

general, this -does not- check if it overwrites any existing data.

 

| Help |

- About...: Take a wild guess.

 

General Scene Data

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

On the "Scene (General)" tab, you'll find several, but not all, settings that are global to the scene, like its

scale or music values. You also select the collision model here.

 

- Name: Specifies the name of the scene. Currently, that's only used for the scene XML's default filename and

those of the separate scene and room files created using the "Save Binary" menu option.

- Scale: Sets the scale at which the models (both collision and rooms) will be imported, in case you need to

change this.

- BGM: Lets the user set which BGM track (in decimal) the scene will play in-game; defaults to Hyrule Field.

 

- Injection Offset: Set the offset (in hexadecimal) at which the scene will be injected to in the ROM when

using the "Inject to ROM" function. Make sure you know about what's where in your ROM,

because this program doesn't and blindly assumes that you do!

- Scene Number: Select which scene number your imported scene will overwrite; defaults to 108, which is Sasatest.

 

- Outdoor Scene (Skybox, Lighting): Checking this will result in the scene being treated as an outdoor area, so

that it will have a skybox, environment-based lighting and normal day-night

cycle. Uncheck this and it will be treated as an indoor scene, like houses or

dungeons, which don't have skyboxes, time-flow, etc.

- Collision Model: This is where you select your collision model file. This program expects a model file separate

from your rooms' so that you can have things like invisible walls to prevent the player from

going out-of-bounds and such. Note that the group names in this file -have to match up- with

those in your room files, otherwise collision polygon type settings won't work correctly. A

design flaw on my part, so please bear with this kludge for now.

 

| Waterboxes |

This set of controls allows you to add, edit and remove waterboxes from the scene. When adding a new waterbox,

by default it extends across the whole scene, but you can shrink and reposition it any way you like. For the

properties (hexadecimal), please consult the z64 wiki and/or just experiment.

 

| Environment Settings |

Similar to the waterbox editor, this set of controls allows adding, editing and deleting of environment settings,

which control lighting, fog and draw distance. Double-click on one of the colored boxes to open the color picker

dialog, from which you can change the respective color. Fog and draw distance are hexadecimal values, which are

very sensitive to change, so if you want to change them, do so a few bytes at a time.

Please note that, depending on the type of scene (outdoors, indoors), the game expects a certain amount of

environment settings. If you've ever seen the game glitch with weird lighting and/or broken Z-buffer ordering,

that's the result of invalid environment data.

 

c) Transitions & Spawns

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

... ... ...

 

Also also, I probably won't get to doing much work on this over the weekend, since I'll be visiting my family and won't be back until either Saturday or Sunday afternoon. Maybe I'll get this done by Sunday evening or so, although don't take this as a release date or any nonsense like that

[Arcaith]

Collaboration is an important part of progress; you guys should look over each others' work and fill in as many gaps as you can. That way we collectively have highly functional pieces of software. I think that's about the best I can offer regarding programming stuff these days ;

[DeathBasket]

From what I can tell the 'bb' you mention in the flags entry of the scene table is used as an index for a list of addresses at 0x8012A3A4 in RAM. The addresses are then loaded and jumped to and the code there decides which textures to load. I haven't looked at it in much detail but the Deku Tree's entry (0x13) will check whether it's day or night (word at 8015E670) and then use that information to load the right texture for the entrance. The lava in Dodongo's Cavern changes texture every two frames (I think), based on a counter at 80223E04.

We could make use of this by changing the texture pointers but it doesn't look like we can do much else at the moment without having to write an assembly hack for it.

[spinout]

  On 8/25/2011 at 2:33 PM, DeathBasket said:

From what I can tell the 'bb' you mention in the flags entry of the scene table is used as an index for a list of addresses at 0x8012A3A4 in RAM. The addresses are then loaded and jumped to and the code there decides which textures to load. I haven't looked at it in much detail but the Deku Tree's entry (0x13) will check whether it's day or night (word at 8015E670) and then use that information to load the right texture for the entrance. The lava in Dodongo's Cavern changes texture every two frames (I think), based on a counter at 80223E04.

We could make use of this by changing the texture pointers but it doesn't look like we can do much else at the moment without having to write an assembly hack for it.

 

Well, that sounds like a perfect opportunity to introduce an extension of the scene/map header format - something, for example, which uses the unused bytes of, lets say, the mesh header command - 0Azzzzzz xxxxxxxx - z is normally 0, but in this case, a hack could assume that if it is nonzero that it is to use the bank of x ((x & 0xFF0000000) | z) - and at that point is a simple and extendable bytecode (which SharpOcarina would write) which an interpreter reads to do these custom textures. Games without these hacks would still function perfectly fine, as the game normally ignores the 'z' bytes. I'm sure DeathBasket and/or myself could throw something together.

[xdaniel]

  On 8/25/2011 at 5:20 PM, spinout said:

Well, that sounds like a perfect opportunity to introduce an extension of the scene/map header format - something, for example, which uses the unused bytes of, lets say, the mesh header command - 0Azzzzzz xxxxxxxx - z is normally 0, but in this case, a hack could assume that if it is nonzero that it is to use the bank of x ((x & 0xFF0000000) | z) - and at that point is a simple and extendable bytecode (which SharpOcarina would write) which an interpreter reads to do these custom textures. Games without these hacks would still function perfectly fine, as the game normally ignores the 'z' bytes. I'm sure DeathBasket and/or myself could throw something together.

 

Now that's an interesting idea. If you can get something like this going, I'd gladly add support for it in the program. The bytecode interpreter could allow one to set up a RAM segment that reflects the current texture for the animation, ex. taken from a number of consecutive textures in the current scene file, plus the animation speed, and instead of pointing to a single texture inside room or scene, the surface's SETTIMG command would point to that RAM segment. I'm also wondering if this could allow ex. something like Jabu-Jabu's wobbly walls (unless we know how they work...?).

 

(Meh, hope this made sense and wasn't redundant, I'm tired and about to go to bed ^^")

[spinout]

  On 8/25/2011 at 10:12 PM, xdaniel said:

 

Now that's an interesting idea. If you can get something like this going, I'd gladly add support for it in the program. The bytecode interpreter could allow one to set up a RAM segment that reflects the current texture for the animation, ex. taken from a number of consecutive textures in the current scene file, plus the animation speed, and instead of pointing to a single texture inside room or scene, the surface's SETTIMG command would point to that RAM segment. I'm also wondering if this could allow ex. something like Jabu-Jabu's wobbly walls (unless we know how they work...?).

 

(Meh, hope this made sense and wasn't redundant, I'm tired and about to go to bed ^^")

 

I wrote an entire bytecode interpreter and was writing some example code before I realized it was an oversimplified and limited MIPS. I then removed everything related to bytecode and ended up with this. As far as animating textures goes, switching textures is largely inefficient but having an image that is, say, two rows too tall and increasing the pointer by four bytes every xth frame and then at the end of the image going back to the beginning would produce a scrolling texture without very much overhead. The called functions (in the example I linked to, nested as an extension of the mesh command) would be nested in the map file. It would be up to the users to generate a binary for your program to insert, and you could also have a few 'configurable' binaries (ex: lights going on/off at certain times, scrolling water) included in SharpOcarina.

[Arcaith]

Having provision for the preset changing textures would be of great use. In any case, the more we implement, the better :3