Tag Archives: Hate

Gorgon v1.x – Visual Studio 2010

I’m updating the solution and projects for Gorgon 1.x in the Subversion respository to use Visual Studio 10 .  The current binary release still uses Visual Studio 2008 and will continue to do so until a new release is put up.

If you are freaking out over this because it’ll somehow be the end of everything you love and hold dear, stop whining and get the express version of VS 2010 here.

Please note Gorgon still uses .NET 3.5 SP1 and you can use the binaries with Visual Studio 2008.  Again, you only need Visual Studio 2010 to compile the source for Gorgon.  I cannot stress that enough.

New version tiem! Gorgon v1.1.3436.39405

sitelogoYes, I know I spelled “time” wrong.  Yes, it’s on purpose.

I’ve uploaded  a new version of Gorgon today.  That puts the current release at version 1.1.3436.39405.  You can read what’s changed by heading on over to the forum and reading this announcment.  After you’ve become completely brainwashed by reading that you can download it.

Clearly I’m still working on Gorgon.  I probably will be until the day I expire, which given my healthy intake of McDonald’s, should be any day now.  If someone wants to lend a hand, contact me via the forums.

Edit – May 29/2009

Because I’m very dumb, I released Gorgon with a nasty bug in the Batch sprite object.  When you use the batch sprite it will complain that it can’t find the vertex declaration for PositionNormalDiffuseTexture1 or some such nonsense.  This of course just totally breaks the Batch sprite.  It’s been fixed and the new version (v1.1.3436.39405) is uploaded.

Sorry about that folks, sometimes Tape_Worm is stupid like ox.

How to annoy me.

sitelogoJust a quick notice.  I think it’s great when I get questions about Gorgon.  And I do my very best to answer what I can as accurately as I can.

However.   I do NOT want questions about how to use libraries created by other groups/people.  I have no problems explaining Gorgon’s inner workings for this purpose, but that’s as far as it goes.  I won’t be transforming it into any other library, that’s your job.   I am not tech support for any other library.  If you want support for another graphics library go to their forums and ask the creators of that library.  If they don’t support their stuff, then that’s tough, take it up with them through whatever means available to you.

Don’t take this as trying to be secretive/anti-competitive about Gorgon or its inner workings.  If I wanted it to be secretive I wouldn’t have released it or the source for it.

End of Line.

Intel needs to STOP making video cards.

Because they’re TERRIBLE at it.  Yesterday I got a bug report about Gorgon displaying nothing but corrupted garbage on an Intel 945 Express chipset.  Of couse my alarm bells when off when I read the word “Intel” and I immediately set out to find someone else to confirm this.  Of course, finding someone with these older chipsets is like trying to find gold in my toilet and thus I had no way to confirm or even know where to start. 

That is, until today when I remember that the machines in the office all have onboard video in addition to having Radeons.  I checked the computer next to me and lo and behold it had an Intel 82865 integrated nightmare.  So I set it up for development with Gorgon and found the issue that was causing the corrupt graphics.  Lo and fucking behold.  It turns out to be, wait for it… a driver bug

Here’s what went wrong:
My code creates one vertex buffer to display the sprites.  It never, ever, ever, changes the structure of the buffer, nor does it have any other reason to re-create the buffer.  All it does is modify the contents of the buffer.  So with this in mind, I only call SetStreamSource once for the lifetime of the application (except in cases of a device reset) – this is a performance thing, while not terribly slow, it still helps speed things up a tiny bit.

So in my search to find what’s wrong I run the ball demo through PIX (which is godly) and get a snapshot of my vertex buffer in action.  For my test I had set up 2 sprites, each using a different texture so it’ll force a flush of the renderer.  Sprite 1 was sized 64×64, sprite 2 was 200×56.  The first sprite was displayed in the upper left of the screen at (0, 0) and the 2nd was place at the lower right (600, 544).  When viewing the contents of the vertex buffer when it was submitted to DrawIndexedPrimitive I saw this for the first sprite:

  • Left, Top coordinates: 0, 0
  • Right, Bottom coordinates: 64,64

That’s correct for the first sprite, but here’s what I got in the vertex buffer for the 2nd sprite:

  • Left, Top coordinates: 0, 0
  • Right, Bottom coordinates: 64,64

Clearly the second sprite is not writing to the buffer.  But why?  So on a hunch i found culprit:  SetStreamSource.  Like I said earlier, it’s only called once to bind the vertex buffer.  So I set it to be called every frame and sure enough, the application worked. 

Here’s why it’s Intel’s fault:
On some advice I ran the program with the reference rasterizer and using the debug runtimes (which I always check first anyway). 

The reference rasterizer is the guide to indicate how D3D is SUPPOSED  to behave.  And when an app doesn’t behave the same way on the refrast as the hardware, then the drivers are in question. 

Anyway, I was concerned that I was doing something wrong by only calling SetStreamSource once, even though it worked on just about -every- piece of hardware that I’ve been using.  So I ran my original code through the refrast and sure enough – it worked.  Thus, the intel driver is broken. 

I think for any other projects that I publish (not including Gorgon since I’m already in too far), I won’t be supporting Intel’s buggy drivers.

Blogs are for idiots.

And thus why I did this.  Plus I’m wanting to move away from my gamedev journal, it’s… yeah, it’s just fucking bad.

So from here on, all Gorgon related announcements will appear here and my rants, which are just fucking awesome, will appear here as well.  Any future projects will have announcements here as well.

So yeah, it’ll be updated every time a random random number generator in a random country returns 3.5322874.  Which is quite often if you have a life expectency of 150,000 years +/- 2.125 years.