Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 02 Jul 2004
Offline Last Active Mar 23 2015 10:48 AM

#5091337 Textures becoming transparent as camera approaches

Posted by on 03 September 2013 - 10:10 AM

Without seeing any code . The first thing that popped into my head is that something is wrong with texture mipmapping.

#5063043 Font rendering with Freetype - Quality problems

Posted by on 19 May 2013 - 12:00 PM

Yes, this makes sense to me.  When dealing with any pixel-perfect rendering, you should always represent your positions and sizes as integers.  When you specify a 0.5f, the GPU will ultimately have to choose which pixel it gets mapped to (this is actually done based on your projection matrix).  I'm not sure why it's different on NVIDIA vs ATI, but it's probably due to floating point math differences.


For pixel perfect rendering I would use an orthographic projection that maps directly to your screen resolution.  Also make sure the viewport (glViewport() if you're using OpenGL) is also set to your screen resolution.  Don't rely on the default viewport that is set for you when you bind the OpenGL context.


I've recently implemented font rendering using freetype and have had results almost exactly to what you have shown in your image.

#5039801 Learning GLSL all over again

Posted by on 05 March 2013 - 06:57 PM

I believe OpenGL handles all of this during glLinkProgram().  It will bind the inputs and outputs of the vertex and fragment shader... and complain (i.e. fail) if anything doesn't line up.  For older versions of GLSL, there was varying.  I believe it's the same concept... just new keywords.


The only output of a fragment shader is going to be a vec4, since you are writing a color (or value) to a render target.

#5029773 [Tutorial] Instant-Insertion Quadtrees

Posted by on 07 February 2013 - 11:28 AM

Great tutorial!

Wit this technique, are my world coordinates forced to be from 0 - 256? And objects will only be spatially sorted at a resolution of (1/256)?

#5022275 Study Doom 3 code

Posted by on 16 January 2013 - 01:30 PM

This may be of interest to you - http://fabiensanglard.net/doom3/index.php

#5020799 Grass and what to do

Posted by on 12 January 2013 - 01:03 PM

I would probably start by creating many textured quads, giving them a sway (via shear matrix), and then batching all of them on the CPU.  Then send them all to the GPU in a single (or minimal) render calls. 


The problem here will probably be depth sorting (since the grass textures will have alpha):  You could either turn off depth writes and just let the pixels clash together, or spend the time sorting them if you have enough CPU resources.  I'm sure there are papers on the subject if you want to get more advanced.


If you want the grass to cast shadows, you can still use standard shadow mapping.  During the shadow pass, draw the grass with alpha-testing enabled. 

#5012554 engine design

Posted by on 19 December 2012 - 01:34 PM

In short, while I respect that you might find it difficult to write a game engine, it feels like you are assuming that everyone just writes game engines without some kind of idea as to what kind of game the engine will be used for.

Certainly not everyone. I did not mean to make that assumption. My initial comment meant to state that if one is having trouble writing an engine, then don't be afraid to continue writing games/apps and then refactor. The notion of "I must write an engine before I write a game" can be a trap for beginners with less experience.

If one is experienced and disciplined enough to write small unit tests for each feature and prove that their implementations work and their API's are intuitive throughout development, then I agree with your methods completely.

The bottom line is, just write code, fail early and often, write more code, and continue learning. This experience will only make you a better programmer overall.

#5010760 engine design

Posted by on 14 December 2012 - 04:03 PM

Continue writing games. Then look back and factor out any common and reusable code. This will serve as the basis of your engine.

#5007136 IMGUI

Posted by on 04 December 2012 - 11:26 AM

I think Zipster hit it spot on.

RMGUI's cater towards artists/designers at the front of the pipleline and programmers at the end. IMGUI is the exact opposite - programmers will implement the logical components of the gui and then can expose the data (layout, color, theme, etc) for artists/designers to tweak.

I suppose it really depends on the project/team you are working with. If your engineers are nothing more than code monkeys, and need specific requirements for everything they write, then RMGUI may be best suited. However, if the engineers are making more of the design decisions, and you just want to outsource your art, then IMGUI may be best suited.

To answer some of the OP questions:
a) I would implement modal dialogs as part of a layered screen system, and use multiple IMGUI objects. You can push and pop "screens" onto the stack and trap input to the top level. Typically though, IMGUI does not support overlapping widgets.

