Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (481)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (548)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Game Development / Newbie & Debugging Questions / Best practices for lightmapping on: 2014-07-04 23:55:05
I've been developing a dynamic lighting system for my 2D game that can raycast shadows. For this, I've been using LibGDX, creating an FBO for a lightmap and drawing the shadow polygons to it (I'm a complete newbie at this so FBO's might now be the most efficient way). From what I've read, most lightmaps are blended in by multiplying them on, which makes sense. If you use colors like blue as the base to your light maps, you can give a nice ambience to rooms.

However, in outdoors scenarios, sometimes it's preferable to use white as the base color, so that the visuals appear clear and not darkened. This is where my problem is. For my lighting system, I'd also like to use additive blending to make lights have a gradient effect. In normal light maps, that's fine, as it would lighten the base color, giving the effect regardless. But if the base color is white (or just a very bright color) then the light's gradient can't be blended onto the lightmap, because it would still result in white.

What is the best way to ensure that all lights have a visible gradient? Should I just use two FBO's instead - one that's multiplied and another that's added? Would that be too expensive of an operation?

Thank you for your help.


To clarify, the above picture shows what would happen in a lightmap where the base color is white. Here, the sun is the light source. As you can see, the light doesn't get shown on the left, because white is the highest value possible. The one of the right does show it, because it allocates all of the glows into a separate FBO with a black base and adds it. Are there better ways to achieve the same thing that the right one does?
2  Game Development / Newbie & Debugging Questions / Trouble understanding bitmasking on: 2014-02-26 15:37:52
Recently I started trying to teach myself bitmasking, and I haven't had much success. In my current game, I am trying to pack multiple variables of data type short into a single long. In addition to getting the below code to function properly, I had a few questions:
  • I have heard that primitive types in Java reserve the last bit to the sign of the variable (plus or minus). Is this true?
  • Java shorts are 2 Bytes, and longs are 8 Bytes. Should I then in theory be able to pack 4 shorts into 1 long? Will the different data types cause problems?
Below are my broken methods for packing/unpacking the shorts. I have an understanding of the bitwise operators and thier functions (although I'm a bit fuzzy on the difference between >> and >>>), so it's more of the actual implementation that is confusing me.
Here is my packing method (components[] is guaranteed to be of length SHORTS_IN_PACK):
1  
2  
3  
4  
5  
6  
7  
8  
9  
private static final long packShorts(short[] components) {
      //should initialize pack to all zero bits
     long pack = Long.MIN_VALUE;

      for (int i=0; i < SHORTS_IN_PACK; i++)
         pack |= (components[i] & 0xFFFF) << (i*16);

      return pack;
}

And here is my unpacking method:
1  
2  
3  
4  
5  
6  
7  
8  
private static final short[] unpackShorts(long pack) {
      short[] components = new short[SHORTS_IN_PACK];
     
      for (int i=0; i < SHORTS_IN_PACK; i++)
         components[i] = (short) (( pack >>> (i*16) ) & 0xFFFF);

      return components;
}

Any advice would be helpful, especially if worded as simply as possible.
Thank you Smiley
3  Java Game APIs & Engines / Engines, Libraries and Tools / LibGDX - placing two bitmap fonts onto one texture on: 2013-08-26 04:57:06
Hello world! I'm working on a game and I've recently switched to LibGDX to get better performance, more target platforms, and a few other reasons, so I'm relatively new to a lot of OpenGL.
From what I understand, LibGDX runs most efficiently using bitmap fonts rendered to a single texture, that uses a texture atlas to select a specific character. For my purposes, this is fine.

My game uses two fonts - one being a modified version of the other. I have placed them below:
<-Original<-Modified

While there are cases where I'd use both fonts on their own, there may be times when I need to use both simultaneously. For instance, I will be animating some text to randomly switch to the modified version to provide a "glitchy" aesthetic.

According to this article (http://www.streamingcolour.com/blog/2009/08/27/texture-atlases-and-bitmap-fonts/), the reason bitmap fonts are stored into one texture is because changing to another texture can be a relatively expensive operation.
Here's the actual quote:
Quote
The reason this is done is that every time OpenGL has to change which texture it’s currently drawing with, it takes time. So if you draw, say, 100 different little sprites every frame, and each one is in it’s own texture, OpenGL has to change which texture it’s using 100 times. This can lead to a lot of inefficiency and can actually significantly slow your rendering code. But if you put those 100 sprites into one big texture atlas, then OpenGL doesn’t need to swap textures, it just changes the coordinates of the current texture each time.

As such, is it possible to put both of my bitmap fonts together as one texture and alternate between the two fonts when necessary? If so, how would I do this in LibGDX?
4  Game Development / Newbie & Debugging Questions / Re: Bullet Directional Shooting Images [Need Help] on: 2013-08-17 04:17:38
I think what you're looking for is:
1  
2  
3  
4  
5  
6  
//rotate the Graphics2D object around the center of your bullet object
g.rotate(angle,x+(bulletWidth/2), y+(bulletHeight/2));
//draw the bullet as you would normally
g.drawImage(bulletImage, x,y, null);
//rotate it back in the using negative angle
g.rotate(-angle,x+(bulletWidth/2), y+(bulletHeight/2));

It's just a matter of rotating it back. Smiley
However, depending on your usage of rotation (especially with larger images), sometimes it is logical to cache an pre-rendered image array of,say every 5 or 10 degrees, so that you don't have to do the rotation each time.

Also, just food for thought, you could also render the bullet as just a line if you don't want to deal with all that.
5  Java Game APIs & Engines / Java 2D / Re: Pixel manipulation with bufferstrategy. on: 2013-08-15 22:37:25
Golly, I almost feel as if I started this whole thing.  Lips Sealed
I don't think this was started as a means to heatedly discuss hardware acceleration or what the most OOP way to access pixels.
6  Java Game APIs & Engines / Java 2D / Re: Pixel manipulation with bufferstrategy. on: 2013-08-15 16:59:26
It's me again, and I'd like to defend my particular argument.

You're both over complicating this, if I understand the question. Direct pixel access of BufferedImage:
1  
2  
BufferedImage img = new BufferedImage(100, 100, BufferedImage.TYPE_INT_ARGB);
int[] pixels = ((DataBufferInt) img.getRaster().getDataBuffer()).getData();

While this is true, I didn't go into it that much because the title of this post is "Pixel manipulation with bufferstrategy." As such, I felt that it was more important to explain how it could be done with a BufferStrategy (which is the fastest method of double buffering provided by Java2D) - instead of a BufferedImage. I'll agree, it is very complicated, and can be insanely slow (pretty much halves my framerate in some cases) doing certain blending algorithms.
Quote
To unpack a value from pixels[] to r, g, and b values:
1  
2  
3  
int r = (pack & 0xFF0000) >> 16;
int g = (pack & 0xFF00) >> 8;
int b = pack & 0xFF;

Pretty sure that Raster.getPixel() performs that exact same operation under the hood, so it's not really that necessary to jump through that many hoops, when there's already a method to do it for you.

I'm not saying that my method is the fastest (especially compared to GPU-accelerated libraries like JOGL or LWJGL), or even that well designed, but for what the OP is asking - which is accessing pixels in a BufferStrategy - I have at least provided a solution to what he is asking rather than talking about getting them from BufferedImages. And to be fair, I've mostly been talking about getting the Raster, rather than how exactly to get the pixels, which from the Raster you can use plenty of different approaches.
7  Java Game APIs & Engines / Java 2D / Re: Pixel manipulation with bufferstrategy. on: 2013-08-15 05:05:08
Your post seems a bit vague in it's wording. This is a bit of code to sift through and I'm away from an IDE at the moment.
Could you point me towards where you're actually trying to do pixel manipulation? Depending on what you're looking to do your answer can vary.

If you're looking to access the exact value of a pixel, getting the Raster object is very useful (WritableRaster if you're looking to actually change their values). For BufferedImages, that's really easy, just use it's getRaster() method, and it'll return it's WritableRaster.

However, dealing with BufferStrategies is different. They purposefully hide their inner workings because they perform very complex operations managing VolatileImages, keeping track of each buffer, clearing unused images, and handling optimized page-flipping or blit-buffering algorithms. For those reasons, it tries to disallow you to edit values inside of it's system. Because of this, there is really only a backdoor way of getting the BufferStrategy's raster, and that's by working through the Graphics2D class.

When performing any drawing operation, the Graphics2D class creates/gets a source and destination raster, and runs them through any of it's Composite classes to blend them together via CompositeContext.compose(). If you create your own Composite and CompositeContext subclasses, you can effectively gain legitimate access to the current BufferStrategy Raster object being used. It's hacky, but it works.

The structure I'm using below is based on the source for AlphaComposite.
Here's an example you can use:
For the Composite subclass
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
import java.awt.Composite;
import java.awt.CompositeContext;


class RasterComposite extends Composite{

  //static version kept to reduce needless instantiation
 //Composite objects really just exist to store the blending rule and other things needed to blend
 //otherwise, Composites should be immutable
 public static final RasterComposite Normal = new RasterComposite();

  //bit of a singleton pattern here, but can be extended for multiple blending rules
 public static final RasterComposite getInstance(){
    return Normal;
  }

  private RasterComposite(){}

  //this is the inherited method from Composite, that links Composite and CompositeContext
 //for our case it's not that important to consider color models or rendering hints
 //but if youd like it's just a matter of passing that stuff via constructor
 public CompositeContext createContext(ColorModel cm1, ColorModel cm2, RenderingHints hints){
    return new CompositeContext();
  }

}

For the CompositeContext subclass
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
import java.awt.CompositeContext;
import java.awt.image.Raster;
import java.awt.image.WritableRaster;


class RasterCompositeContext extends CompositeContext{

  //this is where you should store the destination Raster
 private WritableComposite theRaster;

  //an inherited method which Graphics2D uses to blend colors
 //i believe that by default Graphics2D uses AlphaComposite.SrcOver to render, so we can redirect all rendering to that
 public void compose(Raster dstIn, Raster srcIn, WritableRaster dstOut){
    theRaster = dstOut;   //try this one, but if that doesn't work, try switching it for "theRaster = dstIn.createCompatibleWritableRaster();"
   AlphaComposite.SrcOver.compose(dstIn,srcIn,dstOut);  //this allows pixels to be rendered normally in the meantime.
 }

  //another inherited method. no objects to dispose of though
 public void dispose(){}

  //and here's how you get the raster from your new composite context
 public final WritableRaster getRaster(){
    return theRaster;
  }

  }

Viola, and that's how you get the Raster object out of a BufferStrategy, in theory at least. But depending on what you're trying to do, (like if you're trying to implement additive blending while drawing) it may just be easier to create a Composite system that does everything as part of the drawing process.

Probably another, more inefficient way of getting the pixel values is to use the Robot class and get a screen capture of your screen. This is bad because if I recall this doesn't work in fullscreen, requires access to the window's position/size, needs additional scaling math if you're scaling up (because scaling down causes loss of pixel info), and during the capture, your window must be undecorated.

Hopefully I've provided some sort of solution to your problem. Smiley
Pages: [1]
 

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

The first screenshot will be displayed as a thumbnail.

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

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

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

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

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

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

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

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

Norakomi (37 views)
2014-08-06 19:49:38

BurntPizza (67 views)
2014-08-03 02:57:17
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!