Tag Archives: C#

MSAA (Gorgon v2.x – Dorian)

So, to prove that I actually do work on stuff, I’ve uploaded a new video to the youtubes.  This one shows off the ability to use MSAA in the new version of Gorgon.

https://www.youtube.com/watch?v=DhqrL3iVjDU

To get this effect, in v1.x of Gorgon, you’d draw a series of fading sprites (Alpha of 0 from the start position to an Alpha of 255 for the current position).  However, in this example I’ve used MSAA to simulate motion blur on a sprite.  Nifty eh?  On top of the nifty effect we also get full screen anti-aliasing, which is something the previous incarnation of Gorgon didn’t have.

Before you ask: no, motion blur will not be included as a function of the library, that’ll be up to the developer to implement.

The future.

I recently played around with my own library (see an earlier post about the sun effect) and I found it… well, lacking.  In my day job I do a lot of framework/library code for re-use amongst my co-workers and I’ve learned a great deal over the last few years of doing that professionally.  There’s a huge difference between writing a database/application framework and a graphics library, but, I’ve always been amazed how concepts from one architecture will map to another and as I developed Gorgon in my own time, I ported concepts to the framework code I write for my job and vice versa.  One major difference is that our framework code at the office is always evolving from project to project (granted, the pace of evolution has slowed somewhat), while Gorgon was written, and aside from bug-fixes, it never evolved because I never really used it except to prototype small things from time to time.  Until I wrote the Sun thingy….

Continue reading →

New version of Gorgon – 1.1.4119.34319

Yep, finally.  I’ve rolled up all the updates/fixes that were in the subversion repository and put up a new version of Gorgon.  Version 1.1.4119.34319 is the latest version and you can get it from here.  You can view the change log in this forum post.

Enjoy.

Sun

So, I bet you’ve been wondering what I’ve been up to lately…  You haven’t?   You selfish bastard.

 

Anyhow, I’ve gotten around to playing with this library I wrote for a bit.  I do so little programming on my own time these days and honestly, I never much cared for Gorgon (I felt it could have been better), that I haven’t bothered to try and write anything with it. That my users actually say it’s useful and well written comes as a complete shock to me. Anyway, this last week I mustered up some spare time and I created this abomination:

https://www.youtube.com/watch?v=PqPGa6P52LM

It’s not much, but it’s just a little thing I threw together to see if I could get a “bloom” type effect with a star.  I did.  And there it is.  Note how the surface of the star moves around and all that.  Neat hey?  No?  Shut up.

 

I’ve limited it to 60 FPS on purpose, but it is fairly swift.  I think at one point I was getting > 1000 FPS.  However, my vidja card is quite beefy, so take that with a grain of salt.  So… yeah…. that’s all I have to say.

Enjoy.

Kids… take my advice… don’t grow up

I’m sure people think Gorgon is dead.  Well, it’s not dead, but certainly not active either.  I’m pretty much done with writing for it (bugs being an exception).  If you’re interested in helping maintain it, please let me know via the forums.  My day job and my social life (which I’d neglected for too long) are a priority right now and I have very little motivation (or time)  to write anything related to Gorgon (or anything else).

That said, I do check the forums every day (at least twice a day).  So if you have a bug, or need a question answered, I will try to help.  Again, because of my “schedule” I may be a bit late in the replies (although ShadowDust702 has been doing a fine job of answering questions while I’m out drinki… er.. working).

Speaking of forums, forum member Cycor posted some code to convert GIF animations into Gorgon sprite animations.  You can view the code here (sorry for the late acknowledgment).

New version: Gorgon v1.1.3638.20767

sitelogoSo I’ve finally gotten off of my lazy ass and uploaded a new version of Gorgon.  This version contains all the bugfixes, and enhancements that have appeared in the Subversion repository over the last few months.

You can read about the changes here.

Then you’ll probably want to download it.

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.

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.

