Elite radar

Talk among developers, and propose and discuss general development planning/tackling/etc... feature in this forum.
breese
Bounty Hunter
Bounty Hunter
Posts: 152
Joined: Thu Sep 02, 2010 8:00 pm

Elite radar

Post by breese »

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).
You do not have the required permissions to view the files attached to this post.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Elite radar

Post by klauss »

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.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
breese
Bounty Hunter
Bounty Hunter
Posts: 152
Joined: Thu Sep 02, 2010 8:00 pm

Re: Elite radar

Post by breese »

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"/>
You do not have the required permissions to view the files attached to this post.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Elite radar

Post by klauss »

Cool, I'll take a look when I have some time.

Feel free to bump the thread if somehow I forget ;)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
breese
Bounty Hunter
Bounty Hunter
Posts: 152
Joined: Thu Sep 02, 2010 8:00 pm

Re: Elite radar

Post by breese »

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).
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Elite radar

Post by klauss »

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 ;) )
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Elite radar

Post by klauss »

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 :)

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 :)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
breese
Bounty Hunter
Bounty Hunter
Posts: 152
Joined: Thu Sep 02, 2010 8:00 pm

Re: Elite radar

Post by breese »

Thanks for the constructive feedback. By and large I agree with your comments.
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.
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:CollectRadarBlips::aquire

You commented out AutoLanding. I didn't see a replacement in the patch... that feature should not be removed.
Agreed.

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.
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.
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.)

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.
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...
This is a very good suggestion.
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.
Agreed.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: Elite radar

Post by charlieg »

breese wrote:
klauss wrote:CollectRadarBlips::aquire

You commented out AutoLanding. I didn't see a replacement in the patch... that feature should not be removed.
Agreed.

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.
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.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Elite radar

Post by klauss »

breese wrote:
klauss wrote:RADARLIM::IffType
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.
Seems like an adequate compromise.
breese wrote:
klauss wrote:CollectRadarBlips::aquire

You commented out AutoLanding. I didn't see a replacement in the patch... that feature should not be removed.
Agreed.

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.
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.
breese wrote:
klauss wrote:SortingOrder

You're using <functional> without a real need.
I can easily remove it. In fact, I have eliminated sorting completely in my current code (OpenGL handles it for me.)
How? Depth offset perhaps?
breese wrote:This comment brings up another issue. How old compilers is VS intended to support?
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.

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.
breese wrote:And while we are on the topic, our boost version is really old. Maybe it is time to upgrade.
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.

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.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
breese
Bounty Hunter
Bounty Hunter
Posts: 152
Joined: Thu Sep 02, 2010 8:00 pm

Re: Elite radar

Post by breese »

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.
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: How? Depth offset perhaps?
Yes, but with a twist.

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.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Elite radar

Post by klauss »

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)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Rattan
Merchant
Merchant
Posts: 56
Joined: Sat Jul 18, 2009 5:35 pm

Re: Elite radar

Post by Rattan »

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
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Elite radar

Post by klauss »

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.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Rattan
Merchant
Merchant
Posts: 56
Joined: Sat Jul 18, 2009 5:35 pm

Re: Elite radar

Post by Rattan »

Good points!

Though trying to imagine the technology of 3,000 yrs in the future is pretty wild to do anyway. :wink:
breese
Bounty Hunter
Bounty Hunter
Posts: 152
Joined: Thu Sep 02, 2010 8:00 pm

Re: Elite radar

Post by breese »

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 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.

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.
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)
Yes, I was aware that this was a requested feature, and it was indeed an improvement over the previous arbitrary "sorting."

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.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Elite radar

Post by klauss »

breese wrote:
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 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.
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.

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.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
breese
Bounty Hunter
Bounty Hunter
Posts: 152
Joined: Thu Sep 02, 2010 8:00 pm

Re: Elite radar

Post by breese »

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.
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: 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.
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.

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.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Elite radar

Post by klauss »

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.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
breese
Bounty Hunter
Bounty Hunter
Posts: 152
Joined: Thu Sep 02, 2010 8:00 pm

Re: Elite radar

Post by breese »

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.
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: 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.
As sorting times, whether we use std::sort or z-buffer, are negible, I fail to understand why we are having this discussion.

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.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Elite radar

Post by klauss »

breese wrote:As sorting times, whether we use std::sort or z-buffer, are negible, I fail to understand why we are having this discussion.
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 nonsensical ;)
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.
Now that is a far stronger point in z-buffer's favor.

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.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
breese
Bounty Hunter
Bounty Hunter
Posts: 152
Joined: Thu Sep 02, 2010 8:00 pm

Re: Elite radar

Post by breese »

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?
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Elite radar

Post by klauss »

Bug tracker would be best. But, why so long? Was the previous patch this long?
Such a long patch will be hard to review.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
breese
Bounty Hunter
Bounty Hunter
Posts: 152
Joined: Thu Sep 02, 2010 8:00 pm

Re: Elite radar

Post by breese »

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.
After having spent a lot of my sparetime trying to improve VS, this comes as a surprising and very discouraging question.

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.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: Elite radar

Post by charlieg »

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.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
Post Reply