b) Draggable windows are implemented by returning the (x, y) position of the window out of the function, and using them as inputs for the next frame. The IMGUI will store the mouse drag information in it's internal state.

c) I don't think you can identify controls throughout a frame. All widgets are independent of eachother. I'm having trouble coming up with reasons why you need to identify a control with IMGUI.

d) As in the paragraph above, IMGUI is probably better suited for programmers at the beginning of the pipeline (i.e. hand coded), and then expose whatever data you need tweaked to the artists. Using a generic designer to be later implemented into the game by programmers doesn't really make sense to me with IMGUI. The IMGUI is tightly coupled to the code flow.

e) I don't have an answer.
f) I don't have an answer.

g) An IMGUI can store whatever data it needs between frames. Typically it stores a variety of IDs that reference to what widget is 'hot' or 'active'. The key point about IMGUI is that typically only one widget can be interacted with at a time, so storing state in every individual widget is a waste.

#4972286 Asynchronous Loading - Dependencies?

Posted by on 22 August 2012 - 11:43 AM

As an example, during the load of a Shader, if the VertexShader it is dependent on hasn't been loaded yet, you could do the following:

1) Shader load() returns false - also sending out the dependency it requires.
2) The VertexShader the Shader requires is added to the resource loader if it hasn't been added already.
3) The Shader is re-added to the resource loader

With this in mind, the Shader load() could execute again before the VertexShader and the same thing happens. This could be ok, but will also keep you in an infinite loop if there is a problem locating the VertexShader. In order to handle these cases, I would probably add a timeout or a max fail count to each loader, and log the information.

You could also adjust the thread priority of each loader when a dependency is encountered, but I would try to keep things simple at first and work from there.

#4971880 Lighting in caves

Posted by on 21 August 2012 - 10:28 AM

Has anyone considered an approach like Instant Radiosity w/ deferred rendering? Maybe one Virtual Point Lights could exist per voxel?

With several dynamic lights, I could possibly see this getting expensive though...

#4969869 How to check for UI mouse events properly

Posted by on 15 August 2012 - 10:24 AM

In the past, I've written game logic to include several screens. You can think of each screen as a layer of updates with the bottom layer being the game level/logic. Input is filtered from the top screen down to the bottom. On input, the screen can choose to handle it accordingly, and/or pass the input along to the one underneath it.

This makes it easy to pop up a 'pause screen' and halt updates to the 'game screen'. Or in your case, create a 'UI screen' and if input was handled, don't pass it down to the 'game screen' - just like Faelenor suggested.

#4964554 Material/Shader System - Design Review

Posted by on 30 July 2012 - 11:21 AM

I've implemented two types of shader/parameter systems before. My first implementation was very similar to yours. It has a very nice OO approach. You probably don't need a separate MaterialParameter class, your Material could hold a list of ShaderUniforms and provide an interface to set them. Don't worry too much about type checks - during development they will save your butt, and you can always #define them out in a release build. I don't see where you are doing static casts, but if your checking the type, then I don't see a problem with it.

In my second implementation, I steered away from this design, and tried to create something much simpler. My ShaderUniform class became a struct PoD with a type and union of parameters. I have methods to set them and bind them using a switch statement instead of hitting the vtable through virtual functions (I haven't profiled both implementations yet, so I don't know which is faster). Using a type and union may be simpler, but as I add more types, I need to touch several pieces of code to keep it updated. Using your OO approach allows you to easily create a new derived ShaderUniform and everything should just work.

Overall, I think your design is fine. As long as it's easy to use and extensible... which you'll find out pretty quick once you start using it as an interface.

Edit: It's probably not necessary to cache the ShaderUniforms into your Material class. Why not just create all of the uniforms and give them a default value on Init()?

#4956046 API agnostic systems without massive dynamic casts - possible?

Posted by on 05 July 2012 - 12:00 PM

What Hodgman described above is known as the Pimpl idiom - http://en.wikipedia.org/wiki/Opaque_pointer

It's a nice alternative to inheriting from an abstract class.

#4953776 VBO what does GPU prefers?

Posted by on 28 June 2012 - 04:18 PM

Keep in mind that is it sometimes more appropriate to use separate streams. For example, if you need a depth-only pass, the positional data should be kept in it's own buffer and sent to the GPU separately during this pass.