Jump to content

  • Log In with Google      Sign In   
  • Create Account

mhagain

Member Since 06 Jun 2010
Offline Last Active Today, 03:31 PM

#5302006 Vulkan is Next-Gen OpenGL

Posted by mhagain on 22 July 2016 - 01:13 PM

Axel Gneiting from id Software is porting Quake to Vulkan: https://twitter.com/axelgneiting/status/755988244408381443

Code: https://github.com/Novum/vkQuake

 

This is cool; it's going to be a really nice working example and we'll be able to see exactly how each block of modern Vulkan code relates to the original cruddy old legacy OpenGL 1.1 code.




#5301893 Matrix Calculation Efficiency

Posted by mhagain on 22 July 2016 - 02:28 AM

Yes.

 

And no, no, no, no, no: this is not premature optimization, it's engineering for efficiency, they're not the same thing and don't listen to anyone who tells you different.




#5301599 Weird Problem With Integers And Instanced Rendering

Posted by mhagain on 20 July 2016 - 12:40 PM

You need to use glVertexAttribIPointer rather than glVertexAttribPointer for this; see the documentation:

 

 

For glVertexAttribPointer, if normalized is set to GL_TRUE, it indicates that values stored in an integer format are to be mapped to the range [-1,1] (for signed values) or [0,1] (for unsigned values) when they are accessed and converted to floating point. Otherwise, values will be converted to floats directly without normalization.

For glVertexAttribIPointer, only the integer types GL_BYTE, GL_UNSIGNED_BYTE, GL_SHORT, GL_UNSIGNED_SHORT, GL_INT, GL_UNSIGNED_INT are accepted. Values are always left as integer values.




#5301003 "no Shaders Attached To Current Program" Only In Release Build

Posted by mhagain on 16 July 2016 - 02:32 PM

Differences between release and debug builds are commonly due to uninitialized stack variables: the debug memory allocator will typically initialize these to something well-known, the release allocator will not and you'll just get stack garbage.




#5300206 Rendering same vertex-array in different modes

Posted by mhagain on 11 July 2016 - 10:40 AM

The vertex order requirements will be different for different modes.  Typically you can't really expect a triangle fan and a line loop, for example, to be representable by the same vertices in the same order.

 

For a triangle fan, for example, the first vertex you specify is common to all triangles in the fan.  Every subsequent pair of vertices defines a triangle, with an overlap of 1 vertex between triangles, such that the vertex order is 0|1|2, 0|2|3, 0|3|4, 0|4|5, etc.  The number of triangles in the fan is equal to the number of vertices - 2.  A line loop is completely different.

 

One way to deal with this type of drawing is to switch the polygon mode (using glPolygonMode) between GL_LINE and GL_FILL.  This of course assumes that your actual objective is to provide a "wireframe mode" view of your regular geometry, and will allow you to use GL_TRIANGLE_FAN for both the fill and line options, so you only need be concerned about getting the correct vertex order for that mode.  I don't think this is available on ES (or WebGL, which it looks like you're using), however.

 

Another way is to define every vertex you're going to need in your vertex buffer, then add index buffers specifying the actual vertices (and their order) for each different mode.  Select the appropriate index buffer and draw using glDrawElements.




#5299495 GLEW for Android?

Posted by mhagain on 07 July 2016 - 03:26 AM

GLEW is specifically for desktop GL, not for GL ES, which is a different API.




#5299041 SDL Game Programming in C

Posted by mhagain on 04 July 2016 - 01:34 PM

One doesn't have pointers as a primary feature, the other does. Hell, both a programmer and a non-programmer can tell you that the syntax in even the classic "Hello World" example does not look the same. I like to use the example that saying "C/C++" in general is like saying "this tutorial is written in Spanish/Italian" while being written in just Spanish. Now imagine people just thought it was "your problem" that you only spoke Italian, really?


This is all well and good, but whether you like it or not SDL is still a C API.  That means that it uses C datatypes (yes, even pointers) and C idioms, even in C++ and even if the rest of the C++ code is otherwise well-formed and idiomatic.

 

For sure a C++ SDL tutorial isn't going to give you code that you can just copy/paste to a C program, but I think we can all agree that copy/paste programming isn't learning.  What it will give you is useful information like "this the API call I use to create a device" and "here are the flags I pass in to get the behaviour I need".




#5299038 draw lights in render engine

Posted by mhagain on 04 July 2016 - 01:19 PM

What you're not mentioning is how (if at all) you're planning to implement shadows.  Method 2 will integrate more cleanly with typical shadowing techniques, especially if you want to have an arbitrary number of shadow-casting lights.




