A tutorial? Now I is professional.

sitelogoSo ShadowDust702 was kind enough to create a basic getting started tutorial and put it on the wiki.  This makes it look like Gorgon actually has some interest.  Who knew?  Anyway, the tutorial is here.  If you would like to contribute to the cause, then by all means do so and let me know on the forums so I can tie it all together.

June 1, 2009 • Tags: , , , • Posted in: Programming • Comments Off

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.

Bugs bugs bugs

sitelogoI just noticed an issue in the issues section on the Gorgon project site…  It deals with localization issues with the Sprite Editor.  So if you’re finding the sprite editor is crashing, I apologize for that, there were some localization settings missing when reading the config files.  A fix is being worked on and will be available on the SVN repository asap.  The fix is now in the subversion repository.

May 17, 2009 • Posted in: Uncategorized • Comments Off

Batches of hate

sitelogoSo I’ve been a busy little bee the last couple of days adding a couple new features to Gorgon.

One of the things I’ve been wondering about is how I could possibly improve performance.  To understand, I should explain how Gorgon does its “thing”.  When you draw a sprite to the screen using the Draw() method the actual data doesn’t go to the current render target (screen for our purposes) right away.  What happens is the vertices for that sprite are added to a dynamic vertex buffer.  If the next sprite you draw has the same texture and states as the previous (which will most likely be the case if you perform batching properly) it will just add that sprite to the dynamic buffer and the process continues over and over until the end of the frame.  When the end of frame is reached the buffer is drawn to the screen and the buffer is ‘reset’, that is, all data in it is overwritten with our next frame.  This is all well and good if you only use the same texture and render states (Smoothing, Blending, etc…)   But let’s say we have 3 sprites.  The first 2 sprites share a texture and the last uses a seperate texture.  When the first two are drawn they get added to the vertex buffer and then when the 3rd sprite is drawn the system detects a change in state (in this case it’s the texture) and the buffer is flushed and process starts over with our third sprite.  As you can imagine this can be very inefficient, but if you batch sensibly you’ll see excellent speeds.

So I got to wondering… How can I use this batch methodology to display data even faster?  Dynamic vertex buffers are quick, but they’re snail-like compared to a static vertex buffer.  Of course, the caveat of the static buffer is that it’s just that:  static and incredibly slow to fill over and over in a real-time situation.  However I thought that maybe we wouldn’t need to make changes to the buffer if all we’re doing is displaying a group of sprites as a background or drawing lots of text and we can take advantage of the static vertex buffer.

Thus, the Batch object was created.  Basically it batches your sprites/text sprites in such a way that the system can draw a LOT faster.  More accurately it acts like a snapshot of your sprites.  By calling the AddRenderable method you can attach any sprites that support batching (via the internal Renderable.GetVertices method) and it will store the retrieved vertex data in a static vertex buffer.  The system will even optimize the order of the vertices such that the most common shared textures get rendered first and will group the vertices by texture.  Because it groups by texture a single batch object is capable of  store multiple and drawing objects with differing textures (this incurs a small penalty of course).  The setup is obviously not the fastest thing in the world, but once the buffers are built and running the results are impressive:

Left: The immediate mode (Dynamic Vertex Buffer) Draw function from TextSprite.
Right: The batched mode (Static Vertex Buffer) which uses the exact same TextSprite but draws it via the Batch object.

Notice the HUGE speed difference.  Naturally nothing comes for free and there are caveats to using this thing.  Namely your batched sprites can’t be transformed after they’ve been drawn (unless you refresh the batch and that is too slow for real-time framerates) and any transformations affect the whole batch as a single entity, the same for states like smoothing or blending.  So you’re wondering what use is this?  Well, as you see, if you have a lot of text you can draw it very quickly.  Or, if you have a tile map where the tiles are static you can basically blit (and transform) the entire map at very little cost.

Edit
I’ve posted a video on youtube showing this stupid thing in action with over 100,000 sprites with a large block of text:

MOAR!!! NAO!!!

sitelogoAhoy hoy.

I’ve actually been working on Gorgon off and on (mostly off) throughout the last 2 weeks and I’ve sent a few new changes to the svn repository:

So there you have it.  Hopefully the zip file support will be a plus.  I have no idea when a packaged release will be available, but when it is I’ll make sure to announce it.

Gorgon SVN

sitelogoSmall update.  I’ve updated Gorgon’s code in the subversion repository to use the March 09 version of SlimDX.

End of Line

April 1, 2009 • Posted in: Uncategorized • Comments Off

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.

April 1, 2009 • Tags: , , , , • Posted in: Idiocy, Programming • Comments Off

Oh boy!

sitelogoI’ve had a couple new people join the forums lately, I’m so pleased.  For a while I started to think that all life in the world outside had died off and was replaced with spam bots.

One of our new members is Gourky and he’s writing a  CNC (Computer Numerical Control) CAD program called GGCad that uses Gorgon.  This is awesome because when I designed Gorgon one of my goals was to make it useful outside of the gaming field and now it’s actually being used for such a purpose.  Yay.  Gourky was also kind enough to give out the source code to a control he’s built to scroll a Gorgon render window.  How awesome is that?

I’ve added a screenshot of ggcad to the user screenshots section.

In other news, I’m still terribly busy with real life shit.  But I’ve also started work on another project (although with the limited time I have it’s going to be a very very very very very long time before it even sees the light of day, hell DirectX 15 might be out before I release it) which uses DirectX 10.

Spammers are child molestors

They are. And they need to be hunted down and killed.

Anyway, this leads to this:
The forum has been getting a LOT of signups from spam bots lately. To the point of where I’ve begun banning subnets. Seriously morons, use a virus scanner and some common sense and keep these damn things off your system(s). If you’re a legitimate user from one of the subnets I’ve denied, then I’m sorry to say that you’re out of luck. I hate being an asshole about it, but frankly some places have more zombied machines/spammers than others and that’s just the way it is. If you don’t like it, do something about it. Hunt these fuckers down and cut their nuts off. They’re making it bad for the honest user.

That means that I’ve started cleaning out the shit from the forums.  And by shit, I mean spam bots and their owners.  It’s getting on the stupid side of things lately.  I’ve had several attempts at adding accounts by confirmed spam harvesters.

February 8, 2009 • Posted in: Uncategorized • Comments Off

Hate. VB. Hate. Database.

Work is overrated, I don’t recommend it.

I disabled comments because I’m just getting pummeled by spammers and no legitimate comments.  So I say fuck it and fuck you spamming cocksuckers.

If you have an urgent need to discuss Gorgon or whatnot please use the forums.

February 4, 2009 • Posted in: Idiocy, Programming, Real life • Comments Off

Gorgon v1.1.3266.898

sitelogoA new version of Gorgon has been released.  The current version is now 1.1.3266.898.  This fix includes some enhancements to the sprite editor animation editing interface and several bug fixes.  You can see the change list here.

This will be the final release for Gorgon for a while.  I’m going away on vacation at the end f the week and real life (i.e. work) has become increasingly busy so I have no time to devote to Gorgon at least until later in the new year.  If someone wants to pick up the reins and take over for a bit, post a comment here or contact me through the forums.

Helps

sitelogo

So I’m at a bit of a crossroads here.  I plan on releasing a new version of Gorgon by the end of next week (then I’m on holiday in Winnipeg… I need my head examined).  I’m running out of steam for working on Gorgon.  And I think I’ve done as much as I want to do with it.  It’d be a shame to give it up and just let it die, I did put a lot of time into it. 

So with that in mind I’d like to put a call out for help.  Basically I need someone other than myself to help with maintaining the code, and so on.  So if you like Gorgon and you think you can do it better, then please, leave a message either in the comments section or on the forums and we can get talking.  Even if you just want to write (or already have written) examples or tools for Gorgon, that’d be a help. 

