xdaniel

I'll really need to fix the shader code, huh... Will do so later during the day; 1:15 am right now. The reason you're getting it with the other combiner types is that many known combiner setups (or rather, their ARB and GLSL interpretations) are precached, which caused quite an FPS increase with the ARB combiner - not sure if that's even needed with GLSL. But regardless, the shader code will be fixed as soon as possible.

First, SoD: Yeah, I think that'll be helpful once (or for SceneNavi, if) I go full-on OpenGL 3+; right now vertices, texture coords, etc. are still pushed through using glVertex & co. instead of VBOs. I ought to learn some more modern OpenGL, but old habits die hard Also, I put out a quick bugfix release, mainly to fix complete breakage on lower-end hardware. Note that the update function in Beta 9 and below will tell you that "v1.0 Beta 2305" is available - not a bug, but a change in versioning that those build can't cope with. It'll be Beta 9a once downloaded v1.0 Beta 9a ("My First Hotfix") Added additional sanity checks to prevent potential EntryPointNotFoundException and NullReferenceException, especially on lower-end hardware Changed versioning code to allow for hotfixes Haven't yet fixed the GLSL bug Xenix is getting, that's next on the proverbial list.

Ah, a GLSL error, I kinda expected those to happen... I'm still a bit of a GLSL n00b, so I'm not yet familar with a lot of pitfalls there are with it, which include some drivers allowing certain code while other drivers don't. I did learn more about this while working on the OoT 3D model viewer, but hadn't improved SceneNavi's code based on that... Anyway, in the meantime, try using the ARB combiner ("Options" -> "Combiner Type" -> "ARB Assembly Combiner") which should work on most reasonably modern, non-Intel graphics chipsets.

Still missing features and fixes requested/suggested here, but because I finally want to get a new build out (after what, four months?), here it is regardless... As usual, find it via Beta 8's update function or the Update page. Would very much like some feedback for the GLSL combiner, and from Intel graphics users, in particular. v1.0 Beta 9 ("You've Got Shaders In My Fixed Functions!") Added new GLSL-based combiner emulation, still missing certain rendering details (ex. automatic texture-coordinate generation for reflections) Added support for anti-aliasing and mipmapping in renderer; can be toggled from menu Changed application configuration to use Nini library instead of .NET Properties.Settings Fixed various bugs; combiner inaccuracies, display list caching, Scene TreeView generation, mesh header types, etc. Added experimental help system, displays help string in status bar when hovering over menu items; still needs work Various other OpenGL-related changes and additions (ex. extension checks) Various minor GUI changes (ex. status bar appearance, Options menu arrangement) Need to really get back into things, implement various things ex. petrie requested, get the source out onto Github, and so on... I guess I'll start with that last point very soon? Edit, source code now on GitHub: https://github.com/xdanieldzd/SceneNavi

Sooo, progress on the Pentium and the Amiga fronts: While I haven't had the serial mouse I mentioned in the mail yet (it's the weekend after all), by chance I did come across a Logitech PS/2 mouse with its serial adapter still attached, at a flea market on Saturday. The good news here: the mouse works, in both PS/2 and serial mode. The bad news: not on the Pentium 100. CuteMouse and Microsoft's driver detect the mouse and install themselves, but no applications react to mouse movements or clicks, while Logitech's own driver doesn't even detect the mouse. The Logitech driver also contains a simple program that detects activity on the COM ports, from which I can see that the mouse does do something on the P100 when moved/clicked, but that's about it. Also, which is even worse than the non-working mouse, the P100's power supply seems to be failing. During the two or so hours I tried to get the mouse going yesterday evening, the system shut off without warning three times - complete power loss with the power switch still down (remember, it's AT, not ATX), needed to switch the power off for a bit before it fired up again. One time it even damaged the BIOS settings in CMOS RAM, so that I had to redo the configuration, i.e. HDD parameters, IRQ stuff for the PCI IDE controller, etc. And seeing how I don't have another AT PSU to try and switch this one with, I can't even be sure it is the PSU that's dying... A really frustrating situation. Next up, the Amiga 500. I had asked a friend of mine earlier this week, if I could have one of the junk A500s he's found at recycling centers over time, basically to have spares for mine. He ended up bringing one over yesterday - A500 Rev 5, 512 KB RAM, Kickstart 1.3, broken FDD (does not recognize disks) - that I could have, in exchange for someday setting up an old PC of his, where he's planning to replace the HDD with a CF card in an adapter, with Windows 95. Some of that A500's parts already found their way into my main system, including the keyboard's keycaps, the RF shielding and some screws, which all were in better condition on that one. And speaking of the Amiga, at the same flea market, and the same stall even, where I found the serial mouse for the Pentium, we had also found a bag - literally - of seven(!) Competition Pro joysticks for ex. the Amiga, C64, and anything else with a compatible joystick port - five normal-sized (three of them black, two transparent blue) and two half-sized (one transparent white, the other transparent blue), for 0.50 € each. The downside of that: only two of them are working properly right now, while the others have non-working directions and/or fire buttons. All of them do something, so we'll be trying to diagnose and repair them next weekend. Edit: We have three working Competition Pro joysticks; the second transparent blue one is now working fine as well. The right directional button apparently was stuck or something, because after some (not so) gentle wiggling around, that direction is back in action. Edit #2: The PC mouse problem has been solved. Turns out the IRQ settings for the COM ports were swapped on the multi I/O card! COM1 is supposed to use IRQ4, while COM2 is supposed to use IRQ3. Switched those around, bam! The Logitech drivers for DOS and Windows installed fine and work perfectly. Now to diagnose those random power losses, although I haven't had one today so far. Also, Doom's attract mode has been looping for the last 20 or 25 minutes, without any hickups, so... I guess the PSU might still be fine? But I probably should get myself a multimeter soon anyway, to check the voltages it's outputting.

