It is a game engine but, fortunately, that no longer means that we have to circumvent the OS. I've been in the game industry on and off for a very long time and I have bad memories of what we had to do in the 'old days'.
These days, we don't have to do such things to get performance but there is still a wide variation in graphics hardware and quite a few display driver bugs that we have to work around. I know that recently (unfortunately post LDD-1.4), we fixed some problems that stopped the program working on very old ATI hardware using the r128 chipset.
Ideally, we would like the software to work on any machine that you can install it on but the incredibly wide spectrum of PC hardware makes it difficult to test all combinations.
What kind of hardware do you and you brother have? What CPU speed, memory size, graphics card etc. Also, make sure you have the latest graphics drivers installed - it really does make a difference.
I work for the company that writes the LDD software but I do not speak for the Lego company. The underlying 3D engine that is used by LDD does support Linux - you can find a free download at http://qdn.qubesoft.com./ I can't promise a Linux version of LDD any time soon but I know that one of the LDD guys recently built a Linux box out of some spare parts with the states intention of porting it...
In the FreeBSD project, we have a significant amount of code which is shared between several similar projects (NetBSD, OpenBSD, DFBSD and others). Having shared files include version control tags from all sharing platforms life a lot easier for the people who merge changes back and forth between the systems.
Still, I don't speak for the FreeBSD project and while it is my opinion that the lack of user-defined keywords is significant, the need for a viable cvsup replacement is a much bigger problem. Whatever, the decision to change version control products is not mine to make. If the project does move to subversion, I imagine it would only happen after a long process of testing and evaluation and that process hasn't even started.
The G400 works just fine under FreeBSD with XFree86 4.0.1, including DRI-based 3D support. We also support voodoo3. Other drivers will probably follow when I work out a way to share more of the driver source code betweem the two operating systems.
I created the ia64 directories in CVS so that I can generate patches easier. I'm currently roughing out the kernel port to ia64 and I expect to commit code over the next few months.
Re:freeBSD compatability problems...
on
Which BSD?
·
· Score: 1
This is only a problem booting from CD on some CD drives. It was fixed soon after the problem was discovered. You can still use the CD which you have by building a pair of boot floppies from the images provided on the CD.
This is almost certainly a problem with using NFSv2. The correct behaviour for an NFSv2 server is to perform all write requests synchronously which reduces performance significantly.
Some NFS servers can change this behaviour to improve performance but I would not recommend it since it can cause data loss if the server reboots unexpectedly. For FreeBSD, the command 'sysctl -w vfs.nfs.async=1' will improve the performance of NFSv2 clients.
-STABLE doesn't have some of the VM changes which detstabilised NFS in recent -CURRENT kernels:-).
I would not go so far as to say that NFS in -CURRENT was perfected but it does look good with Matt's latest patches. I really must review them properly and try to help get them committed into -CURRENT...
All of the *BSD family have NFSv3 support since it was part of the original 4.4BSD-lite2 release. The performance of FreeBSD's NFSv3 implementation is pretty good (good enough to do software development on an NFS mounted driver without appreciable performance loss which is what I do regularly).
The two stage write-commit protocol of NFSv3 is necessary to get any kind of performance out of NFS without gross hacks at the server and which violate the protocol semantics.
While there are some obscure bugs in FreeBSD's implementation of NFS client under very high loads (many of which are fixed in FreeBSD-current or will be fixed by pending changes to FreeBSD-current), I believe it to have extremely good performance. The attribute cache which was introduced in FreeBSD-3.x reduces network and server load significantly.
I am biased since I work on the FreeBSD kernel and in the past have been involved with fixing and optimising the NFS client but I also use NFSv3 on a regular basis and see excellent performance with 100baseTX (I haven't measured performance for about a year but I seem to remember multiple Mb/sec write performance).
I can't comment on Linux performance since I have only tested RedHat 5.2 (which has terrible NFS performance, IMHO) and I believe that many improvements have been made in the 2.2.x kernel series.
Slashdot Mirror
It is a game engine but, fortunately, that no longer means that we have to circumvent the OS. I've been in the game industry on and off for a very long time and I have bad memories of what we had to do in the 'old days'.
These days, we don't have to do such things to get performance but there is still a wide variation in graphics hardware and quite a few display driver bugs that we have to work around. I know that recently (unfortunately post LDD-1.4), we fixed some problems that stopped the program working on very old ATI hardware using the r128 chipset.
Ideally, we would like the software to work on any machine that you can install it on but the incredibly wide spectrum of PC hardware makes it difficult to test all combinations.
What kind of hardware do you and you brother have? What CPU speed, memory size, graphics card etc. Also, make sure you have the latest graphics drivers installed - it really does make a difference.
It would also be useful if you could try running the game engine demos at http://qdn.qubesoft.com/index.php?main=downloads or another product using the same engine, such as http://www.earthsim.tv/
I work for the company that writes the LDD software but I do not speak for the Lego company. The underlying 3D engine that is used by LDD does support Linux - you can find a free download at http://qdn.qubesoft.com./ I can't promise a Linux version of LDD any time soon but I know that one of the LDD guys recently built a Linux box out of some spare parts with the states intention of porting it...
In the FreeBSD project, we have a significant amount of code which is shared between several similar projects (NetBSD, OpenBSD, DFBSD and others). Having shared files include version control tags from all sharing platforms life a lot easier for the people who merge changes back and forth between the systems.
Still, I don't speak for the FreeBSD project and while it is my opinion that the lack of user-defined keywords is significant, the need for a viable cvsup replacement is a much bigger problem. Whatever, the decision to change version control products is not mine to make. If the project does move to subversion, I imagine it would only happen after a long process of testing and evaluation and that process hasn't even started.
NetBSD doesn't have ia64 yet. Of course, they are welcome to use the FreeBSD/ia64 low-level code as a starting point for a port...
The G400 works just fine under FreeBSD with XFree86 4.0.1, including DRI-based 3D support. We also support voodoo3. Other drivers will probably follow when I work out a way to share more of the driver source code betweem the two operating systems.
I created the ia64 directories in CVS so that I can generate patches easier. I'm currently roughing out the kernel port to ia64 and I expect to commit code over the next few months.
This is only a problem booting from CD on some CD drives. It was fixed soon after the problem was discovered. You can still use the CD which you have by building a pair of boot floppies from the images provided on the CD.
FreeBSD 4.0 uses a single kernel lock currently. That may change before release depending on whether someone competent does the work.
This is almost certainly a problem with using NFSv2. The correct behaviour for an NFSv2 server is to perform all write requests synchronously which reduces performance significantly.
Some NFS servers can change this behaviour to improve performance but I would not recommend it since it can cause data loss if the server reboots unexpectedly. For FreeBSD, the command 'sysctl -w vfs.nfs.async=1' will improve the performance of NFSv2 clients.
-STABLE doesn't have some of the VM changes which detstabilised NFS in recent -CURRENT kernels :-).
I would not go so far as to say that NFS in -CURRENT was perfected but it does look good with Matt's latest patches. I really must review them properly and try to help get them committed into -CURRENT...
All of the *BSD family have NFSv3 support since it was part of the original 4.4BSD-lite2 release. The performance of FreeBSD's NFSv3 implementation is pretty good (good enough to do software development on an NFS mounted driver without appreciable performance loss which is what I do regularly).
The two stage write-commit protocol of NFSv3 is necessary to get any kind of performance out of NFS without gross hacks at the server and which violate the protocol semantics.
While there are some obscure bugs in FreeBSD's implementation of NFS client under very high loads (many of which are fixed in FreeBSD-current or will be fixed by pending changes to FreeBSD-current), I believe it to have extremely good performance. The attribute cache which was introduced in FreeBSD-3.x reduces network and server load significantly.
I am biased since I work on the FreeBSD kernel and in the past have been involved with fixing and optimising the NFS client but I also use NFSv3 on a regular basis and see excellent performance with 100baseTX (I haven't measured performance for about a year but I seem to remember multiple Mb/sec write performance).
I can't comment on Linux performance since I have only tested RedHat 5.2 (which has terrible NFS performance, IMHO) and I believe that many improvements have been made in the 2.2.x kernel series.