Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (724)
Games in Android Showcase (216)
games submitted by our members
Games in WIP (791)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3 ... 10
 1 
 on: 2017-04-28 06:21:37 
Started by BurntPizza - Last post by Guerra2442
Improved slider, added scrollbar size, started working on the layout system and reworked the title bars to use the layout system.
Click to Play

 2 
 on: 2017-04-28 02:38:08 
Started by BurntPizza - Last post by ra4king
Two monitors is the minimum for productivity for me. I'm waiting until I settle down until I buy a 3rd monitor (I want a vertical monitor this time!)

Generally for me, I have code on one monitor and documentation/IRC/program I'm making on the other monitor.

 3 
 on: 2017-04-27 23:39:54 
Started by BurntPizza - Last post by dime26
Mostly refactoring and bug fixing this top down game, the base car class now works well enough, adding in new vehicles types for the next few days, also added a simple skid mark effect.

Click to Play

 4 
 on: 2017-04-27 20:12:57 
Started by theagentd - Last post by theagentd
I investigated a lot of different solution, from hierarchical systems to waypoint systems, but they all had different problems, ranging from expensive precomputing to not being able to handle dynamic worlds (units can block a tile). In the end I decided to try optimizing the existing implementation and see how far that got me.

The first issue was the memory usage of the array that holds all the nodes. As the worlds we generate are mostly inaccessible terrain like mountains or ocean, a majority of the elements in the array are going to be null. However, a 40 million element array of 32-bit references is still going to use 150MBs, so the single monolithic array had to go. I split up the world into chunks of 16x16 tiles. That left me with a 480x320 chunk array instead, which only uses around half a megabyte of memory instead. This reduced the constant by around 150MBs. Chunk objects are then allocated (and reused) on demand when the pathfinder first enters a chunk for each job. Chunks have all their nodes preallocated, so there's a tiny bit of inefficiency for the edge around an inaccessible area; if just one tile in a chunk is accessible and explored by the pathfinder, the entire chunk will need to be allocated/reserved.

The second problem was the size of each node. The Node object I used to store the pathfinding data of each tile had the following data:
1  
2  
3  
      int x, y;
      int lastOpenedStart, lastOpenedGoal;
      Node parentStart, parentGoal;

For some crazy reason, this ended up taking up 40 bytes per node, plus 4 byte per node in the arrays used to hold the Nodes in each chunk!!! I count 24 bytes of actual data in there. 24 bytes of actual data taking 44 bytes! I decided to look for ways of reducing the size of the information.

As our max world size is 7680x5120, it's clear that for x and y we really don't need the full range of a 32-bit integer. With 13 bits for each of X and Y, we can accommodate up to 8192x8192 worlds, which is just enough for us.

The reason why the lastOpened* values are ints instead of booleans is to avoid having to reset the entire world after each pathfinding job. If those were booleans, I'd need to go through all opened nodes and reset them back to false after each job. By making them ints, I can implicitly "reset" the entire world by simply doing jobID++; once in the pathfinder. Then when I want to mark a node as opened, I do
lastOpenedStart = jobID;
, and to check if a node is opened, I just do
if(lastOpenedStart == jobID) ...
. However, with the chunk system, it became trivial (and necessary anyway) to reset chunks when they're reused, so such a system isn't necessary here. Hence, we can compress the two opened fields down to just 2 bits in total.

Lastly, the two parent references are used for backtracking once a path has been found. However, in our simple tile world there are only 4 possible directions you can travel in, so we can store each parent with just 2 bits used to encode which of the 4 directions the parent is in.

This all sums up to a grand total of...... exactly 32 bits per node. In other words, my "node array" is currently just an int[] which I pack in all the data into. I can fit an entire node in just 4 bytes per node instead of the 44 bytes used before. In addition, the chunk system means that in most cases the worst case scenario for memory usage is never reached due to more efficient reuse of chunks between multiple pathfinding jobs. The new system averages less than 50MBs, with an absolute worst case scenario at under 75MBs. The improvements in memory locality also almost doubled the performance of the system.


Here's a comparison normal breadth-first search and bi-directional breadth first search:

Normal:


Bidirectional:


There's a huge difference in the number of tiles explored by the two (the red area). The normal search explores almost every single reachable tile in the world, while the bidirectional one generally avoids exploring half the world in worst case scenarios. This reduces peak memory usage by quite a bit.

 5 
 on: 2017-04-27 20:02:44 
Started by BurntPizza - Last post by theagentd
Two monitor person here. Best decision ever. Code on one monitor, talk about anime girls with your best friend on the other.
SHHHHHH!!! That was supposed to be our secret! >___<


Jokes aside, two monitors is great. Having a Eclipse on one monitor, Skype/an internet resource/a second Eclipse window on the other helps a lot.

 6 
 on: 2017-04-27 19:37:11 
Started by KaiHH - Last post by KaiHH
Latest JOML release version 1.9.3 is out!
The most notable change is the full compatibility with GWT >= 2.5.0 (even in strict mode), available as org.joml:joml-gwt:1.9.3 on Maven Central (Gradle setup).
Many thanks to @SHC for his great support to make this possible!

 7 
 on: 2017-04-27 18:35:17 
Started by avt232 - Last post by Catharsis
Cool.. I never came across XPilot before. When I get around to releasing TyphonRT it seems like a great vehicle for a demo example client and containerized server effort with a focus on entities / component architecture in implementation. I'll try and keep this in mind!  Grin

 8 
 on: 2017-04-27 17:43:11 
Started by BurntPizza - Last post by Archive
After seeing Numberphile's fascinating new video:
https://www.youtube.com/watch?v=kbKtFN71Lfs&t=0s

I was motivated to make a program that does this
http://www.mediafire.com/file/neef4fzaw3r2r68/sierpinski.jar



Here's the pastebin
http://pastebin.java-gaming.org/63b7358315f17

 9 
 on: 2017-04-27 12:03:44 
Started by theagentd - Last post by kappa
Maybe grid based pathfinding is the wrong algorithm use in this case.

For large worlds it is better to go for a NavMesh based pathfinding solution (like Starcraft 2), memory usage will be massively lower.

 10 
 on: 2017-04-27 09:57:48 
Started by BurntPizza - Last post by SkyAphid
I'm starting to consider getting myself a second monitor. Anyone here coding with two monitors? Does it increase productivity? Smiley
Two monitor person here. Best decision ever. Code on one monitor, talk about anime girls with your best friend on the other.

Pages: [1] 2 3 ... 10
 
Archive (27 views)
2017-04-27 17:45:51

buddyBro (235 views)
2017-04-05 03:38:00

CopyableCougar4 (662 views)
2017-03-24 15:39:42

theagentd (658 views)
2017-03-24 15:32:08

Rule (709 views)
2017-03-19 12:43:22

Rule (683 views)
2017-03-19 12:42:17

Rule (685 views)
2017-03-19 12:36:21

theagentd (699 views)
2017-03-16 05:07:07

theagentd (630 views)
2017-03-15 22:37:06

theagentd (471 views)
2017-03-15 22:32:18
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

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
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!