xdaniel

Changelog for Beta 6 so far: Fixes to Ucode interpreter to not reset certain parameters on display list calls (DL, BRANCH_Z); fixes missing textures on ex. Death Mountain Removed some unnecessary OpenGL function calls; gives notable FPS increase in many cases, such as certain temples Added more fallbacks for lower-end hardware, added detection of Intel graphics hardware to disable combiner emulation regardless of the hardware's reported capabilities Fixed room display list caching; now no longer re-renders rooms on every scene change, even if a room has been cached before with the same settings (i.e. textures en-/disabled) Slightly rearranged Options menu Todo: Implement saving for individual scene/room files Fix borked texturing on Water Temple's first room's walls (works in OZMAV2!) Added LoadTextureBlock macro workaround from OZMAV2; now also tries loading textures after SetCombine command, in case macro detection alone didn't work properly ...probably more... Edit: Finally started working on the Scene Metadata tab, can just change the BGM so far:

Random thought on a broken mess of actors: Let's have eye switches that just float in the room instead of being attached to walls, because "when that scene was made", the variables that now create an eye switch once created a crystal one, or some other kind of freestanding switch.

I don't think there's any way to discern Fast3D and F3DEX2 just from the visuals, it's mainly technical differences (ex. vertex cache, triangle instructions)... although, granted, I'm not sure about possible polygon counts per frame. Those should probably be considered, yeah. Besides that, one of the most impressive things the N64 has - the combiner with its multitexturing and colorization and all that stuff - is actually even Ucode-independent. Hell, I had multitexturing going in Super Mario 64 once, just to prove it works But regardless of that, there is something about the look of old Zelda 64 screenshots, tho, for sure. That's certainly something to emulate if we go in that direction.

Know what? I just added a function called CheckForIntel to my OpenGL helper classes, which is now run just before the already existing OGL extension checks. If the program detects Intel-based graphics (by checking if the OpenGL vendor string contains the word "Intel") it tells the user that... "Your graphics hardware has been detected as being Intel-based. Because of known problems with Intel hardware and proper OpenGL support, combiner emulation has been disabled and correct application behavior cannot be guaranteed." ...and, as stated, it just preemptively disables combiner emulation altogether, so as to avoid bug reports from Intel users I couldn't fix anyway, because Intel has such shitty OGL support. Should probably change the "correct application behavior" part, tho... something like "correct graphics rendering"? Because the program itself will run after all, but it'll not look as good.

For one, that sound like a pretty old version of UoT, although I might be mistaken. I believe this here's the latest one available. Also, consider using a different editor for as many things as you can, as UoT is no longer being developed and is somewhat buggy. The only thing it's still useful for is, in my opinion, modifying the actual room models because mostly everything else - such as ex. moving and changing actors around (i.e. all the interactive things like signs, NPCs, enemies) - can be done in other, less buggy and still supported programs. And to get the blatant advertising out of the way - although I'd hope that people agree with me on this ^^" -, my own work-in-progress SceneNavi is such a tool

...make the compressed files header-less or something, with no or no obvious attribute that'll identify it as compressed data? Would also kinda fall in line with 120's missing room header.

UTC+2 is our current German time, so it's 9:43 pm UTC+2 right now

Netsrac: Yeah, I watched it again, and Minecraft itself is a bit loud compared to the voiceover. I'll turn it down next time, either in the game or just the system volume as a whole. Naxy: Nether portal and then some if we want sounds good, yep. As for my pronunciation, I've rarely ever spoken English in my life, so I guess I'm just wary about my ability to do so? So, is everyone alright with setting a date/time of Friday at 6 or 7 pm UTC+2, at least for now? If something else comes up for anyone, we can still move the time around later.

Alright, Skype call it is, I guess? Also, did another test, now with voice, ranting about Nether portals and wasted levels: http://www.justin.tv/xdanieldzd/b/434801018

I'd be fine with Netsrac joining as well, what about you guys? Also, I think four people should be the limit, just before anyone else asks, for coordination and communication purposes. Any more would probably ex. clog up the chat in more intense moments during battle. Come to think of it, what about communication? Should we just use the in-game chat or have a Skype call or somesuch? Now, about the "when" and "what exactly". I'd be fine with Friday or Saturday, afternoon or evening (local time, uh, UTC+2) as well - something like 6 or 7 pm here? As for "what"... I assume we'd play just regular Minecraft in survival, no special gamerules, and gather supplies, build a base, explore caves, etc. Should we set a goal, like try to kill the Dragon (yeah, right)? As for streaming and hosting the server, I think a dedicated server would be a good idea; the stream I could certainly do then. I'll also do a longer, single-player test stream ahead of our multiplayer stream, just to make sure everything works right (ex. still need to hook up my headset to the desktop and configure OBS for it; I usually use it with Skype on my laptop).

