Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (755)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (842)
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 / Re: LWJGL Rendering problem on: 2012-05-29 19:24:57
They are getting darker because when you get to them in the code, the green shades of the texture are being drawn darker, as you set glColor3f(0f, .5f, 0f);

-0.5 being the green, no red or blue is drawn, thus the red textured grids are not drawn. glColour also affects the way textures are drawn... this can be useful for certain purposes such as 2d lighting systems etc.

It's pretty likely that adding that code will make sure that the grid is drawn again...
2  Game Development / Newbie & Debugging Questions / Re: LWJGL Rendering problem on: 2012-05-29 18:56:57
I'm not 100% sure, but I think that calling:

glColor3f(1f, 1f, 1f);

before drawing the grid should fix that...
3  Game Development / Game Mechanics / Re: Wall Collisions on: 2012-05-29 15:26:06
- The next sprite position gets calculated but not yet applied.
- The calculated position is handed over to the almighty collision master.
- In case of a free way, the sprite is moved.
- In case of collision, movement is cleared, no need to correct any position here.

Collision check points depends on the current heading, there are eight points overall.

If the position delta is too large, the distance is broken into multiple collision checks to prevent wall tunneling.

Surely this would cause the player to appear to collide with an invisible shield surrounding the wall, because the player would never be able to get close enough to touch it. While at high framerates it probably not be noticeable, at lower framerates or higher speeds, this would look a bit odd to the player...
4  Game Development / Game Mechanics / Re: Wall Collisions on: 2012-05-27 15:52:58
I tend to calculate how far into the wall the player hitbox is on the x axis, then displace it by the negative of that amount instantly, so it never appears inside the wall.

I then repeat this for the y axis, after the x position has been corrected.

