xdaniel

Environment settings, header command 0x0F in scenes, do lighting and fog: http://wiki.spinout182.com/w/Maps_and_Scenes#Environments_list

Hm, I guess that looks easy enough... Yeah, I'll see what I can do about replacing Properties.Settings with ex. Nini.

...and that has got to be a rendering bug on your end OR a damaged ROM: What ROM did you use and what video card/chipset do you have?

Well, it might work there, but that doesn't automatically mean that Besitu was once intended for Ganondorf, he was intended to appear in that room, etc. As you say, you got him to work in Lon Lon Ranch, but you wouldn't say he was supposed to appear there, right? And I know that his actors aren't at 0/0/0 exactly, hence me saying "placed around X/Z 0/0" - actor 0x106, Floor of Ganondorf's Room, at X/Y/Z 0/-1000/0, actor 0xE8, Boss Ganondorf, at X/Y/Z -5/0/2. Not sure where you got the Y 10 from btw, SceneNavi shows 0 in an unedited ROM and I'm quite certain it's reading the position out correctly. Anyway, no sense in arguing about this, my opinion is all this with Ganondorf('s room) and Besitu is a coincidence and you have your opinion. Nothing good would come from arguing here, unlike with that hardware-compatible model converter you very much spurred me to work on (still need to improve and release a first build of it)

Don't they just line up because Ganondorf's actors are placed around X/Z 0/0, which is also what many rooms in the game are centered around (Ganondorf's boss room, Besitu, also ex. Chamber of Sages, Fishing Pond, many other interior maps, etc), tho? Still don't think Besitu has anything to do with Ganondorf, or at least nothing we can conclusively prove.

I'm pretty much done with the GLSL combiner for now, just need to double-check my OpenGL extension (and Intel chipset) detection code, as well as look around the net to see if there's maybe a surefire way to detect GLSL support... just housekeeping things, basically. Next up, looking into the additional features again, seeing what's feasible for Beta 9 etc., as well as hopefully finally having a go at improving the actor definition system as per mzxrules' comments and suggestions.

Collision polygons #34 to #39, the floor: As for the room looking like Ganondorf's room... that's kinda subjective. Unless it has ex. vertices that are in the same locations as they are in Ganondorf's room, it's more likely to be coincidence than anything else. Reminds me of how someone, maybe on Glitchkill or Unseen64, said that Besitu looks like Majora's boss room from MM or something.

Watched the first episodes of Seitokai Yakuindomo* and D-Frag! over the last few days, and especially SYD* was already just as great as the first season and the OVAs, really looking forward to more. D-Frag! was quite funny too, so I'll likely be following that as well. Haven't yet watched Chuu2Koi Ren nor any of the other shows, will do so over the next few days.

Just wanted to say, it's really cool to see people actively working on improving Wind Viewer. Sage of Mirrors, Lord Ned, Abahbob, Pho, anyone else - you're awesome.

New valves are mine; cold and warm water main valves got replaced around noon today, because both were old as hell. I'll be sleeping well again tonight! Heh, it isn't, don't worry. I'm not sure if this GLSL stuff will even work right on Intel's junk, or with their junk drivers anyway, so yeah... It's my last try in accommodating Intel users regardless. And if nothing else, it's a good excuse to try and learn something new, at least. And that's sad to hear about your divorce, hope everything's gonna work out for you somehow and you'll feel better soon. As for SceneNavi and the GLSL combiner, I think I've got it working pretty well, for lit and unlit geometry alike. I'm missing some effects that were easily done in the old setup, like automatic texture-coordinate generation for reflections, because now I'll need to implement all of those in the vertex and/or fragment shaders by hand. Not sure if I'm gonna do that, or if that'll be ready by the next build.

Star Fox Adventures, I presume? LZO files I have no idea about, ZLB files have headers as such: ZZZZZZZZ XXXXXXXX UUUUUUUU CCCCCCCC Z - 4 bytes: file tag/magic number (ASCII "ZLB" + null byte) X - 4 bytes: unknown, version number or something? U - 4 bytes: uncompressed length of data C - 4 bytes: compressed length of data [C bytes of compressed data follow, can be decompressed by zlib] Header offsets are taken from the corresponding .tab file, not 100% sure about the .tab format (1st byte of offsets seems to determine if data is compressed?)

On the subject of my leaky valve, plumber's coming tomorrow afternoon, hopefully they can fix or replace that thing quickly. And I have no idea how I manage to stay positive among some of the shit that's been going on in my life, from small to enormous... But there have been times where I wanted to smash something to pieces, although I guess common sense sets in before I actually do it - like "You'll have to replace that, stupid. You really wanna spend XX Euro for five seconds of gratification?" or something On the subject of my GLSL...

Still haven't looked into mzxrules' actor definition comments and improvements. At least this time I've got an excuse for that; don't have cold water in the bathroom since the weekend, water comes gushing out of the main valve for that when opened and drips out even when closed. Haven't slept very well since, haven't slept last night at all, fearing it might break completely (I mean, I sure as hell don't want water damage or something in here!). No toilet flushing, no washing machine, couldn't yet reach house management for them to send a plumber or something over. Anyway, I have worked on SceneNavi a bit earlier, regarding alternative combiner emulation. I've more or less ditched the idea of doing it with glTexEnv (too limited and IMO not very intuitive), so I've started looking into GLSL, which is supposed to be supported on reasonably modern Intel hardware. I'm trying to target the lowest GLSL and OpenGL versions possible (1.10 and 2.0 respectively), too, so that there's a higher chance for this to work on lower-end chipsets. It's still super-early work in progress - in fact, I'm not even parsing the actual combiner setups yet! - but even with some pretty simple "default" shaders, things look... reasonable already (check out the grass!): For comparison purposes, here's the existing ARB_fragment_program combiner: Still, no guarantees this'll work right on Intel GMAs, Intel HD Graphics, etc., I don't have (nor do I want) one of those to test things on.

Might as well apologize publicly to Heavy that I haven't even replied to that last message. Reason being both, that I have not once worked on sound-/music-related stuff in OoT or really any game that I can remember (outside of accidentally corrupting music while trying to find something else in a Digimon WonderSwan game), and that I just forgot to even tell you that - as it's happened to me before, not replying someone because I'd simply forgotten about their message... To anyone who's messaged me or does someday message me: Please don't feel like I ignore you on purpose if you don't get a reply. I'm just dumb as fuck sometimes.

If you're interested in trying that eventually, here's a clearer diagram w/ even the chip's pinout: http://www.trisaster.de/forum/index.php?topic=6243.msg80137#msg80137

.rom, just like ex. .bin, is a super-generic file extension that could be anything, really. Easiest would probably be you open your .rom files in a hex editor and have a look at the bytes I mentioned in my last post, i.e. where the 0x80 bytes are near the start. That should tell you what endianness they have, and thus if they are (meaning, "would usually be named") .v64, .z64 or .n64. .v64 files are ROMs intended for and/or dumped using a Doctor V64 backup unit; .z64 files in turn got their "name" from the Z64 backup unit.

File extensions are quite arbitrary, so they're not a reliable way to detect endianness, although I believe .z64 files should be big-endian, .v64 little-endian and .n64 middle-/mixed-endian. As far as I know: First and ninth byte in ROM are 0x80 = big-endian = .z64 Second and tenth byte in ROM are 0x80 = middle-endian = .n64 Fourth and twelfth byte in ROM are 0x80 = little-endian = .v64 That's how SceneNavi detects which endianness a given ROM has. Also: http://en.wikipedia.org/wiki/Endianness#Examples_of_storing_the_value_0A0B0C0Dh_in_memory (just waiting for someone to point out I read the wikipedia article wrong or something, wouldn't bloody surprise me today...)

Really? I'd actually be interested reading more about that, because all I could find in that regard, is that Japan's NTSC variation uses some signal levels or something from PAL, while everything else in the standard (color encoding, etc.) is pure NTSC. Well, channel frequencies differ from those in the US, too, but apparently that happens all over the world in many forms of broadcasting, like how the Japanese FM radio band ends roughly where ours starts...

All I know is that... Japan never used PAL, so there's no Japanese PAL systems. Regarding cross-region compatibility, NTSC systems only differ in the plastic tabs inside the cartridge slot (remove them to make any NTSC N64 play any NTSC games). While Japan and PAL regions have the same tab configuration, PAL games won't play in a Japanese system and vice versa because of the lockout chips. PAL systems cannot be made region free, IIRC unless you solder in both region's CIC chips - thus "destroying" one NTSC machine in the process - as well as a switch to select between them. Without the aforementioned "dual CIC", PAL N64s can only play NTSC games using an import adapter cartridge, ex. a N64 Passport Plus III. I personally have a PAL N64, a NTSC N64 with the tabs removed, so that it plays Japanese and US games without any adapters, and a Passport Plus III that I used for NTSC games before I got the matching system.

To add to this, you'll still need a small box of collision around the polygons for collision to be the way it should, check ex. all the fences in the game in SceneNavi or so to see what I mean. But for just purely the visible mesh, Sanguinetti's right; backface culling is part of the GeometryMode command 0xD9.