Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
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] 2 3
1  Game Development / Newbie & Debugging Questions / Re: Suggestions for a sound library to use for sound effects? on: 2014-06-14 00:12:22
Thanks! I'll give that a try!
My game lacks the necessary visceral 'pew pew' sounds to add the required fun-factor!
2  Game Development / Newbie & Debugging Questions / Suggestions for a sound library to use for sound effects? on: 2014-06-13 22:28:44
Hi all,

I've heard some musings that the default sound capabilities offered by Java aren't great. I'm currently using LWJGL and the Slick libs, and have pretty much completed my game now, but it doesn't have any sound!

What's everyone else using to deliver sound effects and music in their games? I'm capable enough to engineer the various blips and bloops I need, but just need some advice on what libraries best suit Java game developers!

Thanks all!
3  Game Development / Newbie & Debugging Questions / Re: Calculating probabilities - is this the right way? on: 2014-05-16 21:13:28
Okay, so this method is probably a bit ugly, but it works great:

I start by defining the probability of each cell type. For simplicity's sake, everything is a percentage, with the sum of all values adding up to 100:

1  
2  
3  
4  
int chanceForEmpty = 70;     // type 0
int chanceForBig = 10;       // type 1
int chanceForMedium = 15;    // type 2
int chanceForSmall = 5;      // type 3


Then I run a loop for each chance variable, adding it into a values array as many times as it's needed. This array will contain all of the chance values:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
// get the sum of all values
int valueSum = chanceForEmpty + chanceForBig + chanceForMedium + chanceForSmall;

// set a values look-up array with the same dimension
int[] values = new int[valueSum];

// add each chance value
int iteration = 0;
for (int i = 0; i < chanceForEmpty; i++) { values[iteration] = 0; iteration++; }    // 0 = EMPTY
for (int i = 0; i < chanceForBig; i++) { values[iteration] = 1; iteration++; }      // 1 = BIG
for (int i = 0; i < chanceForMedium; i++) { values[iteration] = 2; iteration++; }   // 2 = MEDIUM
for (int i = 0; i < chanceForSmall; i++) { values[iteration] = 3; iteration++; }    // 3 = SMALL


Now, when I want to get a random, weighted type for a particular cell, I can call up a random value in the look-up array, which provides the weighting / probabilities I need:

1  
2  
3  
Random rnd = new Random();
int index = rnd.nextInt(values.length);
int randomType = values[index];    // 0 = Empty, 1 = Big, 2 = Medium, 3 = Small


I know the more talented guys and gals out there think this is probably ugly. I accept that this is only really useful in situations where the resulting pre-computed look-up array is fairly small. Mine is only 100 elements in size, but much larger sets could have memory footprint issues. But go gentle, this is my first attempt at handling weighted random selection Smiley

There's also the fact that this is precomputed, so obviously there would be additional issues on massive sets whilst everything is being preloaded into the look-up array. But again, my array size is small enough to be fairly inconsequential.

Here's my summary of what I've learned from this experiment:

PROS:
- Probably the easiest-to-understand method of accomplishing this that I've reviewed thus far.
- Quick and easy to code from the ground-up
- Since everything is precomputed, on-the-fly random selection requires no more work that fetching a value from memory.

CONS:
- Probably an ugly way to solve this!
- Adding a new weighted value to the set requires a little bit of coding (new for loop)
- Requires some re-calculation of how it affects the probabilities of other items in the set
- Not suitable for massive datasets (potentially memory-hungry, requires pre-computation).

I hope someone else finds this useful.

Thanks everybody for your help on this today!
4  Game Development / Newbie & Debugging Questions / Re: Calculating probabilities - is this the right way? on: 2014-05-16 14:43:55
All of these methods are actually very good - I can already see, based on the examples, how they would solve my problem.

This would also remove the need for me to do any initial probability testing on the empty vs. something check, since that's accounted for in the probability weighting itself (where the largest probability is nothing and all subsequent probabilities represent discrete entities).

Thanks! This was really helpful!
5  Game Development / Newbie & Debugging Questions / Calculating probabilities - is this the right way? on: 2014-05-16 13:14:42
Hi All,

I'm trying to fill up a grid of cells with random objects, but certain objects need to have a higher chance of generating than others.

So, imagining you have a 5x5 grid of cells, I could say that I want 50% of the cells to be empty, and the other 50% to contain something (potentially).