I find that this gives the cleanest collisions, that stay working regardless of the framerate in a variable timestep environment. (so long as the framerate isn't so low that the player can skip right across it)
5  Game Development / Networking & Multiplayer / Re: Game server general questions on: 2012-05-25 19:38:16
Big servers are usually much more powerful, with tonnes of ram, loads of CPU cores, and a very fast internet connection. Most of them do also run special linux distros, but I don't think there's anything stopping you from downloading one yourself for a standard desktop, If you want that little extra bit of efficiency, but I'm not sure whether it would benefit you.
6  Game Development / Newbie & Debugging Questions / Re: 2d Simplistic Bullets on: 2012-05-22 08:29:32
Do you also have squidNig as a twitter username? hi again Tongue

from your code there, it looks like as soon as you press space, you will draw your box 1500 places to the right of where it initially spawned, because it is only ever drawn after this has run:
ie. you will only ever see it after it has moved.

for (int x= 0; x < 500; x++) {
               dx += 3;

(500*3 = 1500)

If you want to see it animate, you would need to redraw after every step (and also sleep the thread so that the animation is slow enough to see)

What happens when you press the spacebar twice?
I think we might need to see your listener code...
7  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL - How can I... (begginers questions) on: 2012-05-21 19:12:59
I use LWJGL to rasterize 2D projections of representations of virtual 3D objects, based on binary stored geometry and precise matrix transformations. persecutioncomplex
I will take it as my goal in life to translate and decipher that into wording comprehendable for mere mortals. Then I'm going to make a religion about it.

Don't, it sounds much less intelligent that way:

I use a computer to make 3D computer drawings stored in a language of only 1s and 0s become a grid of 2d pixels which represents this 3d drawing in a way that humans can visualise, transformed as depicted by a grid of numbers which describes the transformation.
8  Discussions / Miscellaneous Topics / Re: The miscellaneous projects image thread on: 2012-05-20 15:01:52
Woah, those trees look nice!

I can't see any of those pictures either, Danny02, only the second...
9  Discussions / Miscellaneous Topics / Re: raging right now... on: 2012-05-13 21:10:17
Didn't you hear? All of the cool kids are coding FPSs in Assembler, because its so much faster. Its because java can only makes games out of blocks or simple 2D games, its really slow, and nobody really uses it anyway, apart from for putting scripts in HTML. I mean, the java game engine has really bad graphics anyway.

Anyway, what I'm trying to say is, yes, its really really easy, most people are born with the ability.
10  Game Development / Newbie & Debugging Questions / Re: 2D Isometric-Diamond: Several question into one thread on: 2012-05-07 19:35:06
Could you tell me, is moving the offset of the map right or should I move the player instead?

There is not right or wrong in game programming Wink

Either is possible, I usually prefer to move the player and then offset the map based on the player. Although it sounds like more work, It makes moving the camera slightly for cutscenes or the like much easier, I feel.

Whichever seems easier and most suitable to your game is the one you should use, I know that both techniques are used.
11  Game Development / Game Mechanics / Re: [Help]2D tile map lighting on: 2012-04-26 22:54:39
I think that whatever you do, it's going to involve iterating through all of the tiles in the range of the light. A different technique might be to check for dark tiles and make the dark tile brighter, depending on how many light tiles it borders with, but its a matter of lighting style choice, best way to do it is probably just to try a few different things yourself. Implement different ways of calculating lighting values for unlit tiles, until you find something you like.
12  Game Development / Game Mechanics / Re: [Help]2D tile map lighting on: 2012-04-25 21:23:53
hmm... would you like to post your code for some help, or try at it yourself some more? I can't really tell much more without actually seeing what you've done...

It'll work out in the end, don't you worry Tongue
13  Game Development / Game Mechanics / Re: [Help]2D tile map lighting on: 2012-04-25 21:17:42
It should definitely not be so slow that your code doesn't run... You should not even notice a low frame rate with only one light...

What actually happens? Does any lighting show up at all?
14  Game Development / Game Mechanics / Re: [Help]2D tile map lighting on: 2012-04-25 20:44:43
yep. You would access the array just by going

I hope it works out Wink
15  Game Development / Game Mechanics / Re: [Help]2D tile map lighting on: 2012-04-25 19:59:54
wait... are your x1, x2, y1, y2 coordinates referring to 2 individual pixels or 2 individual tiles?

If you use the bresenham on tile coordinates rather than pixels, you will need to do far fewer calculations, so it will be much faster. Sorry if I was unclear Wink

For logic in tile based games, most calculations, such as pathfinding, lighting, etc. will use the tile as the smallest unit for calculation.

You've adapted the short bit of code from the middle of the page, the stuff at the very bottom should work, yes.
16  Game Development / Game Mechanics / Re: [Help]2D tile map lighting on: 2012-04-25 19:19:47
I assume you were reading from here:

Basically, like the one I showed, what you have coded there only works for 1/8th of the possible lines, you need to scroll down a bit on the page to learn what to change for the others. It is very similar to the first one, but just has a few signs changed and the like.

Also, would you mind explaining why you are accessing map tiles in that array, by minusing and dividing and casting?
17  Game Development / Game Mechanics / Re: [Help]2D tile map lighting on: 2012-04-24 19:26:38
Well, if you want the basic premise for my code, so you can modify it to work for you/rewrite it, this is the basic idea i used:

1. Calculate the gradient and set one of the ends of the ray to be the graph origin.
2a. Stepping through the x coordinates, use the equation y=mx (where m is the gradient) to find the corresponding y value.
2b. take the x value and the calculated y value and check to see whether that tile is blocked
2c. If the tile is blocked, it is not possible to light the final tile
2c. If you have reached the final tile, it is possible for the light to travel this path
3. Repeat steps 2 until all tiles in the possible area have been checked.

I hope this has helped you, good luck Wink
18  Game Development / Game Mechanics / Re: [Help]2D tile map lighting on: 2012-04-24 18:48:43
My code won't work correctly for gradients above 1 because if you have a gradient below one, you need to increment the x value several times to see a change in the integer value of y. For a gradient greater than one, for every x increment, there have been several changes in the y value. So you will skip some values using my code, as it only ever implements x stepping.

I accidentally just forgot to write the second half of the code... Cry

By doing 1/gradient, and incrementing by y, you are essentially flipping the standard straight line equation from y=mx to x=y/m (or x=[1/m]y)by dividing both sides by m. you would need to change a few of the calculations, for it to work properly for y stepping, but it would definitely work.

The Bresenham algorithm is supposedly one of the most efficient ways of doing it, because it keeps clear of using double values and uses ints instead. I haven't looked into how the Bresenham algorithm works, but if I were a beginner, I would use whatever made sense to me the most, because copying and pasting code when you don't understand it and couldn't rewrite it yourself is usually a bad habit to get into.
19  Game Development / Game Mechanics / Re: [Help]2D tile map lighting on: 2012-04-24 17:18:11
Raycasting is the fancy name for what I described, all you need is an algorithm to draw a line. You could finish the one I started, make your own, or google the 'Bresenham algorithm' for more information on how to calculate lines efficiently

Take into mind what theagentd said, about the lights scaling badly. But be sure you only update the lights every frame if you absolutely need to. If the lighting isn't going to change, You only need to calculate lighting when the level starts.If you can place your own blocks or lights, you only need to update that affects that area when you place a block/torch.
20  Game Development / Game Mechanics / Re: [Help]2D tile map lighting on: 2012-04-24 10:53:09
Sorry, I slept on that code and realised that it would not work for line gradients of greater than 1, because it would miss out bits of the line checking. A method I have used in the past is to, if the gradient is greater than 1, do 1/gradient and step by y++ rather than x++.

But this makes a huge mess of code, surely someone can think of a better way?

21  Game Development / Game Mechanics / Re: [Help]2D tile map lighting on: 2012-04-23 21:25:17
Few things before I get to your main question:

1. As far as I know, it is not common to store game maps as 2 dimensional arrays of bufferedImages. This makes any sort of logic look quite messy and usually people tend towards having 2d arrays of ints if the tiles aren't dynamic (or enumerations, if you like to keep it easy to read) (if they are dynamic, give them their own classes), which represent tiles, and are later converted by the renderer to render a static bufferedImage which represents that tile number. Using ints allows you to say:

if(tileNumber>=0 && tilenumber<=20){   //where only floor tiles have IDs between 0 and 20
//do stuff specific to all floor tiles

rather than

if(tile.equalTo(lmi.floor) || tile.equalto(lmi.floor2) || tile.equalto(lmi.floor3) etc...

Maybe it's just me, but i think that although an array of buffered images may seem easier for rendering, it is not as neat when you use it in logic.


2.Rather than searching through every tile to find a torch, which can get quite intensive for larger maps, you may find it would be better to keep an arrayList of points where torches reside.


Now onto your main question. Depending on how you want your lighting to look, and how many torches you are going to be using, there are many different lighting systems you could use.

Probably one of the simplest to implement would be to check whether each tile is visible from the light source.

so you would need to make a method for checking the visibility from the torch tile to the destination tile, and use the result from that to figure out whether the tile should be lit or not.

For example:
public static boolean isTileAVisibleFromB(Point a, Point b){   //couldn't come up with a decent method name :P

   if(a.getX() == b.getX() && a.getY() == b.getY()) return true;

   if(a.getX() != b.getX()){         //To prevent dividing by zero
      double gradient = ((double)a.getY() - (double)b.getY()))/((double)a.getX() - (double)b.getX()));
      if(a.getX() > b.getX()){
         int length = a.getX() - b.getX();

         int x;
         int y;

         while(a.getX() + x != b.getX() && a.getY() + y != b.getY()){
            y = (int)(x*gradient);
            if( the tile[x + a.getX()][y + a.getY()] cannot let light through){   //Pseudocode, you will need to check whether this tile can let light through
               return false;

         int length = b.getX() - a.getX();

         int x;
         int y;

         while(a.getX() + x != b.getX() && a.getY() + y != b.getY()){
            y = (int)(x*gradient);
            if(the tile[x + b.getX()][y + b.getY()] cannot let light through){   //Pseudocode, you will need to check whether this tile can let light through
               return false;
      int length = a.getY() - b.getY();

      int y;

         while(a.getY() + y != b.getY()){
            if( the tile[x + a.getX()][y + a.getY()] cannot let light through){   //Pseudocode, you will need to check whether this tile can let light through
               return false;
                  while(a.getY() + y != b.getY()){
            if( the tile[x + a.getX()][y + a.getY()] cannot let light through){   //Pseudocode, you will need to check whether this tile can let light through
               return false;

   return true;

That might not work completely, i just quickly typed it up in notepad, and there are some sections you need to fill in for yourself where I have just used pseudocode. You just need to check this before you light a tile, each time you were thinking of lighting a tile, and it will create sharp shadows, which are not completely realistic, but some people like 'em. If you wanted them with blurry edges there are a few different paths you could take, but just experiment! that code there should get the hard bit out of the way, but once you understand what I've written, you could customise it to include translucency, mirrors, coloured lighting, all sorts of stuff!.

One more thing, i'm not sure what you're doing with the lighting at the moment, but there is no need to redo the lighting every frame, only whenever you change something in the area of the torch.

Good luck, post us the results Wink


22  Discussions / General Discussions / Re: Noticed something on on: 2012-01-05 15:32:52
it was, for a brief period, and I haven't edited that page ever since then. I'll ask a web guy to fix it next week.

Success. Cheesy
23  Game Development / Performance Tuning / Re: LWJGL Graphics in seperate thread? on: 2012-01-05 12:42:29
And i am derailing another thread  persecutioncomplex

Actually, Your story caused the discussion that fully answered my question, thanks Wink
24  Discussions / General Discussions / Re: Noticed something on on: 2012-01-05 12:37:27
and 100 Guests are viewing this topic.


It's a good thing you need to be able to code to get in, or we would be getting some serious spamming. Really starting to appreciate those entry tests Wink
25  Game Development / Performance Tuning / Re: LWJGL Graphics in seperate thread? on: 2011-12-31 11:38:28
Wow, thanks everyone for the huge response Cheesy

This does work but.... it is very difficult to get working, and in my various tests, rarely achieves more than about 10-20% frame rate increase. And then only if you've got a dual-core system: you'll then find that the performance is slightly worse on a single-core system, which last time I looked was still about 25% of the systems out there in the wild. I'd say don't bother doing it if I were you and concentrate on getting it working single-threaded.

Cas Smiley

Thanks for the info, I think i will follow this advice. Wink

Nice to see people realize that a computer has more than one core!

The main problem with threading out graphics is that you have to make all OpenGL calls from the same thread, meaning that the graphics thread has to own the OpenGL context. This makes it a little difficult to initialize OpenGL (the Display, e.t.c.) and load textures and shaders, since they also have to be in the same thread. It's much easier to flip it around and thread out logic instead, since you can call OpenGL commands from the main thread in that case.

There are 2 kinds of thread-safe: Either you add synchronization to a normal solution, or you adapt the solution to not need synchronization in the first place. The second one usually has slightly worse single-core performance, but scales MUCH better with multiple cores, since synchronization costs some performance. Separating graphics and logic is pretty easy, but getting it perfect is pretty hard. The logic thread will read and write, e.g. update the game state, while the rendering will ONLY read information to draw stuff. Not much synchronization should be needed, but there is a big problem: The state may change during drawing, which may surprise the rendering thread. Some objects may have data from the last update while some objects have been updated. This is okay for a relatively simple 2D game, but in 3D, this can produce seams in the world!

I made a small library for threading games. In it you're meant to setup Task objects which perform different tasks. A Task has a list of other Tasks that needs to have been completed before it's allowed to be run. The Tasks are compiled into a TaskTree which can be run from a GameExecutor. This allows pretty complex threading to be very easily implemented.
 - You can make two Tasks run at the same time by having two Tasks that do not require each other. A multithreaded GameExecutor will put these on different threads. You're not supposed to have any manual synchronization inside Tasks.
 - You can also make Tasks themselves multi-threaded by using a SplitTask. For example this allows you to multithread movement updating by updating every other object from two different threads.

You can take a look on it here: Sadly, the interest on this forum was lower than I expected for it (0 downloads so far >_>).

Thanks for the info, I'll take a look at that threading example you made Wink
(although we have already implemented a lot of threading, so I will only read it for advice, thanks anyway Wink)

How about best of both worlds (pseudocode):
//main thread:
public void gameLoop() {
    boolean isLogicThreadRunning = false;
    if(Runtime.getRuntime().availableProcessors() > 1) {
        new LogicThread().start(); //the LogicThread just calls update in a loop
        isLogicThreadRunning = true;
    while(isGameRunning) {

Then just synchronize as necessary Grin

Yeah, I think we'll persue this route, thanks Wink

My engine is multithreaded. I have a game engine thread, the rendering thread and the network threads. For a game that has AI there is the AI threads.

My reason for doing was to separate the screen frame rate from the game turn rate. Turns out that it kinda doesn't work well without a lot of interpolation code on the rendering side. However this still makes the code much cleaner. Most of the work is still rendering so there is not really a performance increase on a mutlicore system in this case.

For synchronization, the engine gives out game state snapshots to the renderer with a thread safe queue from java.util.concurrent. The controller (aka gui in the renderer) sends command objects to the engine which again just uses a thread safe queue. The map, since it does not change, is shared without any synchronization.

Keeping all the opengl code in a single thread was easy enough. You can always use Display.makeCurrent() otherwise.

I find thread programing reasonably easy if you keep the threads coarse and the communication between them simple. Note also that opengl drivers may do things in the background for you too.

I'm not sure using interpolation would be very effective for our game, there is a lot of movement going on, and it's tile based, so I think it would be fairly obvious if a character overshot and had to jerk back in another direction...

Threading should be one of the last things you implement in the game, but you should still be coding with concurrency in mind if you plan on implementing it later. I am making a strategy game, which means that the CPU is a huge bottleneck in AI, line of sight, e.t.c, meaning that threading is pretty much necessary for large maps with many units. I expect an almost linear increase in performance for the parts I plan to multithread using the threading library I made.

We are making a strategy game also, but I feel it is always easier to multithread code while you know it well. If you code it thinking of concurrency anyway, then usually it won't take long to actually make it concurrent, I feel it is more useful to make it concurrent at the time of writing, really.


Once again, thank you all very much for all of the assistance Wink

26  Game Development / Performance Tuning / LWJGL Graphics in seperate thread? on: 2011-12-30 19:40:16
Hi, Java-gaming!

A friend and I are programming a game together in java, and I wrote a new graphics engine specifically for the game, using LWJGL. However, my friend believes that the game would be both better structured and with better performance if all of the drawing occurred in a separate thread. All of the objects to be drawn are contained within a huge tile map. His solution to keep everything thread safe and synchronised well is to make a deep copy of the map to be drawn, and then (in a thread safe way) move the area across to the graphics thread to be drawn. We already have some aspects, such as pathfinding, multithreaded, but he seems determined to do drawing in a separate thread... I just get this gut instinct that it is a bad idea because it goes against the standard game loop...

Am I being narrow minded? or is it it usually more sensible to keep drawing in the same thread as the game loop?

Thank you Wink

(I wasn't sure whether to post this in the 2d or performance forum, hope this was the right choice)
Pages: [1]
DesertCoockie (52 views)
2018-05-13 18:23:11

nelsongames (82 views)
2018-04-24 18:15:36

nelsongames (74 views)
2018-04-24 18:14:32

ivj94 (757 views)
2018-03-24 14:47:39

ivj94 (87 views)
2018-03-24 14:46:31

ivj94 (643 views)
2018-03-24 14:43:53

Solater (102 views)
2018-03-17 05:04:08

nelsongames (184 views)
2018-03-05 17:56:34

Gornova (426 views)
2018-03-02 22:15:33

buddyBro (1086 views)
2018-02-28 16:59:18
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!