Cody Russell

Users sometimes piss me off

Some of these people in the NeoEngine forums are starting to really piss me off. Basically, they seem to have a bug up their asses because our primary development platform on Windows is Visual Studio, and they don’t have Visual Studio and don’t want to buy it. Instead, they use Dev-C++, which is a free C++ development platform. However, they don’t appear to like it enough to want to maintain the project files for it.

Mattias has been nice enough to take the extra time to install Dev-C++ and make some project files, but he doesn’t always update them whenever changes are made to the engine. So today, while we’re still working on getting the new logging system to work perfectly on our own compilers (MSVC and gcc), some fucker comes and starts bitching about how stuff isn’t compiling on Dev-C++.

Mattias said some nice things about Dev-C++, but said basically that it wasn’t good enough for him to use for his own use, and some guy starts saying stuff like, “Yeah, well I could say that NeoEngine sucks because it doesn’t do this, this, and this…”. Another guy whines, “Yeah, well while I’m paying $200 for Visual Studio, why don’t I just go ahead and pay another $100 for Cypher3D?” and I’m all like, “Yeah.. go spend your $100 like that and piss off.”

I’m sure most other Advogato hackers suffer from pissy, greedy, and insensitive users as well. I apologize for being nasty, I’m just venting. Ignore me if you want.

Engine hacking

Looks like splitting the audio code out is either not happening, or is happening much later. Mattias convinced me that it’s a very low priority at best.

I finished up the namespace stuff on Windows this morning, so now the engine and all immediately relevant libraries have been converted.

Tonight I’m finishing up the new logging code. I’ve got it working, but it needs a little bit of cleaning up before I install it. This will be another fairly big project since I want to completely remove the printf()-style logging stuff, and that means converting the whole engine plus all relevant libraries. *sigh*

Das über-patch

Committed a 1.5 meg patch to NeoEngine, but then the stupid SourceForge mail server bounced the mail that was auto-sent to the neoengine-cvs mailing list because it was too big. SourceForge sucks. The patch was installed just fine, but it wasn’t announed on the mailing list.

Since then, I’ve committed several small patches to the other modules to try to update them with respect to the big one. This has, without a doubt, been the most boring hack in history for me. It took the greater part of yesterday and today to get everything working right, and there are still a few missing things. Since I was working from Linux, I didn’t update the DirectX 9 device yet, so I need to reset to Windows to do that later.

Another mundane job that needs to be done still is moving all the audio code out of the main cvs module, since it is basically not being maintained very well, and move it into a new cvs module. I’ve never really been a big fan of having the audio code in the main engine anyway, so this will be a good thing I think.

Realsoft3D exporter

I haven’t touched it in weeks, and the Realsoft3D guys are getting restless so I think I need to get back to work on it after all this engine cruft work is done.

One cool thing is that Mirco has apparently figured out all the weird stuff of exporting the SDS data, so I’ll incorporate his work there into the exporter.

Miguel

Congrats to Miguel for getting married on Friday!

C++ Streams

I’m learning more about C++ now, figuring out how streams work. I’m rewriting the logging system for NeoEngine to use C++ streams instead of printf()-style output. That way we can write inserters for classes like vectors, matrices, quaternions, and pretty much anything else we want.

I want more functionality than just cout, though. You’ll be able to attach multiple data sinks to one source (stdout, file, or in-engine console) and set a loglevel threshold on each one. Then when you log something you can set the loglevel of it with a manipulator and it will only send that data to the data sinks that are listening for that loglevel or better.

For some reason it feels sort of weird to mention C++ and Miguel in the same blog..

Last concert

Our last concert was last night. Woo! Definitely glad to be finished with it. There was a party last night after the concert, but I just didn’t feel like going.

Tripping to Philly again..

Today I’m driving Lesley to BWI airport, then I’m off to Philadelphia again to see Mr Iizuka. This gig I’ve been playing at was an outdoor gig, and after several weeks of playing outdoors I think the excessive humidity has not done wonders for VLA THE IMPALER.

