New answers tagged

1

Here's what I think is happening: the matrices in your static singleton sprite class (say that three times fast) -- specifically the model-view matrix -- is being modified on drawing every sprite without being reset to how it was before the modification. As such, any transformation you perform for one object is also applied to any subsequently drawn object ...


0

Well, i just figured it out - i just set uniform samplers variables incorrectly.


0

It's probably better to use one surface view. Each GLSurfaceView appears to get its own OpenGL context unless you jump through a bunch of hoops to manually create the context and customize the way each surface creates its context. The practical upshot is that you cannot easily share resources between each view, so you will need to reload textures and ...


-1

If i was you, i should multithread the whole thing, having a renderthreat and a enginethreat or whatever you want to call it


2

As far as I know, you must initialize GLEW after creating GL context. Which means, after creating a window. If it wont work, please post an entire code of Engine::init().


2

At least i have found the solution. It includes 2 step : 1- My surface texture wraping was wrong. X axis must be repeated and Y axis must be clamped to edges. The correct one is: surfaceTexture.setWrap(Texture.TextureWrap.Repeat, Texture.TextureWrap.ClampToEdge); 2- When we use "ClampToEdge" wrapping, texture's Y coordinates must be between 0 and 1. So i ...


3

It's only a matter of opinion and code style. You can use: GL_TRUE and GL_FALSE true and false 1 and 0 Or anything that can be converted to 1 and 0. They all may have different types, but usually it does not matter because they all will be implicitly converted to GLboolean upon use. Use whatever you want, any of them will work. My only advice would be ...


1

I accidentally stumbled upon a template for the shaders in Monogame installation directory and replaced the shader with this one: #define SV_POSITION POSITION #define VS_SHADERMODEL vs_3_0 #define PS_SHADERMODEL ps_4_0_level_9_1 Texture2D SpriteTexture; sampler2D SpriteTextureSampler = sampler_state { Texture = <SpriteTexture>; }; struct ...


1

From my experience, it's not expensive to bind textures. I have a program that binds about 30 textures per frame and it runs pretty smooth. Since you're using only 9 textures and VBOs on top of that, I imagine your game actually runs very well.


2