Alright, good to hear it works now This also seems to be an example of how some hardware or drivers lie about their capabilities. The program uses the list of supported extensions, as reported by the OpenGL implementation, to determine if everything it needs is supported on the system it's run on. If a required extension is missing from the list, the program gives an "Extension Warning" message and disables combiner emulation, otherwise it should run with full texture and combiner support (multitexturing, etc). Apparently, tho, this Intel chip/driver says "Oh, I can do all that! Don't you worry!", but when the time comes to actually use those features, it just goes "Hey, wait, what? What're you asking for? glActiveTexture? glBindProgram? Uh, I... uhm... let's, uh, just ignore that and keep going. I mean, what could possibly go wrong... right?"

Sure, I wouldn't mind! If Naxy wants to, has the time, etc. as well, I guess we'll now need to figure out when we'll be playing - this weekend? - and what - I'd like Minecraft for sure, but depending on how it all goes, maybe something else as well (if we all have or can get it)?

Hehe, the fact that you actually want to do these things in a ROM, as opposed to the Rusty moron and his video editing tools, is what I really like about the idea. Nice one

Spent the last 45 minutes or so trying to get a good quality stream of Minecraft working. Got two results: 1) good FPS for me, bad video quality for the viewers. 2) bad FPS for me, bad video quality for the viewers! I take it my upload speed (between 0.7 and 1.1 Mbps, depending on the speed test site used) isn't high enough to stream anything above 480p or something without it looking like ass. Or well, it looks like ass regardless, but it's either "anything in motion smears and looks like ass", or it's "really low resolution looking like ass". I'd still want to go ahead, with the latter kind of looking like ass then, so that you can at least see something, but... Naxy, is your upload speed any better, and could you thus stream a multiplayer game if we did one? I could set up the server, which in ex. Minecraft I know I can do, upload- and performance-wise. Oh, and last and "best" attempt here: http://www.justin.tv/xdanieldzd/b/434712291 (will be deleted in 47 hours according to the site)

Hm, from my experience with bug reports on earlier programs of mine, OpenGL on any Intel HD Graphics / GMA chip is... problematic to say the least. Do you get any "Extension Warning" messages when starting the program? If not, do you get proper textures if you uncheck "Enable Combiner Emulation" in the Options menu?

So, I have this justin.tv account that I've used once so far to stream my desktop (and music listened to) while coding. And now I was wondering - and literally while trying to fall asleep, so this is probably a meh idea anyway - if anyone would be interested in seeing me play some kinda game while butchering the English language's pronunciation. I was thinking - which is the main reason why I think this might be meh, as I realize it's rather overdone - of playing Minecraft, starting a new world, sharing my fear of Endermen, my hatred for Creepers... and my both of the new Skeleton AI with whoever would want to watch. It's the only game I can think of that I personally enjoy watching other people play (such as Guude, VintageBeef and the other Mindcrackers; or for the Germans, the PietSmiet team), because of how each world is different (unless you deliberately use a known seed), and how each player has a different experience playing depending on what they focus on, like building or exploration or whatever. And I wouldn't really want to play something "on camera" that I wouldn't want to watch myself. So, yeah, would anyone be interested in this in general, and if so, would you like to watch and hear me play Minecraft?

Oh, oh, "teh baeta!!"

Went bugfixing and optimizing: [*]Changed the display list parsing code in the Ucode interpreter to not reset certain parameters on calls to other display lists (via DL and BRANCH_Z commands), which fixes certain missing textures, most notably Death Mountain Trail's paths [*]Removed some (hopefully unneeded) OpenGL attribute pushes and pops, which gives a notable increase in FPS in many cases; for example, Spirit Temple was just scratching the 60 FPS mark in Beta 5 for me, now it reaches around 100 FPS, both times with collision rendering, etc. enabled, while other areas have even bigger performance jumps [*]Also added some more fallbacks, etc. for lower-end hardware (especially hardware that appears to lie about its capabilities or something...), although I can't be sure those work as intended, as I don't have such old hardware ready to go Comparison screenshots for the first two bullet points in the spoiler - Beta 5 first, then the upcoming Beta 6:

