Sign in to follow this  
  • entries
    40
  • comments
    7
  • views
    25104

About this blog

Full of nub.

Entries in this blog

Gorgon


Since it's pretty dead there (not that that's unexpected, I hardly update the site), I will be shutting down the forums.


They will be locked into a read-only mode so that any information required is still available.


If you have a pressing Gorgon issue, I recommend using the Github repository, or leaving a comment on the blog (the git hub site is preferable however).


As for Gorgon: Believe it or not, I still work on it. Just at an incredibly slow pace. Similar to time dilation in a black hole or something magical like that.



Source

Git hub

sitelogoI'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):


https://github.com/Tape-Worm/Gorgon



Source

Font editor

sitelogo.pngIt's been a very long time since I've made an update here. I've been working steadily on the font editor module for the Gorgon editor and it's finally nearing completion (the last 99% of 99% of 99% etc...).
I'm quite proud of this thing. It's supports a pretty well rounded suite of functionality for designing a bitmap font for use with Gorgon. Besides the usual standard stuff like font outlines, font faces, styles, etc... it also supports glyph brushes, custom glyphs, glyph advancement and offset editing and custom kerning pair tables.
Here's a few images:

fonteditor03312014_lg.png
fonteditorgradbrush03312014_lg.png



These show the glyph gradient brush and the custom glyph functionality. Images showing the outline effects can be found in the gallery.
There are 4 supported glyph brush types in the editor:

  • Solid - Basic coloured brush.
  • Gradient - An editor linear gradient brush.
  • Texture - A brush that paints each glyph using the defined texture.
  • Pattern - Various patterns.

    The custom glyph stuff is basically like clipping a sprite from a larger image. And since glyphs can proportional, you obviously need to adjust it so that there's no overlap (unless you want it) with other glyphs in the text. You can clip your custom glyph and adjust its advancement and offset until it mixes in well with your text. If you want really precise control, you can also define kerning pairs (not finished yet) to get better placement depending on the surrounding characters.
    And finally, there's a secondary outline colour. This allows us to create interesting effects with the glyphs like glowing letters or hollow letters.
    It's come a long way since I last did an update. And I'm pleased with the what I've managed to do with the editor at this point. As always, the code is available on the subversion repository if you want to give it a test run.

    Source

Cameras

sitelogo.pngIn 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.
There's more info and a video inside...

For the last few days I've been perfecting my camera object, particularly the Orthographic camera, so that you can define any coordinate system you need. By default, Gorgon uses a screen space coordinate system. This is a comfortable system that many users are familiar with: 0,0 is the upper left, and Width, Height is the lower right. But sometimes that just doesn't cut it. What if you want everything relative and resolution independent? Well with the new camera object you can define your viewing area using a relative unit system by telling it to use -1, -1 as the upper left and 1,1 as the lower right (this would be a rectangle with an offset of -1, -1 and width and height of 2). Now when you place a sprite and assign it the coordinate of 0.5f, 0.5f, it will place it 480x320 on a 640x480 screen or at 768x576 on a 1024x768 screen. Perfect when your resolution is no longer at a fixed size.
So that's nice. But wait, there's more:


What's that in the video? Well, there's also a perspective camera. For those instances where you want to add a 3D component to your sprites. Using the perspective camera, the Depth property now sends the sprite deeper into the view space and perspective is correctly applied to the movement of the camera relative to the objects. In the video we see the ship pushed into the background and when we move the camera, the ship moves in perspective.
Also note that everything is relative to the camera. If you follow the green icon (and not the mouse cursor arrow), you'll notice that the ship is moving relative to the camera. In the code, only the camera is changing position. The ship is at the exact same coordinates it was assigned and was never moved. This is where a camera really shines.
So, I know it's been ages since I typed anything here. But as you can see, I'm still working on Gorgon. The refactoring process is nearly complete, and the 2D portion is nearly done. Once the editor is cleaned up and finished it'll be ready for release... I hope. I can't give an estimate on when that will be. It certainly won't be soon as I am only one man.

Source

More the editor