Continue reading →

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:

  • Modified the bump in the night sample (-again-) to allow better results when rendering specular maps and also to update a stupid mistake that I made.  That is, I added unicode symbols directly into the source code instead of using their respective codes.  While this hasn’t given me trouble yet, there’s always that possibility.
  • Modified the TextSprite object to fix an issue where the MeasureText function was not calculating the correct height for a block of text.  Also fixed an issue where the alignment settings would sometimes place the text in between pixels and cause the text to look jagged and unreadable.
  • Removed Mount()/Unmount() from the public interface of the FileSystem object.  These functions didn’t really serve any purpose and just made more work for the user.  Internally Mount() is still available as a protected method for plug-ins so that the file system index can be built after a root is assigned.  Sorry if this breaks anything.
  • Added support for MRT (multiple render targets)!  Finally!  This allows a pixel shader to output to multiple targets at the same time and should help out in performance situations where multiple passes are being used to achieve the same thing.  To manipulate the additional render targets you can call Gorgon.SetAdditionalRenderTarget to add/update/remove a render target or Gorgon.GetAdditonalRenderTarget to return one.  The previous property: CurrentRenderTarget is still in place and uses the SetAdditionalRenderTarget internally and is available for use if you’re only looking to switch the primary target.
  • Font objects can now load external TTF files.   While you could always do this by hand by using PrivateFontCollection and then creating a Gorgon Font object from the resulting GDI+ font, it was a pain the ass.  This new functionality will allow the reading of TTF fonts from various sources such as:  A TTF file on the disk, an embedded resource, from a stream, or from a Gorgon file system.  To load a font you just call: Font.From* (were * = Resource, File, FileSystem, or Stream) and it’ll import the font.  For luddites:  You can still create fonts directly from GDI+ font objects if you wish.
  • And finally, the one that caused the most cursing:  GorgonZipFileSystem.dll.  What’s that?  It’s a file system that allows you to manipulate zip files (you know, the files that Winzip generates).  Now using this plug-in the file system editor can open/create/update your zip files.  Or you can forego the file system editor completely and just use winzip.  There are some caveats however:  You cannot use a password, you cannot use encryption and the file format must be the legacy zip file format (Zip 2.0).  But yeah, awesome.

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 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.

Gorgon v1.1.3246.24958

It’s that time again.  A new version of Gorgon has been released into an unsuspecting populace to help spread terrorism and christianity at the same time.

There are multiple bug fixes, and these are detailed here.  The most fun thing is that I’ve included a new example that demonstrates how to make per-pixel lit (and bump mapped) sprites via normal maps.  It’s pretty spiffy if I do say so myself.

Other than that, the biggest change is the upgrade to the November version of SlimDX.  With this version the requirement for the Visual C++ 2008 SP1 runtimes has been dropped (about goddamn time too) and the SlimDX guys have created awesome installers for SlimDX.  The big deal about dropping the runtimes is that Gorgon no longer requires the runtimes to be distributed with its own installer and this has decreased the size of the installer (a little).  But the biggest deal comes from the SlimDX runtime installer and x64.  This installer will put SlimDX (both x64 and x86 versions if you’re on an x64 version of Windows) into the GAC.  This means that if you’re running with a project configured for AnyCPU (Project Properties->Build Tab), and you’re running on an x86 OS, it’ll use the x86 version of SlimDX automatically, and if you’re on an x64 version of Windows it’ll use the x64 version automatically.  This means there’s no longer a need to maintain two project/solution files for x86 and x64.  This is a great relief to me as it was a pain in the ass to keep updated.  Of course, this only works if both platform versions of SlimDX are installed into the GAC (e.g. if you only have the x86 version of SlimDX installed and the program is forced to compile to x64 – it’ll fail). 

Wait… what’s that?  You -want- an x64 (or x86) only version of your program?  Well, just set it to compile for x64 (or x86) instead of AnyCPU and the runtime will automatically use the x64 (or x86) version of SlimDX.  Fantastic!

So what are you waiting for?  Happiness is only a download away.