Antidote: A two years old bug report and Mono still has it? Ugh... On the plus side, it's only the saving of settings in SceneNavi that doesn't work in Mono, correct? Also, that last build is now the official v1.0 Beta 5 release. Either use the update function in Beta 4 (which I'd prefer for testing purposes ) or download it directly from my last post. Changes since Beta 4: Texturing support and faking of PrimColor-based colorization for lower-end hardware Some bugfixes (glClearDepthf entry point, Control key IndexOutOfRangeException) Here's hoping the bugfixes actually do fix those bugs for good...

http://magicstone.de/dzd/progupdates/SceneNavi-v10-b5test.rar Strati, or anyone else with low-end hardware: Do you get textures with this build? Everyone else, does everything still look as it did before, ex. with multitexturing on the grass in Hyrule Field, etc? Also, the levels of texturing/combiner emulation now supported, in order of screenshots in the spoiler: 1) No textures, no combiner emulation. 2) Textures without combiner emulation. 3) Textures with full combiner emulation. The first two both also fake PrimColor colorization, such as the red roofs in Kakariko.

The ClearDepth thing might be an issue with the later OpenTK build (opentk-2012-03-15) I switched to for Beta 4: http://www.opentk.com/node/2891 Try this test build, which has the workaround described at the link above, and tell me if it works: http://magicstone.de/dzd/progupdates/SceneNavi-v10-b4test.rar - I'll also look into at least getting textures to work with low-end graphic chips. EDIT: Working on low-end texture support, about to look up some old combiner faking code from the OZMAV1 days to at least also get colorization via PrimColor working...

Rinku: I agree with Antidote, that's really odd... especially because that GL.ClearDepth call has always been there, and the program worked for you before, didn't it? Do try reinstalling/updating your graphics drivers, then try running it again. Antidote: Ignoring that fontconfig warning (which doesn't look like a C# thing, guess Mono itself is using something that got deprecated?), that trace looks like Mono has a problem reading the application settings. If you ex. toggle VSync or rendering of collision, actors, etc., then exit and restart the program, do the settings get restored or are they reset back to default? About VSync and FPS, it's intended for the FPS not to be displayed when VSync is on, as they'll just be hovering around your refresh rate anyway. As for that IndexOutOfRangeException when pressing the Control key, I'll have to look into that.

SceneNavi v1.0 Beta 4 Changes since Beta 3: [*]Changed mouse behavior to have three different modes: • Camera mode: Camera movement only • Moveable objects mode: Select and move things considered "moveable" by the program (actors, waypoints) • Static objects mode: Select immobile, static things (collision polygons) Modes can be selected via menu or can be cycled through by clicking the mode label on the status bar [*]Implemented mouse-based actor and waypoint movement: • Left click: move object left, right, up and down (or X and Y axes with neutral camera) • Middle click OR left click and Ctrl key: move object forward or backward (or Z axis with neutral camera) • Right click: opens context menu that allows rotating the object in both directions on any supported axis [*]Limited collision editing enabled; collision polygons' polygon type association, and polygon types' ground type and raw 64-bit definition can be edited (more separate options for ex. exit triggers, damage, etc. to come) [*]Added preliminary support for editing of individual scene and room files • Note: does not yet support saving, highly WIP [*]Improved overall collision overlay performance • Might incur slight stuttering when rapid changes are done to the collision, such as changing a polygon's ground type [*]Added ROM byte order detection and automatic byteswapping functions • If an incompatible byte order is detected, the program will ask if the user wants the ROM to be converted or, if the user does not want this, cancel loading [*]Added update checking functionality, can be manually accessed via the menu • Checks online for newer version of the program and can direct the user to a download if one is found [*]Actual functionality for the window's status bar implemented; now shown are: • Current mouse mode • Information about the currently loaded scene and room and/or general status messages • Current camera coordinates [*]Added VSync option for FPS limiting, can be toggled from the menu [*]Improved OpenGL-side housekeeping functions for GL extensions, texturing and combiner emulation • Should hopefully improve usability with lower end graphics cards And I really, really need feedback on this build in particular. I've added so much stuff, it's kinda hard to keep track of what I have tested thoroughly, what I couldn't test due to absence of a test case and so on. So please, mess around, try modifying collision, try running this with an Intel HD graphics chip, try checking for updates (even though there's none), try moving actors and waypoints around, try using ROMs with the wrong byte order, and most important of all: please leave comments, suggestions, bug reports, even if it's just a note that the program works fine for you. Any kind of feedback is welcome and encouraged.

Screenshot dump! Too lazy and tired to write big ass descriptions! 5:09 am! Still need to make saving work with individual files, but everything else should work!