Althar

Members
  • Content count

    47
  • Joined

  • Last visited

Community Reputation

580 Good

About Althar

  • Rank
    Member
  1. Not All is Fine in the Morrowind Universe

    Am I the only one wanting to see an article on "PVS-Studio" checked by itself?
  2. Hello all,   Here is my take : I've been in the game's industry for nearly 3 years now, and previously worked for a year on mobile Apps (multimedia and productivity) - I agree with 1 & 3, but am not so sure about 2 & 4.   The expression "having an impact" may be interpreted differently, based on how you view your job and your work. From a point of view of the number of characters in the code base that will be a result of you physically pressing keys on your keyboard, then no... This is a specialist world, and specialists will get to work on their areas of expertise and there is a good reason for that : no one wants a cowboy programmer going in and hacking in features in systems he/she is not familiar with - this is bad for the business and for the other programmers who have to mop up behind.   On the other hand, you will and should have an (positive) impact on your team and work colleagues - having an impact is about sharing ideas and contributing to the company in a personal and professional way : you get to suggest technical solution, help build and shape the future of the company, make friends, strap yourself to the code wolf of the company and pick his brains until you are ready to take his place.   I cannot really say I have experienced any overtime, not forced at least. My job is my passion, so there has been times where I have personally decided to stay in the office a little bit longer to finish something off. I have never been forced to stay, or been asked to work overtime unpaid. Maybe I have been lucky with my work places?   I would add to 3 that it isn't a good idea to keep your head low - on the contrary as a beginner you should constantly be talking to people and striving to learn anything you can from the best. Forget about your personal ego, all these cool games you've made and/or rendering features you've implemented during your years at uni/college - you will soon find out that there is a trick to the trade and it is very much an organic way of working as opposed to text book academia stuff you are taught in your studies.   Two points I will add to the list:   30% of your time writing up emails, 50% having discussions and attending meeting and only 20% actually writing code. For good reasons, if you lock yourself in a room and have to hammer down at your keyboard writing code from 9 in the morning until 5.30 closing time, then there is something seriously wrong with your work methods & it is likely to harm you, both mentally and physically.   You will learn to despise technical debt. Bugs are bad, missing features annoying, but technical debt is the root of all evil - be ready to deal with those, having to juggle between spending days re-factoring entire systems or succumbing to the workaround that has been in the code-base for years, de-cyphering code that has been modified by a gazillion programmers getting worse with every iteration, and crying in a corner when the only person who knows how the system works has moved to another company and now owns a yacht.
  3. I was sort of expecting someone to comment on Ogre3D   - can't really say I am a fan either, but I guess what I was trying to imply was that reading through existing rendering architectures might give him some insight on the various components and sub-system. In retrospective, it probably wasn't a good idea to paste it here, as one would probably need some for of experience in the field to be able to review it and tell the good from the bad.    Both XNA/Monogame & Gameplay3D (haven't used Gameplay3D much) are more frameworks/API rather than full fledged rendering engines but they are pretty standard in the way they wrap around rendering APIs and present a more user-friendly way of rendering.   I found XNA particularly fit for prototyping rendering pipeline architectures as you do not need to worry about resource management, and all the rendering API-gotchas.    +1 for the Bitsquid blog, well worth a read - I particularly enjoyed their sections of editor/asset database systems.
  4. Ok... I finally managed to get to the bottom of it.   I was misreading gl3wIsSupported return value, as a result of my confusion and it was working as expected after all.   The issue in the end was that I was providing invalid parameters to my glGetActiveAttrib call - specifically the size and type parameters are non-optional (I was passing NULL, silly me...) which didn't seem to bother the Mac's implementation but on the PC would result in a horrible crash.   Anyway, thanks guys for your help
  5. Just a quick progress report : I thought I would ditch GLEW (which apparently has a few issues with core profiles) and tried my luck with GL3W instead.   Verdict, the result is exactly the same - for some reason, a call to gl3wIsSupported(3, 3) fails even though the running context is OpenGL 3.3 and my PC has full core support for it. I can call the same function with different versions (tried 2.1, 3.0 & 4.4) and all of them work just fine...   What I do not understand is that I should be able to run my code in two different ways : Running an OpenGL 4.4 context with backwards compatibility Running an OpenGL 3.3 core context But for some reason none of these two options work...
  6. On Windows, my OpenGL context is created as the following : 3.3 Backwards-compatible Debug context I have also stepped through GLEW's initialisation process using gDebugger and the culprit function glGetActiveAttrib is being queried as expected - it would just appear that it is either or becomes invalid later down the line.   I have noticed however that the "Renderer version" comes out as 4.4 instead of 3.3 although I am not sure if this can be changed or whether this is at the driver level.
  7. Good point... The Macbook version seems fine as it is running a core profile, but now that you mention it I am not sure if this is the case for the Windows version. I had a go at hinting GLFW to create a core profile on windows but didn't seem to make any difference. I'll have to revisit my test in gDebugger as it does sound quite likely. I must admit I am still not on the ball with the concepts of core profile, forward and backward compatibility. I've come back to desktop GL after a few years of GLES1.0/2.0 and a lot of Direct3D.
  8. Thanks for the replies guys. Although you both have a valid point, I am setting glew experimental. As far as I am aware I am doing the text-book initialisation sequence, namely : - initialise GLFW - set window hints (aka. request OpenGL3.3 explicitely) - create the window and OpenGL context and set it as current - initialise GLEW I have run gDebugger to try and figure out what was going on. It would appear that GLFW first creates a 4.4 context, then destroys it and creates the requested 3.3 one. Just before initialising GLEW I query GL_VERSION and am positive it is using OpenGL3.3. If I try and compile a shader with version >330 it will complain that it does not support it which is the expected behaviour. What makes no sense is the fact that GLEW has its functions bound as if it was running 4.4. I doubt this would have any impact but It may be worth mentioning I am linking GLEW as a static lib (GLEW_STATIC with the single context variant). The only explanation I can think of for the moment is that GLEW is somehow initialising against the initial context GLFW created (4.4) instead of the one I explicitly requested (3.3) which is the only one in existence at the time where glewInit is taking place. I would happily cater for both implementations if I knew why GLEW behaved in such a way. In the meantime I am slightly concerned with the lack of consistency in behaviour and what I am observing. As it stand it would be impossible to implement my GL render interface following the OpenGL3.3 to the letter.
  9. Hello all,   I am having a bit of an issue with my personal game engine, more specifically with GLFW's context & GLEW's initialisation.   I started off supporting the default context that my PC would support (OpenGL 4.4) but as I have now decided to make it cross-platform made the decision to settle for & comply with the specifications of OpenGL 3.3 (which is supported by my 2010 MacBook Pro).   I have managed to setup an OpenGL 3.3 context using GLFW' and the returned "GL_VERSION" is the expected value - on the other hand, it would appear that my GLEW is not properly initialised and will result in unhandled exceptions when trying to call certain functions.   For instance, my shader compilation code performs reflection to extract the vertex attribute name and bind them to pre-defined bindings : OpenGL 4.4 : glGetProgramResourceName  OpenGL 3.3 : glGetActiveAttrib   For some reason obscure I am finding that the OpenGL 4.4 call works (glGetProgramResourceName) while the OpenGL 3.3 call (glGetActiveAttrib) results in a crash.   Any ideas what could be the cause of that and/or through what mechanic GLEW binds its functions?   Thanks in advance,      
  10. As everyone else said, C++ is the bread and butter of the AAA industry.   I completely agree with djtesh with C# being a popular contender in the indie category and fairly widespread (Unity, Monogame/XNA), so that would have to be my first choice : it is a strong multi-paradigm language, very beginner-friendly and is a good place to be in if and when you decide to make the jump for C++, Java or any other language (even functional).   Unity has a few sharp edge and you can get into tricky situations if you stroke it the wrong way but overall it is a very good prototyping tool which allows you to concentrate on gameplay logic (get to learn some C#) and get content into your game without having to worry about all the nuts and bolts that build up the asset conditioning pipeline, scene management and general engine architecture.
  11. Game Engine Architecture is definitely a must-read ; it doesn't go into the specifics of the rendering pipeline per say but should give you an insight on what is out there so that you can then do your own in-depth research.   Don't be afraid to download various rendering frameworks/game engines out there and have a look for yourself. Going through presentations from AAA companies will also give you some insight on how their engines are designed :http://developer.amd.com/wordpress/media/2013/02/Andersson-Tatarchuk-FrostbiteRenderingArchitectureGDC07_AMD_Session.pdf   Again, you will find it very difficult to find a tutorial or paper on "designing and writing your own rendering framework" simply because it is too vast a subject and the solutions, as well as the complexity of the systems varies greatly with the scope of the project.   If your goal is to get a simple game up and running, you can usually make without a sophisticated rendering architecture and just go for immediate rendering. On the other hand if you go for something more complex, it is difficult to point you out to a single resource, as there is simply too much to cover.   My advice would be to read up about the general stuff, download a few frameworks and peel through the code/use them (Ogre3D, XNA/Monogame, Gameplay3D, etc.) and work out the patterns into your engineering brain dump. Once you get there, you'll have a fairly good idea of what to tackle and what kinds of solutions are available to you.
  12. Hello,   One thing to keep in mind is that there is no one-fits-all rendering architecture. The architecture will depend on a range of parameters, from the targeted platforms/APIs to the effects and techniques you would like to support.   What level of abstraction are you thinking about when you talk about the rendering architecture? There are many layers to it, to name a few : The Hardware abstraction layer : OpenGL/Direct3D etc. if you are only targeting a single platform/API you can probably get away without, otherwise this is a good place to start. The Pipeline or sometimes called the "RenderManager" which typically organises a list of "Renderables" or sometimes even more abstract render commands into render lists and submits a frame to the HAL. The Scene visibility/queries : which will typically build lists of entities to render and submit them to the pipeline.   Rendering architectures is a wide subject, so you will find it very difficult to find all-in-one tutorials. If you give us more information regarding what it is you are trying to achieve and what your requirements, we should be able to point you towards some useful resources.   On a personal note, I would advise you to stay away from any scene-graph-based rendering architectures - at least until you get a better understanding of what is involved. Using a scene graph to do everything can be attractive and seem intuitive at first but it just leads to code spaghetti and maintenance nightmare later down the line when it is mis/overused (which is often what you find on the web) and has severe limitations, both performance-related and feature-related when abused.
  13. A vertex occlusion baking guide

    Impressive - would you be able to share with us a screenshot of the AO on its own?
  14. Roads on Geo MipMapped Terrain

    Not entirely sure what you could get out of these, but Outerra has a few blog posts on their road system :    http://outerra.blogspot.co.uk/2009/06/roads.html
  15. PCSS

    Hello NEvOI,   The penumbra width calculation is the following : lightSize * (zReceiver - zBlocker ) / zBlocker . Effectively, the penumbra width is approximated by the distance ratio between the receiver & the blocker depth, modulated by a constant : The zReceiver depth is the depth of the fragment (in your shadow map) you are trying to shade The zBlocker depth is the average depth (in your shadow map) around the receiver fragment. The lightSize will be a fixed constant in world-space.  Put simply, the further apart zReceiver and zBlocker are, the bigger the penumbra - similarly, as zReceiver tends towards zBlocker, the penumbra width will tend to 0.   I am not sure where you got sizeWindowSample from, but I have had good results, with just this simple formula above. The papers you mention calculate a dynamic search width based on various parameters but aren't really needed to get it working : a fixed search width does the trick.   Hope this helps?