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.
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.
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:
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.
Well we have another user contribution from forum member domq. He’s doing a “sort-of” Ultima 6 MMO remake called Britannia On-Line. Frankly it looks awesome, and I can’t believe Gorgon can be used for stuff like that. Who knew? I sure didn’t.
Anyway, I’ve added screenshots of the project to the screenshots gallery under the user contribution gallery. You can check out more about the project in the forums.
Domq also found an issue with the TextSprite when the bounding rectangle is very small and WordWrap = true. This has been corrected (by domq) and I’ve put the fixed code into the Subversion repository.
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.
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.
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.
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.
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!