Tag Info

New answers tagged

0

The scaling looks fine, but the calculation of indices doesn't look correct. I think it just happens to somewhat work by accident when the objects are small enough. This code: for(int i=0;i<numtriangles;i++) { indexBuffer.putInt(i); indexBuffer.putInt(i); indexBuffer.putInt(i); } adds the same vertex index three times for the triangle meaning ...


0

Well you could just start with a plane/quad with a static/animated water texture. From there you could maybe make an animated mesh with a texture. If you want to get into shaders, then you'd have to research the optical physics of water before trying to develop any


0

I want you to think about a refactoring of your code. Since you already have a vector structure (Vector3f - I guess its from lwjgl) why not use it? // Calculate the vector pointing from the mob toward the position with // a length of their distance. // This is equal to: wayTowardPlayer = playerPosition - mobPosition Vector3f wayTowardPlayer = new ...


0

Like @Terje says, the short answer is "Yes, OpenGL can outperform Swing." You've seen modern video games, you know current graphics hardware can do truly amazing things. Pragmatically, what you can do is look at the CPU load of your current "Pong" game, or whatever it is. Based on the CPU percentage, and what your ultimate goal is, maybe Swing is just ...


1

OpenGL performance will outperform Swing quite heavily once you start doing something a little more advanced. I dont have hard numbers to back my claim, but I have experience. I too started out with pure Java2D, with BufferStrategy and the works. And it was ok for Pong, Snake, Tetris, and so on. But once venturing beyond in graphical effects (blending, ...


0

if yow saw this pop up while you start to run your code just click your main class which contains your main method


0

You're doing something strange: Every frame, you calculate the x,y,z values of the bullet's movement, based on a yaw and pitch that will never change. Why not create a vector3 that stores the direction and speed of the bullet in the bullet constructor? This way, you can do the calculations once per bullet, and then just add its speed vector to its current ...


0

Well for one, your x,y,and z would stay zero based on moveFromPosition. If you want the bullet to follow a certain path, you need to get rid of the zeros, math calculates anything multiplied by 0 is equal to 0 Your next problem is you are over-complicating the math in moveFromPosition. All you need to do during an update is loc.x += ...


0

For me the fastest way has been "Find in files" feature of the IDE / text editor. Recursively searching for the function name from either LWJGL API documentation or source folder quickly reveals the correct class name. This is just a few key presses compared to switching to a web browser and searching from the reference pages.


0

The reference material on the OpenGL website is a good source for this. The function reference pages there have a "Version Support" section that details which version of the API the function in question is available in. Here's the page for glDrawElementsBaseVertex, for example. A machine-readable form of this data is available via the API XML, which would ...


1

TLDR: VBOs makes a huge difference in performance. One simple reason to use them would be that OpenGL ES (mobile devices) don't support glBegin(...)/glEnd() so you have to use glDrawArrays() but not necessarily VBOs. The main reason to use VBOs is that it allows the OpenGL driver to keep the vertex data in GPU memory, rather than CPU memory which forces ...


0

Double check if you are truly using viewport correctly. You're not rebinding the texture to the FBO. That SHOULDN'T be necessary, however the spec makes no guarantee that glTexImage won't screw up any attached framebuffers, so assume that it can. If that doesn't work then its the way you're sampling from it. For simply allocating a texture with undefined ...


2

To be safe I'd delete and recreate the entire FBO. Some drivers have strange stability issues when recycling/resizing FBOs. I've had entire screen flickers and occasional crashes. Switching attached textures to another of the same size & type seem to work fine all the time on all drivers but with some drivers it is much faster (more than 100x) to have ...


1

According to OpenGL Insights there are a couple ways to efficiently stream data to a VBO. A simple but efficient method is to "orphan" the buffer (allocating a new piece of VRAM in the process) and refill the entire thing. This allows the current frame to use the old data while you can upload the new data. // orphan the buffer so that we can write new ...


0

for (int i = 0; i < wallList.size(); i++) { Wall wall = wallList.get(i); wall.update(); if (wall.getX() < -1 * wall.getImageWidth()) { wallList.remove(i); } } If you remove a wall then the next wall at index i but you skip it. Decrement i after the remove or use an iterator based loop: for ...


0

You are drawing the shadow using a cone from the light source which extends above the object causing the wrong shadow when the object is below ground. You need to draw volumetric shadows by extending the shadow-casting object in the direction opposite to the light source, capped at the object. Google "Volumetric Shadows" or "Shadow volume". ...



Top 50 recent answers are included