Chronic Logic

I don't think speed should be uncapped.  kvinge was onto something, it could lead to serious problems with collision detection when objects move too far between calculations.  I'd just like to see the cap increased since the train really doesn't move very fast at all at its top speed.  It seemed to be able to move much faster in the original Bridge Builder.

The HAV does seem to be able to go faster than trains, but a 10-car train seems to be about as slow as a 1-car train when running down a slope.

I think the speed of the train is capped too.  I've tried to make levels with a huge approach slope to get the train moving quickly, but it doesn't really work.  I wanted to make a jump and have the player try to build something strong enough to catch the train.  http://www.pontifex2.com/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'>

I'm the friend with the Intel 550 and the GF2 Pro.  http://www.pontifex2.com/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'>  Thedoc, I'm guessing that your Athlon 1.4GHz doesn't have a problem handling all the transform and lighting that your TNT2 can't do, but his Athlon 800 does have issues with it.  Handling the physics engine for thousands of links, plus doing the polygon transforms for them is just too much.  You can tell that your computer isn't fast enough when "fast" doesn't speed up the train at all.

It's my feeling that a lot of optimization of the graphics engine could be done; for instance, optimizing the terrain rendering as mendel mentioned.  I'd be happy to offer any sort of assistance in getting the game to run faster.

I've noticed that the 'build' sound will just stop working on my system.  I build several links, and hear the sound, and then any more that I add don't produce a sound at all.  I still get the sound for removing links, and I still get train sounds when I run with the train-cam, but the building sound is gone.  To get the build sound again I have to restart Pontifex, and it only lasts for a few links anyway, so it's not really worth it.  I actually have two sound devices, one is an SB64D integrated into the motherboard (it's Gateway's SB64 with a digital output), and the other is a true legacy ISA SB16.  I'm not sure what could cause this; maybe when the build sound is played, it fails to close the sound channel, until they're all filled up?  But then I would think it would screw up the rest of the sounds, unless they each have a dedicated channel.

(Edited by Entroper at 5:24 pm on Oct. 23, 2001)

Er, I see his bridge is already uploaded, see the "short-link physics bugs" thread for a link.

If you put in the longest diagonals, it's even funnier looking to watch.  I built a simple 1-unit wide box, putting in every possible diagonal beam everywhere.  When the sim starts, the box is floating in mid-air... and it just pops immediately, throwing the remaining pieces of it in random directions, some up, some down.  It actually had my two roommates and I falling over laughing when we watched it explode on the "fast" setting.  http://www.pontifex2.com/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'>

Anyway, beaujob has created a level with varying tower designs, and it basically verifies that the more beams that intersect at a single point, the worse the 'exploding factor' of the tower.  I'll have him upload it to the Serious Fortress server so you guys can all see what's going on firsthand without having to reconstruct our designs.

It seems if you build lots of cross-pieces in a tower, the entire tower will break instantly upon starting the simulation.  The tower is constructed like this:

http://www.seriousfortress.com/images/SeriouslyForums/BridgeBuilder/riptower/scsht000.jpg" border="0">

At the beginning of the simulation (note that "pause" is activated), the tower looks like this:

http://www.seriousfortress.com/images/SeriouslyForums/BridgeBuilder/riptower/scsht001.jpg" border="0">

Immediately after unpausing, the tower looks like this:

http://www.seriousfortress.com/images/SeriouslyForums/BridgeBuilder/riptower/scsht002.jpg" border="0">

Now, it occured to me, as I'm sure it will occur to many of you, that perhaps the tower is too heavy to support its own weight.  But you would think it would have to "settle" first, and then only the bottom links would be destroyed.  I further studied this by creating a simple box in midair, so that it would freefall toward the ground, and should have no stress whatsoever.  Results:

http://www.seriousfortress.com/images/SeriouslyForums/BridgeBuilder/riptower/scsht010.jpg" border="0">

http://www.seriousfortress.com/images/SeriouslyForums/BridgeBuilder/riptower/scsht011.jpg" border="0">

http://www.seriousfortress.com/images/SeriouslyForums/BridgeBuilder/riptower/scsht012.jpg" border="0">

Perhaps this is some sort of quirk in the physics?  If I were to take a stab in the dark, I'd say that floating point errors are accumulating... I had the same problem in a 3D program I wrote, where a series of rotations screwed up a model's orientation, and really funky things happened to it on the screen.  Maybe if too many beams are putting pressure on each other at once, the same sort of thing happens, and instead of putting insane stretches on a model, it puts those stretches on the beams, causing them to snap almost immediately.

Because it's better.  http://www.pontifex2.com/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'>

That, and Direct3D isn't portable to any other OS.  So if CL wants to make a Mac version and a Linux version, OpenGL is the (only) way to go.

Thanks for giving me credit for the stack thing, beaujob.  :P  But anyway, that's interesting that all the vertices are still there.

My theory is that links are allocated dynamically, but that there's an array of pointers to link objects which overflows at around 16,000.  Interestingly, pointers are 4 bytes, and 4x16,000 is roughly the size of a 'segment' in memory.  The stack used to be typically limited to a single segment due to interesting issues with x86.  http://www.pontifex2.com/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'>  So that's why I thought it might have something to do with running out of stack space.  But it may have nothing at all to do with the stack, and just be a freak behavior of segments and such.  I don't think the array of links would be statically allocated.  http://www.pontifex2.com/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'>

Yeah, 32-bit registers are cool.  Which is why I'm still confused on this one.  I keep trying to think of other things that could mess it up, because it seems like an artificial limit would be more likely to make the new links disappear than the old ones.

I think you guys handled it the right way -- whenever there's a question of fairness, take it to the judge.  http://www.pontifex2.com/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'>  It was interesting how you found out about it too.  Anyway, kudos for doing the right thing.  If people had submitted similar bridges with a noticeable difference in cost, there could've been a big mess about disqualifications and things like that.

Be careful when you say "American time"; the contintental U.S. spans four time zones.  http://www.pontifex2.com/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'>  7:00 p.m. EST or 4:00 p.m. PST are after the deadline.

What I'm talking about IS the out of box drivers.  If an OEM is ordering lots of GeForce cards from a company, they're probably installing the drivers that come with the cards.  Those drivers do, or should, provide OpenGL support.

I suppose if you buy from an OEM, they'll have the drivers for all the hardware installed for you.  And if you build your own, it's your responsibility to install drivers.  Besides, I would think if you don't have the latest drivers for your videocard, Direct3D apps would also run incredibly slow, since it would all be emulated in software.