I made a little diagram showing kind of how the distribution of values works:



Here's where I get confused.

When I write the code to determine whether or not a cell is empty or not, I can do something like this:

1  
2  
3  
4  
5  
6  
7  
int chanceForSomething = 50;

Random rnd = new Random();
if (rnd.nextInt(100) < chanceForSomething)
{
    // cell isn't empty, generate something here!
}


But what confuses me is how I then further determine what to generate, based on their individual chances of generating? Looking at the percentage graph above, I can see how the lower 50% could be broken up into their own percentages (20% becomes a 40% chance, 5% becomes 10% etc.). However, if I were to do a calculation like this:

1  
2  
3  
4  
5  
6  
7  
8  
9  
int chanceForHuge = 40;
int chanceForLarge = 30;
int chanceForMedium = 10;
int chanceForSmall = 10;
int chanceForTiny = 10;

Random rnd = new Random();

int rndVal = rnd.nextInt(100);  // how does this distribute against the chance probabilities?


How do I work out what chance probability 'rndVal' matches? Am I thinking about this all wrong?

I want larger objects to spawn more frequently than smaller ones, so they should have a higher chance of being created. But I also need potential room to add more objects to this list of probabilities in future, without having to resort to 'baking' the percentage chance check with code like 'if (chance >= 5 && chance < 10) ...'. That seems like an unnecessarily 'dirty' way of handling this.

Any helpful insight into this would be greatly appreciated. Thanks!
6  Game Development / Newbie & Debugging Questions / Re: Upgrading movement to use acceleration / deceleration, rather than static values on: 2014-03-29 22:32:04
Thanks to you both for your helpful replies, I'll get onto trying these out!

Many thanks again Smiley
7  Game Development / Newbie & Debugging Questions / Upgrading movement to use acceleration / deceleration, rather than static values on: 2014-03-28 13:16:41
Hi all!

I'm pretty comfortable with camera movement so far:

1  
2  
3  
4  
5  
6  
7  
8  
9  
private void moveForward()
{
    float dist = (maxMoveSpeedInUnitsPerSecond / 1000) * Engine.DELTA;
    float addX = dist * Math.sin(Math.toRadians(camera.yaw));
    float addZ = dist * Math.cos(Math.toRadians(camera.yaw));

    camera.position.x += addX;
    camera.position.z += addZ;
}


However, this is a pretty linear way of moving around (a key press makes you instant move at your 'maximum speed').

I'd like to modify this set up to use some degree of acceleration (and deceleration). I'm not sure how to approach this concept, as I'm somewhat confused as to how acceleration / deceleration on both movement axes are combined (forward / reverse combined with strafing).

Any insights here would be most appreciated, thanks!
8  Game Development / Newbie & Debugging Questions / Gravity works great - steps, that's another issue! on: 2014-01-30 14:41:48
I'm having resolving an aesthetic issue with my 3D gravity calculations for player movement.

I have no problem calculating the effect of gravity on the player:

- Add a gravity coefficient to a vertical inertia value
- Test the new 'feet' position of the player against the current floor height
- If the player's feet go through the floor in the next update, 'snap' them to the floor's height and zero-out the vertical inertia

So far, so good. However, I want the player to be able to walk up onto floor heights that are higher than the current one. Stepping down already works (gravity takes care of that), but at the moment the player will simply 'snap' to the higher step height without any form of 'smoothing'.

I've seen many 3D games perform this 'step' smoothly - interpolating the player's vertical position between the lower and higher step point, without the interference of the gravity-vs-floor snapping code.

Does anybody have any suggestions of theory on how to overcome this? Currently the player will snap to the floor-heights without issue - it's the graduation between the two that is causing me consternation!

Thanks!
9  Game Development / Newbie & Debugging Questions / Re: Using a texture atlas with a display list? [SOLVED!] on: 2014-01-18 23:12:19
Whoops! Not any more Smiley
10  Game Development / Newbie & Debugging Questions / Re: Using a texture atlas with a display list? on: 2014-01-18 22:59:43
The solution:

I broke up the segment's geometry into two main components - the horizontal quads (floor / ceiling) and the wall quads (for both inner and upper / lower step walls).

Since the display list for each bit of geometry can only accommodate one set of texture coordinates, I decided to make a Geometry Atlas, which is just a fancy-pants way of saying that I mapped a texture atlas to a display list array.

