xdaniel

(also: SC2000 = <3)

Maybe you're right, because for one, it's actually only ~1500km between here and Helsinki... 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).

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...

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

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

Based on Arcaith's test dungeon, here's a little PPF patch + PJ64 savestate for the Debug ROM. Just patch a copy of the ROM, load the savestate and press A (savestate at the map select, sasatest and Adult Link being selected). It's basically the result of me messing around with the importer for a few hours, fixing some importing and GUI bugs in the process... Hoping this is gonna work correctly, download the package here.

1, because in 2, in my opinion, the sand is too dark and clashes with the walls.

Bought a few things lately, but this one probably takes the cake: Mega Man: The Wily Wars (PAL) for Mega Drive - only released in Japan and Europe and usually expensive as hell. And what did I pay for it? 33 € (47.50 USD). Another complete copy of the game was sold on eBay Germany a few weeks ago for 190 € (273.50 USD).

1) Red and Green do not have Pokemon animations, so the White Hand Sprite thing is impossible. Crystal is the first game to have animations, and only at the start of battle, R/S/E only feature some sprite distortion effects, etc., etc. and only since Black/White is there actual animation over the course of the whole battle. 2) Haunting.swf? A Flash animation? On the original, monochrome Game Boy? Yeah, sure. 3) Am I the only one who finds the Lavender Town stuff, creepypasta and all that boring?

Some minor fixes to collision writing later... Multi-room scenes working correctly, transition actors working correctly http://core.the-gcn.com/public/style_emoticons/default/thumbsup.gif And another screenshot:

Freshly installed Windows XP SP3 on my old Dell Latitude C640 laptop now named "Kyouko" - Pentium 4 Mobile 2 GHz, 768MB RAM, ATI Mobility Radeon 7500 w/ 32MB, 30GB IDE HDD, Intel PRO Wireless. With a semi-broken keyboard, very weak hinges, cracked HDD slot cover and many, many scratches.

Kargaroc: Single vertices and thus ex. their colors cannot be edited, because it currently imports everything as an outdoor scene that adheres to environment lighting. I don't think I'll be able to add editing of single vertices without rewriting much of the conversion code, which I - at least not in the near future - don't really want to. I will add an option to disable lighting and enable vertex colors per group in the .obj file, as well as an option to disable skybox, timeflow and such, so you can experiment with ex. the environment settings to get the map to look the way you want it to. Next up, an update: Transition actors are theoretically implemented, complete via GUI-side editing, but I can't really test support for multiple rooms, because I currently don't have an importable map with more than one room I could try (hint, hint, Zeth?) http://core.the-gcn.com/public/style_emoticons/default/thumbsup.gif

Am I weird for importing Japanese manga when I just barely understand the language? Then again, it's Madoka, so I just had to!

Hm, not much of an update, but for one I finally added the ability for the user to select which scene number to overwrite. Besides that, I started cleaning up the source code somewhat (beginning with the texture converter, maybe the smallest important piece) in preparation for release. But mind you, said release is still some time away, considering the still missing/incomplete features alone. Next up... I dunno. I should probably get to adding transition and spawn point modification. But making the interface for that is a pain... Edit: Transitions aren't implemented yet at all, but spawn points can now be added/edited/deleted. I ended up splitting off the actor editing controls and their logic into a separate user control, which I can now place on the form and just feed with the proper parameters, instead of having to duplicate the controls and code for each other actor editing facility. Will add support for transition actors in the scene generation code, then for their room and camera settings in the actor editing control, and then that should be done. Gonna do that tomorrow, tho, been messing with the program for several hours straight again http://core.the-gcn.com/public/style_emoticons/default/thumbsup.gif

Now editable:

Top: A blue square representing a water box (not yet editable via the GUI); bottom: the water box in action.

Guess I'm not going to try too hard with DMA table rebuilding and such then... Anyway, some more progress. XML loading and saving is pretty much done, so that... ...equals... ...and equals...

Not yet, sadly, it's still just modifying the scene table. I'm for now concentrating on getting a working importer with support for actors and the like going, then after the first release, I'll go back to trying DMA table modification/rebuilding. Edit: Actor adding/editing/deleting; no mouse-based movement yet.

128x64 for grayscale I-type textures only. 16-color textures can be up to 64x64 (CI 4-bit), 256-color textures up to 64x32 (CI 8-bit) or whichever other combination of width/height that doesn't exceed the maximum per texture type. As long as a texture, when converted, is smaller than either 4096 or 2048 bytes (depending on the type converted to, see the list), it should work... Well, uh, I'm bad at explaining this, sorry. Source texture files should be able to be anything C# supports by itself, so bitmaps, PNGs, JPGs and many others. As for lighting and darkening textures, I don't think that's needed as the converter calculates proper vertex normals, which means the model adheres to the game's lighting like the regular outdoor maps (Hyrule Field, Kakariko, etc) do and thus lightens and darkens according to that.

SanguinettiMods: As in, what texture sizes are supported, what N64 formats are they converted into? On the N64 side: - RGBA 16-bit, max. 4096 byte (ex. 64x32) - CI 4-bit, max. 4096 byte (ex. 64x64) - CI 8-bit, max. 2048 byte (ex. 64x32) - IA 8-bit, max. 4096 byte (ex. 64x64) - IA 16-bit, max. 4096 byte (ex. 64x32) - I 4-bit, max. 4096 byte (ex. 128x64) - I 8-bit, max. 4096 byte (ex. 64x64) Any texture works as long as it fits into one of those "categories", so to speak. And the converter's also trying to figure out the best texture format to convert the texture into, by looking at things like size, color depth, actual color count, alpha channels, etc.

DeathBasket: Yeah, the map's representation in the program is a preview based on the source information (.obj model, etc), mainly for actor placement and such; it doesn't read back the converted data. Also, while I don't have concrete plans for just converting into Display Lists yet, the code's flexible enough for that, so either I'll add that somehow/make a new tool for it, or someone else can do so once the source is released (which I guess I'll do with the first release).

Naxy: It's not perfect yet, tho http://core.the-gcn.com/public/style_emoticons/default/thumbsup.gif The water surface works right, while Link always appears in front of the waterfall, for example. Zeth: I've been side-jumping all over the place just now and did not go through any walls, tho that's not to say it might still happen on a map with more complicated collision and such. Edit: Capable of changing the scale, BGM value, scene injection offset and collision model, as well as adding/deleting rooms, changing their injection offset and each group's alpha value. Every group in an .obj model is a Display List, so it's a good idea to make ex. water a separate group from your other geometry. Actors and everything else not mentioned cannot be changed via the GUI yet. Edit 2: Objects can now be added/edited/deleted.

(Also, for some reason I keep getting timeouts when browsing the forums...?) Edit: Even better now~

Same, but with $199 + shipping, as I'd like to have it with a case and CIC...