So, I kinda neglected this thread because I kinda neglected the Pentium 100 it's been about. However, I am (hopefully) having a serial mouse for it coming in the mail soon-ish, so that I can actually use the system properly, at which point I'll also try and get some sort of presentation video about it up on YouTube. In the meantime, there's something else I've been thinking about and partially working on... my Commodore Amiga 500, as mentioned in one of the posts above. I haven't yet gotten an accelerator for it yet or anything, but there's a very recent expansion card called ACA-500 that looks quite interesting. It attaches externally to the A500's side expansion port, has a 68000 CPU at 14 MHz (up from the original 7 MHz 68000), 2 MB Fast RAM, two CompactFlash slots (one as an HDD replacement, one for data exchange with PCs), you can attach certain A1200 accelerators to it to upgrade the system even more, etc. There's more details about it on this site. So that ACA-500 is something I'm interested in getting someday... and honestly even something I'd be willing to sell part of my "collection" of games for. And thinking even further ahead, if things align somehow, converting that A500 into a desktop or tower machine would be wonderful. We did have a heavily upgraded A500 when I was a kid, some 15+ years ago - 68030 accelerator with 40(?) MHz, a lot of RAM, big HDD, a CD-ROM drive, all in a modified AT form factor desktop case - but I cannot for the life of me remember what happened to it. I went looking for it the last two times I visited my family, but with all the junk accumulated in the basement and attic there, I had a hard time going through everything and couldn't find it. Either it's still "buried" somewhere there, waiting to be resurrected, or we actually sold it, or even gave it away after we all got PCs. Anyway, the whole ACA-500 thing is something for the future, right now it's about getting this A500 back into better shape. The keyboard, but not the rest of the case, is badly yellowed, the internal shielding is bent and discolored, at least one component on the board - a NAND buffer chip, I think? - has corroded or oxidized legs, and leaving the system aside, I have hardly any floppy disks that work well left... and the situation for those here is even worse than with the PCs, because the Amiga uses 3.5" DD (Double Density) disks at 880 KB, instead of the more recent HD (High Density) disks that PCs have used since, I dunno, the late 80s? ...yeah, so, old hardware-wise, the A500 is probably gonna have my attention from now on. I already have modified a PC floppy drive (yes, the drives themselves differ slightly, too) for Amiga use, just in case something was to happen to the old drive, so that I don't have to go and buy a replacement eventually. And speaking of which, while the sounds of the original drive are really, really nostalgic to me, the modified drive (a 1999 vintage Sony) is sooo much quieter and thus far more pleasant to the ears than the original (a Panasonic from I dunno). Here's a quick comparison I made after performing the modification.

Easiest and cheapest should really be a GameShark v3.x, a parallel port cable, and a compatible PC. It is a bit unstable, as mentioned on the page that Airikita linked to, but can be gotten to work rather reliably, and is also a lot more, well, economical than trying to find a Z64 or Doctor V64.

