Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
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  
  Making a pixely game, what's the fastest way to do it?  (Read 2141 times)
0 Members and 1 Guest are viewing this topic.
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Posted 2012-06-04 17:38:58 »

A while back I made some pixely games like this and I used glRectf to do this. I'll post the exact code below, it's simple. I remember changing it to vertex arrays later and actually saw a large decrease in performance. I wasn't sure if this was because I was using FloatBuffers wrong (they were specifically what seemed the slowest to me) or if it's simply faster to a bunch of rect calls.

Since I've done almost all of my more complex OpenGL work within iPhone and have had access to C arrays, I'm a noob when it comes to leveraging float buffers the correct way.

So, what are recommendations for doing this?

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
GL11.glDisable(GL11.GL_TEXTURE_2D);
     
//Draw each pixel.
for (int i = 0; i < pixels.length; i++)
{
   for (int j = 0; j < pixels[0].length; j++)
   {
      if (pixels[i][j] >= 0)
      {
         Color c = Globals.NES_COLOR_PALETTE[pixels[i][j]];
         GL11.glColor4ub(c.getRedByte(), c.getGreenByte(), c.getBlueByte(), c.getAlphaByte());
         GL11.glRectf((x+i)*scale.x, (y+j)*scale.y, (x+i+1)*scale.x, (y+j+1)*scale.y);
      }
   }
}


FYI looking at that not sure why I didn't just do a glScale call beforehand - maybe I had a reason maybe I didn't. Smiley

And in an ideal world, I could draw every single pixel individually, rather than using FBOs or anything to store unchanging values. Sort of like some voxel games (may or may not) do it.

See my work:
OTC Software
Offline davedes
« Reply #1 - Posted 2012-06-04 19:07:35 »

Why not use PNG sprites and save yourself countless hours of headache?

If you are really set on software rendering pixel-by-pixel, I'd imagine you might get decent performance with a PBO. Upload pixel data to a texture which is then rendered to the screen (scaled quad with nearest-neighbour filtering). For optimization you would probably want to use multiple textures and/or texture atlases -- i.e. the pixel sword (which is repeated frequently) would be uploaded to a texture atlas, and then you would render each sword with its own textured quad (using the texcoords of the sword). The idea would be to minimize texture uploads as much as possible, only doing it for truly dynamic animations.

Also, I wouldn't rely on glRect or immediate mode, especially if you plan on rendering pixel-by-pixel... Shocked

Offline theagentd
« Reply #2 - Posted 2012-06-04 19:13:22 »

Just set GL_NEAREST for filtering and you get a perfectly horribly pixelated texture?

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #3 - Posted 2012-06-04 19:23:10 »

Render to a smaller texture first, then render the texture to the screen using nearest-neighbor.
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #4 - Posted 2012-06-04 19:32:25 »

Cheesy

So obviously the catch is that any object could explode into individually animated and physicsed pixels at any time, as you can see if the video I linked. Also the level can be chopped up and ruined like in Voxatron. This is voxels, which as I understand is basically just a 3D pixel. But I don't understand voxels very well. Smiley

In the video I showed you (Lego City Ransom), the characters are all textures and then their pixel data is used to generate a bunch of individually placed pixels when they die. The weapons, however, are all of the pixles drawn individually - could certainly use an FBO to be faster.

In this example thing I made: Pixel Splosion geo modding, the planet is an FBO and the pixel pieces (press P with your mouse over part of the planet) are drawn with glRect.

So anyway I see a lot of things like that may be necessary, but I'm just wondering how people did like Voxatron which is so fluid and has so much moving at once. I'll look at PBOs, I've never used them.

See my work:
OTC Software
Offline Roquen
« Reply #5 - Posted 2012-06-04 20:06:59 »

Are you just wanting to do an old school console hardware "mosaic" mode rendering?
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #6 - Posted 2012-06-04 20:22:47 »

Not exactly. I'd like the world to be pixely but able to exist more fluidly. As in, the art might be 300x200 resolution but an individual broken pixel block can fly around at whatever resolution your monitor supports. In that case it seems a bad idea to hold onto a giant 2048x2048 FBO (or whatever size I would need) and modify the pixels within it, when instead I could draw the dynamic pixels individually.

See my work:
OTC Software
Offline theagentd
« Reply #7 - Posted 2012-06-04 20:28:51 »

Not exactly. I'd like the world to be pixely but able to exist more fluidly. As in, the art might be 300x200 resolution but an individual broken pixel block can fly around at whatever resolution your monitor supports. In that case it seems a bad idea to hold onto a giant 2048x2048 FBO (or whatever size I would need) and modify the pixels within it, when instead I could draw the dynamic pixels individually.
BF3 uses 4 x 16-bit float RGBA textures to render to with 4xMSAA. I think you're fine with your gigantic 1920x1080 FBO 8-bit RGB texture, since BF3 uses a 42.67x larger framebuffer and actually runs.

