Elite radar
-
- Bounty Hunter
- Posts: 152
- Joined: Thu Sep 02, 2010 8:00 pm
Elite radar
I have been toying around with the radar lately, because I want to have a better spatial perception of where enemy units are during combat.
The Elite radar is a good step in that direction, but unfortunately it does not work. I have looked at the code, but it looks beyond repair. As the code for the WC radar also is a bit convoluted, I decided to refactor the radar code so that they share the same code except for the drawing (and associated calculation and sorting.) After this refactoring I reimplemented the Elite radar. I use the left radar view for nearby units (useful during combat) and the left radar view for distant units.
I have attached two snapshots of this radar. The first resembles the original radar from the Elite game the most, except the ground plane has not been drawn (eventually it will be.) Blips below the ground plane are darker than those above. In the picture you can see a lot of debris to the left of me (it once was an LHW patrol.)
In the second picture, I have drawn the enemy positions as triangles instead of lines. The left radar view shows an enemy in red before and above me, and a fighter barrack in white to the left and below of me. On the right radar view, you can see that the closer the units are, the lighter the color of the triangle becomes.
I am currently experimenting with exactly how the radar should work, so that it does give you a good view of the combat. The basic problem is that the radar becomes cluttered when there are many units nearby.
Another thing that I want to do is to integrate the Elite radar properly into the game. That is, instead of being a config option, the radar should be available as an update sensor. However, I have not looked into this at all.
If anybody is interested in the experimental code, then I can send a diff (against SVN).
The Elite radar is a good step in that direction, but unfortunately it does not work. I have looked at the code, but it looks beyond repair. As the code for the WC radar also is a bit convoluted, I decided to refactor the radar code so that they share the same code except for the drawing (and associated calculation and sorting.) After this refactoring I reimplemented the Elite radar. I use the left radar view for nearby units (useful during combat) and the left radar view for distant units.
I have attached two snapshots of this radar. The first resembles the original radar from the Elite game the most, except the ground plane has not been drawn (eventually it will be.) Blips below the ground plane are darker than those above. In the picture you can see a lot of debris to the left of me (it once was an LHW patrol.)
In the second picture, I have drawn the enemy positions as triangles instead of lines. The left radar view shows an enemy in red before and above me, and a fighter barrack in white to the left and below of me. On the right radar view, you can see that the closer the units are, the lighter the color of the triangle becomes.
I am currently experimenting with exactly how the radar should work, so that it does give you a good view of the combat. The basic problem is that the radar becomes cluttered when there are many units nearby.
Another thing that I want to do is to integrate the Elite radar properly into the game. That is, instead of being a config option, the radar should be available as an update sensor. However, I have not looked into this at all.
If anybody is interested in the experimental code, then I can send a diff (against SVN).
You do not have the required permissions to view the files attached to this post.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Elite radar
Beware of doing too much work at once.
Try to build incremental and constrained patches.
For instance, the refactoring would be one patch. Elite rendering another. Etc, etc...
Otherwise, maintaining or reviewing them could be problematic.
Also, consider techniques used in real radars to remove clutter: threat assessment, for instance, makes immediate threats pop up above and independent of clutter.
Try to build incremental and constrained patches.
For instance, the refactoring would be one patch. Elite rendering another. Etc, etc...
Otherwise, maintaining or reviewing them could be problematic.
Also, consider techniques used in real radars to remove clutter: threat assessment, for instance, makes immediate threats pop up above and independent of clutter.
-
- Bounty Hunter
- Posts: 152
- Joined: Thu Sep 02, 2010 8:00 pm
Re: Elite radar
I have attached a patch for an Elite-like radar. The patch is a diff against SVN.
The patch is not final -- there are still a few issues to resolve first. However, I have decided to post it anyways, because it is functional and I would like feedback on it.
The most important issue is that the Elite radar does not handle planets very well -- it will display the center of the planet, not the surface.
To enable the Elite radar, change the hud / radarType to "Elite" in the configuration file.
I have added some extra radar features that will work with both the WC and Elite radar. First, the radar can show the size of the objects. Second, the radar can indicate severe threats (missile or capital ships targetting you) with pulsating colors.
As none of the present sensors support these features, they can be enabled by adding the following line to the "hud" section of the configuration file.
<var name="radarIff" value="true"/>
The patch is not final -- there are still a few issues to resolve first. However, I have decided to post it anyways, because it is functional and I would like feedback on it.
The most important issue is that the Elite radar does not handle planets very well -- it will display the center of the planet, not the surface.
To enable the Elite radar, change the hud / radarType to "Elite" in the configuration file.
I have added some extra radar features that will work with both the WC and Elite radar. First, the radar can show the size of the objects. Second, the radar can indicate severe threats (missile or capital ships targetting you) with pulsating colors.
As none of the present sensors support these features, they can be enabled by adding the following line to the "hud" section of the configuration file.
<var name="radarIff" value="true"/>
You do not have the required permissions to view the files attached to this post.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Elite radar
Cool, I'll take a look when I have some time.
Feel free to bump the thread if somehow I forget![Wink ;)](./images/smilies/icon_wink.gif)
Feel free to bump the thread if somehow I forget
![Wink ;)](./images/smilies/icon_wink.gif)
-
- Bounty Hunter
- Posts: 152
- Joined: Thu Sep 02, 2010 8:00 pm
Re: Elite radar
Have you (or anybody else) looked at the patch yet?
I should mention that I am continuing to develop the radar, so if you prefer small(ish) patches, then it may be in your own interest not to delay this for too long.
Actually, I am mainly interested in feedback about how the radar(s) work while playing, rather than feedback on the code.
Although performance has not been my main focus, I found a way to avoid the blip sorting for the WC radar. This also enabled a better spatial perception for this radar. It is a bit difficult to explain, but imagine that there are two nested spheres, where the outer sphere shows the distant objects and the inner sphere shows the near objects (to be accurate, objects are mapped somewhere between the two spheres depending on their distance).
I should mention that I am continuing to develop the radar, so if you prefer small(ish) patches, then it may be in your own interest not to delay this for too long.
Actually, I am mainly interested in feedback about how the radar(s) work while playing, rather than feedback on the code.
Although performance has not been my main focus, I found a way to avoid the blip sorting for the WC radar. This also enabled a better spatial perception for this radar. It is a bit difficult to explain, but imagine that there are two nested spheres, where the outer sphere shows the distant objects and the inner sphere shows the near objects (to be accurate, objects are mapped somewhere between the two spheres depending on their distance).
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Elite radar
My ISP@home had trouble and now I'm without internet access.
Since I can't playtest anything at work, I'm effectively cut out from SVN (commit, checkout, whatever).
That sucks, but it doesn't stop development. I've been battling those issues, so no, I haven't had a chance to test the patch. But I'll give it some priority soonish.
(I'll ship the patch home in a pendrive if necessary
)
Since I can't playtest anything at work, I'm effectively cut out from SVN (commit, checkout, whatever).
That sucks, but it doesn't stop development. I've been battling those issues, so no, I haven't had a chance to test the patch. But I'll give it some priority soonish.
(I'll ship the patch home in a pendrive if necessary
![Wink ;)](./images/smilies/icon_wink.gif)
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Elite radar
Ok, I've got a few coding-style comments on your code, and few important objections.
First of all, I like how you've organized radar rendering, it's a lot nicer than before. It also feels more maintainable and customizable. So don't take the many observations as a bad thing, in fact, it's nice to feel like I can make all these observations![Smile :)](./images/smilies/icon_smile.gif)
On that line of thought, I'd like to take the opportunity to take it all the way there.
I should really install a review board somewhere... but until that's done, lets go through the patch step by step.
RADARLIM::IffType
It's ok to give names to things, but I think you're modifying the scale without modifying the dataset. Shouldn't you modify units_csv to parse the new scale? I recommend an encoding similar to that used in the tractorability column, with a letter code (or textual enum) being coverted at load time to the actual enum.
CollectRadarBlips::aquire
You commented out AutoLanding. I didn't see a replacement in the patch... that feature should not be removed.
SortingOrder
You're using <functional> without a real need. Functional is useful when you'll be playing with template metaprogramming, and you want to start composing functions. But in the case of SortingOrder, that's all unneeded. Avoid using advanced template stuff without a real need/benefit, as that only hurts compatibility with older compilers.
Tabs/Spaces
You mix tab and spaces. Please convert everything to spaces only.
RadarDisplay derivatives
You have a neat "abstract" class RadarDisplay, I like that, but you didn't use the chance to actually separate concrete classes from client code (clients of Cockpit). I'd like it better if RadarDisplay was a real abstract class, and the many display modes concrete classes derived from it. You could create a folder (gfx/radar) where to put all this, each class on its own file, etc...
Also, client code should not be exposed to boost::random and other implementation details. That should be on each concrete class, and if it's common to all concrete classes, an intermedate class could encapsulate common behavior.
If you feel like addressing those issues, great. If not, it'll take time, but I will.
Thanks for the patch![Smile :)](./images/smilies/icon_smile.gif)
First of all, I like how you've organized radar rendering, it's a lot nicer than before. It also feels more maintainable and customizable. So don't take the many observations as a bad thing, in fact, it's nice to feel like I can make all these observations
![Smile :)](./images/smilies/icon_smile.gif)
On that line of thought, I'd like to take the opportunity to take it all the way there.
I should really install a review board somewhere... but until that's done, lets go through the patch step by step.
RADARLIM::IffType
It's ok to give names to things, but I think you're modifying the scale without modifying the dataset. Shouldn't you modify units_csv to parse the new scale? I recommend an encoding similar to that used in the tractorability column, with a letter code (or textual enum) being coverted at load time to the actual enum.
CollectRadarBlips::aquire
You commented out AutoLanding. I didn't see a replacement in the patch... that feature should not be removed.
SortingOrder
You're using <functional> without a real need. Functional is useful when you'll be playing with template metaprogramming, and you want to start composing functions. But in the case of SortingOrder, that's all unneeded. Avoid using advanced template stuff without a real need/benefit, as that only hurts compatibility with older compilers.
Tabs/Spaces
You mix tab and spaces. Please convert everything to spaces only.
RadarDisplay derivatives
You have a neat "abstract" class RadarDisplay, I like that, but you didn't use the chance to actually separate concrete classes from client code (clients of Cockpit). I'd like it better if RadarDisplay was a real abstract class, and the many display modes concrete classes derived from it. You could create a folder (gfx/radar) where to put all this, each class on its own file, etc...
Also, client code should not be exposed to boost::random and other implementation details. That should be on each concrete class, and if it's common to all concrete classes, an intermedate class could encapsulate common behavior.
If you feel like addressing those issues, great. If not, it'll take time, but I will.
Thanks for the patch
![Smile :)](./images/smilies/icon_smile.gif)
-
- Bounty Hunter
- Posts: 152
- Joined: Thu Sep 02, 2010 8:00 pm
Re: Elite radar
Thanks for the constructive feedback. By and large I agree with your comments.
I wanted to move the AutoLanding to a more appropriate place, but I was not sure where. It seems more appropriate to be triggered from the code related to collision checks than radar blip.
This comment brings up another issue. How old compilers is VS intended to support?
And while we are on the topic, our boost version is really old. Maybe it is time to upgrade.
I started by changing the type throughout all the code, but the ran into problems in the serializers -- some macro insisted that it should be stored as a float, or something like that. Also, I was not sure about how to maintain backwardscompatibility with the current configuration files. So, I decided to use the IffType in to cockpit code to make it more readable, and to leave the serialization stuff alone. This, of course, requirest that they agree on the values used. I will assign a value to each enum to make sure of this.klauss wrote:RADARLIM::IffType
It's ok to give names to things, but I think you're modifying the scale without modifying the dataset. Shouldn't you modify units_csv to parse the new scale? I recommend an encoding similar to that used in the tractorability column, with a letter code (or textual enum) being coverted at load time to the actual enum.
Agreed.klauss wrote:CollectRadarBlips::aquire
You commented out AutoLanding. I didn't see a replacement in the patch... that feature should not be removed.
I wanted to move the AutoLanding to a more appropriate place, but I was not sure where. It seems more appropriate to be triggered from the code related to collision checks than radar blip.
Sure, std::binary_function is not necessary, but I used it to document to the reader that SortingOrder is a functor, not a plain struct. However, this is not a major issue. I can easily remove it. In fact, I have eliminated sorting completely in my current code (OpenGL handles it for me.)klauss wrote:SortingOrder
You're using <functional> without a real need. Functional is useful when you'll be playing with template metaprogramming, and you want to start composing functions. But in the case of SortingOrder, that's all unneeded. Avoid using advanced template stuff without a real need/benefit, as that only hurts compatibility with older compilers.
This comment brings up another issue. How old compilers is VS intended to support?
And while we are on the topic, our boost version is really old. Maybe it is time to upgrade.
This is a very good suggestion.klauss wrote:RadarDisplay derivatives
You have a neat "abstract" class RadarDisplay, I like that, but you didn't use the chance to actually separate concrete classes from client code (clients of Cockpit). I'd like it better if RadarDisplay was a real abstract class, and the many display modes concrete classes derived from it. You could create a folder (gfx/radar) where to put all this, each class on its own file, etc...
Agreed.klauss wrote:Also, client code should not be exposed to boost::random and other implementation details. That should be on each concrete class, and if it's common to all concrete classes, an intermedate class could encapsulate common behavior.
-
- Elite Mercenary
- Posts: 1329
- Joined: Thu Mar 27, 2003 11:51 pm
- Location: Manchester, UK
- Contact:
Re: Elite radar
And isn't this traditionally a problem with the VS codebase, "spaghetti code" if you will, features in places you would not expect to find them such as here, the autolanding code being entwined with the radar code.breese wrote:Agreed.klauss wrote:CollectRadarBlips::aquire
You commented out AutoLanding. I didn't see a replacement in the patch... that feature should not be removed.
I wanted to move the AutoLanding to a more appropriate place, but I was not sure where. It seems more appropriate to be triggered from the code related to collision checks than radar blip.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
FreeGameDev forum - open source game development community
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Elite radar
Seems like an adequate compromise.breese wrote:I started by changing the type throughout all the code, but the ran into problems in the serializers -- some macro insisted that it should be stored as a float, or something like that. Also, I was not sure about how to maintain backwardscompatibility with the current configuration files. So, I decided to use the IffType in to cockpit code to make it more readable, and to leave the serialization stuff alone. This, of course, requirest that they agree on the values used. I will assign a value to each enum to make sure of this.klauss wrote:RADARLIM::IffType
It should indeed be in collision code. But I bet it's there because of the frequency with which it is called. Completely farbot.breese wrote:Agreed.klauss wrote:CollectRadarBlips::aquire
You commented out AutoLanding. I didn't see a replacement in the patch... that feature should not be removed.
I wanted to move the AutoLanding to a more appropriate place, but I was not sure where. It seems more appropriate to be triggered from the code related to collision checks than radar blip.
In any case, a refactor to remove that code from radar code and put it where it belongs is in order. But we cannot commit any intermediate code with the feature completely missing, privateer mods depend on it.
How? Depth offset perhaps?breese wrote:I can easily remove it. In fact, I have eliminated sorting completely in my current code (OpenGL handles it for me.)klauss wrote:SortingOrder
You're using <functional> without a real need.
In windows land, Visual Studio 7, VS compiled at one time with Visual Studio 6, but I'm not sure whether it does anymore, and I don't think we should worry about it. But right now, Visual Studio 8 brings some deployment trouble (the binaries it creates aren't entirely compatible somehow) so VS must still compile with Visual 7.breese wrote:This comment brings up another issue. How old compilers is VS intended to support?
In nix land, I'm not sure. I use gcc 4.3 and 4.2, there may be older distros with older gcc versions. In nix land we're stuck with what the popular distributions come with, so it's a moving target.
Point being: lets not introduce potentially problematic code if we can avoid it easily. If some template class really helps you, ok, we'll test. But in this case, it doesn't even help, so... gone.
In nix land, you can tell ./configure to use system boost (ie: newer), with ./configure --with-boost=system. In fact I believe it's the default. The same goes with cmake, it tries to use system boost by default.breese wrote:And while we are on the topic, our boost version is really old. Maybe it is time to upgrade.
In windows, yep, we could upgrade, but then again, compatibility with Visual 7 must be checked since boost is one of the hardest libraries to compile.
-
- Bounty Hunter
- Posts: 152
- Joined: Thu Sep 02, 2010 8:00 pm
Re: Elite radar
I will submit a new patch that includes AutoLanding. However, it may take a while as I am also incorporating your other suggestions.klauss wrote: It should indeed be in collision code. But I bet it's there because of the frequency with which it is called. Completely farbot.
In any case, a refactor to remove that code from radar code and put it where it belongs is in order. But we cannot commit any intermediate code with the feature completely missing, privateer mods depend on it.
Yes, but with a twist.klauss wrote: How? Depth offset perhaps?
The WC radar projects all ships (and other objects) unto a sphere by calculating the unit vector for each ship. The problem is that more ships may be projected unto the same blip -- their unit vectors are the same even if one ship is near and the other is distant -- and it is arbitrary which one will block out the others.
The sorting handled this by making sure that enemy blips are drawn on top of friendly blips.
The first change I did was to sort all blips according to distance. Nearby ships would be drawn on top of distant ships.
The next change I did was to fiddle with the unit vector. The unit vector is calculated by dividing the vector by its own length (Vector unitVector = vector / vector.Magnitude()). I scaled the length (the magnitude), so that the length of the unit vector was not 1.0 for all ships, but rather 1.0 for distant ships and 0.98 for nearby ships. By using all three dimentions of the modified unit vector when drawing the vertex, the depth handling of OpenGL took care of the rest, and the sorting became superfluous.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Elite radar
Are you sure that works?
Because I don't think radar rendering has z-test and z-write enabled, which would invalidate your technique. And if it were to be enabled, I don't think the z-buffer is properly initialized. And if it were. the overhead of clearing the z-buffer may be higher than sorting on the CPU.
Also, beware that hostiles on top of friendlies was a requested feature.
(though I like your idea of splitting contacts in far and near contacts, since hostiles at light seconds distances don't really matter that much)
Because I don't think radar rendering has z-test and z-write enabled, which would invalidate your technique. And if it were to be enabled, I don't think the z-buffer is properly initialized. And if it were. the overhead of clearing the z-buffer may be higher than sorting on the CPU.
Also, beware that hostiles on top of friendlies was a requested feature.
(though I like your idea of splitting contacts in far and near contacts, since hostiles at light seconds distances don't really matter that much)
-
- Merchant
- Posts: 56
- Joined: Sat Jul 18, 2009 5:35 pm
Re: Elite radar
Purely as a point of realism, shouldn't the "problem" of ships close together or behind one another from the player's ship pov result in an incorrect or uncertain radar blip? Maybe a big scanner system with multiple mount points far enough apart to get more detailed scanner info could be available for huge things like a capship or station.. But just offhand, I'd think that some possible radar confusion on friend/foe when they are very close together and the possible tactical advantages of ducking behind a large ship or station or object to get off your opponent's radar for a few seconds to make a hopefully unexpected course change could be good things?
Personally, I always liked the Elite style of scanner display. It is a lot of info condensed into fewer pixels. But logically, however the scanner is working, it still would have to be using a one point source and as such an object could be hiding behind another object. While it could have some depth/distance perception by how long it takes for a ping to return, it still doesn't seem to me that it would be able to accurately and reliably see through objects like Superman or something. LOL
Personally, I always liked the Elite style of scanner display. It is a lot of info condensed into fewer pixels. But logically, however the scanner is working, it still would have to be using a one point source and as such an object could be hiding behind another object. While it could have some depth/distance perception by how long it takes for a ping to return, it still doesn't seem to me that it would be able to accurately and reliably see through objects like Superman or something. LOL
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Elite radar
It's more a matter of separating concepts.
If the detection model (practically nonexistent atm, but.. just follow the line of thought), if the model decides the scanner detects a ship, the rendering on the screen should be clear.
Modelling detection deficiencies should happen at a different level.
Moving onto the realism point, studying modern radar technologies may debunk a lot of myths about their limitations. They're incredibly sophistcated nowadays, and one can only wonder what sophistication levels would be found in the far future of VS.
One point I'd like to consider, is ISAR technology, which currently allows sea-based radars to make out some sort of structural imaging of a target hundreds of miles away. Sort of an x-ray image of the target ship. The technique only works with sea-based targets because of very specifc phenomenon that don't apply to other situations, but extending the technique to other targets is just a matter of creativity and computing power.
With that in mind, do you think 3000 years in the future radars won't be able to tell two aligned ships apart from each other? I think they would. Maybe they wouldn't be able to see through planets, true, but they wouldn't be confused by most formations either.
Another important issue is, if concepts are not properly separated, the limitation is artficially and unfairly asymmetric. For instance, if rendering defects make two units undistinguishable, it will be a confusion that only affects the player and not the AI, giving the AI an unfair advantage.
If the detection model (practically nonexistent atm, but.. just follow the line of thought), if the model decides the scanner detects a ship, the rendering on the screen should be clear.
Modelling detection deficiencies should happen at a different level.
Moving onto the realism point, studying modern radar technologies may debunk a lot of myths about their limitations. They're incredibly sophistcated nowadays, and one can only wonder what sophistication levels would be found in the far future of VS.
One point I'd like to consider, is ISAR technology, which currently allows sea-based radars to make out some sort of structural imaging of a target hundreds of miles away. Sort of an x-ray image of the target ship. The technique only works with sea-based targets because of very specifc phenomenon that don't apply to other situations, but extending the technique to other targets is just a matter of creativity and computing power.
With that in mind, do you think 3000 years in the future radars won't be able to tell two aligned ships apart from each other? I think they would. Maybe they wouldn't be able to see through planets, true, but they wouldn't be confused by most formations either.
Another important issue is, if concepts are not properly separated, the limitation is artficially and unfairly asymmetric. For instance, if rendering defects make two units undistinguishable, it will be a confusion that only affects the player and not the AI, giving the AI an unfair advantage.
-
- Merchant
- Posts: 56
- Joined: Sat Jul 18, 2009 5:35 pm
Re: Elite radar
Good points!
Though trying to imagine the technology of 3,000 yrs in the future is pretty wild to do anyway.![Wink :wink:](./images/smilies/icon_wink.gif)
Though trying to imagine the technology of 3,000 yrs in the future is pretty wild to do anyway.
![Wink :wink:](./images/smilies/icon_wink.gif)
-
- Bounty Hunter
- Posts: 152
- Joined: Thu Sep 02, 2010 8:00 pm
Re: Elite radar
I enabled z-test and z-write to make it work. As radar blips are drawn into the main viewport, which already uses z-buffering (e.g. for the targetting boxes), I do not think that this will impact performance.klauss wrote:Are you sure that works?
Because I don't think radar rendering has z-test and z-write enabled, which would invalidate your technique. And if it were to be enabled, I don't think the z-buffer is properly initialized. And if it were. the overhead of clearing the z-buffer may be higher than sorting on the CPU.
I had to move the damage flash polygon slightly backwards (i.e. I changed its z coordinates from 0 to 1) so that it did not obstruct the radar blips, but that was the only other change needed to make it work.
Yes, I was aware that this was a requested feature, and it was indeed an improvement over the previous arbitrary "sorting."klauss wrote: Also, beware that hostiles on top of friendlies was a requested feature.
(though I like your idea of splitting contacts in far and near contacts, since hostiles at light seconds distances don't really matter that much)
However, as you notice, I found that closeness was a more important trait during combat. The only problem is that some time into a large-scale combat, the combat ground may be cluttered with cargo. I am currently experimenting if drawing cargo blips transparently (with a low alpha value) will solve this problem.
Besides, if people want a better combat radar, they should buy a Highborn (Elite) or Rlaan radar, which solve these problems in different ways.
The Highborn radar does not have front/rear views, but rather near/distant views. The near view shows the ships within a 30 km radius, which seems well-suited for close combat, and the distant view shows everything beyond the 30 km boundary.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Elite radar
Ouch... I think it will.breese wrote:I enabled z-test and z-write to make it work. As radar blips are drawn into the main viewport, which already uses z-buffering (e.g. for the targetting boxes), I do not think that this will impact performance.klauss wrote:Are you sure that works?
Because I don't think radar rendering has z-test and z-write enabled, which would invalidate your technique. And if it were to be enabled, I don't think the z-buffer is properly initialized. And if it were. the overhead of clearing the z-buffer may be higher than sorting on the CPU.
You're burning through a lot of VRAM bandwidth to avoid sorting on the CPU, a task for which the CPU is uniquely suited.
You perhaps don't notice because you have a high-end GPU (perhaps?), or perhaps VS is shader-bound atm, but low-end or onboard owners will probably feel the hit.
I'd rather sort on the CPU. It's not that big a deal, even with 10k units (which would be a lot even in VS), remember the shuffle thingy avoided copying and moving lots of bits, it was just a matter of sorting the indices. I remeber profiling the code, and it practically disappeared from the top-50 when I added the indices thing.
-
- Bounty Hunter
- Posts: 152
- Joined: Thu Sep 02, 2010 8:00 pm
Re: Elite radar
I suppose I have a medium range GPU. When I approach a planet with an atmosphere, the frame rate drops to below 10.klauss wrote: Ouch... I think it will.
You're burning through a lot of VRAM bandwidth to avoid sorting on the CPU, a task for which the CPU is uniquely suited.
You perhaps don't notice because you have a high-end GPU (perhaps?), or perhaps VS is shader-bound atm, but low-end or onboard owners will probably feel the hit.
It sounds as if you are comparing the sorting of blips with the sorting of indices of blips here, and I cannot argue with that. However, that is not really what we are discussing here.klauss wrote: I'd rather sort on the CPU. It's not that big a deal, even with 10k units (which would be a lot even in VS), remember the shuffle thingy avoided copying and moving lots of bits, it was just a matter of sorting the indices. I remeber profiling the code, and it practically disappeared from the top-50 when I added the indices thing.
Rather than guessing I sat down and measured the performance. The std::sort row shows the time of the original DrawBlips, and my OpenGL z-buffer approach. Both rows show time in milliseconds.
#blips: 50,100, 200, 300, 400, 500, 600, 700
std::sort: 0.2, 0.4, 0.8, 1.4, 1.8, 2.1, 2.7, 3.5
OpenGL: 0.15, 0.35, 0.7, 1.1, 1.4, 1.8, 2.1, 2.5
At low numbers of blips they are close, but at high numbers of blips the OpenGL approach clearly wins.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Elite radar
You can't measure performance like that when you're offloading work to the GPU, since the GPU will queue your work to be performed asynchronously.
It may be stalling the rendering loop later, outside of radar functions.
In essence, the difference you see is the time it takes to sort the blips. The rest of the time is the time it takes to generate the blips. As you can see, sorting takes very little, and the times you measure absolutely don't count the time spent rendering the radar. That's very hard to measure.
BTW: did you try a bucketsort? Bucketsort is O(N). That's fast. And it would work here like a charm, on the CPU, without applying z-buffer tricks.
But don't worry about that... we can benchmark and tweak later.
It may be stalling the rendering loop later, outside of radar functions.
In essence, the difference you see is the time it takes to sort the blips. The rest of the time is the time it takes to generate the blips. As you can see, sorting takes very little, and the times you measure absolutely don't count the time spent rendering the radar. That's very hard to measure.
BTW: did you try a bucketsort? Bucketsort is O(N). That's fast. And it would work here like a charm, on the CPU, without applying z-buffer tricks.
But don't worry about that... we can benchmark and tweak later.
-
- Bounty Hunter
- Posts: 152
- Joined: Thu Sep 02, 2010 8:00 pm
Re: Elite radar
This has already been accounted for. I did a glFinish() before starting the measurement and before measuring the end time to make sure that the timings included the work done by the GPU.klauss wrote:You can't measure performance like that when you're offloading work to the GPU, since the GPU will queue your work to be performed asynchronously.
It may be stalling the rendering loop later, outside of radar functions.
As sorting times, whether we use std::sort or z-buffer, are negible, I fail to understand why we are having this discussion.klauss wrote: In essence, the difference you see is the time it takes to sort the blips. The rest of the time is the time it takes to generate the blips. As you can see, sorting takes very little, and the times you measure absolutely don't count the time spent rendering the radar. That's very hard to measure.
The reason I started looking at the z-buffer approach in the first place was because the Elite radar had to sort the blips differently. I could approximate this by sorting the blips by their z-value, although that would be incorrect because the Elite radar uses a different viewing angle. Instead, the z-buffer approach guarantees that the ordering is correct regardless of what kinds of radars we may construe.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Elite radar
I fear the effect could be far more noticeable on low-end onboard GPUs. But, then again, discussing this much without benchmarks is a bit nonsensicalbreese wrote:As sorting times, whether we use std::sort or z-buffer, are negible, I fail to understand why we are having this discussion.
![Wink ;)](./images/smilies/icon_wink.gif)
Now that is a far stronger point in z-buffer's favor.breese wrote:The reason I started looking at the z-buffer approach in the first place was because the Elite radar had to sort the blips differently. I could approximate this by sorting the blips by their z-value, although that would be incorrect because the Elite radar uses a different viewing angle. Instead, the z-buffer approach guarantees that the ordering is correct regardless of what kinds of radars we may construe.
Perhaps elite could use z-buffer and not other radar types. Just consider the possibility, and lets not dwell on the issue any longer.
PS: don't leave the glFinish call there, only use it to profile, it's deprecated by almost every hardware vendor since it hinders parallelism and creates contention between the CPU and the GPU.
-
- Bounty Hunter
- Posts: 152
- Joined: Thu Sep 02, 2010 8:00 pm
Re: Elite radar
I am almost done with the radars now. I only have a little cleaning up and documentation to do.
The patch is over 4000 lines (not including data files). How would you like me to submit the patch? Here or in the bug tracker?
The patch is over 4000 lines (not including data files). How would you like me to submit the patch? Here or in the bug tracker?
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Elite radar
Bug tracker would be best. But, why so long? Was the previous patch this long?
Such a long patch will be hard to review.
Such a long patch will be hard to review.
-
- Bounty Hunter
- Posts: 152
- Joined: Thu Sep 02, 2010 8:00 pm
Re: Elite radar
After having spent a lot of my sparetime trying to improve VS, this comes as a surprising and very discouraging question.klauss wrote:Bug tracker would be best. But, why so long? Was the previous patch this long?
Such a long patch will be hard to review.
The primary question why the patch has become this long is because my previous patch was not accepted, so this patch includes the changes you asked for. Furthermore, the previous patch was an intermediate patch, and since then I have integrated the radars into the Upgrades system, and I have continued to make improvements to the radars.
If you have a suggestion for a better way to handle this then I am all ears. I have set up my own git repository to mirror the VS svn repository, because it is very tedious to make bigger contributions to VS without commit privileges.
-
- Elite Mercenary
- Posts: 1329
- Joined: Thu Mar 27, 2003 11:51 pm
- Location: Manchester, UK
- Contact:
Re: Elite radar
I don't think klauss intended to be discouraging, even though he was a little unartful in the construction of the question.
I think the issue at hand, from his perspective, is that the VS codebase is complex so he doesn't want it getting more spaghetti-like, so I think your answer satisfies that somewhat because you are improving structure rather than adding to it.
I think the issue at hand, from his perspective, is that the VS codebase is complex so he doesn't want it getting more spaghetti-like, so I think your answer satisfies that somewhat because you are improving structure rather than adding to it.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
FreeGameDev forum - open source game development community