Car Problems

On Saturday my car stopped working, and I was worried that I wouldn’t be able to go to Philly today. But I managed to find an auto place that was open on Sunday, and they fixed it. My alternator had gone out, which really sucked because it cost a lot to get fixed.

ARB code

I didn’t expect to get the new vertex buffer committed until I got back to Texas, but Cameron helped me get it onto my school shell account the other day. I found a bug in the code after putting it on there, though, but once I fixed that I went ahead and committed it. I removed the NV vertex buffer from the Makefiles, but went ahead and left the NV sources in cvs for now.

Namespaces

I did part of the namespace change for NeoEngine last tonight and this morning, but I’m definitely going to wait until I get home to commit it.

Update: Happy birthday, Uraeus!!

Working around weird driver bugs is cool

Well, cool enough anyway. Fixing the bugs would be better, but, alas, NVIDIA doesn’t give us the source.

We were having a problem in NeoEngine recently due to a bug in the NVIDIA drivers (and because of the beloved unified driver architecture NVIDIA uses, this happened on all platforms: Windows, FreeBSD, and Linux) where it was crashing the client when a certain set of GL commands happened. It was difficult to debug since it was an internal driver error, and it only happened on one particular Quake3 map so it wasn’t worth the trouble of really figuring out what was going on.

Anyway, it was apparently a bug when using a certain sequence in vertex arrays. My new vertex buffer code using the ARB extension fixes the problem, which is very cool. I’m happy.

ATI hardware on Linux

ksuther on #macdev was telling me today that he uses a Radeon 9700 on Linux and it performs reasonably well using the FireGL driver provided by ATI. This is encouraging news to me. I would like to compare the performance between ATI and NVIDIA hardware on Linux, but he and I have quite different hardware (I have an Athlon 1000mhz and he has an Athlon XP 2800+).

People using Linux with fairly high-end hardware (say, Athlon XP 2800+ and NVIDIA GeForce FX 5600 or better), drop me an email sometime and I’d like to do some tests between these systems.

It’s not likely that I can do a really good test since I doubt I’ll find either two people with the same hardware (other than video boards) or find one person with one machine and two high-end video boards. But a general, rough estimate would be interesting.

NeoEngine

I finally took the time to implement a new vertex buffer and manager for the OpenGL renderer. This one uses GL_ARB_vertex_buffer_object extension. Using ARB vertex buffers is a really good thing, and we can now ditch the NV_vertex_array_range vertex buffer for NVIDIA hardware since they’re support the ARB extension on all hardware now. Unfortunately we still need to keep the ATI_vertex_array_object support because it seems that ATI doesn’t yet support the new ARB extension on their Radeon Mobility chips. So once this gets committed, everyone with NVIDIA boards and everyone with non-Mobility Radeons will use the ARB code. Reducing the number of code pathways for different vendor hardware is always a good thing, so I’m glad I finally did this. I’ll commit next week when I get back to Texas.

I have lots of other cool ideas that I’m going to pursue once the terrain system is committed. More details later.

Usability Tests

I was reading some story on Slashdot about usability comparisons between KDE and Windows XP. There is some discussion about whether KDE/GNOME will ever catch up to Windows, despite the fact that the article puts KDE right behind Windows XP.

I would argue that these sorts of tests are not thorough enough because the usability tests only cover the most mundane of tasks, such as creating files and directories, burning CDs, and things like that.

Usability tests really should be divided up into various categories, I think. Configuring the system services and hardware should be an important part of usability tests, I think. Installing drivers, configuring network and PPP dialup settings, and installing applications should be parts of usability tests as well.

Although not strictly a Windows vs KDE vs GNOME test, I think usability testing between standard sorts of applications such as word processors would be beneficial in these sorts of tests as well.

So, while KDE came in a very close second in this recent test, I think these further tests would put it (and GNOME) far behind Windows XP.