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...
Spherical maps: work on.
Moderator: Moderators
Re: Spherical maps: work on.
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.
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.
Re: Spherical maps: work on.
Who is "we"?
Re: Spherical maps: work on.
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.
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.
Re: Spherical maps: work on.
Cool stuff! Keep at it!
Re: Spherical maps: work on.
just wait until op delivers, in the meantime stop bumping the thread.
-
- Posts: 1398
- Joined: 17 Sep 2008, 04:36
Re: Spherical maps: work on.
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).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.
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.