• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

[Java] Best datatype to store object position/Snap to grid?

Any of y'all interested in a F2P space mmo that's better than EVE but is limited to CLI display?


  • Total voters
    2
Joined
Dec 21, 2016
Messages
68 (0.06/day)
Location
A dusty server room
System Name HP DL380 G5
Processor 2x Intel Xeon X5460 @3.16 Ghz
Motherboard HP DL 380
Cooling 6 60mm intake fans rated for 14k RPM max load
Memory 16GB of DDR2 667Mhz
Video Card(s) AMD XFX R7 360
Storage 3x 140GB 10K SAS JBOD
Display(s) 1x Hisense 42" TV
Case DL 380 G5
Audio Device(s) HDMI Out
Power Supply 2x 800w Proprietary PSUs
Mouse A cheap logitech wireless mouse
Keyboard Acer KU-0355
Software Windows 10!
Benchmark Scores Ill get around to em soon
Hey guys, I've been designing a 2D, CLI-based space MMO ( sort of like EVE, meant to give the shit your brains experience as Aurora 4x/Dwarf fortress for those who know what that is) and I've been trying to figure out what are the best datatypes to store object position on a "massive scale" universe?

I use trigonometry to move the ships along a path towards the intended destination. But in doing so, I tend to have really large decimals and even if I round, I lose precision, and the objects

You'd expect in the perfect world that these ships would just snap to their nearest intended coordinate while moving there (without a decimal) and the world is happy and maybe I could store these values as longs instead of doubles.



My attachment
Java:
public class ShipPhysics {
    //THIS CLASS GETS CALLED EVERY FRAME, THIS TELLS ALL SHIPS TO UPDATE THEIR PHYSICS IN CASE OF DESTINATION CHANGE!
    public static void updateMovement(){
        for(int i = 0; i < lists.ships.size(); i++){
            ship s = lists.ships.get(i);
            double gotoX = s.getDestinationX();
            double gotoY = s.getDestinationY();
            double speed = s.getSpeed();
            double dx;
            double dy;
            double dir;
            dy = Math.abs(gotoY - s.getYPos());
            dx = Math.abs(gotoX - s.getXPos());
            dir = Math.atan(dy/dx);
            //System.out.println(i + " x: " + dx + " y: " + dy + " slope: " + slope);
            if(gotoX != s.getXPos() || gotoY != s.getYPos() ){

                if(gotoX < s.getXPos()){
                    s.setXpos(s.getXPos() - (speed * Math.cos(dir)));

                }
                if(gotoX > s.getXPos()){
                    s.setXpos(s.getXPos() + (speed * Math.cos(dir)));

                }
                if(gotoY < s.getYPos()){
                    s.setYpos(s.getYPos() - (speed * Math.sin(dir)));

                }
                if(gotoY > s.getYPos()){
                    s.setYpos(s.getYPos() + (speed * Math.sin(dir)));
                }
            }
        }
    }
}
Here I send the battleship at coordinate (0,0) to coordinate (100,50) and takes a straight slope path to get there(trig), but yields this awful result. Sending the other ships to coordinate 100,50 results in numbers that round to (101, 51)
sendthebattleshipto100-50from00.PNG


However, I wish for the grid to always snap to the nearest whole number.

Thanks ~ Sal
 
Last edited:

FordGT90Concept

"I go fast!1!11!1!"
Joined
Oct 13, 2008
Messages
25,692 (6.24/day)
Location
IA, USA
System Name BY-2015
Processor Intel Core i7-6700K (4 x 4.00 GHz) w/ HT and Turbo on
Motherboard MSI Z170A GAMING M7
Cooling Scythe Kotetsu
Memory 2 x Kingston HyperX DDR4-2133 8 GiB
Video Card(s) Sapphire Radeon RX 5500 XT Pulse 8 GiB
Storage Crucial MX300 275 GB, Seagate Exos X12 TB 7200 RPM
Display(s) Samsung SyncMaster T240 24" LCD (1920x1200 HDMI) + Samsung SyncMaster 906BW 19" LCD (1440x900 VGA)
Case Coolermaster HAF 932 w/ USB 3.0 5.25" bay
Audio Device(s) Realtek ALC1150, Micca OriGen+
Power Supply Enermax Platimax 850w
Mouse SteelSeries Sensei RAW
Keyboard Tesoro Excalibur
Software Windows 10 Pro 64-bit
Benchmark Scores Faster than the tortoise; slower than the hare.
Use round() after you do math to get it back to the grid. Alternatively, yeah, change to longs.

