Enalis

Members
  • Content count

    326
  • Joined

  • Last visited

Community Reputation

333 Neutral

About Enalis

  • Rank
    Member

Personal Information

  1. Chaining Pixel Shaders

    Just to elaborate some more, chaining shaders would require you to output to an FBO at each stage, this takes up quite a bit of VRAM if they are RGBA32. Also, keep in mind that you are writing out to a lot of extra pixels for every frame, this also slows things down quite a bit. As mentioned before, it is unavoidable sometimes, like in the case of a Bloom pass, but it should definitely be minimized.
  2. Are you planning on doing this in real-time in a shader? I ask because that could result in quite a performance hit. Also, if you are not doing it in a shader, there is software that can already re-build height maps for you, given an obvious height scale parameter. It's important to note that if you are mapping something like stone, where one "bump" in the normal map might have the same slope as another, you will end up with the same height at those two different places because the curvature is the same and there's no way to know without the original height map where the slope ends in height at those distinct spots.
  3. *Obligatory don't do it yourself unless you really have to reply!*   Before you delve into this, have you looked at Tiled (http://www.mapeditor.org/)? It's very powerful and would easily create these sorts of maps with the right tile-set.
  4. Terrain tesselation and collision

    As mentioned previously, these things are indeed separate. I have also been working on the problem. What I do is keep the mesh data in very very small patches. I can tessellate these patches on the GPU for more visual detail, or turn them into a grid to pipe to the physics system. It works pretty well.
  5. I often describe my day simply as such:   40% research/reading 40% conversation 20% coding
  6. SFML 2.1

    I've had no issues thusly with any of the modules. I would avoid their threading stuff now though, since c++11 threads are pretty good.
  7. I'm working on a design for a pipelining game engine, with data some parallelization at each pipeline stage as well.   If I have 4 stages (input/networking, physics/animation, logic/ai, rendering). If I understand the idea of pipelining correctly, then each stage would get it's own copy of the game state, including a copy of the physics simulator (in my case a bullet physics world object). That way each stage can operate concurrently without affecting the other.   Now let's say that at stage 3, an object gets added to the simulation, stages 1, 2 and 4 are now out of sync, and since their simulation state data is ahead/behind respectively, then how can I even add this object to those simulation states without having them be out of sync from the start?   I'm sure this is something commonly solved, I just haven't been able to find any literature on the subject.   Thanks in advance!
  8. DAE is XML, there's a schema and a specification... beyond that it's pretty much up to you. The last time I went to use DAE directly, I ended up reading it myself. I would personally recommend Assimp.
  9. HTML5 tile enigne

    A good start for anyone getting into js coding is to use a lint tool. It will help you keep your code tidy and professional, as well as use good practices. You need to be heading in a good direction though. As far as cameras go, you can either define a simple x, y position in the world, and just offset your tiles by this. You can also give it a width and height to know how many tiles fit in a camera's frustum. There are many approaches but starting there might be easiest.   Have you considered using a HTML5 canvas rendering engine? There are many out there and will help you get started with rendering sprites and normal game things.
  10. I encourage you to spend time and look at a few different operating systems, APIs and development environments in general. I found love with OpenGL and KDevelop on KDE in Linux (Kubuntu). I haven't looked back in quite a while. I keep my engine/games cross platform so they'll run on Windows, OSX and Linux though, just for good form.
  11. SDL "Transparent" Window

    Have you tried setting the clear buffer color to say, 0, 0, 0, 0?   In opengl that is: http://www.opengl.org/sdk/docs/man/xhtml/glClearColor.xml
  12. 1: If it's truly turn based, this should be completely fine, and will make life a lot easier I'd say. I've even considering using compressed json strings for packets on real time games just because JSON rocks.
  13. Who uses linux?

    I'm going to try to put my Linux fanboyism aside:   For development, I find Linux to be a little easier to get started. You simply install most of the things you need to get started via the package manager and go. And when you do need to compile your own dependency, I find it less of a headache.   I also prefer the idea of Linux. Most distributions like Ubuntu are mostly if not all open source. This allows for the community as a whole to work on things together. The beauty of it is that you can go hack on your favorite Linux application most of the time and get things fixed.   Typically, if you have well supported hardware, Linux is rock solid. Because hardware vendors sometimes don't release specifications for their hardware drives can be a bear. Normally there is some support somewhere but it's hard to reverse engineer other drivers or figure out how to write some from scratch.   I for one am a fan of Kubuntu's latest version 12.10. I find KDE (The desktop environment, like explorer in Windows) to be a good transition from other OSs that doesn't sacrifice customizability. Out of the box, the applications bundled are rock solid as well. If you are a coder, you'll likely love KDevelop or even just Kate.   I do keep a windows box around for gaming and some media in general hooked up to my TV but that is it. And with Steam beta being out for Linux, and Netflix at least working for now, that Windows Box may not survive much longer.   My suggestion to you is to go out and download Kubuntu 12.10 and put it on a USB Drive to test it. You don't have to install it to test it out. The experience won't be as good running from a USB Drive but you can at least test some of your system compatibility.   Here's a link: http://www.kubuntu.org/
  14. I would say it's a useful exercise. There's still plenty of validity to the technique. I see the future of graphics techniques for engines being a myriad of approaches mixed together. Deferred is obviously an awesome technique for many lights on opaque surfaces. But many deferred renderers have a sort of traditional forward renderer stuffed inside to do translucent objects as well. As far as where to learn this stuff, I spent most of my time piecing together tiny articles talking about techniques, but in the end, how you implement it might be entirely dependent on the scope of the engine/game being developed. For instance, the battlefield 3 engine has buffers specific to terrain info storage, where my engine wants to accommodate both ground/space based games so I can't count on this info being there. In the end, I sincerely recommend you piece through some code. Feel free to look at mine as I've already done a lot of what was mentioned, but it's really up to you to discover your own techniques. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] [url="https://github.com/palodequeso/Element-Games-Engine/blob/master/Engine/Graphics/Source/RendererDeferred.cpp"]https://github.com/p...rerDeferred.cpp[/url]
  15. I struggled with this at first but found the data driven architecture to be quite nice. I have the basic Object class which you can attach any number of different types of attributes too. These include mesh/materials, variables, lights, particle systems, rigid bodies, etc. Attributes are user create-able too so you can attach any number of your own attribute types to the object. These can be used and manipulated in the specific game code, outside of the engine. One other thing you can do is attach a lua script to an object which has the ability to manipulate the object directly. Obviously some things need coded specific to the game itself, but most things can be accomplished with a flexible attribute system. I know this still sounds like a tangle web, but I invite you to just try coding a simple prototype... I think you'll find it easy to get through once you start. My code is on github, feel free to take a look. Here's a starting point: https://github.com/palodequeso/Element-Games-Engine/blob/master/Engine/Game/ObjectAttribute.h