Eventually I’d love to just leave this project in the hands of whatever “community” is interested in Gorgon and then I can go on my merry way.

Animation is fun

So I took on a major undertaking this weekend and fixed up some outstanding issues with the SpriteEditor’s animation editor system.  Mostly tweaks and bug fixes for the next release, nothing major.  The major undertaking was the new track view panel I added.

One thing that’s bugged me for a long time is that the animation editor never had a standard track view where you could add keys and see all the other tracks in relation to the track you were busy building.  The downside to this was that building an animation with multiple tracks could be tricky to sync up.  The reason for this is because in the public incarnation, the animation editor only has a combo box displaying the track names and a track slider to advance through the keyframes.  If I wanted to sync up a rotation to match up to a position key frame, I’d have to switch back to the position track find the key, make a mental note, switch to the rotate, add the key and pray it worked.  This of course was designed this way because I’m very lazy and wanted something quick.  No real animation package would work this way.  They all have this wonderful grid of boxes with each row representing the animation track and the cells indicating the individual key frames.  All very pretty, and very annoying to code.

But this weekend, I did this:
Behold the track system at the bottom.  And it’s got those funky glassy buttons that we all hate but secretly love because they do look fairly awesome.  I think it looks much better now.  And of course the thing is functional, if you click on a keyframe button, it’ll jump to that frame, and if you click on the track name, it’ll load the appropriate editor.  Assigned keys show up in blue, and so on, It’s just fantastic.   

One thing I ran into while building this behemoth (aside from the spectacularly shitty code I’ve written for the sprite editor in general) was that once an auto scroll has an AutoScrollMinSize of (32767, 32767) it stops responding to events.  What’s even more funky is that it still works, it scrolls right to the end even if the size is greater than 32767.  Unfortunately this causes issues for my animation system as you can have thousands upon thousands of keyframes if you so choose.  The solution to this hiccup was to make the keys wrap underneath after 1024 keys (1024 was the highest number of keys that could be displayed before the scrollbars went into overflow).  Of course, not the best solution to the problem, but it works.

Anyway, this will be included in the next milestone of Gorgon or if you’re addicted to subversion, you can grab the most recent build from the trunk.

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:

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

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.

Quicktime is a whore

Quicktime is garbage.  It’s ugly, slow and useless.  But more than that, it hijacks some file associates and MIME settings.

Tonight I spent about 2 hours trying to make Quicktime let go of the PNG MIME association.  Why?  Because every time I opened a PNG in IE7, the fucking thing would launch quicktime and use THAT to display the PNG.  So, instead of ranting on further about how awful quicktime is, here’s how you cut that piece of shit off:

  1. Run regedit.  Back up your registry – Be very careful about fucking with your registry, you can damage your install of Windows.  No, I don’t take blame if you’re too dumb to be careful.
  2. In the following places:  HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\MIMEAssociations\
    Delete anything to do with png, you’ll see keys like image/png and image/x-png.  Delete those.  Quicktime has placed those keys there.  Try out IE and see if you can display PNG files.  If you can, we’re done.  If not, see step 3.
  3. HKEY_CLASSES_ROOT( and KEY_LOCAL_MACHINE\Software\Classes)\MIME\Database\Content Type\
    Look for the following keys:image/png and image/x-png.  Do not delete these keys.
    In these keys you should have these two string values:
    Name: “Extension”, Value: “.png”
    Name: “Image Filter CLSID”, Value: “{A3CCEDF7-2DE2-11D0-86F4-00A0C913F750}”
    Only those keys should be there, remove any extra keys.
  4. For x64 users: Perform step 3 and include KEY_LOCAL_MACHINE\Wow6432Node\Software\Classes as well as the other two locations.

I hope this helps someone.  Because, Christ, there’s next to NO info on how to fix this problem.