Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Jun 2010
Offline Last Active Today, 02:26 PM

#5307050 Which Win 10 for Visual Studio / DirectX

Posted by on 21 August 2016 - 12:00 PM

64 bit, always.


All modern PC hardware is 64-bit hardware; 32-bit is now niche and confined to ultra-low-spec machines, netbooks and the like.


32-bit Windows is limited to 4gb of RAM.  That's nowhere near enough.


64-bit Windows is perfectly capable of running 32-bit programs, so you won't be restricting yourself in any way.

#5304943 Resetting States In A Data-Driven Renderer

Posted by on 09 August 2016 - 01:07 PM

I never reset states.


Resetting states at the end of a rendering stage implies that the next rendering stage can make assumptions about what states are when going into it.  That seems very very dangerous.  Instead I have each rendering stage set all states required on entry.  If required I can easily add state filtering to this, so that only states which actually change are set; otherwise this kind of setup also behaves itself properly with deferred contexts in D3D11.

#5303925 Directx And Multi-Platform Games

Posted by on 03 August 2016 - 11:57 PM

The same way that multiplatform games targetting console APIs and PC APIs are made.

This is something that has been a solved problem for years. Multiplatform doesn't just mean Linux and the consoles don't use OpenGL. Everything has platform-specific code; using OpenGL doesn't automagically make a game multiplatform. Sound, input, networking, threading, memory, timing, windowing, etc - they're all platform-specific too, and OpenGL is nothing to do with them.

So you write an abstraction layer over the platform-specific parts and have done with it.

As for C# - there's absolutely nothing platform-specific about that. It's been multiplatform for years, it's even an open standard.

#5303670 About text in OpenGl

Posted by on 02 August 2016 - 11:06 AM

WiredCat now that looks easy. No additional libs like glut needed? Thanks for the code, I'll try tomorrow.


Beware of unspecified dependencies.


AnsiString text

What is "AnsiString"?  A custom class?  Something from a library?  Which library?


glListBase(base);                              // Set the base list to our character list
glCallLists(text.Length(), GL_UNSIGNED_BYTE, text.c_str());  // Display the text


What is base?  Where does it's value come from?  What is used to generate the display lists?  Where are they generated?  Does this generation have any other dependencies?

#5303619 Virtual Machines

Posted by on 02 August 2016 - 04:25 AM

Mesa3D drivers have a software implementation, the latest releases support OpenGL 4.3.


This of course should always come with the warning: as a software implementation it's going to be too slow for general usage.

#5302818 Multi Vertex Buffer And Inputlayout

Posted by on 27 July 2016 - 03:32 PM

In D3D10+, which I assume you're using based on the API calls used, you would combine these into a single call, like so:


ID3D11Buffer *buffers[] = {vb1, vb2};

UINT strides[] = {sizeof (vertex1), sizeof (vertex2)};

UINT offsets[] = {0, 0}; // assume - may be different

context->IASetVertexBuffers (0, 2, buffers, strides, offsets);

#5302006 Vulkan is Next-Gen OpenGL

Posted by 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 on 22 July 2016 - 02:28 AM



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 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 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 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 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 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 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 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...