Jump to content
  • Advertisement

Tape_Worm

GDNet+
  • Content Count

    1230
  • Joined

  • Last visited

Community Reputation

2832 Excellent

About Tape_Worm

  • Rank
    Doctorb

Personal Information

Social

  • Github
    Tape-Worm

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Tape_Worm

    Gorgon

    What is Gorgon? A modular set of libraries useful for graphics and/or video game development. Gorgon uses Direct 3D 11.4 (via SharpDX) to provide high performance graphics for your applications. What is not Gorgon? Building applications with Gorgon requires that you write code. There's no nodes, no blueprints, etc... It does not contain: A fully featured game engine. An all-in-one editor that uses drag and drop to build your application. A scripting system. Gorgon is meant for people that want to write their own functionality, get down into the guts of their applications and not have to deal with a black boxed scripting system, or editor. In short, it's more work, but more customizable. For those that want a more complete (and polished) package to build their applications there's Unity, Unreal or Godot. What’s the licensing? Gorgon is licensed under the MIT license. How far along are you? Is it done yet? How about now? Gorgon 3.0 is currently in sporadic development as time allows. At this point, there's no release planned. What can it do? Gorgon provides a set of libraries that are capable of handling pretty much any task thrown at it. It includes: [x] Gorgon.Core Core functionality, plug in support and utility functionality. This is the base library that everything else uses. [x] Gorgon.Windows Core Windows specific functionality. Provides UI functionality, such as custom message box dialogs, timing functionality using QPC and/or the windows multimedia timer and various other bits of utility/diagnostic functionality. [x] Gorgon.FileSystem A virtual file system that can mount a directory as a file system root, or using various file system providers, can mount a packed file as a virtual file system root. This code is based on the popular PhysFS library. By default, Gorgon's basic virtual file system is based on the folder/files on the Windows file system, but using filesystem providers via plug ins, applications can read any type of file storage container can be used if the appropriate plug in is available for it. Gorgon comes with two plug ins for file system providers: Gorgon.FileSystem.GorPack: Gorgon's proprietary packed file system format, using BZip2 compression. Gorgon.FileSystem.Zip: Mounts standard .zip files as virtual file systems. By default, the file system provider [x] Gorgon.Input A flexible input library to handle joysticks/gamepads, keyboard and mouse input. The input library can use events or polling to retrieve data from the various input sources. Keyboard and mouse input is provided using the Windows Raw Input API, and joystick/gamepad support is driven by the following plug ins: Gorgon.Input.XInput: Support for the XBox 360 controller (and potentially XBox One controller - not tested) Gorgon.Input.DirectInput: Support for gaming devices that are not covered by the XInput API. [x] Gorgon.Graphics.Core A "low-level" graphics API that sits on top of Direct 3D 11.4. Provides a simplified system to build objects such as render targets, swap chains, buffers, etc... The rendering portion of the API provides a simple mechanism to submit batched state and draw information back to the underlying D3D API. [x] Gorgon.Graphics.Imaging Functionality to read and write image formats. This also contains functionality to use a fluent interface to manipulate images for things like cropping, scaling, etc... Gorgon uses codecs to read/write images and includes codecs for the following formats: DDS - Direct Draw Surface TGA - Truevision Targa PNG - Portable Network Graphics JPG - Joint Photographic Experts Group BMP - Windows Bitmap GIF - Graphic Interchange Format (supports animated gifs as well) In additon to the support above, applications can extend the support for file formats by adding their own custom codec plug in to read/write in their desired format(s). [x] Gorgon.Graphics.Fonts An extensive bitmap font creation interface (within the graphics module) that supports kerning, outlining of font glyphs, and other customizations to help generate impressive looking text. Currently Gorgon supports reading and writing of font files through codecs. Support is included for: GorFont: A proprietary binary format for Gorgon. BmFont: A popular font file type created by Andreas Jönsson (Note: this support is limited to the text based file format at this time). In addition to the support above, applications can introduce their own codecs to read/write whatever font types they wish by extending the GorgonFontCodec type. (Plug in support is pending at this time) [x] Gorgon.Renderers.Gorgon2D A 2D renderer that sits on top of the graphics module to make developing 2D games/applications much easier. It supports: Sprites Primitives (triangles, lines, ellipses, arcs, and rectangles) Text rendering A shader based effects system All of these are provided using batched rendering, similar to MonoGame for maximum performance. [x] Gorgon.IO.Gorgon2D IO functionality for serializing sprite and polysprite data to and from various formats using codecs. [x] Gorgon.Animation An animation module that allows the creation and playback of key framed animations for various types of objects. Animation controllers for the 2D renderer are provided by the Gorgon.Animation.Gorgon2D assembly. [x] Gorgon.Editor (In Development) A flexible content editor to allow for the creation and editing of content. Supports a plug in based architecture to allow developers to extend the editor indefinitely. Supports file management of content by using a simple tree layout for folders and files. Comes with an image editor plug in which allows users to add depth slices to 3D images (I have yet, for the life of me to find anything on the web that does this), mip maps and array indices, and other simple functions. Comes with a sprite editor plug in which allows users to clip sprites from an image and store them as a file. Can output the files as a packed file. The type of file that be written out is provided via plug in support (currently only supports the proprietary Gorgon packed file format). Can import packed files using file system plug ins (currently has support for zip and the proprietary Gorgon packed file formats - included with Gorgon as file system plug ins). TBD... What's required? .NET 4.7.2 Windows 10 (Build 15063 or later). Microsoft DirectX 11.4 To compile the library Visual C# 2017 v15.8 or later. To use the library You may use any .NET 4.7.2 enabled language (e.g. Visual Basic .NET) to write an application with Gorgon. Source code The master branch contains the current release version of Gorgon 3.0. Acknowledgements Gorgon uses icons from the following sources: Oxygen https://github.com/pasnox/oxygen-icons-png http://www.iconarchive.com/show/oxygen-icons-by-oxygen-icons.org.html Icons8 http://https://icons8.com Sprites example textures from: http://millionthvector.blogspot.com/ This following image(s) is/are not redistributable without permission from the original author. "HotPocket.dds" by Starkiteckt https://www.deviantart.com/starkiteckt/art/Hot-Pocket-433337115 Third Party True Type fonts: Tequila by uZiMweB \ A Charming Font by GemFonts \ Sunset by Harold's Fonts \ Monsters Attack ! by The Empire of the Claw \ Grunja by Apostrophic Labs \ The Bold Font by ???
  2. Tape_Worm

    Gorgon Update #2

    This is another small update that fixes a couple of bugs in the editor. These issues were not logged in the issues page on the github repo, but a description can be found in the change log on the releases page. To get the latest version, go to the Github Releases page and download version 3.0.72.168. View the full article
  3. Tape_Worm

    Gorgon Update #1

    An update for Gorgon was released today. This addresses issues #10 and #11 on the GitHub issues page. To get the latest version, go to the GitHub releases page and download version 3.0.71.153. View the full article
  4. Tape_Worm

    C# v3.0 Release

    So, after about 5 years. Version 3 is done. Well, as done as I’m going to make it. Gorgon is finally released at version 3.0.66.147 and you can download it from the Gorgon GitHub repository on the releases tab. A lot of work has been done over the last few weeks to finalize this release. Bugs fixed, examples created, documentation updated, etc… One of the new things added was an effect for HDR Bloom (yeah, I know, it can be tacky). And along with this effect, a new example was created to show off a bunch of functionality (including the aforementioned bloom effect) all in one place. The ever predictable space scene. Now, I’m sure there’s still a ton of bugs and I’m aware of some performance issues in particular the editor application and saving packed files. Any issues can be filed on the GitHub repository issues tab. So what’s next? Well, I’ve spent a massive amount of time on this, especially in the last year and I really need a break. So I’ll be stepping away from this for a few weeks. Of course, if there are any bugs I’ll be sure to deal with them. I’ve been checking the issues tab on the repo for years now, I probably won’t be stopping any time soon. So yeah, there it is. Download it, give it a spin, and let me know what you find. View the full article
  5. Tape_Worm

    Screenshots

    Just a quick update to let anyone who’s listening (all 0 of you – and the Russian spambots) know that the screenshot gallery has been updated with new images from v3. If you’re interested in seeing what Gorgon can do for you, you might want to pop in there and have a gander. View the full article
  6. Tape_Worm

    Editor v3

    So, the radio silence is now over, at least for this post. I’ve been toiling away on creating an editor for Gorgon so people can edit sprites, and images (somewhat). A little about the editor The editor is similar to the one in v2 in that it is completely plug in driven. That is, almost all functionality is based on plug ins, and without any plug ins the editor is nothing more than a file manager. The advantage of this is that end users can write their own plug ins for their own content. For example, if you’re making a game that uses a tile map, you’ll likely want a tile map editor. Instead of writing your own full fledged editor, and trying to make it work with the Gorgon file system, you could write a plug in for the Gorgon editor that allows you to create tile maps. All file system manipulation is taken care of, and with default plug ins, even sprite creation and image handling is all in the same place as your tile editor. Where this version differs from 2.0 is … well, pretty much everything else. The previous incarnation opened up a packed file and copied the contents to a temp folder, and when you worked on the content, it’d alter the file in the temp directory. When you saved the project, it’d repack the file with the updated content. This has proven to be less than performant. The new editor works more like Unity now, in that you pick a folder on your hard drive and you use that for editing your content. The folder is no longer temporary, so you can use it directly in your applications, or, should you want a packed file, you can export it as a packed file using the Gorgon packed file format (a plug in, a developer could create one that writes zip files if they so choose). You can also import packed files using the default plug ins for the Gorgon packed file format, or zip files. Plug ins Obviously, the editor is useless without plug ins. So, Gorgon (as of this writing) comes with 2 plug ins out of the box. The image editor, and the sprite editor. As time and energy allow, more will be added as development continues. Image Editor The image editor, with a volume texture loaded. It even has a volume rendering preview. The image editor is a bit of a misnomer. You don’t actually paint on the image/texture like you would in Paint.Net or Photoshop. It’s mostly a viewer, but there is some editing functionality like changing the image type, image format, updating array slices, mip levels and, if you have a 3D (volume) texture: depth slices. As you can see in the screenshot above, there’s a volume texture loaded with Perlin noise (and some alterations done by me – that’s the black line) with a nifty volume rendering preview to show how the texture will look. I’ve yet to see any image editor handle volume textures, so this is particularly handy. Adding array index data, mip data, and depth data is easily done by dragging an image into the image area on the screen. You can drag from the file explorer on the right hand side, or you can drag from Windows Explorer. If you have a texture cube, it will even change the view to the typical cross format and you can drop an image into each face, and it will also support multiple image cubes in the same texture (by having an array count that is a multiple of 6). If you want to edit the image data (i.e. paint some pixels), then Gorgon will take the current array index/mip level/depth slice and export it as a PNG file and load it into the editor associated with PNG files. When you are done editing, the image will automatically update in the editor. When images are imported into the editor, they are converted to DDS format. Why? Well: DDS is a ubiquitous format and has been around forever and designed for textures exclusively. It supports every texel format. It supports DXt compression – This is very useful when you have a lot of image data to load into the GPU. And it’s just easier to deal with one file format instead of trying to guess which format should be used when loading/saving image data. Now, with that said, images imported into the editor will be converted from their native format into DDS. So you can import any image file format supported by Gorgon, and, of course, by any image codec plug in you supply (this is supported, but no image codec plug in management is available in the editor yet – soon). Sprite Editor The sprite editor. The sprite editor allows you to clip out sprites from image/texture files and save those clipping coordinates, and other metadata into a file that can be read back and used. This saves a lot of grief if you’re trying to build up a bunch of sprites by not having to copy them out by hand. Sprites can be clipped in the usual way by dragging and resizing a rectangle around on the screen. And if you need pixel level accuracy, you can bring up the Manual Input window and enter the coordinates in by hand. You can also clip sprites by using a fixed size selection rectangle. But, you’re not limited to just drawing a rectangle to get at your sprite data. You can also use the sprite picker to click on a sprite in the image, and the sprite editor will do its best to determine the bounds for that sprite and surround it with a tight fitting rectangle. Or, if you want some spacing, you can also pad the rectangle by a specified number of pixels. The picker works by using a masking color/alpha value as means to locate the boundaries. When you click on the sprite it starts sampling the image in multiple directions and if it hits the masking color/alpha value, it stops and takes that as a minimum/maximum bound area. It then continues this process until the full extents are found (it’s basically a dumb flood fill). This masking color/alpha value can be modified by the user. Sprites can also have their corners (vertices) moved independently to allow skewing of the sprite using a corner offset editor. Other functions like altering the sprite color (or individual sprite corner/vertex color), and anchor point editing are also available. And the texture wrapping functionality changes the view to show what each wrapping mode along the X and Y axes would look like, and allows you to apply wrapping to the sprite (be aware though, that if you’re using a texture atlas, then the results will differ from the editor view). Sprites can also be imported into the editor like images, and by using plug ins, external formats can be loaded and converted into the Gorgon sprite file format. Currently this import process supports Gorgon v1, v2 and v3 sprite files. What’s next Well, there’s a few things that need to go in. Such as plug in management support for sprites and images so users can bring in other formats not supported natively by Gorgon. Also, a tool to clip multiple sprites from a texture atlas using a grid, and a sprite atlas creation utility. Ideally, I’d like to have a Font editor and Animation editor in there. But those will take some time to get off the ground. And the Animation editor is higher priority for me, so that one would be tackled first. Anyway, that’s it. The most current commits on the v3.0 branch on Github have the updated editor code, so feel free to check it out. And report any bugs you find on the Github issues page. View the full article
  7. That is patently untrue. I've been doing this kind of stuff in pure C# off and on for almost 15 years now, and performance is not an issue, especially for 2D games. Frankly, the kind of performance I bet you think you need requires quite a bit of effort even in a native language like C++. If you insist on going down this path, realize your world is going to get quite a bit more complicated by merging the C#/C++ world together, so a look at C++/CLI might be beneficial. That said, I would definitely not recommend you try and mix up the languages like this. The same could be said by using Unity or Unreal. I get that. But ask yourself, what do you really want to do here? Do you want to make a game? Or do you want to make a rendering API and/or Engine? For myself, I don't care about the former, I gave up on that when I was in my 20's. But I do continue on building the latter even now in my 40's because I find it fascinating and fun for learning, knowing full well that I will almost certainly never make a game. Knowing where your objective is makes getting there a lot less frustrating. I'm going to assume based on this statement that you have very little experience in real world programming. But if you feel this way, you'll never function well in a team, or even using any API that you didn't write. You need to break yourself of this "not written here" mindset, that way lies madness. Given the bullshit surrounding Unity the last couple of weeks, this is entirely understandable. That's a good reason. But you need to ask yourself: What do I need to implement that isn't provided by another engine? Can I implement it using the other engine (FYI: the answer is yes more often than not)? How do you know you can't do what you need in the other engine without having tried it? It's all well and good to want to learn, and write a bunch of stuff, but you also have to set realistic expectations and mixing things up like this is likely going to end in frustration. If all you want to do is plop a few sprites on the screen and have them pew-pew at each other, then you can do that in any number of engines without much work. If you insist on writing code to build up your game/engine/whatever, then pick a single language that you're comfortable with, pick up an API (MonoGame for C#, SDL for C++, etc...) and play with it until you see some results. The benefit with both MonoGame and SDL is that they're open source, and as you get more comfortable with using them, you can crack them open and see what makes them tick, and then you can think about writing an engine or whatever.
  8. This article, and the citations it presents, terrifies me. I dread the potential flood of things like: "why are we using that crappy ol' OOP!?", "Duh, data oriented is SO much better and OOP is garbage, I read it on Breitbart once!", etc... I'm not even referring to the potential commentary on this site. In my own professional world, I can see things like this coming up and having to spend energy (that I could be using for other things) on explaining why articles like this need to be ignored and why it'll be a very cold day in hell before I allow the rewrite of our code. Especially to placate those people who've bought into the software development equivalent of fake news. As someone said before. OOP is a tool. Like everything else, it has a time and a place and needs to be wielded correctly to avoid cutting your (or someone elses) fingers off. Even principles like SOLID, which I endorse wholeheartedly, are nothing more than a set of guidelines/best practices and sometimes that can run counter to the solution of the problem you're trying to solve, but it doesn't mean you shouldn't try to follow them. This kind of thing is basically the equivalent of saying, "hey, my phone has thumbprints on the screen, clearly thumbs are terrible and should be removed entirely and replaced with using my big toe!" Personally, I'm of the mind that the only thing that's absolute, the "one true thing", is that you need to employ critical thinking skills when using your methodology/toolset/clothing style/haircut/etc... of choice. Otherwise you will end up making a straight up disaster.
  9. Tape_Worm

    Entity Component Systems and Data Oriented Design

    I, for one, would be quite interested in this. I spend a good chunk of my day reviewing code at work for poor design decisions that violate SOLID principles, and it'd be nice to see your point of view on what constitutes a violation of SOLID and ideas on how to best repair those violations.
  10. I agree. Also, I'd like to add that anything politics related should be hidden from the main topic stream on the front page (at least give me the option to filter it). If people want to talk shit politics, then they should have to go looking for it explicitly. It gets very tiresome and annoying (and occasionally rage inducing) whenever I see some idiot ranting about their "free speech" being suppressed because the world at large is telling them it's not OK to be racist/homophobic/misogynistic/transphobic/gay frogs/Alex Jones/etc... on my front page feed. For the most part, I rarely participate in these types of conversations because I personally believe people don't want to learn or be educated and just want to be right. It's a waste of my time and energy to deal with them or even read their nonsense. And I certainly wouldn't go seeking it out on my own, so having them show up like that provides me with absolutely no value whatsoever. Political conversation has its place and outright banning it would be a mistake. But, given the current state of things, it's a topic that needs very special handling and a zero tolerance approach. I don't think suppressing the rating/voting system is a good idea either. Frankly, some of us just want to tell people they're idiots without getting into a long drawn out argument (an argument that is a waste of time because people will double down on their stupidity more often than not). I think it's an OK (not perfect) mechanism to show people that their kind of backwards thinking is not wanted or appreciated and they should consider going elsewhere without having to write a thesis.
  11. Tape_Worm

    PerspectiveOffCenterLH

    Awesome, thanks for the explanation. I managed to make it all work out by just transforming my quads instead and leaving the camera fixed. By doing that (and countless other small adjustments...) I got the end result I wanted: I did this all with my 2D API that I've been writing off and on over the last... well... very long time.
  12. So, I'm using PerspectiveOffCenterLH (in SharpDX, but that should not matter) to project perspective correct stuff into screen space. Up until last night, it was working well. I could translate on all axes, and I can rotate on the Z axis just fine. So I added y-axis rotation for giggles and that's when things went all weird. Every time I rotated about the Y-axis, my geometry (a simple quad) gets distorted. Now, I have to admit to being a dumbass when it comes to linear algebra, and it's been a very long time since I've had to deal with a projection matrix directly, so it could be that I'm using the wrong tool for the job due to my ignorance. Basically it looks like the vertices on each side stretch off into the distance (more and more as I rotate): I'd like to note that I have another app, where I'm using PerspectiveFovLH, and that's working just fine. So again, this very well could be a case of "the wrong tool for the job". Here's the code I'm using to build up my stuff: // Matrix construction code. Anchor is 0, 0 for now, so we can ignore it. // ViewDimensions is the width and height of the render target. var anchor = DX.Vector2.Zero; DX.Matrix.PerspectiveOffCenterLH(-anchor.X, ViewDimensions.Width - anchor.X, ViewDimensions.Height - anchor.Y, -anchor.Y, MinimumDepth, MaximumDepth, out ProjectionMatrix); // This is my code for combining my view + projection DX.Matrix.Multiply(ref ViewMatrix, ref ProjectionMatrix, out ViewProjectionMatrix); // And this is my code for building the view. DX.Matrix translation = DX.Matrix.Identity; DX.Matrix.RotationYawPitchRoll(_yaw.ToRadians(), 0, _roll.ToRadians(), out DX.Matrix rotation); // NOTE: This doesn't work either. //DX.Matrix.RotateY(_yaw.ToRadians()); DX.Matrix.Multiply(ref rotation, ref translation, out ViewMatrix); // My code in the vertex shader is pretty simple: Vertex output = input; output.position = mul(ViewProjection, output.position); return output; The order of operations is indeed correct. It works just fine when I don't rotate on the Y (or X - but that's not important for today) axis. So, yeah, can someone tell me if I'm dumb and using the wrong projection matrix type? And if I can, an explanation for it would be much appreciated to so I don't make this mistake again (don't go too math crazy, I'm old and my math skills are worse than ever - talk to me like I'm 5).
  13. Tape_Worm

    Gorgon v3 – Animation

    I got the rework of the animation system for v3 done and up on the git hubs. Naturally, I took this awesome video of it. It’s a music video. But not just any music video. A very bad, cheesy 80’s music video (the best kind). Of course, the music is metal \m/ (done, very poorly, by yours truly). Anyway, that’s all. View the full article
  14. So, it’s been a long time since I’ve posted anything here. Mostly because I’ve not been writing much code in the last while and real life has been my focus. Since I’ve been gone, I’ve become a software architect at my job, and that keeps me quite busy. Gorgon I’ve uploaded Gorgon v2 (such as it is) to Git. I’m not entirely happy with that version, and frankly I lost my motivation to finish it. As it is, it’s feature complete, but may have bugs. However, the editor application is in an unfinished state (it’s usable, but it’s got issues). From time to time I toyed with making a new version, but never really had the motivation to go beyond prototyping. I tried using Unreal and Unity, and while those things are quite impressive, they seem to … I dunno, lack something. Especially in the 2D arena. Also, as a programmer, and an oldschool one at that, it felt quite unnatural to use an editor like that to build up stuff. However. Lately I’ve been in a fit of watching game documentaries on Youtube (and oddly enough, CBC.ca), and while watching a documentary series on game developers from the 80’s (henceforth known as the best decade), I felt compelled to have another kick at the can. So, how’s it going? Well.. it’s going quite well. I’ve got the core graphics library done, and the 2D renderer is well under way (I can render text and sprites). I’ve opted to learn how modern rendering engines do their thing to see if I can get some inspiration for performance improvements. And I did. The core Gorgon library now renders using a stateless drawing mechanism where an immutable draw call object, configured with immutable pipeline states (similar to how D3D 12 does a PSO). It’s quite a departure from the older versions. But, I’ve seen some impressive performance gains because of this. I’ve also decided that I absolutely HATE Direct3D 12. I get it, it’s wonderful for squeezing every last ounce of performance from your machine so you can get incredible visuals. But it is a complicated beast, leaving it to the developer to control almost every aspect of programming the GPU. It kind of reminds me of Immediate mode back in the D3D 3.0 days (nowhere near that bad though). So, to that end, I’ve decided to base Gorgon’s core graphics API on the latest (at least, latest available in SharpDX) version of Direct 3D 11, which is 11.4. Honestly, from all I’ve seen, Microsoft has no intention of abandoning 11.x since it has a firmly rooted place in development due to how much simpler it is to use over 12. That may change in the future, but for now it’s good enough for me. And this is likely to piss some people off: This new version of Gorgon requires Windows 10. And no, I don’t care to hear about how I’m being spied on. So, you’re probably wondering hows the performance of the rendering in the 2D API? Well, see the image: Yes, that’s 131072 sprites, plus text, rendering at above 60 FPS. That’s running on a GeForce 1080 GTX. A pretty high end GPU. And you might think… “well, for that GPU, 70+ fps isn’t that great” But keep in mind, those are alpha blended, textured, animated sprites (all 131072 of them). This little test/example app has been with me since 1.0 and it’s served me well as a quasi benchmark. To give you an idea of how much of an improvement this is from v1 to now (all on the 1080): V1 – ~15 FPS with the same number of sprites, and a lower window resolution (800×600 vs 1280×800). This version used D3D 9 V2 – 28-30 FPS. Same resolution, using D3D 11.0 V3 – Well.. look at the screen shot. It’s an improvement. So yeah, that’s where I’m at. Will I keep going and release this? Who knows… I do have a v3.0 branch up on the GitHub repo, which contains just the core API for now (which, sadly has some bugs that I’ve since patched while creating the 2D API). So, if you want, you can grab it, and mess around with it. Just keep in mind that I offer no support for that version, and it will change over time and may break your stuff. View the full article
  15. Tape_Worm

    VSSetConstantBuffers1 Problems

    It's 256 minimum if you're going to offset into the buffer with xxSetConstantBuffers1. I can assume, if you don't offset into the buffer, the size is still an actual minimum of 16 bytes.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!