sitelogo.pngHere's a another screenshot of the editor. This time with the Font editor plug-in in action. Note that this is very very very incomplete and may not look like this when everything is said and done.

gorgon_fonteditor_plugin.png



Source

The editor

sitelogo.pngSo 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:

Font_Editor-256x192.png


Ugly.
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:

gorgoneditor_v2.x.png


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.

Source

DEATH TO D3DX!

sitelogo.pngFINALLY. I'VE FINALLY DONE IT! It took weeks of work, but I managed to exorcise D3DX from Gorgon. Behold my video playing an animated GIF using a 2D texture array:


I've provided extensive info after the jump thingy.
In case you're wondering (and you know that you are), I used the D3DX utility library to handle some horrible jobs in Gorgon. Namely saving and loading textures and importing GDI+ (System.Drawing) bitmaps into textures. But with the abomination that is Windows 8, and DirectX 11.1 (which, just to be clear, Gorgon is NOT using), D3DX has been left to rot. Fine by me, one less dependency (and hopefully no more d3dx4312318793728.dll was not found errors).
So, how am I performing texture loading/saving? Well, being the daft bastard that I am, I created a rather complicated (for me) imaging system to handle loading, saving and manipulation of image data. The last part is underlined because Gorgon 1.x had very limited capability in that area. It's all based on the toolkit code in SharpDX by Alexandre Mutel and the DirectXTex library by Chuck Walbourn. I seriously wouldn't have been able to get anywhere if those guys hadn't done as much work as they did.
That said, it was still no walk in the park. The SharpDX toolkit code is fairly basic, and the DirectXTex library is in C++ (I now remember exactly why I don't use that bastard of a language anymore).
With all that said, here's what's new with texture loading/saving:

  • Image data is now manipulated through the GorgonImageData object. This allows us direct access to the pixels of an image on any texture array (or depth slice if using volume textures) index and mip map level. It breaks the indices and mips into parts that can be indexed like a collection and provides data streams to allow reading/writing of data into those buffers. All requisite information is included, such as row pitch, slice pitch (= image width * height * bytes/pixel). All in all, it makes accessing the data pretty easy.

    • Images can be loaded directly into the image data using FromFile/Stream methods. This is pretty straightforward. Image data can also be saved to a file/stream.
    • The image data object can perform conversion on several (but not all) formats. Plus it'll do resizing of images.
    • That's the image data object... is that a texture? No, it is not a texture. It is the data that a texture can use however. You may create textures by loading them directly from a file/stream, or into an image data object and then pass that image data object into the texture creation methods. Or even create an empty texture and copy the data in later. The two object types are related, but different. One is for low level image manipulation, the other is for dumping that image data into your video card.

    • Codecs... Gorgon now has several objects called codecs. These are used to decode/encode image data from a file/stream. Codec objects are passed to load/save methods whenever texture or image data objects are loaded/saved. Currently Gorgon has support for:


        1. DDS - This was a bastard to write.
        2. TGA
        3. GIF - This was a bastard too
        4. PNG
        5. TIFF
        6. BMP
        7. WMP


      • Codecs are objects. Not enumeration types like the previous versions of Gorgon. Why? Because each codec has a set of properties which allow you to alter how images are decoded and encoded based on the codec you're using. This allows us to do transformation of image data as it's brought in.
      • Codecs are custom objects. That is, you, yes you, can write your own by inheriting from GorgonImageCodec and you'll be able to save/load your very own file format. Because the world needs more file formats.


        Currently GIF, PNG, BMP, WMP, and TIFF are using the Windows Imaging Component API to encode/decode the data for those file formats. This requires that WIC be installed on your system if you plan on using those formats. However, this shouldn't be an issue because Windows 7 should have it installed already. Also, because codecs can be created by users, you can always write your own PNG codec and not use my crappy version.
        Anyway, that's about as much as I care to babble on about this.

        Source

Boing!

sitelogo.pngWell, it's been a while. I've been busy. You've been busy.
Anyway, I actually took some time to test out a piece of functionality for the new version of Gorgon. This new version of Gorgon will have a graphics API separate from the 2D renderer (the 2D renderer uses the graphics API however). This is unlike the previous version where the renderer was pretty much all you had access to. I had a user ask me a long time ago if it were possible to access the underlying renderer to render 3D along with the 2D. At first, it did not, but I did hack in a way to access SlimDX directly through a plug-in and it was awful.
So, in this version I decided to give the developer access to the full graphics API under the renderer. This allows the user to switch between 2D graphics and whatever they want. And here's the results of my intense labour pain:


Yep, it's a clone of the old Amiga demo "Boing". As you can see, there are 2D elements (the text and the logo) along with the 3D elements (which were all done manually I might add, Gorgon does NOT have a 3D renderer so don't get too excited). I've decided to include the code as an example program for the new Gorgon.
Rejoice.