#5298510 SDL Game Programming in C

Posted by mhagain on 29 June 2016 - 04:45 AM

SDL is a C API so any SDL tutorial you find is going to be valid, at least so far as the SDL elements are concerned.

 

Maybe you need to improve your C a bit more first...




#5298422 [MSVC] Why does SDL initialize member variables?

Posted by mhagain on 28 June 2016 - 12:07 PM

It's been a while since I dug into the subtleties of the Windows virtual memory APIs, but carving off a page and VirtualProtecting it with PAGE_NOACCESS would satisfy the non-NULL requirement, but also point at invalid, but not potentially arbitrary, memory.  Of course, it's typically the case where if something like that isn't done, there's normally a perfectly good reason which we're just not currently aware of.




#5298419 Blending order

Posted by mhagain on 28 June 2016 - 11:53 AM

The only case where you don't have to render translucent objects in back-to-front order is where they don't overlap.  The whole point of back-to-front order is so that rendering of overlapping translucent objects will work right, both in terms of the blend equation and of depth testing.

 

Checking that objects don't overlap might be more expensive than just doing the sort, however.

 

Some cases you're just not going to bother sorting every single translucent object.  If, for example, you have multiple particle emitters in a scene, each emitting hundreds of particles, you're probably going to want to sort by emitter rather than by particle, and the result can look OK.




#5298390 [MSVC] Why does SDL initialize member variables?

Posted by mhagain on 28 June 2016 - 09:20 AM

I think you're missing the point that the "S" in "SDL" stands for "Security".

 

It's nothing to do with assisting debugging, it's nothing to do with spotting non-security issues in your code.

 

So in the case of a pointer it's either initialized or it's not, and if it's not initialized then it's going to be pointing at some memory address that's effectively random.  Hence security: a 3rd party could use your unitialized pointer to gain access to some other arbitrary data in your process address space.




#5298097 Is using one the switch statement better then using multiple if statements?

Posted by mhagain on 26 June 2016 - 05:59 AM

Unless it's in a performance-critical part of the code, just use whichever makes the code clearer and move on.  Otherwise it's actually really difficult to give a generalized answer to such a broadly-scoped question these days.

 

On modern hardware, with sophisticated branch prediction, the question of which approach is faster is probably not so clear-cut, and overly simplistic approaches (such as counting the number of asm instructions) could give misleading results.  If it's absolutely performance-critical you really should be coding up both, and doing proper profiling under a representative real-world workload.

 

If you're debating between using if or switch to avoid doing a calculation (or other work), you should also be considering whether the cost of the calculation is going to be less or more than the cost of the branch.

 

Different hardware is different.  What's faster on PC hardware may not be faster on mobile hardware, and vice-versa.

 

Are you going to blow cache?  Is it going to scale across multiple threads?  How well will it pipeline?  These can all be more important than micro-optimizing at the individual assembly instruction level.

 

Bottom line is that it's not the 1970s, 1980s, 1990s or even 2000s any more, and you absolutely do need to consider the performance characteristics of your target hardware as well as those of your code.




#5298096 The latest BMP I made crashes the program, other BMPs work fine

Posted by mhagain on 26 June 2016 - 05:37 AM

First of all, learn to use your debugger.  It's often trivial to identify causes of crashes by running a debug build under a good debugger; it will halt on the line of code that crashed and you can then inspect the contents of variables and follow the execution of code to help determine what went wrong.

 

Secondly, learn the file format you're using.  Did you know that the BMP format requires each row to be padded to a multiple of 4 bytes?  If you didn't know that, there's a good probability that this is the cause of your crash.

 

Thirdly, learn how to ask for help properly.  Don't just say "it crashed"; give as much information as possible to help others help you.  Even worse is saying "it gave an error message" without saying what the error message was.

 

Between these you should be able to determine and fix this problem.




#5296949 Logarithmic depth buffer/Infinite far clip plane?

Posted by mhagain on 17 June 2016 - 07:01 AM

Infinite far clip is not actually intended for this use case.  What it's actually for is geometry that needs to be projected on the far clipping plane, or extruded to infinity, with a classic example being stencil shadow volumes.  Despite sounding attractive, it actually suffers from the same precision issues as a standard perspective projection.  So while the far plane may be at infinity, that doesn't mean that you have a usable infinite range between the near and far planes; you still have the majority of your precision concentrated at the near plane and you still have the same number of bits asif you'd used a classic perspective projection.






PARTNERS