Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Jun 2010
Online Last Active Today, 08:01 AM

#5311812 [dx9] setting a shader constant?

Posted by on 21 September 2016 - 02:02 PM

It should be 16 in the last parameters of SetVertexShaderConstantF, not 4. A matrix is made of 16 floats. So your're just passing the only 4 elements, not the whole matrix.


No, 4 is correct:

Number of four float vectors in the array of constants.

but now I dont get the geometry on my screen anymore. it worked with the constant table

Do you need to transpose your matrix?

#5311421 GoldSRC to Unreal engine

Posted by on 19 September 2016 - 09:05 AM

...be prepared to get a "Cease & Desist" from Valve though.  They really don't like people doing this kind of thing...

#5311056 Getting started with OpenGL development in linux

Posted by on 16 September 2016 - 05:18 AM

2-Why would you use GLEW under linux? I thought GLEW only job to implement functions that links to the driver under windows. The reason for this is because windows only support OpenGL 1.0. So GLEW gives access to OpenGL 1.0+ functions. So Linux doesn't need that since Linux support every version of OpenGL natively. Doesn't it?


A misunderstanding on your part.


Windows supports OpenGL versions from 1.0 to 4.5, without issues.


However, the headers and librarys supplied with the Windows SDK only support up to OpenGL 1.1, with a smattering of extensions.  That's an important distinction because it's perfectly possible for other SDKs or build systems that support all current GL versions to exist; nothing about Windows prevents that.


So you use the extension loading mechanism (another important distinction; this is not the same as using extensions) to access higher functionality.


The key thing to realise is that the same constraints can exist on Linux.  Depending on your build tools and/or SDK used, you may have headers and librarys for all current GL versions or you may also need to use something like GLEW.


It's not the OS, it's the tools.

#5310987 How many RAM on VDS server I need setup, then my fb game will support 1000 on...

Posted by on 15 September 2016 - 03:50 PM





Seriously - there's absolutely no way we can know this.  Have you done any profiling?  How much RAM does one player use?

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