So I finished four out of five shows I've been watching this past season so far, with the fifth one's final episode waiting on my HDD. All in all, they're D-Frag, Mikakunin de Shinkoukei, Chu2koi Ren, Seitokai Yakuindomo* and the second half of Log Horizon. Log Horizon aside, as a show that had started last season, I think the two shows that weren't sequels are actually the ones I liked the most, thus D-Frag and Mikakunin, and of those two... hrmmm, I am not sure which I like more. I think I like Mikakunin a lot for its coherency and development in general, for how well everything fit together, while I like D-Frag a lot for how its just insanely fun to watch. Also, the respective OPs of each of the two shows are extremely addictive: Mikakunin's is quite cute and meaningful at the same time, while D-Frag's is pure crazy energy. And both are just catchy as hell! Ah doushiyo? ... I never know why! <3 Now Chu2koi Ren and SYD* were good as well, but, for better or worse, also were simply more of the same. Luckily it wasn't really for the worse for both of them, although I can understand that Chu2koi in particular could draw someone's ire... I think it was fine overall - ex. regarding character development, including for the side characters (namely Nibutani and even Kumin-senpai kinda) - but it also had some kinda stupid or annoying things to it, like how some of Shichimiya's arc was handled, as well as how Isshiki was even worse off this season than before. Not that I care about him much, but he got totally shafted here, with not a single "good" appearance for him, and I really don't get why they did that. But hey, at the very least, Chu2koi Ren didn't leave you with this awful aftertaste that things like a lot of Oreimo season 2 or Haruhi's Endless Eight left you with... And Log Horizon... well, Log Horizon was wonderful. No, scratch that, it was nyanderful. I have no words for how well this show was made, how well planned, well written and well executed it was. I am a bit concerned about how soon season two is gonna come, in particular considering how most of the novels so far has already made it into season one - there's just not very much material left at the moment, and I don't think Touno-sensei will be able to finish two or so more books in time for the anime's production... I guess I'll just have to have faith in the producers and Touno-sensei. As mentioned before, I guess it's simply going to be a 1-cour season i.e. about 12 episodes instead of the first season's 25. And finally... Takao, Kobeni, Nibutani, Shino and Akatsuki ftw! (Whew... and it's 5 am again already, damn it...)

Well, it's April 2nd over here by now, so here's more details... ...and more on the technical side:

I was looking through some non-model files in OoT 3D out of curiosity, and am pretty sure I stumbled across at least the vertices and some textures for... something. It's not in the same format the rest of the models are (cmb) - in fact, I have no idea how anything besides the vertices works yet - but at least the textures can be converted using existing code. Seems to be at least two different models, too. I hacked together some basic code to render those vertices as "point clouds", the result of which you can see in the spoiler below. One of the two models looks familiar, too, but I can't quite put my finger on it... ...also, have the textures I mentioned:

To paraphrase Arcaith: No drama, please. Not regarding Cen's latest multiplayer hack, not regarding any past ones, whether spinout copied Cen's work or not, etc.

I'd honestly like to be very cynical and sarcastic about this right now because it's Cen, but I won't for various reasons, one being that this actually looks interesting and I'm curious about how it works - his words of "this works theoretically with any stock, unmodified emulator" make me think it might be supported by a separate program that hooks to several running emulator instances and monitors/modifies their emulated RAM, because the minority of N64 emulators support netplay as far as I know (haven't messed with netplay much). ...and damn it, Airikita, posting while I'm typing, mentioning (I assume) the same emulator connection method I mean I don't think this is internet-based, tho, and only works on one local machine.

There's also marshallh's 64drive, and some other flash cart ("Neo Myth 64"?) that uses that manufacturer's GBA flash carts as storage, instead of standard SD or CF cards, or something weird like that. There are multiple options for pretty much every cartridge-based system (besides some Sega ones, where there's only the respective Everdrives?), so you can pick based on what features you need, game compatibility, the price point, etc. You can still find copiers from back in the day even - Doctor V64, Z64 and co. -, although I don't think those are a very viable solution nowadays anymore. Well, maybe if you can get one for dirt cheap... which, granted, isn't too likely for N64 copiers.

As mentioned on the shoutbox, implementing this might take a while, as my knowledge of skeletal animation and skinning when it comes to modern OpenGL is extremely limited. I can think of some hacky workarounds that would probably bypass the whole point of using more recent OpenGL functionality, but might just work for the moment... we'll have to see. Finally open-sourcing the whole thing would be a good idea, too, so that other people can ponder over and experiment with this. Think I'll do that soon-ish, probably next week...