Solved by reversing the indices for the problematic bottom face. Indices are now: Indices = new int[] { // front face 0, 1, 2, 2, 3, 0, // top face 3, 2, 6, 6, 7, 3, // back face 7, 6, 5, 5, 4, 7, // left face 4, 0, 3, 3, 7, 4, // bottom face 0, 4, 5, 5, 1, 0, // Back to ...


1

You can't get the "right" vector from just a "forward" vector. Any particular "forward" vector could have an infinite number of different legal "up" and "right" vectors. For example, if I am looking forward along the z axis forwardVector = vec3(0,0,1), then I could have up be along the y axis upVector = vec3(0,1,0) and right therefore be along the x axis ...


1

Whether you input, update, render or render, input, update is irrelevant. The loop will restart, so there is no difference. Same with whether you input, update, draw or update, draw, input(which becomes input, update, draw under the same logic). Now, if your blocking at the end for a swap or frame-sync, then you may have input lag to rendering if you receive ...


1

Dont know how your particle system is written but it is very possible that your bottle neck is the communication time between CPU and GPU. Not going to go into too much detail but just know that this operation can be very slow because it causes stalling. Perhaps the idle time you see in profiling is due to that. What a good particle system do is to move all ...


0

See Do I really need to use a graphics API? Sure, you can ask for a buffer, set some bits in it and write it to the screen. That was essentially the only way to do graphics programming on the PC until the availability of graphics accelerators in the mid-90s from 3DFX. Even in Windows, DirectX was developed to give direct access to video memory. But on ...


3

I would take a look at glDraw*Instances (Instancing) Also, reducing vertex count for a large amount of small particles is extremely important. I don't know if your using a model or a single 2D texture or what, but some general tips: Use as few verticies as possible. If using transparency in your textures, use glAlphaFunc to reduce blending needed. If ...


2

The above answers are excellent, but none really goes over the most important reason as to why OpenGL and such are preferred. The main reason is to make use of dedicated hardware designed especially to work with things like rendering millions of pixels on a screen, the GPU. With software rendering, using the CPU, the renderer will be looping, one by one, ...


6

While the answers from others are more correct than any answer I could give, I want to point out the fundamental misunderstanding about how software development works that I think underlies your question. While it's always possible to do things "by yourself" without a framework, and there's often great educational benefit from doing so, the reality is that's ...


37

It's not just about speed of execution, but also about simplicity. Although the software rendering used in this example would be a lot slower than using hardware acceleration (i.e. a GPU), drawing a few bitmaps on screen is such a trivial task that you would not notice the performance drop. However, low-level activity like triangle rasterisation, depth sort ...


11

What he does is called software rendering, what OpenGL does is called GPU rendering What's the difference between them? Speed and memory. Rasterization (filling out triangles on screen) takes some time. If you do it on the CPU, you essentially take that time away from game logic, especially if it's not optimized well. And doesn't matter, how small the ...


24

My question is: why even bother using something like open gl, sfml, sdl when all you have to do is simply allocate some buffer, pass a bitmap and draw it to the screen? Short: Because its fast (OpenGL, DirectX). Long: You may think you can do this all yourself. Draw pixels to a screen. You might write a small library to draw shapes, like quads or ...


3

Engines do much more that just draw a picture to the screen. They handle lighting, shadows, input , collision detection. Even just the rendering part is way more complex than just pushing a buffer onto the screen. For 3d scenes especially you need to do a lot of calculations on far more complex data than a bitmap. Let me give you a analogy with a car: What ...


0

Transform them in software using the CPU and give the GPU only the final vertex coordinates. The savings in bus bandwidth by reducing the VBO size will be greater than the cost of the transform on the CPU which can be greatly simplified by combining the sprite expansion and transform into a single step, no heavy matrix multiplication needed. 2D rotation, ...


1

According to this post you can draw a rotated quad. The line texture could be a 1x1 colored pixel. public static void drawLine(Batch batch, float x1, float y1, float x2, float y2, float lineWidth, TextureRegion lineTexture) { float xdif = x2-x1; float ydif = y2-y1; float l2 = xdif*xdif+ydif*ydif; float invl = (float)(1/Math.sqrt(l2)); //dif is ...


0

Turned out exposure = 1.0f was way too high for the image I was using. The results of tonemapping with these two formulas I found on this tutorial are not so pretty with real hdr images, just with analytic lights. I got a very bad, but at least visible, result with exposures around 10e-5.


0

If you're willing to restrict yourself to drivers which expose Bindless Textures you can make all the textures you want resident, put their handles in an uniform or structured buffer as sampler2D values and use those transparently in your shader. If not, you could have a series of texture arrays, one for each size and in your shader code branch to select ...


2

What user1118321 says is true -- all the textures need to be the same size. But that doesn't mean you need to USE all the space. For a small set of standalone textures, it's not a big deal to waste some space. You can simply store the U/V coordinates of where a smaller texture ends and use that. When creating the array, just set a max size and make ...


1

I'm not sure what you mean by "so I only make one glBindTexture call throughout a scene." What advantage does that get you? 2D texture arrays require the textures to be the same size. I don't know of any way around that. One other option you have is to use a texture atlas. You can make a single texture that contains all of your assets and simply pass the ...


23

There are two main benefits: First, if you downsample by more than a factor of two, some pixels in the original image will have no impact on the result image. Using GL_LINEAR, each destination pixel will only sample from at most 4 pixels from the source image; the other pixels simply get discarded. By downsampling by a factor of two, you ensure that each ...


1

It seems each time you call getHeight(x,z) you get different results, regardless of whether the (x,z) is the same or not, so the generated normals don't match the terrain surface. Normals will match the actual terrain if you compute them from the generated terrain, and not from what getHeight returns. However, it makes sense to also fix getHeight so it ...


-1

try using something >= your near (i.e. >= 0.1) for your window_z instead of 0? glm::vec3 wincoord = glm::vec3(mx, 480 - my, /**/0.1f/**/);


1

The screen coords go from {-1,-1} to {1,1} but you are most likely feeding it {0,0} to {1,1} - hence the fact that only one-quarter of the screen gets rendered. So just to be clear - point {0,0} is not the top-left (or bottom-left, depending on your co-ordinate system) point; it's the center. This also explains the texture coord tranformation that you are ...


2

I don't know cocos2d, but the general approach to use for this effect is simply to just render the scene at a lower resolution into an offscreen render buffer (VBO, in OpenGL terminology), and then copy that low-resolution image to the screen, with smoothing turned off. (in OpenGL terms, that'd be performing the copy using GL_NEAREST instead of GL_LINEAR). ...


0

In glsl, the texture function returns a vec4, thus you provide too much arguments to the vec4. It should be color = texture(sampler, texCoord); To avoid issues like this, always print out what glGetError returns. Second problem: Guess what GL.ShaderSource takes in as arguments. A shader, and you provided a shader program to it.


-2

Line 5 and 6 of LoadShaderProgram() contain a copy/paste error. GL.ShaderSource(program, VSSource); GL.ShaderSource(program, FSSource); Should be instead: GL.ShaderSource(vshader, VSSource); GL.ShaderSource(fashader, FSSource);



Top 50 recent answers are included