xdaniel

Good to know about all the .x support, I'll take a closer look at it once I've gotten further with the program... Now, as for what I've done during the SOPA/PIPA blackout, take a look: The combiner editor is getting places. It's using SayakaGL's code to (partially) emulate the color combiner and some OpenGL trickery to put the resulting texture back into a Bitmap for display in the material browser. You can change each component of the combiner setup, the raw combiner mux, and select one of currently 6 different presets or templates that cover some typical scenarios - "Shaded surface /w Prim color", "Shaded surface /w Prim color & alpha", "Multitextured, shaded surface", "Multitextured, shaded surface /w alpha", "Unshaded surface /w Prim color" and "Gouraud-shaded surface", each with a description that explains the mode in slightly more detail. Also note that the primitive color is composed of the material's "Kd" or "Ka" and "d" values. On the downside, several components of the setup just cannot be emulated correctly in this scope because they need other variables, etc. not supported here (ex. Shade comes to mind here, which needs lighting, or the Environment color/alpha, which is set by the game itself if I'm not mistaken). Also, multitexturing doesn't work right yet - neither in the preview, nor (if it was implemented already) in the Display List generator. Several variables for that I still have to gather together, make editable, make the preview use them, then make the eventual DList generator use them. Finally, don't expect more seemingly fast progress like this. I could reuse code from Sayaka here, for example, and there's still a bunch of work to do in this part alone (multitexturing). EDIT: As mentioned shouted on the shoutbox and in the "post what you're doing" thread, finally I managed to replicate some bloody multitexturing in custom maps! There's a bunch of manual hacking around going on still, the textures in question cannot be CI-type textures (limitation of the console? dunno), I had to replace a scene with pre-existing grass (Kakariko for the example) because otherwise Environment Alpha wouldn't be set correctly, but it kinda works!

Just bought something interesting off of eBay... a Korean Hyundai version of Diddy Kong Racing, one of 20 supposedly new copies a Korean seller has had (four left now) - $9.99 or resp. just over 8€ with free shipping. Looking through the feedback the guy recieved, someone from France had also bought one of those DKRs and left a positive comment, so I'm positive about this as well. Hope it's going to be sealed/shrink-wrapped, too, and not just unplayed, because that'll look very nice on the shelf

Implementing vertex color editing in SO shouldn't be much of a challenge, but it's not really feasible because 1) effective usage would require manual editing of each and every vertex in the model, which I don't think anyone would want to do, and - even more important - 2) saving them certainly would be a headache and a half. I am thinking of adding support for editing and saving of at least the material library in the rewrite (see the last screenshot), so adding support for the same for the actual model, and, say, adding an additional parameter for vertex colors like "vc" isn't much of a stretch. However said "vc" parameters would only be understood by SO, every time you export a model from ex. SketchUp they'd obviously get lost, etc., etc. Too many pitfalls to work around for too little gain, I think... The .x format is looking like a very good alternative to .objs there, although I haven't looked too much into it yet. How's support for that format in modellers, by the way? Is SketchUp capable of exporting to that, seeing how many people use it as their modelling program? Also, one more update before I'll close VC# for the night, although it's more of an "under the hood" thing: Extended the rendering function list into its own RenderingQueue class with support for giving each function a different priority level out of five. As an example, room models will be rendered first (very high priority), actors come next (normal priority, tho actors don't even exist yet), while the collision model overlay comes last (very low priority).

Well, I need some input on a few things regarding the rewrite... First of all, I'm going to abandon my group-based approach to specifying properties like transparency. That stuff is technically supposed to be stored in the material definition, so I'll be doing this how I should've done it in the first place. Texture tiling (wrap, clamp, mirror) will also be set on a per-material basis, plus each material may reference another material from the same material library (calling that "Linked Material", but call it whatever you want), which will be used for multi-texturing, so that you can hopefully finally have stuff like Hyrule Field's grass on your maps. Remember, tho, that I'm still laying the groundwork for all this, so don't get all excited for combiner setups and such already. Groups will still be used for Display List generation, so that one group equals one DList when converted, and collision type definition will also still be group-based, but there won't be any of that "group name in collision must be the same as group name in model" junk from SO anymore. Collision should be 100% independant from any models besides the one you select as the collision model. Next, a question about the material libraries: Which of a material's texture maps should be used as the "primary" one? Ambient? Diffuse? One model viewer expects map_Ka, while the next one expects map_Kd, some exporters only set map_Kd, others use map_Ka. Judging from their names they have different uses, but apparently they're usually set to the same texture map? Honestly, I don't get it, I'm thoroughly confused. Do you have any other lower-level suggestions, things to pay attention to, ex. regarding the Wavefront format or whatever else? But please don't get into Zelda-specific questions and such yet, because even Display List generation is still a good way off, let alone scene or room files. And finally, another screenshot of the current progress with material management...