Source

Gorgon in text mode

sitelogo.pngYep. Console window actually. Exciting. Just a silly example program showing how to use some of the functionality from the common library.
You can go back to sleep now.
Gorgon_In_Text_Mode-256x192.png
Text mode. Now you too can write state-of-the-art adventure games. N, E, LOOK, INV, instant death... good times.

Source
sitelogo.pngSo here's a screenshot of the dual monitor code in action:
DualMonitor1-256x192.png
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.

Source
sitelogo.pngSo, 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:

  1. It'll probably crash. It's in development after all.
  2. You NEED Windows Vista Service Pack 2, or Windows 7 (Windows 8 -might- work, but don't count on it).
  3. 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 1280x800 although you can modify the BallDemo.config file to change to a resolution you like.
Let me know what your performance is like.

Source
Apparently there's an issue with Gorgon installing SlimDX. When the installer runs, it is supposed to detect whether the March 2009 SP1 (v2.0.7.41) SlimDX assemblies are installed. If they are not, then it will install SlimDX for you. However, it has come to my attention that the Gorgon install has not been installing SlimDX.
The issue is with the March 2009 SP1 SlimDX end user runtime installer (Gorgon runs this when it installs). Apparently it's not working, and even though I've tried to download it from the SlimDX site it still refuses to run (for me) and claims that the installer is invalid.
If you're having issues running Gorgon applications because it can't find the v2.0.7.41 SlimDX assemblies:
"Could not load file or assembly 'SlimDX, Version=2.0.7.41, Culture=neutral, PublicKeyToken=b1b0c32fd1ffe4f9? or one of its dependencies. The system cannot find the file specified."
Then install the SlimDX March 2009 SP1 Developer SDK from here and all should be well again.

Source

Gorgon

sitelogo.pngThere'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:

  1. 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.
  2. 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.

You can download Gorgon from here.

Source

Editors

sitelogo.pngI decided to take a break from writing the library, and have been working on the editor. Here's a screen shot of the font editor in semi-action. Please note that this is very preliminary and there's not a lot going on here.
GorgonEditor-256x192.png

Source
sitelogo.pngHere'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.
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.

Source

Gorgon v1.x

sitelogo-300x98.pngI'm updating the solution and projects for Gorgon 1.x in the Subversion respository to use Visual Studio 10 . The current binary release still uses Visual Studio 2008 and will continue to do so until a new release is put up.
If you are freaking out over this because it'll somehow be the end of everything you love and hold dear, stop whining and get the express version of VS 2010 here.
Please note Gorgon still uses .NET 3.5 SP1 and you can use the binaries with Visual Studio 2008. Again, you only need Visual Studio 2010 to compile the source for Gorgon. I cannot stress that enough.

Source
sitelogo.pngSweet merciful fark. That was painful.
I just spent the last 4 evenings/nights writing Gorgon's font system and it was not fun. And, of course, I'm still nowhere near done (still have to create the TextSprite object, and other the font effects like gradients and GDI+ image brushes). But, I got it working. Not only that, unlike the previous incarnation, it actually implements kerning properly (well, approximated kerning, I'm not dicking around with actual kerning. fark that.) One of the things about the 1.x font/text rendering that I absolutely hated was while it was worked, every now and again (especially on smaller fonts), it'd screw up and a letter would appear slightly (or not so slightly) shifted. Quite annoying. Here's a screen shot showing how awful it was compared to GDI+ and how awesome v2 is going to be (click to expand it):
GorgonText-300x118.png
Gorgon/GDI+ text comparison
Note that all text is the same font: Arial, 9.0 point, Bolded and Antialiased. Also note that v2.0 is nearly (but not quite pixel perfect) identical to the GDI+ DrawString version. I think that's a slight improvement.
After our forum member, ravl, had issues with Gorgon's fonts and DPI on his game, I decided to rethink how fonts are handled in Gorgon. Currently, the fonts are generated on the fly by copying the glyphs from a GDI+ font object (via DrawString) to a GDI+ bitmap and arranged on that bitmap to use the space as effectively as possible. Then that bitmap is copied to a Texture (or textures) and then the TextSprite uses those textures to draw the glyphs. This is all well and good, however, if the DPI is different on someone elses monitor, the font that's created on your monitor may be smaller/larger than the font when it's displayed on someone elses monitor. That's annoying. And, because I thought "Hey, no one will ever need to load/save these fonts because you can generate them on the fly!", you can't, well, save or load these fonts as bitmap fonts.
Enter Gorgon v2 fonts. These font objects will now be able to be persisted as-is as bitmap fonts. No more worrying about DPI, if it's 24 pixels high on your monitor, it'll be 24 pixels high on theirs. Gorgon v1 originally did fonts this way, but I had issues with kerning that I could never quite get past (until now), so I dropped it in favor of this scheme. It works well enough, except when it doesn't (see image above). However, what if you do care about font scaling? Well, no worries, I got that covered too. Gorgon will allow you to create these fonts in code like you could before.
I decided to forego putting the font object in the 2D library. I didn't want to tie it to the 2D stuff because really it's all just texturing and crap and no real geometry. So, it resides in the main graphics library as part of the textures object group (after all, it is essentially a very specialized texture). However, the TextSprite will be part of the 2D library.
My plans are to make the font completely customizable, and to that effect, custom glyphs can be added with custom textures. So if you wanted a giant flaming skull in the shape of an 'A' or some shit, you can do that and still keep your regular font. Kerning is customizable as is glyph advancement as well. I'm also going to make an editor for fonts so that building a font won't be a chore. But that's in the future.
Anyway. It's progress.

Source

Gorgon Shaders

sitelogo.pngSo I got custom shaders up and running in Gorgon 2.0. The new version has always had shader ability because it's using Direct3D 11, so it's required to use them. However, up until now the shader code has been hardcoded to use 3 default shaders. But after today, there's an ability to use customized shaders:
In this little sample, there's a new system at work. It's basically a mini effects framework that can do multi-pass rendering and in this video there's a wave shader and an embossing shader at work on the sprite. If you want to learn more, click the stupid link below
Shaders in this new version work a little differently than the previous version:
The first thing is that they're Direct3D 11 shaders, so the use of constant buffers are required to send over your data to the shader.
The second thing is that shaders used in the 2D part of Gorgon require a little editing:

#GorgonInclude "Gorgon2DShaders"

That line should be at the top of the file so that Gorgon can import its own built in shaders (and so you can use them without trying to guess how I've laid everything out).
And finally, there's the Effects system. Which is still being worked out, but here's the code I used to generate that video:
_2D.Target = _target2;
_2D.Effects.Wave.Amplitude = 0.01f;
_2D.Effects.Wave.Period += (50.0f / _target.Settings.Height) * timing.FrameDelta;
_2D.Effects.Wave.Length = 50.0f;
_2D.Effects.Wave.WaveType = WaveType.Both;
_2D.Effects.Wave.Render((int index) =>
{
_2D.Drawing.Blit(_target, Vector2.Zero);
_2D.Target = null;
_2D.Effects.SharpenEmboss.Amount = 2.0f;
_2D.Effects.SharpenEmboss.Area = _target.Settings.Size;
_2D.Effects.SharpenEmboss.UseEmbossing = true;
_2D.Effects.SharpenEmboss.Render((int innerIndex) =>
{
_2D.Drawing.Blit(_target2, position);
});
}
);

That's the general gist of it anyway. As you can see, there's a SharpenEmboss and Wave effect, which are prepackaged with Gorgon under the Effects property. I have several more prepackaged ones that I plan to implement, but, the user is also able to define their own by inheriting from one of Graphics.GorgonEffect or Renderers.Gorgon2DEffect. The differences between the two are merely support. The latter does a little more for you behind the scenes, while the former does barely anything at all for maximum control.
Anyway, that's it. I hope that's of some use to someone.

Source

Hi I

In order to give Tape_Worm more time with the next Gorgon and other things, I'll be maintaining the 1.x version of Gorgon. So in other words if you have problems, or feature requests, or along those lines with the 1.x version then I'm your man.

Source
sitelogo.pngI am sick as a pig. I hate having a farking cold.
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 "fark 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.
Anyway, thought I'd throw that out there.

Source

Stupid drivers

sitelogo.pngI 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.

Source

You

sitelogo.png
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):
GorgonPrimitives-256x192.png
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...
All primitives (except points, they don't support texturing because, well, they're points and there's no... forget it) support texturing for their filled and outlined mode, and support line thickness and are now actual objects. You can create a line by calling CreateLine or what have you and you can reuse it as you wish. The advantage is that these objects now get a lot of the same functionality as a sprite, like anchoring, rotation, scaling (lines don't though, they're a little different). You don't need to create explicit instances of primitives however, there's also an interface that will draw the primitives directly to the target if you don't need a lot of control.
There is one caveat: The quality of rendering for the ellipse object is adjustable, so if you want really smooth ellipses, then you'll probably hit a performance penalty (more lines/triangles to draw). I've found a setting of 64 (which is the number of line segments used to draw the object) is pretty good.
The line thickness was a real farker to get working. Basically it draws a line as a quad, and for non-textured, that's fine, however for the texture coordinates... man, it was brutal. But I learned some neat things from Vortex 2D.Net (by Alex Khomich, and is a great library, I highly recommend it) and now it's working better than I could have hoped.
To give a summary of the image:

  • The "sprite" of the ball, is not a sprite, it's actually a filled ellipse using the ball as a texture.
  • The ball with the center cut out is an unfilled ellipse using a texture and a thickness of 3 pixels.
  • I am farking tired.

    Anyway, that's it for today. Hopefully it won't take me too long to get back on track after the move.

    Source

65536 balls.

sitelogo.pngSo, 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)
If you recall the ball demo in v1.x of Gorgon, it's a stupid bouncing ball simulation with rotating, translating, scaling and fading balls bouncing around the screen. It's been my testbed for a long, long time. And it still is (yes, it'll be in the examples for Gorgon v2). Anyway, I ran that old v1.x version of the ball demo running on Direct3D 9, pumped the thing up to 65536 balls and on my Radeon 6870 (on a Core i7 machine) it got an unhealthy 15-16 FPS (~60 msec of draw time). So, I compared it against the new version running under Direct3D 11 and got 35 FPS (~28 msec of draw time). That's 263,184 vertices being transformed, coloured, blended, etc... running at above 30 FPS. The older version had some text being displayed on a render target, so that may account for the difference, but with a difference of 32 milliseconds, it's unlikely. Still, I'm impressed with Direct3D 11. On a lesser video card, performance seems to be on par with the Direct 3D 9 version (sometimes it's faster, sometimes it's slower depending on the card).
It's been a major pain learning the changes to this API. Especially when I want to structure it in a certain way. States are set differently, shaders are required, data is uploaded in various ways, etc... But those changes seem to improve the performance. I also can't forget that I'm using SharpDX instead of SlimDX and there's definitely a performance boost there.
When I initially transitioned over to SharpDX I was shocked to see how much faster it was when rendering thousands of draw calls in comparison to SlimDX. However, Gorgon batches things internally so the draw calls are kept to a minimum so it's only a part of the performance boost. Still, I'm very pleased and I'd like to thank Alexandre Mutel for all of his hard and amazing work on SharpDX (dude is farking brilliant, seriously).
Now, if anyone is actually reading this, I'd like to point out some of the MAJOR differences between v1.x and 2.0:
[color=#008000]Gorgon is no longer (just) a graphics library:
[/color]Yep. That's right, it's now a big set of libraries which you can add or not add your leisure. There's a graphics library in there, it's just not the primary thing anymore. The libraries are:

  1. Gorgon.Common.dll - This is shared amongst all the other libraries and contains utility code like base collection objects, specialized collections, diagnostic information (e.g. frame rate), a new data stream object, the plug-in management, extensions for IntPtr, numeric types, string formatting, and hash code generation. It's required to use any other component.
  2. Gorgon.Filesystem.dll - This is a file system object. It's not even remotely close to what was in the previous version.
  3. Gorgon.Input.dll - This is the input library. It handles input from joysticks, keyboards, mice and even has rudimentary support for custom human interface devices.
  4. Gorgon.Graphics.dll - This is what you've likely come here for. This is the base graphics API. It does nothing fancy, it provides you the same things that Direct3D 11 would provide you, except it's wrapped up in my own functionality (and simplified where I could do it).
  5. Gorgon.Graphics.2DRenderer.dll (this is what the name might be, I'm still working on it) - This is the functionality for the 2D stuff in Gorgon. Sprites, text, etc... are all here.

[color=#008000]The file system is nothing like what I had before:[/color]
Basically, it works more like PhysFS in that it mounts directories or packed files (zip and gorgon bzip from v1 are included through plug-ins) into a unified file system. So you could mount C:Folder into / and D:BigZip.zip into / and you can access data from each file system as though they were in the same area. Unified. Hot. It's good for rounding up resources into a virtualized central location.
[color=#008000]More input plug-ins:[/color]
All of the input management is done through plug-ins (like the previous version), however now there are more plug-ins to choose from such as raw input (like v1), windows forms (basically a pass through) and xinput (this is new and for xbox game devices only - Microsoft's limitation, not mine). You can load all of these plug-ins at the same time and use keyboard from the windows forms plug-in, the mouse from the raw input plug-in and the xinput gamepad interface.
[color=#008000]Graphics are split up into multiple components:[/color]
This is the big one. Basically I wanted to separate the API from the renderer. The previous version kind of did this under the hood but you weren't given any access to it. So, for this version I split it out so that a user could write their own 3D library, 2D library, or whatever away from the 2D renderer. It's also the object that gives access to the 2D renderer and the swap chains you'll need to draw into (or any other render target). Aside from that, some notable improvements are the ability to use anti-aliasing, full screen on multi-monitor setups with multiple swap chains and it does caching of state objects so you don't have to (this is a big thing in Direct 3D 11, and VERY different from Direct 3D 9).
The 2D renderer is still being fleshed out, so I don't want to comment on it yet (mostly so I don't make promises I can't keep).
[color=#008000]The idle loop is decoupled from the graphics:[/color]
Yeah, this might be a pain in the ass, but it allows the use of the idle loop without requiring graphics (you know, because there are other application types out there) and it allows the ability to swap out idle loops at will. The down side is that instead of doing the page flip for you at the end of the loop, you'll be required to call the Render() method of the 2D interface or Flip() on the current swap chain before seeing any graphics. However, think of it this way: You now have complete control over when your graphics get displayed with this.
The down side to these massive changes is that if you're looking convert to version 2, you've got your work cut out for you. For example, in Gorgon v1 you called Gorgon.Initialize and Gorgon.SetMode and off to the races you go. Not so with the new version. As it stands, you call Gorgon.Run(
, ) to start the application (it replaces Application.Run in Program.cs). This gives the advantage of being able to run the application outside of the form. Traditionally you would do all the initialization from OnLoad of the form, and you still can, but now you can also do it outside if you so choose.
To set the video mode (which is actually just a swap chain), you create the graphics object and call the CreateSwapchain method. You can then pass the resulting swap chain to the 2D renderer and start working Gorgon like you normally would (well, more on that at another time).
So, that's a summary of what's going on. I hope it's not too painful for most people (fark, who am I kidding? It'll be painful I'm sure). I hoped to make Gorgon more generalized, and it looks like that's what I'm getting. It's more work to initialize it, but in the end I think the flexibility will be worth it.

Source
Sign in to follow this