Looking for someone that is good with OpenGL/lwjgl. Java of course If you know CUDA (jcuda) that much the better, but not required.

It should hopefully be pretty straightforward for someone experienced. All 2d and will probably be dealing with Frame Buffer Objects and Textures but will defer to your expertise on best way to implement it.

From what I've read: a pretty standard way to do this is to create a Frame Buffer Object, Rendering that to a Texture "offline" then display the texture.Another much faster is to use a pixel shader or cuda to do all the manipulation on the GPU. or third unknown option, like I said in my first post; I'm willing to defer to the expert on whatever he thinks would work best.

In terms of performance I'm looking for at least 60 fps at 1024x768 on moderate hardware.

In terms of deliverable, I'm looking for a "screen" class that has an easy way to set pixels like setPixel(x,y,color), can render texture resolution independent of display (ie. internally use a 1024x768 texture for speed, but display it was 1280x800 [or whatever the set resolution is] either scaled or centered). Should also have some sort of update/render methods were it does its work. That way I can control how much updates it gets. If it starts lagging, I can start skipping updates and still render the last good texture generated; then resume updating once it catches back up. Or manually call an update after a setPixel.

Have an object that stores/renders a texture, store it and update/render it any way you want as longs as it's fast. Have an external method that allows modifying/getting of that data. How the values that are passed into the modifying function are generated shouldn't matter. Just assume it's random data.

Yea, assume that it'll call the modify function on one or more random x/y pair to set it to a random color. The update and render functions will be called atleast 60 times per second. From your objects point of view, there is no way it'll be able to assume any patterns on the data coming in. The only thing it could reliably assume is that x/y will be in a valid range and color will be a valid color value (in whatever way you wish to store that data).

An example:

Create texture 800x600, set all pixels to black.

setPixel(100,200 red) is called.The texture is updated(). It's all black, except pixel x=100/y=200 is red.texture is rendered() and displayed to the user

setPixel(200,100, blue) is called.The texture is updated(). It's all black, except pixel x=100/y=200 is red, pixel x=200/y=100 is bluetexture is rendered() and displayed to the user

setPixel(100,200 black) setPixel(200,100, black)The texture is updated(). It's all black again.texture is rendered() and displayed to the user.

roughly 97% of the time it's bound by the GL11.glVertex2f functions.I'm drawing direct to screen.

I hoping that it would be faster to generate a texture off that data then just throw up the entire texture. Rendering 1 texture to screen should be tons faster then all those calls.

The bottleneck will move to generation of the texture. Which if fine. That is only updating it, not rendering it and can always be throttled.

That is possibly the most pathologically worst way of achieving this result without actually writing it in Ruby! See Riven's answer. Basically: allocate a direct ByteBuffer to hold the raw pixel data. Poke directly into that. Every frame, call glTexImage2D() to upload your data to OpenGL. Draw a single quad. Rinse, repeat.

That is possibly the most pathologically worst way of achieving this result without actually writing it in Ruby! See Riven's answer. Basically: allocate a direct ByteBuffer to hold the raw pixel data. Poke directly into that. Every frame, call glTexImage2D() to upload your data to OpenGL. Draw a single quad. Rinse, repeat.

Actually GL will be a bit faster as it's slightly more direct. And if he wants to scale the image to whatever actual size - maybe with mag/minification - very probably quicker, or at least reliably quicker in more places more of the time.

dime - this is possibly the simplest thing you can do with OpenGL. I've not got the time to google it for you though. You basically want to: create a texture of appropriate size. Then in your loop, calculate your pixels and directly twiddle the data in the byte buffer. Upload the data to the texture each frame using your direct byte buffer and glTexImage2D. Render a quad using that texture over your entire display.

Actually GL will be a bit faster as it's slightly more direct. And if he wants to scale the image to whatever actual size - maybe with mag/minification - very probably quicker, or at least reliably quicker in more places more of the time.

Sure, if you scale/clip/do-anything OpenGL will be faster, but a pure blit (memcpy) is hard to beat. The upload to the GPU will be much slower.

Oh well, sounds to me like it's best for him to keep things simple Once it works on the CPU, he might want to try to support scaling and whatnot by pushing some work to the GPU.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org