Yeah, to reiterate my shouts: xdaniel (16 January 2012 - 02:34 PM) Just seen the logos for those games, the Japanese titles are more or less nonsense xdaniel (16 January 2012 - 02:35 PM) Or at least really inconsistent - writing Ice in katakana (as in the English word "ice" rendered in Japanese) while Fire is the kanji for "fire" xdaniel (16 January 2012 - 02:36 PM) Plus, why would there be a を? If anything, it should be の xdaniel (16 January 2012 - 02:37 PM) 氷の予言 and 火の予言 would be better, plus the first one is actually what Google Translate spits out for "Ice Prophecy"

- Konami GB Collection Vol. 3 (GBC, EUR) ...and guess what, it contains the dead Twinbee from my last post here! So all is well. - Lufia (SNES, PAL), which I actually started to play earlier today! We'll see if I actually continue playing it, tho... - GG Shinobi (Game Gear, EUR) Sadly all loose, but what can you do... (And unrelated to games, got some PC parts to fix up and upgrade my secondary Pentium D machine - a new PSU, more RAM, better CPU cooler to overclock it, and got my old GeForce 8500 GT in there; see the third CPU-Z validation in my signature )

Better don't expect anything from this for now Besides, tho, I suppose I'll look into it. Already wanted to add support for it in the current SO, but never actually went and did so... Also, new rewrite screenshot, .obj model and material loaders are on a good way: And now I should better go to bed as it's ~4 AM, as I've got to get up between 8 and 8:30 AM again, as I'm going to be dragged to a flea market at 10 AM...

On the PC it's keyboards, mice, a wired Xbox 360 controller. Come to think of it, mostly the first two, actually. On consoles... well, each console's specific original controller, excluding the PS2 as I've sadly never had an official Dual Shock 2. Using some pretty good third party controllers on that one, forgot what brand etc., tho.

Adamantite Repeater + 2500 Hellfire Arrows = MASSIVE DAMAGE (oh how long has it been) across the whole hill, Rainbow Dash included, naturally. The Demolitionist would be proud. So yeah, taking this charred land. My hill.

Nowadays more known for botching Sonic games (excluding Colors, Generations and Sonic CD's Retro Engine ports, but that's another story entirely), rereleasing old games with bad emulation and other unflattering things, they were once also known for their consoles. The Mega Drive was probably what really put them onto the map in this regard, although decisions surrounding it and its successors would eventually lead to their downfall as well, but even said successors still have their followers to this day. So, what's your history with Sega so to speak, if you have one? Your first system or any classic games by them, or games on their systems? Favorite games, from anywhere between Master System (or hell, the SG-1000 if you want!) and Dreamcast? Any system or game you don't have but really want? I dunno, I just wanna talk a bit about Sega, I guess! By now, I have most of Sega's systems starting at the Master System - because really, I'm not gonna pay 100€+ for a bare SG-1000 or something -, MD Models 1 and 2, a Mega CD 2, several Game Gears, two Saturns (one PAL, one NTSC-J) and two Dreamcasts (one PAL, one NTSC-U). The only important thing I don't have, or not in working condition anyway, is a MD 32X. I know it's place in Sega's history, the ill-conceived stopgap it was, but I still kinda want one... at the very least for Knuckles' Chaotix because that's a great game, and it hasn't been rereleased on anything. Shame on you, Sega, the one game I want you to bring out again, you just ignore. Out of the bunch, I'm not sure which is my favorite of their systems... I'd almost want to say Saturn. Probably because it's got both, great 2D games (more often than not the best home ports of arcade games, for example) and still rather nice looking and playing 3D games (compared to the PSX anyway). Also, for someone without that much money, it's a pretty cheap system to collect for, as long as you get Japanese games. There's good stuff for a few hundred yen - Sega Rally, Nights, Panzer Dragoon, The House of the Dead, Puyo Puyo Sun, all less than 1000Y each. Well, as long as you don't shop on eBay anyway. There are pricey games too - Radiant Silvergun comes to mind, and that's mid-range I believe -, but those exist on all systems. Well, enough from me, someone else gush about Sega (and no extensive hate, please)!

