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.
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).
So I’ve been meaning to do this for a while, but laziness and real life gets in the way. Anyway, one of the forum members, Zeraan, has created a nifty little asteroids clone called Asteroids of Beyaan. You can check out the project (which includes a link to the game itself) in the forums. I’ve also added screenshots for the game in the screenshots section of the site under the user contributed screenshots section.
I’ve also added two new (well, not so new seeing as they’ve been there for a long time) screenshots for the RPC project by ShadowDust702. Those too can be found in the screenshots/user contributed section. Check the project description for a download (demo/test version) link.
So 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.
So 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.
Yes, 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.
I 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.
So 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.
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.
Made some small fixes to handle a change to the FillTexture callback and to work around a bug in Texture.FromStream.
Updated the ShadersInSpaaace to draw the film grain crap properly.
Updated bump in the night sample to include specular mapping and included the specular map (yes it’s supposed to look that grainy). Updated normal map for more accurate lighting. Crazy bump is the shiznit.
Fixed bugs in the file system editor that caused the whole file system to be exported to explorer even if only a single file was selected. Fixed bug in file system editor where if root wasn’t selected the export file system button would break. Changed export button to be more clear about its function.
I’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?
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.
A 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.
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.
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.