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.
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.
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.
You can read about the changes here.
Then you’ll probably want to download it.
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.
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.
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.
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.
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.
So I kind of broke my promise to not add anything new, and added a new example. This one deals with per-pixel bump mapping. It will be included in the next round of bug fixes for Gorgon (of which there are many). I’ve put up a screen shot of it in action, although it really needs to be seen in its fully animated glory to get the full effect.
As I said there are many bug fixes that have been implemented in Gorgon and I’ll package and distribute another release by the end of the month (I want to be sure to catch as many as possible). None of them are show stoppers, just annoyances. You can easily keep up to date by grabbing the code from the sub version repository on the google code page. I’m aiming for the end of the month for a release unless I find a really major bug, so it’s entirely possible that it could come sooner. But the way things are looking, it looks like I’ll stay on schedule.
As always, I’ll keep all two of us posted.
Edit: I just encountered a bug with the 1.1.0.0 installer. If you attempt to install the source code it’ll complain about installing x64 components if you’re using an x86 version of Windows. Just deselect “Install Source” before installing. If you need the source, you can get it from the subversion repository. Sorry about that, I’ll get that straightened out with the next release.