I've read about that but never encountered it myself. Is it documented in the sense that you know what's going on? I can't fix bugs I'm not getting myself - I can check for any glaring errors (and can imagine there being some) but beyond that, no idea. A precompiled Linux version I'm not sure about, seeing how I had one posted that ex. didn't work for spinout IIRC... tho that might've been thanks to some missing GL extension availability checks, come to think of it. Oh, I still care - as I said, I have no idea if that rewrite will go anywhere. As far as I can see, the reason for that is simply that SO does not check if "scene offset + scene data size > room offset". Honestly, I didn't think about situations like that, where the user specifies injection offsets that are very close together. And while I do mention "this does not check if/what gets overwritten in the ROM, yadda, yadda" in the Readme, it's not directly in that context, so it's (yet another) oversight on my end. Will see about fixing that - ex. when such an overlap is detected, giving the user the choice a choice between "cancel injection and let user manually change the offsets" or "automatically inject scene and then all rooms consecutively".

I'll see what I can do. Found some documents on the specifications, which'll hopefully get me started at least: http://paulbourke.ne...m_Template_form http://www.xbdev.net...xfileformat.php ...that is the format you mean, right? ".x" isn't exactly a descriptive name Also, that's still some time away as I need to get the whole framework going properly and such, but gives me a reason to use interfaces again (as with the two renderers in my PCE emulator).

Question for those who have played the previous games: If I didn't like Kazooie and Tooie, might I like this one? Or would I find it even worse?

Most likely it will, if not directly on the SVN. I'll probably pack the latest version in an archive and put that up as a separate, deprecated download at the same time the rewrite's source goes up.

Multi-texturing and manual changing of combiner setups is something I really want to do, so it's planned for inclusion. Depending how the rewrite goes (= if badly), I might even bite the bullet and try to rewrite the current SO to support this. As for area name textures, can they even be loaded from scene/room files? I forgot, but if that's the case, I can surely allow the user to add them at the end of the scene or so. For now, here's one more screenshot of the "Incubator rewrite", now finally displaying something more than just the GUI - that is, rudimentary collision model rendering (that of Arcaith's demo dungeon models to be exact). Kinda gives me hope that something's gonna come from this, tho not necessarily much...

