Pulsar 4X

[Nathan_]

Here is a screenshot from the quadtree example I cooked up. The red and blue blocks know that they are inside/outside the hyperlimit respectively. The green and yellow ones are close enough to the boundary that they have to calculate it. unfortunately this didn't offer savings over just calculating the distance, again because it was only 1 collision being tested against. In the simulation all of the blocks are moving between the white block bases at random, and traveling at 10x speed when outside of the hyperlimit.

[Antagonist (OP)]

Defintely looks interesting, not just your simulations which is essentially documenting and testing the components and ships and tech and combat systems, but also your experiments with quadtrees which as I understand it you say is not worth it.

So long as your datafiles are clear and readable it should not be a problem porting those over when needed, and your with lookup tables and formulas definitely interest me in respect to the combat and simulation modules of Pulsar4X.

Its just gonna take a while I think before Pulsar4X has matured enough to take advantage of your work in this regard, since we need to implement the functionality in the UI to manipulate fleets and ships and components before we can really have playable spaceflight or battles. Perhaps we can for testing purposes implement something to allow random automated battles sooner than otherwise, but will have to see how things go.

There has been mention in the Ideas forum about decoupling emitters and detectors with sensors that I am somewhat keen on, though again it would likely increase the complexity of a proper working sensor system.

And yes, strictly the XCOM geoscape 'realtime' kinda system, wish we had a better illustrative example so its not confused with the battlescape time system.

The simulations you are doing, is it using newtownian or transnewtownian physics? Also, how does your subimpulse vary? Minimum step of 5s like base Aurora or less?

[Nathan_]

I'm aiming for 5.6 rules, the above image doesn't have components implemented as yet, those are just blocks moving at 1x speed and 10x speed. and my sub pulses will essentially be real time, once I get there.

[clement]

And done.

premake now generated .sln and .csproj files that compile and work okay on my PC.  They may need some extra references added as we add code however.

Just grab source from repo and run premake4.exe in the base directory to set it up.  Try not to sync the generated solution and project files back to the repo tho till we have confirmed this works.

Works for me, I can run premake.exe and compile the resulting projects.

[Antagonist (OP)]

I still need to get premake properly working for sublight on his Mac/Mono setup, but for the majority on windows the current setup should work fine.

I want to get the repository to a point now where people can actually start contributing, seeing my name over and over on the repo.  There are still some decisions that need to be made regarding ORM or so, but for most that won't affect anything.

Some things still rely on design decisions we need to make, but for basic UI and game logic we can work with what we have decided so far. See about getting something running. So for every dev that has offered: What do you want to work on and what do you need done before you can start.


EDIT: Best way to get involved is also to join us on skype. Just add me (l.skyfire) and I'll add you to the room.

[SnopyDogy]

"As you say these resolution/collision issues" - Aurora doesn't really do collision detection, and pulsar probably shouldn't worry about it either, other than for hyperlimits and sensors, I experimented with a quad tree, but with just 1 object its a waste, and sensors are basically going to be dynamic(and wierd due to having multiple detection radii) so no reason to do anything there.  We'll see how that plays out.  The biggest gain item that I think I can do is to have lookup tables instead of calculating various things.  thus far sensors and FCs have lookup tables in my code for detection/accuracy at distance functions.

By Collision I mean testing for a condition that requires 2 different objects to interact in some way.  You example of a ship and a stars hyper limit is a good one.  These things happen all the time in Aurora and handling it right, especially across large increments, is important.  For the sensors have you thought about marking the quads in the quad tree with a marker to say "if in this quad and above this mass, test to see if in range of this ships sensors"? Sorta like combining the lookup tables with your quad tree.

BTW I would love to have a look at the code for your skirmish sim if you’re willing to share.

[Nathan_]

Sure, and most of it will be stuff that I'll want to convert to c# and upload anyway, but I'll wait for milestones for releases like that.

[Antagonist (OP)]

Nathan_: I won't be the one doing it, but I advise that when we get to laying the groundwork for the simulation framework you have a nice long chat with the devs that will be responsible. On design and implementation and algorithms. Best case you all learn something and might help eventual porting if we choose to port something.

That said, your work so far looks good.

[Nathan_]

I've got all the code written for components atleast, so am testing some things. I've taken the hyperEx code and put sensors and signatures in, and have these two images that are mostly the same. the ships are now yellow boxes, and above them are 3 boxes colored red, green, and blue of varying brightness depending on how many other ships have spotted this one on thermal, active, and em respectively. the signatures are determined randomly for each ship, but each ship's sensor is the same basic size 5 active,thermal and em sensors. And lastly there are 500 ships running around.

the FPS change is the result of this sliver of code, with the 1st image using the lookup tables that I mentioned earlier, and the second calculating everything on the fly:

Code: [Select]

int newRange,thm,em,newRange2,thm2,em2;
if(swapQT == 1)
{
newRange = 25000000 * pow( ( (double)(ships[ loop2 ].TCS - 1 ) / 100.0 ) , 2.0 );
newRange2 = 25000000 * pow( ( (double)(ships[ loop ].TCS - 1 ) / 100.0 ) , 2.0 );
thm = calcUnknownSignature(ships[loop].thermal,(ships[ loop2 ].thermalS - 1));
thm2 = calcUnknownSignature(ships[loop2].thermal,(ships[ loop ].thermalS - 1));
em = calcUnknownSignature(ships[loop].EM,( ships[ loop2 ].EMS - 1 ));
em2 = calcUnknownSignature(ships[loop2].EM,( ships[ loop ].EMS - 1 ));
}
else
{
newRange = ships[loop].active->lookUpST[ (ships[ loop2 ].TCS - 1) ];
newRange2 = ships[loop2].active->lookUpST[ (ships[ loop ].TCS - 1) ];
thm = ships[loop].thermal->lookUpT[ (ships[ loop2 ].thermalS - 1) ];
thm2 = ships[loop2].thermal->lookUpT[ (ships[ loop ].thermalS - 1) ];
em = ships[loop].EM->lookUpT[ ( ships[ loop2 ].EMS - 1 ) ];
em2 = ships[loop2].EM->lookUpT[ ( ships[ loop ].EMS - 1 ) ];
}


These things happen all the time in Aurora and handling it right, especially across large increments, is important.  For the sensors have you thought about marking the quads in the quad tree with a marker to say "if in this quad and above this mass, test to see if in range of this ships sensors"? Sorta like combining the lookup tables with your quad tree.

I had thought about that, but quadTrees really only work best with static unchangeable terrain. since sensors are so weird, can move around, and can be destroyed at will, the overhead from the quad tree would probably eat any gain from it.

[Antagonist (OP)]

Just to let everyone know, just cos its quiet here on forums doesn't mean nothing is happening.

We're pretty active on Skype and getting plenty work done.


What we're hoping to do soon is to release an 'alpha' version which basically includes the F9 screen and the system view screen.  Since the system view is done in OpenGL we'd like as many people possible to test it on a variety of hardware so that we can get an idea on how well supported our code is on the platforms that players will be using.

This will showcase our star and planetary system generation, though it will be an ongoing effort to optimize it.

If anyone is interesting in taking part in the skype discussions, either as an interested party or as someone willing to contribute, just send me or sublight a message with your skype id.

Just keep an eye on this space!

[joe]

I am for sure in for a testing pig
1440x900 screen resolution on a notebook is not that standard. . .  but then again. . .  maybe it is :p

Looking forward!

[SnopyDogy]

Joe, if you want to start testing early contact antagonist or sublight and join the skype conversation. I could really use someone to test the OpenGL stuff more.

[joe]

Intergalactic message away. . .
Unfortunately I am not well suited for skype conversations, as they are not allowed at work and when I am at home, I tend to my 1. 5 year-old twin ladies and my wife most of the time

[SnopyDogy]

Pitty You can't get on Skype Joe, Still the offers still out there if anyone else wants to jump in. We could really use someone for testing Mono Compatablilty in Linux in addition to the OpenGL stuff.

[Antagonist (OP)]

Might as well actually post this here.

If you wanna see what we're up to but don't want to join on skype, you can download and compile the source yourself.  It's very easy. We would especially like this to test whether the OpenGL works properly on a wide range of hardware.  We'll release an alpha once we're happy with the features we're adding, but if you can't wait you can check out our in-progress build.

Assuming windows, you'll need Visual Studio 2010.  Express will do: http://www.microsoft.com/visualstudio/en-us/products/2010-editions/express
Then you need github for windows: http://windows.github.com/
Head to this site: https://github.com/Pulsar4xDevs/Pulsar4x
and click on clone in windows.

This should place a copy of the source in the Documents\Github\Pulsar4x directory by default I think.  Double click premake4.exe to generate the solution and project files, then double click on the resultant .sln.

Build and run from the menu and you should see our splash screen appear!



If there are errors, particularly ones relating to OpenGL, please alert us.  There should be a .log next to your exe which might contain essential information on the error.  I'm thinking we might need a bug report topic, but will see how this goes.

If you are NOT on windows then we would especially like your help to get Pulsar4X working on other platforms.  We are for the most part windows devs so that is what we have been focusing on. All libraries we use are mono-compatible, we just need to get them linking correctly.  No real coding skills needed just some knowledge of your platform, command line, how to get around on it, install packages and knowledge of where the libraries are installed on your platform. If so, please let us know and preferably join us on skype!

EDIT:
I added a new thread for all this.