I’ve finally given in and become a lemming and followed the rest of the planet to git hub. So, from this point forward, Gorgon’s source code will be hosted at Git Hub. The source code currently hosted in the Subversion repository at Google code will remain as-is indefinitely. This means that in order to get the most up-to-date version of Gorgon, you will have to go to the git hub repository.
And here’s the link (also posted on the right side bar over there):
In the 2.x version of Gorgon I wanted to add cameras. It was most tedious before when you wanted to translate an entire scene by an arbitrary amount. So when I started this thing, I created an Orthographic camera object. The previous version of Gorgon used an Orthographic camera internally and this was never exposed to the user. But in this case, I exposed the camera so that the user can define their own viewing mechanism.
So I’ve been busy working on building the editor for creating the content for Gorgon. I know I posted a screenshot of a very old initial version of the editor way back:
Anyway, I totally scrapped that old thing and restarted. And here’s a more up to date (but not even close to being done) screen shot:
A little better.
This new editor is going to be a replacement for all the tools in the previous version of Gorgon. It will handle file management duties (File System Editor in v1.x), sprite editing (Sprite Editor in v1.x) and atlasing (Atlas tool in v1.x). It will also add font editing. The big thing about this editor is that it’s entirely plug-in based. Meaning that the font editor, sprite editor, etc… are/will be DLLs that are loaded/unloaded as needed. What this means for you: You can write your own plug-in modules for it. Want to build a map editor and integrate it with the rest of your content? With the plug-in system in the editor, you can write your own map editor and host it right in the editor interface (if anything the minimized tedium of having to write UI code is worth it). Want to write out your content data as encrypted data? You can extend the file writing functionality to write out encrypted file data.
Unlike the sprite editor in the previous version, the files are no longer saved as loose files on your hard drive that require a separate utility (file system editor) to pack into a single compressed file. This editor now outputs data as a packed file (of course, this can be modified with a plug-in) so you don’t have to come up with a strategy to update your content, allowing you to edit directly. This is where it takes over from the file system editor and like the old file system editor this one is capable of importing files by either clicking on an Import menu item, or dragging and dropping directly from explorer. And, obviously, there’ll be a way to extract the files to your harddrive should you wish to do so.
I have several plans for plug-in modules for the editor including a sprite editor, image editor (a very very very very simple editor, use photoshop or paint.net if you want high detail stuff), a font editor and a shader editor (maybe).
FYI, the window will look like that in Windows 7 as well (i.e. no aero glass). I’ve modified it to look like the Zune window by including a new object in Gorgon.Common.Dll called ZuneForm. Basically you inherit this form instead of a System.Windows.Forms.Form and then you get a Zune-looking window.
So, I got myself a copy of Visual Studio 2012 Pro. It’s pretty nice, except for the shitty all-caps menus (which you can turn off with the registry hack located here). I really didn’t have any plans on moving Gorgon v2.x to .NET 4.5/VS2012 until I saw this:
So here’s a screenshot of the dual monitor code in action:
It’s not much to look at, but it was a major pain in the ass to get working, and does indeed work. Basically you create 2 forms, and 2 swap chains and set both swap chains to full screen and then add some special code to handle cases where focus is lost/restored on the primary form.
Gorgon would normally handle focus loss to reset your full screen mode for you when focus is returned (this is due to a bug in WinForms and DXGI). And that’s all well and good, but this code really doesn’t work well with multiple monitor situations. So, there’s a flag to tell Gorgon to turn off the automatic mode reset on focus, and that will let you, the user, handle the transition when dealing with multiple monitors. It’s not an ideal situation, but it works
It’s a bit complicated to set up, but there’ll be an example included with Gorgon on how to use dual monitor setups that’ll guide you through the process.
So, I’ve been quite busy lately with a new job and such. And as a consequence I haven’t had any time for Gorgon recently. But I finally sat down this evening and did a little work (not much mind you, and certainly nothing of note) on Gorgon 2.x.
I’ve uploaded the Ball Demo to the site so people can have a look at it. I’d appreciate any feedback (please post the feedback to the forums, thank you).
Please note the following before running it:
It’ll probably crash. It’s in development after all.
You NEED Windows Vista Service Pack 2, or Windows 7 (Windows 8 -might- work, but don’t count on it).
It will run on Direct 3D 9 capable video devices. However, it requires Direct X 11 be installed on the system (hence the OS requirements).
To run it, just run the BallDemo.exe and pray (oh, and ensure that the zip file isn’t ‘blocked’ by Windows, .NET assemblies hate that shit). It defaults to windowed mode with a resolution of 1280×800 although you can modify the BallDemo.config file to change to a resolution you like.
There’s a new version of Gorgon uploaded. There’s not a huge amount in this release regarding the actual graphics library, just a few bug fixes.
However, there are two important changes:
The project/solution files for the library source code were converted to Visual Studio 2010. This means that in order to compile the Gorgon library, you will need Visual Studio 2010. The library still uses .NET 3.5 SP1, so Visual Studio 2008 will continue to work when using the library assembly.
Most important of all: There’s been a new library added called GSound (Gorgon Sound). Written by ShadowDust702. New forums have been added to reflect this new addition.
So, I figured out the issue that prompted all of this and it took damn near forever. Apparently feature level 9.x devices can’t copy GPU data to resources (e.g. textures) that have a shader binding flag set to CPU accessible resources. And apparently the D3DX functions to save the texture does exactly that. It copies the GPU texture to a CPU staging texture and writes that out (makes sense, reading from the video device is a no-no). Unfortunately my device object just says “fuck it” and promptly dies when this happens, which seems like a driver problem. Anyway, it’s fixed now. Not that it matters, but it was painful and could have meant the end to Direct3D 9 video card support in Gorgon (which no one probably really cares about anyway).
Unfortunately the fix comes at a price. Part of that price is increased memory usage. It’s painful enough to have to create temporary textures when converting to a format that’s not able to accept anything by standard RGBA 32 bit formatting, but with the feature level 9.x there needs to be another temporary texture that doesn’t have a shader binding flag. It’s kind of gross. The other part is that the only way to get it without a shader binding is to create the texture as a render target (unordered access views would have been nice, but they’re for Direct3D 11 devices only), so that limits the number of formats that can be used when saving.
I need some help, I’m having issues when saving a texture and I need to know if it’s a driver issue or something in Direct3D 11. I have a post in the forum about it here. If you can help and you have an Nvidia video card, please go read the post and run the test application (Windows 7/Vista SP2 required). Thanks.
So, I’m moving to a new place tomorrow and work on Gorgon v2 is going to halt for a bit until I get my life back in order. In the meantime, here’s a screenshot of the primitives (rectangles, lines, etc…) that have been making me insane (click it to see a larger version):
You can see the line (barely, I know, you can see it when it’s running for sure) and the rectangle, but I’ve gotten ellipses to work as well. Now, what’s the big deal you ask? (You are asking that, I demand it). And I’ll tell you. Unlike the previous incarnation where the primitives were generated one pixel at a time (very inefficient), this time it’s using polygons to generate the primitives. So a line is using the line drawing on the video card, the rectangle and unfilled ellipse are using the line drawing as well and the filled ellipse is using triangles. So all in all, they’re MUCH faster than the previous version. For more details click the thingy at the bottom there…
So, I’ve gotten most of the sprite functionality back into Gorgon 2.0. And of course, with the help of my stupid ball demo program I learned something neat… (click the “read the rest of this post…”, you know you want to)
So, here’s some more proof that I’ve been working on the next version of Gorgon:
As per the description on the youtubes:
An example showing the new version of Gorgon.
Currently this is just a simple sprite test using 1024 multi-textured sprites via shaders on Direct3D 11 hardware. It also shows a new feature that’s being planned (but not promising anything) to use the 3D stuff to allow perspective corrected sprites.
This video also shows depth for the sprites by walking a camera into the sprite cloud.
Currently getting about 1200 FPS with this (the selective multi-texturing really slows shit down).
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.
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.
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….