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.
Here’s a sample of text rendering in Gorgon 2.0 (Dorian). It’s rendering 16,019 characters, animated with shadowing (which doubles the character count), plus the FPS counter. When it renders the text, it renders with kerning information (provided the font has any) so the output should be properly spaced. And while it’s doing this, it’s scaling the text to pump up the fill rate.
(The video has since been deleted)
All that at ~75 FPS, that’s not too bad hey?
In this particular “demo” you can see that I’m able to compress and expand the lines of text. This is possible because of the new “LineSpacing” property in the text object. This allows the user to set line spacing by setting a multiplier. For example, a LineSpacing of 2.0 will give you double spacing and 0.5 will only move the lines half way.
Anyway, I’m still plowing through all of this. And I’m pretty happy with the results.
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.
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.
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).
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.