An example of this would be nice, as no one else (unless they didn't contact me with it) has encountered this, as far as I'm aware. And on another subject... I'm not really happy with how SharpOcarina has turned out. It's relatively simple to use and all that, but... - its internal design leaves a lot to be desired (the kludge of how group names in collision and room models have to match up, for one) - Wavefront .obj support is incomplete and incorrect (usage of ambient/diffuse/specular texture maps, transparency isn't supported and is hacked in otherwise, surely more) - parts of its code were supposed to be temporary solutions but became permanent (the ROM injection code comes to mind) So alongside maintaining SO as it stands right now, I have started - take a wild guess - to rewrite it from scratch. For example, each kind of "object" - that is the scene, rooms, the collision, Wavefront models and their material libraries, etc. - will be its own pair of handler class and properties dialog, as opposed to ex. every user-configurable setting being squeezed onto a few tab pages. The 3D preview will be a separate window (also a pair of handler and form), which will be capable of rendering different things, depending on which rendering function it has been given. So ex. a model handler can tell it to simply render the model, while a room handler could potentially generate a temporary room file, the Display Lists of which could be interpreted using SayakaGL's interpreter, which thus would give a much closer representation of how it's gonna look in-game compared to just rendering the Wavefront model itself. There's also a custom exception handling system in place already - it's still rather primitive, but could be extended to generate more detailed logs the user could post in case a serious problem happened, etc. Yeah, much talk already, of which very little has been implemented yet. Then again, it's only a day old or something. Then again, I'm known for being lazy, loosing interest in things rather quickly, so who knows... maybe this'll be dead by Monday already. (And even if this dies as quickly as it came, I guess at least the exception handling will probably see use in my other projects...) (And I wonder if anyone will get where the "Incubator" namespace came from. Probably not.)

Looking at this thread, taking a screenshot of my screen, uploading it to imgur, then putting its BBCode here: (Prior to that I watched Jeremy Parish of 1UP suck at Mega Man 3, and after this I'll go to bed...)

That's why.

New WW Text Viewer release: http://magicstone.de...om/WWText_3.rar More control codes supported (Japanese furigana display, more button icons, etc), added some output formatting options (simplification/removal of control codes, removal of furigana), initial parsing of the file is much slower because it now parses each message four times, but that makes it faster when changing said formatting options, some other changes.

Watching a German Terraria Let's Play:

Oh god, I was just reminded of why I started SayakaGL back then. UoT, as it is, is a piece of crap. So I tried to replicate the collision settings Jason posted in Hyrule Field, modifying collision type #15 (ex. top of the bridge near Kakariko entrance's railing). First, no matter what I changed, no matter how often I pressed "Apply", once I switch to a different type and back to #15, the settings were reset! Saved the ROM anyway, tried it out, works! As long as there's water where you'll be jumping. Went back to UoT, reopened the ROM, it still doesn't show the changes? Plus, looking at the changed ROM in a hex editor, it messed up the second to last byte in every collision type! Was was originally the four leftmost bits were saved over the rightmost four, turning a 0x2F into 0x02 etc.! Anyway... I'm guessing something like 2C00000200005FC4 should basically work in SO, however manual editing is slightly broken in the current versions and the code on the SVN, whereas the leftmost four bytes cannot be entered manually! Oh ffs, hacking this game is so much trouble...

Not yet released, it kinda fell by the wayside like so many other things I start... Still need to implement the actual importing of textures, as well as general refinement. As for the "Navi" texture, I'm pretty sure I've seen it before (using Tile Molester I think), among the other interface textures. It's a very tiny texture IIRC, so it's easy to miss.

"03 xx 02" you say? I'd say "xxxx 02". The "Letters for <player>?" message is number 0x03A2 in the file's message list, while 0x03A3 is "Well met, Hyrule King!"; their message IDs - not used in the case of cutscenes, apparently - are 0x0CEB and 0x0D49 respectively. EDIT: So, for example, replacing the 03A2 with 0159 should give you "To call Tingle, use a Nintendo GameCube Game Boy Advance cable [...]". As for bmgresh.arc, it's very well possible that it's the Hylian text. From the technical side, the file contains 15 Japanese messages in all Katakana, starting with "ヒサシブリダナ　ハイラルオウヨ" or "Hisashiburi da na, Hyrule ou yo" or (very roughly something like) "It's been a long time, Hyrule King". Someone correct me if the translation's wrong. If it is the Hylian text, I'd assume the game's Hylian font maps one-to-one to the Katakana characters in Shift-JIS encoding. And the demo's maps are: majroom (rooms 0-4), MajyuE (room 0), Mjtower (room 0), M_Dra09 (room 9), M_DragB (0), M_NewD2 (0-16), Name (stage only; file select background, I guess?), sea (0-49!) and sea_T (0 and 44). I have yet to look at them, tho, just listed the folders on the disc. Finally, some tidbits: the build date according to the COPYDATE file is 02/12/06 16:54:20, the banner data (as seen in the GameCube's menu), country code, etc. is mostly Japanese, besides "THE LEGEND OF ZELDA the wind waker for USA SHOP VERSION" and it probably has all the objects the normal retail version has. Or well, there's a bunch of them at least, including all the Demo##.arc archives, etc.

Here's the whole thing in case someone wants to take a look: http://magicstone.de...demo-script.txt - you might have to manually set the character encoding to Unicode/UTF-8 to get the Japanese text to show up correctly. (And I should get that text viewer updated...)

It's US vs. US so to speak, but against an earlier version of the US script. But not to get anyone's hopes up too much, this earlier version isn't from some internal prototype, but comes from the Wind Waker demo that's on one or two of Nintendo's "Interactive Kiosk Demo Discs" or whatever they were called. Apparently, the English localization was in a pretty early state, as this version of the script 1) is still mostly in Japanese, 2) seems kinda literal, tho I have no means to really check that, and 3) has several typos. Alternatively, the whole thing might've just been quickly thrown together for the demo, as 1) it's mostly in Japanese - yeah, this kinda counts for both possibilities - and 2) has some demo-specific messages like: ERROR!<lf> Please contact the sales staff for<lf> assistance.<end> ...which replace most but not all of the Memory Card-related messages.