Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (553)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Hiring for small job.  (Read 6052 times)
0 Members and 1 Guest are viewing this topic.
Offline dime

Senior Newbie





« Posted 2010-09-30 11:12:58 »

Looking for someone that is good with OpenGL/lwjgl.  Java of course Smiley
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.

I can pay via paypal or check in USD.

Email if intrested: dimecoin@gmail.com
Offline ryanm

Senior Member


Projects: 1
Exp: 15 years


Used to be bleb


« Reply #1 - Posted 2010-09-30 11:30:01 »

Can you give any hints on what the jobs entails or what your budget is?
Offline dime

Senior Newbie





« Reply #2 - Posted 2010-09-30 19:34:57 »

Sure.  In terms of budget, I don't know.  Was looking for an estimate for whoever was doing in.

In terms of what needs to be done, I need to update the screen per pixel.
See this: http://www.powerengine2a.com/images/screenshot_290.png
What I'm doing now is pretty slow.

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 783
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #3 - Posted 2010-09-30 19:55:32 »

What kind of algorithm is used in your calculations? You can't just convert any algorithm to GPGPU/cuda/opencl, so we need to know a bit more about your project.

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

Senior Newbie





« Reply #4 - Posted 2010-09-30 20:53:15 »


The more I think of it, the cuda/opencl is probably more than needed.  Standard opengl hopefully will be fast enough.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 783
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #5 - Posted 2010-09-30 20:55:27 »

Same goes for OpenGL.

So, again, what's the algorithm like? What are you calculating?

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

JGO Kernel


Medals: 363
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2010-09-30 21:05:22 »

I smell confusion.

Cas Smiley

Offline dime

Senior Newbie





« Reply #7 - Posted 2010-09-30 21:17:31 »

Same goes for OpenGL.

So, again, what's the algorithm like? What are you calculating?

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 blue
texture 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.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 783
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #8 - Posted 2010-09-30 21:36:52 »

If you really want 'random' pixel access, nothing beats CPU performance:
1  
2  
3  
4  
public void setPixel(int x, int y, int color)
{
    this.rgb[y*w+x] = color;
}

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

JGO Kernel


Medals: 363
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2010-09-30 21:43:33 »

It's all this talk of attempting to set individual pixel data with individual method calls that seems a bit suspicious to me...

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline dime

Senior Newbie





« Reply #10 - Posted 2010-09-30 21:57:00 »

here is what I got:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
GL11.glBegin(SGL.GL_QUADS);

      for (int x = 0; x < width / pixelSize; x++) {
         for (int y = 0; y < height / pixelSize; y++) {
         
            int x1=x*pixelSize;
            int y1=y*pixelSize;
            GL11.glVertex2f(x1, y1);
            GL11.glVertex2f(x1 + pixelSize, y1);
            GL11.glVertex2f(x1 + pixelSize, y1 + pixelSize);
            GL11.glVertex2f(x1, y1 + pixelSize);
         }
      }

GL11.glEnd();


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.



Offline Riven
« League of Dukes »

JGO Overlord


Medals: 783
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #11 - Posted 2010-09-30 22:05:52 »

If you really want 'random' pixel access, nothing beats CPU performance:
1  
2  
3  
4  
public void setPixel(int x, int y, int color)
{
    this.rgb[y*w+x] = color;
}


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

Senior Newbie





« Reply #12 - Posted 2010-09-30 22:07:31 »



Sorry, but I don't understand how this helps.  My bottle neck is in rendering, not in access or manipulating the data.
The vast majority of time is spent in GL11.glVertex
Offline princec

JGO Kernel


Medals: 363
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2010-09-30 22:09:46 »

here is what I got:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
GL11.glBegin(SGL.GL_QUADS);

      for (int x = 0; x < width / pixelSize; x++) {
         for (int y = 0; y < height / pixelSize; y++) {
         
            int x1=x*pixelSize;
            int y1=y*pixelSize;
            GL11.glVertex2f(x1, y1);
            GL11.glVertex2f(x1 + pixelSize, y1);
            GL11.glVertex2f(x1 + pixelSize, y1 + pixelSize);
            GL11.glVertex2f(x1, y1 + pixelSize);
         }
      }

GL11.glEnd();


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.

Cas Smiley

Offline dime

Senior Newbie





« Reply #14 - Posted 2010-09-30 22:11:37 »

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.

Cas Smiley

Any examples/tutorials of that?  Like I said, I suck at opengl.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 783
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #15 - Posted 2010-09-30 22:15:47 »

I don't get it.

You know how you push data into your image.

You can render your image using plain old Java2D: g.drawImage(img, 0, 0, null);

1  
2  
3  
4  
5  
6  
7  
8  
9  
   public static int[] accessRasterIntArray(BufferedImage src)
   {
      return ((DataBufferInt) src.getRaster().getDataBuffer()).getData();
   }

   public static byte[] accessRasterByteArray(BufferedImage src)
   {
      return ((DataBufferByte) src.getRaster().getDataBuffer()).getData();
   }




1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
BufferedImage img = new BufferedImage(w, h, BufferedImage.TYPE_RGB_INT);
int[] rgb = accessRasterIntArray(img);

public void setPixel(int x, int y, int color)
{
    this.rgb[y*w+x] = color;
}



public void paint(Graphics g)
{
    g.drawImage(img, 0, 0, null);
}




I doubt anything will be (much) faster than that.

Why do you want OpenGL? It *will* be slower.


* Riven thinks he deserves a few bucks Smiley

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

JGO Kernel


Medals: 363
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #16 - Posted 2010-09-30 22:22:03 »

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.

Cas Smiley

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 783
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #17 - Posted 2010-09-30 22:25:48 »

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 Smiley 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
Offline dime

Senior Newbie





« Reply #18 - Posted 2010-09-30 22:27:50 »



ok, thanks guys.  I guess this thread can be closed.  I go back to reading up on opengl.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (23 views)
2014-08-22 19:31:30

atombrot (34 views)
2014-08-19 09:29:53

Tekkerue (30 views)
2014-08-16 06:45:27

Tekkerue (28 views)
2014-08-16 06:22:17

Tekkerue (18 views)
2014-08-16 06:20:21

Tekkerue (27 views)
2014-08-16 06:12:11

Rayexar (65 views)
2014-08-11 02:49:23

BurntPizza (41 views)
2014-08-09 21:09:32

BurntPizza (32 views)
2014-08-08 02:01:56

Norakomi (42 views)
2014-08-06 19:49:38
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!