Myomyomyo.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2012-06-04 21:01:36 »

Like others suggested... simply poke colours directly into an RGB bitmap in a ByteBuffer. If you're not intending to ever read the colours back again, use a PBO. Then render it to any size you want and let OpenGL scale the pixels appropriately.

Cas Smiley

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #9 - Posted 2012-06-05 03:23:20 »

Cool I'll give that a go then, thanks fellas.

See my work:
OTC Software
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ra4king

JGO Kernel


Medals: 337
Projects: 2
Exp: 5 years


I'm the King!


« Reply #10 - Posted 2012-06-05 04:58:01 »

Not exactly. I'd like the world to be pixely but able to exist more fluidly. As in, the art might be 300x200 resolution but an individual broken pixel block can fly around at whatever resolution your monitor supports. In that case it seems a bad idea to hold onto a giant 2048x2048 FBO (or whatever size I would need) and modify the pixels within it, when instead I could draw the dynamic pixels individually.
BF3 uses 4 x 16-bit float RGBA textures to render to with 4xMSAA. I think you're fine with your gigantic 1920x1080 FBO 8-bit RGB texture, since BF3 uses a 42.67x larger framebuffer and actually runs.
How do you know this stuff and where could I read about it all?! Grin

Offline pitbuller
« Reply #11 - Posted 2012-06-05 16:57:33 »

Not exactly. I'd like the world to be pixely but able to exist more fluidly. As in, the art might be 300x200 resolution but an individual broken pixel block can fly around at whatever resolution your monitor supports. In that case it seems a bad idea to hold onto a giant 2048x2048 FBO (or whatever size I would need) and modify the pixels within it, when instead I could draw the dynamic pixels individually.
BF3 uses 4 x 16-bit float RGBA textures to render to with 4xMSAA. I think you're fine with your gigantic 1920x1080 FBO 8-bit RGB texture, since BF3 uses a 42.67x larger framebuffer and actually runs.
How do you know this stuff and where could I read about it all?! Grin

There are tons of slides hanging on internet. This is kinda good source http://publications.dice.se/publications.asp?show_category=yes&which_category=Rendering

Also learn to spent countless of hours in there http://www.gdcvault.com/
Offline gimbal

JGO Knight


Medals: 25



« Reply #12 - Posted 2012-06-05 17:48:33 »

Not exactly. I'd like the world to be pixely but able to exist more fluidly. As in, the art might be 300x200 resolution but an individual broken pixel block can fly around at whatever resolution your monitor supports. In that case it seems a bad idea to hold onto a giant 2048x2048 FBO (or whatever size I would need) and modify the pixels within it, when instead I could draw the dynamic pixels individually.

Something like Sword & sworcery EP I'm guessing?

http://www.youtube.com/watch?v=j-W5nQQPiAQ
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #13 - Posted 2012-06-05 19:48:44 »

Not exactly. I'd like the world to be pixely but able to exist more fluidly. As in, the art might be 300x200 resolution but an individual broken pixel block can fly around at whatever resolution your monitor supports. In that case it seems a bad idea to hold onto a giant 2048x2048 FBO (or whatever size I would need) and modify the pixels within it, when instead I could draw the dynamic pixels individually.

Something like Sword & sworcery EP I'm guessing?

http://www.youtube.com/watch?v=j-W5nQQPiAQ
To some extent. But not nearly as pretty.  Cry

See my work:
OTC Software
Offline ra4king

JGO Kernel


Medals: 337
Projects: 2
Exp: 5 years


I'm the King!


« Reply #14 - Posted 2012-06-06 11:06:49 »

Not exactly. I'd like the world to be pixely but able to exist more fluidly. As in, the art might be 300x200 resolution but an individual broken pixel block can fly around at whatever resolution your monitor supports. In that case it seems a bad idea to hold onto a giant 2048x2048 FBO (or whatever size I would need) and modify the pixels within it, when instead I could draw the dynamic pixels individually.
BF3 uses 4 x 16-bit float RGBA textures to render to with 4xMSAA. I think you're fine with your gigantic 1920x1080 FBO 8-bit RGB texture, since BF3 uses a 42.67x larger framebuffer and actually runs.
How do you know this stuff and where could I read about it all?! Grin

There are tons of slides hanging on internet. This is kinda good source http://publications.dice.se/publications.asp?show_category=yes&which_category=Rendering

Also learn to spent countless of hours in there http://www.gdcvault.com/
Oh great.....there goes my life.....I won't stop reading anytime soon........

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.

Riven (12 views)
2014-07-29 18:09:19

Riven (8 views)
2014-07-29 18:08:52

Dwinin (9 views)
2014-07-29 10:59:34

E.R. Fleming (26 views)
2014-07-29 03:07:13

E.R. Fleming (10 views)
2014-07-29 03:06:25

pw (39 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (27 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!