xdaniel

Besides the usual thoughts that this project sounds quite cool, and that I wish you the best of luck with it, there's one other thing... The Etrian Odyssey player here was thinking: "Escape Rope" -> "Ariadne Thread"? Or "Warp Wire", depending on the EO game and/or translation, but that's really not much different from Escape Rope.

Don't mind the title text, it's all in good fun, I hope! Download: http://magicstone.de/dzd/random/Model2F3DEX2-PublicBuild0.rar Usage: ObjFile | o= [inputFile],[baseAddress],[ForceRGBA],[AddPadding],[OutputFile] All arguments must be given, but I'll try to make the optional ones really optional from the next release, I guess. InputFile: Path to .obj file you want to convert. BaseAddress: Base address for addressing inside display lists, ex. if you want to convert a model for a room, and want the textures and display lists to start 0x50 bytes in, you put 0x03000050 as the BaseAddress. ForceRGBA: Force all textures to be converted to RGBA, set to true or false, defaults to false. I'd prefer for people NOT TO JUMP ON THIS immediately because they're scared other formats might not work correctly. THEY SHOULD. And if you can prove that they DON'T, I'd be happy to look into why! Sorry for my wording, but I hate it when people jump to conclusions and resist trying something new... AddPadding: Add actual padding bytes to the output according to the BaseAddress, so if you've put ex. 0x03000050 as BaseAddress, this will add 0x50 null bytes at the start of the output. Also true or false, and defaults to false. OutputFile: Path to the output file you want to write. Argument example: Model2F3DEX2.exe ObjFile="E:\oot-obj\__ACCURACY_TESTS__\test.obj",0x03000050,false,false,"E:\oot-obj\__ACCURACY_TESTS__\convert.bin" This example uses this .obj file, results in the above screenshot, and thus in this output. Other notes: As per an earlier post of mine, group names are used to determine if culling and lighting should be enabled/disabled. Works exactly as described in that post, so refer to that for details. Also, base address can be anything. It's not limited to RAM segments, so you can enter an absolute address like 0x80123456 for this and it should work. Well, looking forward to your feedback and feel free to ask any questions.

After more combing through the Model class, the ModelViewer gamestate and the PVR setup parameters, and finally another round of hardware testing, I'm 99% sure that I've got the weird crashes isolated and "fixed". The aforementioned loop has been going through 22000+ models on my Dreamcast now with not a single crash. I haven't verified against emulation yet, tho, so I can't actually say if the changes I've done to the code (changed buffer sizes in PVR initialization, disabled BGM playback) are why it appears to work fine on hardware, or if it just was nullDC being nullDC the whole time (i.e. buggy). Regardless, I'm probably going to conside the Model class fully functional now, so I'll probably get the dungeon gamestate started soon-ish. At least basic map management with some dummy map, the camera and party movement.

Super Happy Fun Random Junk Time! ...and in not so fun news, DCEO/Frenda's Model class seems to be leaking memory, and if it does, I have no bloody clue where. I've changed the model format, as mentioned before, to contain multiple models per file and have rewritten the class accordingly... but there seems to be something wrong with it, because (at least under emulation, not tried this in particular on hardware yet) this loop I've added for testing - which just loads one model file in, then unloads it the next frame, and moves onto the next file / loops back to the first when finished - causes the system to crash after a few thousand files (= constructor/destructor calls). I dunno, I'm pretty sure I'm using new/delete properly, not leaving any memory allocated with new undeleted, etc., etc., but it still happens. I'll have to burn a CD I guess, and see how long it'll keep going on my Dreamcast...

But I can't just put if(variable >= 0 && variable < array.Length)s and if(variable != null)s everywhere! Or shudder, try-catch statements! That would be work and proper technique! What do you think I am, application developer by trade? Well, if things work out, I might be two years from now, but right now, I'm not! (But really, I know that better error handling wouldn't hurt, I'm just lazy...)

Despite the problem being fixed, to â–²ChriisTiianâ–² and everyone else who encounters errors in SceneNavi: Always post as many details as possible about an error, about the ROM you used, about what you did with the ROM and in SceneNavi, etc. There's always the chance that I might not be able to reproduce the problem on my end - as can be seen in this very thread, where ex. people's ROMs were simply messed up -, so without any details, I'd have to randomly take stabs in the dark to try and localize the source of the problem. Edit, and this, yep:

Hmm, worth looking into despite the wrong definition, as the program's behavior should be consistent regardless. While it's only been meant to select and edit a single collision polygon at a time, this does sound useful to have, ex. for changing the type of multiple polygons at once, etc. Performance might be an issue, but I'll look into this as well. I thought I had fixed this, but that might've been in another program... Should be an easy fix, likely just need to clear the keys pressed when the 3D view loses focus. EDIT, fixed: private void customGLControl_Leave(object sender, EventArgs e) { keysDown.Fill(new bool[] { false }); } Gotta work on SceneNavi again, huh?

No offense but, you know, if you want people to take your project seriously, you shouldn't just post "I need a team, please message me", but you should show that you're serious about this by trying to learn how to modify the game(s) in question. To start out, decide on one thing you want to do - say, edit some levels - and then research how to do it. What level editors are available? What do you need to know when editing levels? Any limitations? And so on, and so forth. Once you've made a small hack, nothing big, show it off to the rest of us. That'll show people that you're serious about wanting to try this. Not saying you should know everything and do everything alone, but that you should prove that you're capable of doing at least part of the project yourself. Again, no offense intended at all, just trying to give some advice.

Alright, let's see. I had a quick look at the stuff stored in the basement earlier today. I was looking for 1) one more PS/2 mouse I knew I had, and 2) any other parts that might benefit the P100, such as a faster CD-ROM drive. The other mouse I did find, some Fujitsu mouse with a very short cable (presumably meant for a laptop?), but I couldn't get it to work with the PS/2-serial adapter, either. To be exact: The mouse aside, I didn't see anything else useful in the basement, or nothing I could get at easily - there's lots of boxes stacked on top of each other. I did find a few more video cards - ex. a Matrox (MGA Millenium, I think), an ATI Mach64, and a few AGP cards (ELSA Erazor X! GeForce 256 with 32 MB RAM!) - but I haven't decided yet if I want to switch the V7-Mirage/S3 Trio64 out. Also did see a few optical drives, but they were mostly DVD-ROMs and CD-RWs, and I don't think they necessarily "fit" in a Pentium 100 from 1995 or thereabouts. I did install Internet Explorer 5 (shudder!) just for fun, but it's quite useless, because of the rather elderly system it's running on, and because of modern websites and their images, stylesheets, scripts and such.

I'm leaning towards variant 2. For example, I dunno about the gray category background and light blue text in variant 1...