Important changes to Dagon

As development of the engine progresses, we make tests and listen to your feedback, I realize some things could be improved to make ours lives easier. The following features are currently being implemented in the new experimental branch of Dagon:

  1. Goodbye TEX format. Most Dagon developers will be interested in hearing this one: I’m looking to abandon support for our custom texture format. The reasons are many: the bundles are large, graphical quality is drastically reduced (especially with scenes making heavy use of gradients), and they can’t be loaded on mobile devices, thus forcing us to maintain two different formats of assets. It’s a hassle and the only benefit is quicker loading of nodes. The workaround is something I wanted to do a long time ago: node precaching. With todays computers, we could preload quite a few of them – just 1GB of RAM equals to 3-4 nodes… typically an entire room! It’s a no-brainer: you load smaller JPG textures directly, no conversion, and we could still achieve instant speeds with background preloading. Work needs to be done on this one but expect less headaches after I’m done.

  2. Switch to GLFW for interfacing with platforms. Of all the choices, I decided to stick with this library. SFML is rather intrusive and SDL way overkill. GLFW (http://www.glfw.org) does the two things we need and it does them great: create an OpenGL window and grab input. Dagon takes care of all the rest. This means I’m deprecating the native implementations of the engine in favor of this single DGSystem module based on GLFW. So far it’s working great!

  3. Handle threads with C++11 standard. Similarly, to avoid maintaining different implementations, I’m reworking threading with this new standard. It’s straightforward and portable, and that’s all we need. The caveat is that the latest version of your compiler of choice is required (for example, if you use Microsoft tools, you’ll have to stick with Visual Express 2012 to compile Dagon). No big deal anyway and it’s much less painful to maintain the code now.

  4. Use Premake for building Dagon. I will still provide Xcode and Visual Studio project files for you convenience, but you will be able to build your project of choice with Premake (http://industriousone.com/premake). This looks like the ideal system for Dagon given its reliance on Lua (and we happen to love Lua!). Besides, Cmake is ugly.

  5. License update. I can confirm that I will switch to MPL 2.0 for licensing Dagon, which is less annoying than CDDL.

I’d like to thank Phazon for suggesting the majority of these changes. They really seem to be the best approach to maintain a cross-platform and easy-to-maintain implementation :slight_smile:

Make sure you check out the GitHub repo for other upcoming updates to the engine. I’ve been tidying up the whole thing, especially the Issues section: https://github.com/Senscape/Dagon

The GitHub repo is on fire! Make sure you check out the experimental branch for cutting edge updates, including upcoming features in Asylum :wink:

https://github.com/Senscape/Dagon/tree/experimental

I was getting banding with jpg’s :s
I hope Imari kept all her images! I’m sure she was converting to TEX

Banding with JPGs? That’s weird. Did you try with quality=10?

If needed I can keep the TEX code but I’d advise against using it. In short, JPG will be more efficient with the node preloading. I’m also analyzing using the new libjpeg-turbo which allegedly is twice as fast :slight_smile:

Sent from my iPhone using Tapatalk 2

I’ll see what happens when all the new stuff is built, I’m in no rush
I’ll check what the quality was at…

what aboug pngs? Still my favorite format…

Oh yes, typical formats such as TGA and PNG will be also supported.

I was excited to see the flood of GitHub activity, but am still sorting through it. :stuck_out_tongue:

The TEX format as it stands now works very well, but I can batch convert. I have noticed that after the TEX conversion, there is some “rainbowing” in the gradient tones of the skys, but I was expecting the skys on the cube faces to be replaced by a movable sky. (I’ve saved alpha maps for each side of the cube separately.) Are you still planning to introduce the movable skys?

I prefer PNG to JPG, so I’m glad that it will still be okay.

Yes, keep those alphas as they will be useful for fancy effects, including movable skies :slight_smile:

PNG textures can get very large (especially at 2048x2048), although depending on the size of each project they could be good alternatives :nod:

Agustin, when the engine “reads” the JPG images, will they be automatically uncompressed?

I ask, because an earlier engine that I tried did just that. I took the images from a sample node and the initial TGAs are a whopping 72MB, but the TEX file is 12MB. The same node when converted to JPGs with 10% compression weighs in at 6MB, but uncompressed it is 27MB. As PNGs the node is 31.5MB.

Yes, of course. That’s the whole idea: to keep the files you distribute as small as possible and let the engine do all the hard work. In terms of convenience, nothing beats JPG.

I need to rework quite a few things in Dagon, though, to make this happen. But it can be done :slight_smile:

BTW there’s a current alternative to TEX: 8-bit PNGs. Now 8-bit equals 256 colors which is just as problematic for gradients, but you’d be surprised to see minimal differences in Asylum. With PNG-8 you can have sizes smaller than TEX with very fast loading. Still, the future is JPG :slight_smile:

Sorry, I didn’t phrase my question clearly. I assume that we should compress the JPEGs for use in Dagon to 90% quality or less? Otherwise the cumulative size of the node’s images will be about twice as large as the current TEX file. Will the additional compression of the JPEG, say to about 90% quality, require more time to open? Large JPEGs sometime open slowly because the program has to uncompress them in order to display them.

On a related note, I’ll still continue to save my initial renders as PNGs or TGAs. I’d also advise anyone who is likely to do any postwork on their images to do the same and to only save the image in JPEG format after all postwork is done. JPEGs degrade in quality every time that you open, then edit and save them. This is true even if you save the image as “uncompressed.”

Exactly, the original file should be in a lossless format. Either PNG or TGA do the trick.

As for JPGs, 90% is a good tradeoff between size and quality. However, sizes grow exponentially as you go higher. In fact, anything above 95% is overkill for pretty much any purpose.

Loading JPGs is very slow, yes, especially at 90% and above. But the upcoming preloader algorithm should make up for that. Hopefully, you won’t have to worry at all about loading speeds :nod:

About JPGs, are they going to be loaded as they are? For example if I render a scene and take a JPG image as a result, when I look at it from an image viewer, will the result be same in the engine (not counting the effects like saturation, brightness etc. that i need to change in the engine of course)?

I’m asking because as it is now after converting my images to the TEX format, my scenes become different in game as night and day. They are darker, have more artifacts, and gradients are visible. I wonder if JPGs will go through some sort of process to load them faster and change their quality in the meantime.

Precisely, they will look just the same! For example, if you disabled config.effects, they should look exactly as you rendered them (sans some inevitable smoothing from their transition to 3D).

Smashing! Splendid! Bee’s knees! Thank you.

By the way I understand the points 1 and 5, but I must admit I have no idea what you are talking about in 2, 3, and 4. I’m working on something almost identical to Asylum gameplay-wise. Lua code of Dagon is the limit of what I can handle. I hope I won’t be missing anything important if I can’t code.

Don’t worry about 2, 3 and 4, those were intended for users that contributed or will contribute to the Dagon code. And no, you won’t miss any features of the engine if you stick to the Lua side :slight_smile: