Spherical maps: work on.

Spherical maps: work on.

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Post Reply
Charadin
Posts: 11
Joined: 03 Nov 2011, 14:00

Spherical maps: work on.

Post by Charadin » 10 Nov 2011, 16:49

It's little early but i share here, where we are seeking.

ur goal is to provide spherical map with the less re-write damage to other code.

we are working on two coordinate mark, one for the planet and map damage, one for all the remnant, units, projectiles etc. with this second who is personal, and impermanent.

both linked by Vector Z planet.Vector Z unit = 1

the planet mark x,y, angle based will be used to draw mesh, we think we can keep the bitmap input for the heightmap, even if we use only 1 pixel at line 1, 5 pixel at line 2 (icosphere) etc... (will be a little weird to draw bitmap)




the second mark is a normal x,y,z like is it already in game but
lock on the unit the temporary mark will need a refresh every time the unit move (with limitation for don't spam cpu),
because it's a tangent plan we will get a climb-down effect for the projectiles, if the map is enought big, this will be petty.

Pathfinding, projectiles, every coordinate based stuff work well until you click more far than a quarter of sphere, so just click less far than the quarter.

because of, every units, every stuff had his own mark (every one had a different x,y, plane) we fear about the load of cpu, with 1000+ units, this will be ur testing priority and can end this way if the load is too much.

the mathematical model work, we are now planning the performance.
on the side we work on ur coding knowledge.


To be continued with code...
0 x

User avatar
momfreeek
Posts: 625
Joined: 29 Apr 2008, 16:50

Re: Spherical maps: work on.

Post by momfreeek » 10 Nov 2011, 17:18

As an exercise to further your own understanding there's nothing wrong.

But.. describing the basis for the idea and the underlying maths is not even a first step. Thats like drawing a picture of a car.

Designing and building that car is another matter (you need designers and engineers and CAD drawings and electronics and you need to fit all the workings into the design and build a prototype and test it and endless complicated things). Taking an existing car and making it look like your car only works if the existing car already fits your model.
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Spherical maps: work on.

Post by jK » 10 Nov 2011, 17:19

Who is "we"?
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Spherical maps: work on.

Post by AF » 10 Nov 2011, 19:00

I heard it mentioned in the past that allowing multiple quadmaps would let you have platforms.

One could extrapolate from this and build a map that was composed of multiple triangular-ish platforms, arranged in formation as a subdivided icosahedron. At which point one need only deal with the camera/UI and the gravity physics to give a very crude sphereworld ( or any other shape you would like ).

The extent of the initial work to support the platforms or arbitrary playing fields aside from the main we currently have as the map however I cannot comment or speculate on.
0 x

User avatar
MidKnight
Posts: 2650
Joined: 10 Sep 2008, 03:11

Re: Spherical maps: work on.

Post by MidKnight » 10 Nov 2011, 19:05

Cool stuff! Keep at it!
0 x

User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Spherical maps: work on.

Post by knorke » 10 Nov 2011, 20:09

just wait until op delivers, in the meantime stop bumping the thread.
0 x

luckywaldo7
Posts: 1397
Joined: 17 Sep 2008, 04:36

Re: Spherical maps: work on.

Post by luckywaldo7 » 10 Nov 2011, 23:32

Charadin wrote:we are working on two coordinate mark, one for the planet and map damage, one for all the remnant, units, projectiles etc. with this second who is personal, and impermanent.

both linked by Vector Z planet.Vector Z unit = 1

the planet mark x,y, angle based will be used to draw mesh, we think we can keep the bitmap input for the heightmap, even if we use only 1 pixel at line 1, 5 pixel at line 2 (icosphere) etc... (will be a little weird to draw bitmap)




the second mark is a normal x,y,z like is it already in game but
lock on the unit the temporary mark will need a refresh every time the unit move (with limitation for don't spam cpu),
because it's a tangent plan we will get a climb-down effect for the projectiles, if the map is enought big, this will be petty.

Pathfinding, projectiles, every coordinate based stuff work well until you click more far than a quarter of sphere, so just click less far than the quarter.

because of, every units, every stuff had his own mark (every one had a different x,y, plane) we fear about the load of cpu, with 1000+ units, this will be ur testing priority and can end this way if the load is too much.
Wait wait what what what are you doing. Why not instead move everything to a spherical coordinate system? That's not a hard conversion to do math-wise, although how that would work with spring's code and opengl and all that stuff I don't know (talk about the blind leading the blind here).

I imagine there would be some pretty funky effects though. Like lasers bending along the curvature of the planet. Well, gravity bends light anyway so WHATEVER.
0 x

Post Reply

Return to “Engine”

cron