So I know that my texture atlas contains 8 x 8 texture tiles:


Therefore, I know that I'll need an 8 x 8 array of display list handles (for a total of 64) - one for each uniquely textured quad.

All I do therefore, is run a loop that creates a new display list for each XY tile coordinate in the texture atlas - which contains the glBegin... glEnd instructions for creating a uniquely textured quad based on its respective XY texture tile.

At runtime, when I create the segments, I simply tell the Geometry Atlas to return me the right display list handle for whatever XY texture I need. The work done earlier on creating the lists make this a one-line call.

The result is a much faster scene render. The great thing is that this is still not fully optimised - I'm not running my line-of-sight code here, which will vastly speed up performance beyond what is shown here.

A video showing it running with this new code can be seen here:
http://www.youtube.com/watch?v=q4S664yizGo
11  Game Development / Newbie & Debugging Questions / Re: Using a texture atlas with a display list? on: 2014-01-18 22:52:07
I've finished implementing the changes - I'm really chuffed with the results.

I'm just uploading a video showing the performance improvement, and I'll write up a brief explanation of how I solved this in a moment.
12  Game Development / Newbie & Debugging Questions / Re: Using a texture atlas with a display list? on: 2014-01-18 22:07:33
zFollette, I've come up with a solution that was inspired by a comment you'd made on one of your threads.

I'm writing a GeometryAtlas that can take a texture atlas, and initialises itself into an array of display list handles, where each handle represents a quad UV mapped to specific sub-texture from the atlas.

The first part - creating an atlas to use for the single patch (one quad) wasn't too difficult. I'll have to extend this to the other parts of the Segment's geometry, but it shouldn't be too difficult.

I'll report my progress back here so that other people can learn from this as well.

Thanks for your help!
13  Game Development / Newbie & Debugging Questions / Re: Using a texture atlas with a display list? on: 2014-01-18 21:23:03
Would chunks be relevant for what I'm making? Obviously I'm not saying doing A is more correct than doing B, but I'd like to think that what I'm doing is much more lightweight than the typical 'voxel builder' type of game.

Consider this: the typical level in this game will look a little something like this layout:


That's a 50x50 region of space, subdivided into 1x1 individual XZ tiles. Each tile, or Segment, can have a variable floor / ceiling space (I guess a little bit like Doom's line-defs).

Breaking up this level into chunks seems like overkill.

Even textured, this region of geometry gives over 155 FPS - but obviously I want to improve this since I'm running this on a fairly modern iMac (last 3 years), and I want better legacy support.

As a final point, this is a worst case scenario - I have a line-of-sight algorithm (which is perfect for the corridor-style nature of this type of level design) which effectively culls 80-90% or more of the geometry on show. This will ease the load, but I will still have that nagging thought in the back of my head that I'm doing all of this in a really dirty way at the moment!
14  Game Development / Newbie & Debugging Questions / Re: Using a texture atlas with a display list? on: 2014-01-18 20:56:52
Thanks, zFollette.

This would mean, by extension, that I can't use just 4 display lists to generate the entire map's geometry - since you should be allowed to apply different textures to the walls / floors etc. Doing so would change textures for all geometry parts generated by that display list.

What a pickle Sad
15  Game Development / Newbie & Debugging Questions / Using a texture atlas with a display list? [SOLVED!] on: 2014-01-18 19:26:22
UPDATE: This has now been solved! A video showing the new code in action can be seen here: http://www.youtube.com/watch?v=q4S664yizGo

Hi all,

I've hit another rather annoying roadblock with my level editor / engine, and this one seems to have fairly serious implications for the way I'm doing things.

Here's a screenshot of the editor running to give you some context for the issue:

(Please ignore the red / blue highlights - they're markers to help me orient my UV coordinates)

So here's the deal. The level is made up of segments that look like this:


A segment is made up of 5 potential textures - a floor, ceiling, inner wall, upper wall and lower wall texture. The upper and lower wall textures are used for segments that have overhangs or steps, such as in the following image:


The problem I have is that, up until the previous iteration of the editor I had been drawing all of this geometry using immediate mode (glBegin()... glEnd()), this was combined with a texture atlas and modified UV texture coordinates to give me a decent render speed (to save repeated texture binds).

This was the original texture atlas:


However, after upgrading my geometry to display lists - which has given me an incredible 500fps boost - I can now no longer manipulate the texture coordinates of each group of quads once they've been compiled into the display list. It has to bind to a unique texture each time it needs to draw a different group of quads.

As you can see from the UI output data in the screenshot, I have a terrible, terrible number of texture binds.

I'm using around 4 different display lists to make up the segment - a floor / ceiling list, a wall list, and a list for both the upper and lower overhangs. Altogether they give me amazing performance benefits over immediate mode, but this problem has now left me questioning whether this was, in fact, the right way to do it.

If anybody else has managed to solve this problem, I'd be most grateful for some input.

Many thanks!
16  Game Development / Newbie & Debugging Questions / Re: Mouse clicking in 3D space? on: 2014-01-15 10:30:32
A very thorough and detailed explanation, thank you for taking the time to draft it out. This should answer the OP's question nicely, and will allow me to correct the method I'm using to do this to something more appropriate.

Thanks.
17  Game Development / Newbie & Debugging Questions / Re: How does one "Stick" to it? on: 2014-01-14 18:35:05
I found the OP's questions particularly close to my heart, because I used to reach the same roadblocks with almost every project I undertake.

I had to medal Rickmeister's post because he made a tremendously good point. I stop working on many ideas that I feel are 'killer' at the time I start writing them, if the interest peters out during development then clearly it's not the right time for me to be working on them.

However, what Rickmeister hit on particularly well is the point that no code you write is necessarily bad code - you learn from it, make mistakes, refactor and improve what you've written.

I've saved so much time reusing and improving classes I've written for older projects, which makes prototyping and reaching that 'sweet spot' in development that much quicker.

What do I mean by 'sweet spot', exactly?

Well, many developers will probably get the gist of what I mean. You've implemented all your boiler-plate code, got your project environment sorted, and you've got things happening on the screen. You think, 'It'd be awesome to add this in...', and you grab a soda/coffee/energy drink and sit there boppin' your noggin' to some good tunes and code away. A zen-like state of coding bliss.

But invariably, you can get burned out, and yes sometimes don't always pan out the way you want. But every line of code you write you learn a little bit more - and failure can only teach us how to succeed next time, even if those steps are small and incremental.

Eventually, your combined knowledge and skill in programming, in terms of both persistence and capability, will see your projects complete.

I love the OPs ideas, and would love to see some games come from him in future!
18  Game Development / Newbie & Debugging Questions / Re: Mouse clicking in 3D space? on: 2014-01-14 17:22:13
Could something like this work?

So you know where your near clipping plane is (based off of your camera's current position). You can therefore map the user's XY mouse position to its relative 3D world coordinates (the red dot).



Then, using information known about your far clipping plane (the end of your camera's view frustum) you can accurately map a point in the relative position on that far clipping plane (the blue dot).

The vector between these two points would effectively become the current picking ray (the dotted, red line) - and either using iterations OR line-intersection you could work out what this ray hits first in the scene, and pick that.

If none of this is right, I would appreciate some input so that the theory behind this is correct. I'm basing this off of my own interpretation of line picking that correctly observes the camera's FOV.

Thanks.
19  Game Development / Newbie & Debugging Questions / Re: Mouse clicking in 3D space? on: 2014-01-14 12:51:55
Danny, I'm glad that you've pointed out that line iteration is not perhaps the best way to do this type of object picking - but could you elaborate more on the concept you're discussing as the right way to do this?

I think that both I and the OP (along with anybody else interested in this particular topic) would benefit from some insight into the correct methodology to achieving this. I'd like to improve my own attempts at this.

I took the time to write up some code to illustrate one possible method of tackling this problem, and while I'm not suggesting that you need to do the same, I'd be interested to see a more explained version of your concept, as I had some difficulty understanding it.

Thanks.
20  Game Development / Newbie & Debugging Questions / Re: Mouse clicking in 3D space? on: 2014-01-13 17:56:19
Based on the way I accomplish this very task, and similar to the responses above, you can follow this sort of code...

(EDIT: I'm hastily typing this out at work, so apologies if the code is a bit sloppy)

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  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
public static Block pickBlockAtCursor()
{
   // grab a reference to your camera's current world position
  float camX = camera.x;
   float camY = camera.y;
   float camZ = camera.z;

   // you'll need your camera's orientation in space too. We'll assume your
  // camera angles are in degrees.
  float camYaw = camera.yaw;
   float camPitch = camera.pitch;

   // now decide what kind of resolution you want:
  // a longer test distance will allow you to pick blocks
  // further away, while the test iteration distance will
  // improve the accuracy of the picking algorithm.
  // Balance this how you see fit, but the iteration distance
  // should really be around 1/3 of your block's actual size
  float maxDist = 50;
   float iterationDist = 0.5f;

   // now work out how many iterations along the camera vector
  // we'll be testing with
  int iterations = (int)Math.floor(maxDist / iterationDist);

   // now we'll loop through and get each test point in 3D space
  // along the test vector
  for (int i = 0; i < iterations; i++)
   {
      // how far in front of the camera will this iteration take us?
     float currentDist = iterationDist * i;

      // get the current delta point in space for this iteration
     float f = (float)Math.cos(Math.toRadians(camPitch));

      float addX = currentDist  * f * (float)Math.sin(Math.toRadians(camYaw));
      float addZ = currentDist  * f * (float)Math.cos(Math.toRadians(camYaw));
      float addY = currentDist  * (float)Math.sin(Math.toRadians(camPitch));

      // now finish up by converting this to an actual world coordinate
     Vector3f pointInWorld = new Vector3f();
      pointInWorld.x = camX + addX;
      pointInWorld.y = camY + addY;
      pointInWorld.z = camZ + addZ;

      // let's assume you have an array of objects in your world that you're picking
     for (Block block : blockList)
      {
         // create a method like 'isPointInside' on your Block object that
        // just tests whether or not a Vector3f coordinate is 'inside' the
        // block's bounds
        if (block.isPointInside(pointInWorld))
         {
            // we've found our block!
           return block;
         }
      }
   }

   // we couldn't find anything in this test
  return null;
}


This code isn't perfect, but should give you the general idea.

Note that the 'blockList' array should be a list of logical blocks that are likely to be within the viewer's camera frustum - so you'd obviously not be looping through the entire world's block list, but rather your optimised list of blocks within the viewing cone.

Picking blocks using the mouse cursor (rather than with the camera's line of sight, a-la Minecraft) can be accomplished using a technique known as unprojecting, but this is more complex and I'd recommend getting to grips with this method first.
21  Game Development / Newbie & Debugging Questions / Why does my camera's forward motion 'snap' to weird yaw angles? on: 2014-01-11 21:43:05
Hi all,

I've been using this camera movement code (below) for ages now, but it has a strange bug that I've never been able to crack.

First, here's the code. The variables pitch and yaw represent the camera's yaw and pitch angles in degrees (in the 0-359 range).

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
public void moveCamForwardWithValue(float value)
   {      
      double cameraPitchInRadians = Math.toRadians(pitch);
      double cameraYawInRadians = Math.toRadians(yaw);
      float f = (float)Math.cos(cameraPitchInRadians);
     
      // prevent pitch angle from affecting forward speed
     if (!flyMode) { f = 1; }
     
      float addX = value  * f * (float)Math.sin(cameraYawInRadians);
      float addZ = value  * f * (float)Math.cos(cameraYawInRadians);
      float addY = value  * (float)Math.sin(cameraPitchInRadians);
     
      speedX -= addX;
      speedZ += addZ;
       
       if (flyMode) { speedY += addY; }
   }


What happens is that the user presses the 'forward' key (such as W) and moveCamForwardWithValue is called with a suitable input value.

Every frame the camera's position is modified by the speedX and speedZ values (and speedY if flight mode is enabled).

The camera moves forward fine, but the YAW angle it moves along doesn't always seem to be correct. Even stranger is that if I stay moving long enough, the movement 'snaps' to another yaw angle, almost as if it's eventually snapping to the yaw angle it should've been on all along.

I should add that the flyMode variable is a toggle to allow the camera to travel up / down along the pitch vector (as if flying) for debugging purposes.

I hope all of the above makes sense, please let me know if any further clarification is needed.

Tearing my hair out on this one!

Thanks Smiley
22  Game Development / Newbie & Debugging Questions / Re: Some assistance required with 3D room rendering style, visualizations included! on: 2014-01-09 23:37:01
Thanks, I appreciate the sentiment, and yes - I'm only too happy to post the editor framework once it's in a decent state. But as you say, it'll depend mostly on peoples' needs for something like this - but mapping out a 2D tile environment (for later extrusion into some 3D) might have its uses for some people Smiley
23  Game Development / Newbie & Debugging Questions / Re: Some assistance required with 3D room rendering style, visualizations included! on: 2014-01-09 23:22:26
Thanks... it took a little while for me to get my head around how the float buffers get filled (and flipped), but it made a lot more sense when I start added line breaks between each vertex's data when building the buffer array - it made it feel a little bit like writing out the old-style glVertex3f(...) commands!

For what it's worth, here's the final implementation I've gone for (with some handy visualisations).

All quads are drawn as VBOs now, where I simply have one VBO for each face orientation (horizontal, vertical) which are flipped as required depending on where they need to be drawn.

From a speed perspective, the line-of-sight algorithm does the leg work in calculating which segments need to be visible - the segments will draw their quad VBO lists if they're in the renderable list.

Here's how I visualised it.

The whole map is tiled in 2D. So every X/Z tile can store 1 segment. This segment can have a floor and a ceiling height, and up to 4 walls. This means that I can calculate a line-of-sight algorithm in 2D as well.

The following image shows the level editor with placeholder tiles on the ground to represent where the level's floors would be (just as an example, the actual segments are full 3D extrusions). The dark tiles aren't rendered at runtime (invisible to the line-of-sight), and the light ones are seen by the player.

The green line represents the left-most edge of the camera's viewpoint, and the red line the right. The purple lines indicate each ray that is being fired to test for wall collisions (in increments of 0.5 units, where one tile is 1 x 1 unit in width and depth).

You can see how, out of all of the level geometry, only 9 segments are actually visible. Massive speed boost!


The way the levels are designed will help in preventing the player from seeing too much distant geometry, but still allow them to see far down long corridors without having to render the entirety of room areas they're 'looking' in to:


And even on larger spaces, there's still a relatively low number of line of sight calculations happening:


I've restricted the LOS calculations to only happen once every 10 ticks or so, which should reduce the burden. Although to be fair, 146 calculations per tick wouldn't be a massive problem in any case. There will unlikely ever be more than a thousand or so at worst - and since this all happens between render cycles, it won't even chew up even a single millisecond of CPU time.

Quite pleased with these results - and I really appreciate your time in helping to answer my questions and be patient with me. I really appreciate it!

If anybody wants the LOS code, let me know and I'll post, thanks!
24  Game Development / Newbie & Debugging Questions / Re: Some assistance required with 3D room rendering style, visualizations included! on: 2014-01-09 17:26:07
I managed to solve this conundrum with your assistance, so thank you. VBOs work really well for speeding up the rendering.

However, I made another addition that has significantly increased draw speed across the board.

Before this change, I had been calculating a 'boxed' region around the player (camera's) position which was the render bounds - no segments outside of this region would even be checked for rendering.

Then, within this region, anything inside the camera view frustum was being rendered.

However, there was a lot of occluded (hidden) geometry being rendered needlessly. Since these levels will be mostly rooms and connected corridors, there's going to be plenty of cases where only partial geometry visibility is required, and to this end I wrote a line-of-sight algorithm.

I based it loosely off of Besenham's algorithm, in that it works in a top-down perspective against the (for all intents and purposes) 2D data map of Segments. From the player's perspective, several rays are fired in a fan that spans the entire camera's FOV. These rays are then tested incrementally until they encounter a wall (or, more specifically, a lack of any segments, which indicates 'nothing', or a 'wall'). As soon as they do encounter a wall, that ray's tracing is stopped and processing moves on to the next ray.

By tracing out the vectors using actual GL lines it's quite cool to see how it's calculating the ray vs. segment visibility.

By simply flagging all segments as 'hidden' to begin with, the ray tracer does a stellar job of only showing geometry that isn't occluded, and is within the player's view cone. It works even better than simple frustum culling, which required all of my geometry to be cross-referenced.

If anybody reading this is interested in my method for doing the ray-traced line of sight calculation, let me know and I'll post it up in a separate thread. I'm sure someone else might find it useful too Smiley
25  Game Development / Newbie & Debugging Questions / Re: Some assistance required with 3D room rendering style, visualizations included! on: 2014-01-08 18:32:35
Thanks - I thought it was a case of 'you're doing it wrong!' Smiley

I've just boiled the game down to, essentially, a 3D interpretation of 2D data (x,z position plus height data).

Just one last question, then: if you set up one VBO, can you reuse that VBO with different textures? Just bind the one you want before you invoke the draw method of the VBO?

Thanks for your input, I'm glad to know I'm on the right road!
26  Game Development / Newbie & Debugging Questions / Re: Some assistance required with 3D room rendering style, visualizations included! on: 2014-01-08 17:05:09
Thanks for your reply, there's some helpful ideas in there!

But you're right, of course, in that some context might help to further ground the idea behind what I'm trying to implement.

Yes, this is a level-editor, but I'm curious where you say you've never seen an editor work like this - could you elaborate what you mean? Smiley

In creating levels for a game I want to work on, I wanted to be able to visualise the layout of rooms and how they're connected and accessible to the player. I created an environment where I could move around in all dimensions, and move a cursor around the grid to help me add segment tiles to one another, raise and lower floors / ceilings etc. This seemed to serve the best of both worlds. Being able to build the level in 3D, sculpting almost, felt like a natural fit.

Anyway, I digress. The segments' edge data is re-calculated every time you add or remove (or change) a segment in the editor. During a recalculation, every segment is looped through and its edge data is calculated (the required dimensions of the edge quads and so forth).

The Segment object in the game would differ from the editor version in that it wouldn't necessarily need the additional pre-calculation variables - as you rightly point out. Rather than storing the drop values and visibility flags, I could simply store an array of objects that define each of the segment's faces (vertices, colours, tex coords and texture ID). Is this what you mean?

I would ask whether storing this 'quad' structure would be better served by putting the quad inside a display list (or VBO?), since all quads in the engine need to be equally sized (I'm using a texture atlas, so I can't leverage texture repeating on one long surface - such as a tall inside wall - instead it needs to be comprised of several same-sized quads).

This is where I'm most concerned - the continued use of immediate mode drawing (glBegin) where I could possible improve my Segment render method to something more streamlined (such as a simple list of 'quad' objects with the above list of properties).

Thanks for your input, I hope the above all makes sense!
27  Game Development / Newbie & Debugging Questions / Some assistance required with 3D room rendering style, visualizations included! on: 2014-01-08 14:55:47
Hey all!

I'm working on a kind of 3D room rendering data structure, but I'm having trouble with a couple of points.

First and foremost, here's a couple of screenshots from the actual engine running:

An example room:


From inside the room:


A room is made up of segments. A segment can be defined as a 1 x 1 tile that extends upwards by an arbitrary amount to form a hollow 3D cuboid.

Every time you add a segment next to another, their two adjoining faces are removed (not rendered) to form a larger interior space, until you create an entire room, as explained in the following diagram:



Up to this point, my data structure would define each segment as simply having an X, Y, Z position, a floor height and a ceiling height. The inner wall height is naturally the difference between the upper ceiling Y and lower floor Y.

Here's where things get a little more complicated :S

Adjacent floors can be different heights (as can ceilings). This raises the problem where you need to fill in the 'gap' between floors. This can be neatly explained in the following diagram:



The data structure gets a little more complex now. I've reduced the need to do runtime processing of these 'step' values by pre-computing them. For each segment in the entire map, I calculate the difference in floor height between each segment, and for each face (north, east, south and west). This  allows each segment edge to drop down to a unique height from its other edges.

If the adjacent floor is higher, it gets ignored since that higher floor will do the processing for that edge anyway.

So, here's where I'm having trouble.

I'm doing all of the tile rendering in immediate mode - so I have a Segment object that looks a bit like this in code:

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  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
public class Segment {

private float x, y, z;   // the segment's position, where Y is the floor's position
private float height;   // the height of the segment
private float ceilingY;   // for convenience, set as y + height

// the values that define how much lower this segment's neighbouring floors are
private float lowerDropNorth, lowerDropEast, lowerDropSouth, lowerDropWest;

// flags to enable or disable drawing of each side wall
private boolean drawNorth, drawEast, drawSouth, drawWest;

// flags to enable or disable drawing of the lower step edges
private boolean drawStepN, drawStepE, drawStepS, drawStepE;

public Segment() { }

public void render()
{
    // draw inner walls
   if (drawNorth)
    {
        glBegin(GL_QUADS);
        // vertex definitions...
       glEnd();
    }

    if (drawSouth)
    {
        glBegin(GL_QUADS);
        // vertex definitions...
       glEnd();
    }

    if (drawEast)
    {
        glBegin(GL_QUADS);
        // vertex definitions...
       glEnd();
    }

    if (drawWest)
    {
        glBegin(GL_QUADS);
        // vertex definitions...
       glEnd();
    }

    // draw step edges
   f (drawStepNorth)
    {
        glBegin(GL_QUADS);
        // vertex definitions...
       glEnd();
    }

    if (drawStepSouth)
    {
        glBegin(GL_QUADS);
        // vertex definitions...
       glEnd();
    }

    if (drawStepEast)
    {
        glBegin(GL_QUADS);
        // vertex definitions...
       glEnd();
    }

    if (drawStepWest)
    {
        glBegin(GL_QUADS);
        // vertex definitions...
       glEnd();
    }
}

}


This seems massively inefficient to me. Even with frustum and manual distance culling, this doesn't really seem to be an efficient way of rendering each segment's required faces. Or is it?

I figured that having each Segment's data pre-processed (position, step size etc.) would be beneficial since nothing is ever going to move once its created (static geometry), but I can't seem to think of a more appropriate way of rendering it.

I'd greatly appreciate feedback from anyone else who might have experience with these things!

Thanks!
28  Game Development / Newbie & Debugging Questions / Re: Looking for a solution to the un-repeatable texture atlas problem? on: 2013-12-28 19:32:02
Thanks! I'll probably have a look at the OpenGL texture array, as it might be impractical to do rotations with the way my engine has been set up (although I could still change it without too much effort).

Much appreciated!
29  Game Development / Newbie & Debugging Questions / Re: Looking for a solution to the un-repeatable texture atlas problem? on: 2013-12-28 18:14:55
This looks like it could be a solution - I'm just trying to wrap my head around it!

Here's an in-context example of what I mean from my project:



The walls and floor are all being textured from a single image (texture atlas). The floors (and ceilings) can be lowered and raised - which should affect the repeating value of the texture being used.

Here's an better look at the problem (the walls are '2 texture units' high, where as the floor is made up of 1x1 texture units):



As you can see, since the image is being snipped from a texture atlas, I'm only able to draw 100% of the texture across the whole quad - not, say, 140%.

I might take your advice on looking into OpenGL texture arrays. My target platform(s) at the moment are Windows and Mac. I would hate to rule out mobile support, but the specifics on my issue might end up forcing my hand to an unsupported method of solving this issue Sad
30  Game Development / Newbie & Debugging Questions / Looking for a solution to the un-repeatable texture atlas problem? on: 2013-12-28 17:50:17
Hi All!

I've been doing some digging around the forums trying to find somebody who's found a solution to the problem where you cannot repeat textures across a single quad (using UV coordinates) where said texture comes from a texture atlas.

Cue fancy images to explain!



So in this example, I'm building tiles, one quad at a time, and texturing them from a single-image texture atlas by manipulating each quad's UV texture coordinates.

So far, so good, but the above method of rendering the map geometry is inefficient.

So, cue image 2!



This time around, I've optimised the level geometry to combine quads that lie on the same row as one another. This makes the geometry three times more efficient, but I immediately fall into the trap I've raised this thread for.

From reading other forum posts, it seems impossible to repeat textures that have been 'snipped' from a texture atlas, so the above method of combining geometry wouldn't work - I'd have to render a single, correctly-sized quad for every texture tile I want to place, making it tremendously inefficient.

What I'd like to know is whether or not anybody has solved this conundrum yet?

I can't imagine that loading up a single image file for each texture tile is a better way around this - because even with an optimised texture binding order (to ensure each texture is only bound once for all geometry that uses it), I can see frames being chewed up and wasted by doing this.

I'm reaching out for some hands-on experience with this problem (and hopefully, a solution!).

Thanks all Smiley
Pages: [1] 2 3
 

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

The first screenshot will be displayed as a thumbnail.

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

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

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

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

ctomni231 (50 views)
2014-07-18 06:55:21

Zero Volt (45 views)
2014-07-17 23:47:54

danieldean (36 views)
2014-07-17 23:41:23

MustardPeter (39 views)
2014-07-16 23:30:00

Cero (54 views)
2014-07-16 00:42:17

Riven (55 views)
2014-07-14 18:02:53
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!