Remember that computationally, longs are much quicker than doubles. If you're going to end up copying from long to double to do math getting a double result which you have to convert to long again, just leave it double and round as needed.

I guarantee you cos() and sin() are returning doubles or floats so best to just keep it double. The stupid thing is that round() returns longs or ints so you're going to have to do senseless casting no matter what approach you take with Java.
 
Joined
Dec 21, 2016
Messages
68 (0.06/day)
Location
A dusty server room
System Name HP DL380 G5
Processor 2x Intel Xeon X5460 @3.16 Ghz
Motherboard HP DL 380
Cooling 6 60mm intake fans rated for 14k RPM max load
Memory 16GB of DDR2 667Mhz
Video Card(s) AMD XFX R7 360
Storage 3x 140GB 10K SAS JBOD
Display(s) 1x Hisense 42" TV
Case DL 380 G5
Audio Device(s) HDMI Out
Power Supply 2x 800w Proprietary PSUs
Mouse A cheap logitech wireless mouse
Keyboard Acer KU-0355
Software Windows 10!
Benchmark Scores Ill get around to em soon
Use round() after you do math to get it back to the grid. Alternatively, yeah, change to longs.

Remember that computationally, longs are much quicker than doubles. If you're going to end up copying from long to double to do math getting a double result which you have to convert to long again, just leave it double and round as needed.

I guarantee you cos() and sin() are returning doubles or floats so best to just keep it double. The stupid thing is that round() returns longs or ints so you're going to have to do senseless casting no matter what approach you take with Java.
Thanks for the quick reply :). What I have done is that I round once the object has finished moving to the pseudo-correct position. Maybe that patches in the hole. The issue I am later to be faced with, is size of the universe. I was thinking maybe big double, or something along those lines. But it's best I keep things simple for now as is before moving to the more extreme datatypes

Thanks ~ Sal :)
 

FordGT90Concept

"I go fast!1!11!1!"
Joined
Oct 13, 2008
Messages
25,692 (6.24/day)
Location
IA, USA
System Name BY-2015
Processor Intel Core i7-6700K (4 x 4.00 GHz) w/ HT and Turbo on
Motherboard MSI Z170A GAMING M7
Cooling Scythe Kotetsu
Memory 2 x Kingston HyperX DDR4-2133 8 GiB
Video Card(s) Sapphire Radeon RX 5500 XT Pulse 8 GiB
Storage Crucial MX300 275 GB, Seagate Exos X12 TB 7200 RPM
Display(s) Samsung SyncMaster T240 24" LCD (1920x1200 HDMI) + Samsung SyncMaster 906BW 19" LCD (1440x900 VGA)
Case Coolermaster HAF 932 w/ USB 3.0 5.25" bay
Audio Device(s) Realtek ALC1150, Micca OriGen+
Power Supply Enermax Platimax 850w
Mouse SteelSeries Sensei RAW
Keyboard Tesoro Excalibur
Software Windows 10 Pro 64-bit
Benchmark Scores Faster than the tortoise; slower than the hare.
You're not going to want to do anything larger than double because processors will have to take multiple clocks to handle each operation.

If you know for a fact that you're going to be perfectly okay with pinning everything to a whole-number grid and longs are big enough for you, then go with longs. Java round() already forces you to that, from what it looks like.

Most games address the problem you're describing by having grids inside of grids. e.g. a universe grid, a cluster grid, a galaxy grid, a star grid, and a planet grid. Each has its own scale and when you hit a coordinate on one, you move to the next down position relative to the approach. This is how they were able to make a game like Star Control back in the 90s on 16-bit processors.
 
Joined
Dec 21, 2016
Messages
68 (0.06/day)
Location
A dusty server room
System Name HP DL380 G5
Processor 2x Intel Xeon X5460 @3.16 Ghz
Motherboard HP DL 380
Cooling 6 60mm intake fans rated for 14k RPM max load
Memory 16GB of DDR2 667Mhz
Video Card(s) AMD XFX R7 360
Storage 3x 140GB 10K SAS JBOD
Display(s) 1x Hisense 42" TV
Case DL 380 G5
Audio Device(s) HDMI Out
Power Supply 2x 800w Proprietary PSUs
Mouse A cheap logitech wireless mouse
Keyboard Acer KU-0355
Software Windows 10!
Benchmark Scores Ill get around to em soon
You're not going to want to do anything larger than double because processors will have to take multiple clocks to handle each operation.

If you know for a fact that you're going to be perfectly okay with pinning everything to a whole-number grid and longs are big enough for you, then go with longs. Java round() already forces you to that, from what it looks like.
It's what additional position variables are for :D.
 
Top