OpenXcom Forum
OpenXcom => Suggestions => Topic started by: hellblade on October 20, 2011, 07:46:23 am
-
The lack of visuals to show radar coverage probably has bugged alot of you. (One of my friends went as far as mapping out his game radar coverage on a real world globes, using ruler, compass, and radar range data, to plan his 8 base locations.)
So I suggest something along these lines:
1) Add 3 circles centered on the mouse during "place your base" so we can see what it covers. The 3 circles are small,large,hyper-decoder of course.
2) Add a toggle button on geoscape to show what current radar coverage is.
And IF anybody has the time to write the programming, then maybe make the coverage area colour/colour-shade coded to show probability of detection.
-
it's not that easy.
1. color shade/hueing is nearly impossible in 8bit mode (contour line sound more real).
2. detection work in lang/lat terms, so projected area (distance) is not really a circle (shrinked near pole).
3. there are lot of complicated maths for drawing any circles on a sphere (specially distorted), and it will eat noticable amout of CPU time.
4. this radar visualizing in "mouse hover" mode will be additional performance eater.
Though I tend to agree with need of something like that.
-
3. there are lot of complicated maths for drawing any circles on a sphere (specially distorted), and it will eat noticable amout of CPU time.
nope, i could draw 32 circles for shadow on globe without big difference to current shading method.
trick is to compute very big table with hight of sphere (similar to that you want draw flat circle but you dont write color but hight of that sphere to table)
2. detection work in lang/lat terms, so projected area (distance) is not really a circle (shrinked near pole).
only this is problem in my approach, because i will get real circles
i think it could be new color scheme for this, you switch to radar mode and you see only shape of lands and radar ranges (black & green colors only used like in real radars displays)
-
2D circles is not the case. Forget them. They will work only for locations at the center of the viewscreen. All others will look like inclined ellipses (probably partly hidden, if went hidden side of globe).
I've looked at xcom code, and found how they calculating detection. ShortRange=500, LongRange=750, Hyperwave=800, XCom Craft=200 (yeah it has its own detection range). Detection probability depends on ufo size and altitude and number of radars of same type (yeah number of radars actually affect on probability, as they say in ufo user manual - each radar makes full scan every 5 minutes, so increasing number of radars will increase detection capability of base). Units of distance are direct 3D distance between 3d coordinates (sqrt(x*x+y*y+z*z)). Earth diameter is 2048 units. So one hemisphere is covered by range of 1448. It's like, borderline of such radar is a intersection circle between earth globe and detection 3d __sphere__ of base/craft.
And by the way, UFOs are detected only every 30 minutes.
-
2D circles is not the case. Forget them. They will work only for locations at the center of the viewscreen. All others will look like inclined ellipses (probably partly hidden, if went hidden side of globe).
I've looked at xcom code, and found how they calculating detection. ShortRange=500, LongRange=750, Hyperwave=800, XCom Craft=200 (yeah it has its own detection range). Detection probability depends on ufo size and altitude and number of radars of same type (yeah number of radars actually affect on probability, as they say in ufo user manual - each radar makes full scan every 5 minutes, so increasing number of radars will increase detection capability of base). Units of distance are direct 3D distance between 3d coordinates (sqrt(x*x+y*y+z*z)). Earth diameter is 2048 units. So one hemisphere is covered by range of 1448. It's like, borderline of such radar is a intersection circle between earth globe and detection 3d __sphere__ of base/craft.
And by the way, UFOs are detected only every 30 minutes.
i will get 2d circles ON globe not on screen :>
https://openxcom.org/forum/index.php/topic,150.msg2168.html#msg2168 i can have something similar to this shadow.
and this work base on on intersection between two spheres (that are stored as 2d array of hight, in case of this shadow i use 32 different intersections). from that you said now i can do it without problems (i only need find some time to do it).
-
How about this:
Yankes will attempt to make a proof of concept build/video, and if it's feasible then it would be implemented in OpenXCom in the "UFO Extender" category as an optional feature?
:D
-
Yankes, what do you mean by "hight"? :)
-
sorry, height (sh** i eat up letter again :/).
-
M-kay.
Radius of planet in game units is 1024 and diameter is 2048, with actual great circle length is 40009.88km, so radar ranges for different game entities are:
distance 200 (craft) = 1245.69km = 672.61nm (osg=600nm)
distance 500 (small) = 3141.01km = 1696.01nm (osg=1500nm)
distance 750 (large) = 4774.98km = 2578.29nm (osg=2250nm)
distance 800 (hyper) = 5110.91km = 2759.66nm (osg=2400nm)
https://www.ufopaedia.org/index.php?title=UFO_Detection
Differences between actual range numbers and observable (and listed in official strategy guide) are because of ufo always have some progress travelling undetected inside of radar range between 30min scans. But this isn't applied on UFO base detection (because they are static), and for slowly flying and ground UFOs.
-
i made some progress on my globe shading and drawing circles on sphere :)
i see some limitation in that approach, when i try draw small circle i get some glitch and i dont get circular shapes.
-
has anybody been looking into this some more? because I really liked the idea. it would be a nice way of making the geoscape more interesting.
-
After my globe shading was added to master branch, 90% things need to do it are in game now.
Only problem is some free time to do it :)
-
nice! except for the free time part. why does RL always have to get in the way of the important stuff? ::)
hmmm... another thing just crosses my mind... do you think it would be possible to add UFO flight path "traces" that fade over time?
-
I dont see any easy way to do it. Only solution that could work is to store somewhere previous position of craft, but this will require many changes to do it.
-
too bad :( I thought there might be an easy way.
-
I like the idea of the radar coverage. Even if it's just a single circle at the edge of the coverage.
The flight trails sound quite good too. Might be possible if you ditch the "fading", and just retain the last (n) long/lat locations, and instead of drawing the square indicator, just draw a single pixel. This will give you a "snake" like trail. If you use the game gradients, you could always just select it to a darker colour. Not quite fading, but should look pretty good
-
8 bit is not enough for all geoscape fancy radar circles over shading.
-
why not? I'm sure there is a nice green that could be used to draw a simple circle outline. it doesn't need to be shaded at all, since it's more of an overlay.
-
Sure, if you have infinite CPU speed, to calculate "hovered" and multiple sphere-projected circles, and don't mind of ugly aliased lines.
-
ah, now I see your point
-
a few thoughts on radar coverage:
looking at the code (although I'm not a programmer), I guess you could just re-use the country-border part of "Globe::drawDetail()" to draw the static radar circles around the bases. wouldn't that work?
as for drawing radar coverage of aircraft... I don't know. :)
there's another idea that comes to my mind: similar to the battlescape "fog-of-war", you could toggle the geoscape between two views: the standard view with shadow indicating the time of day, and the "tactical" view where "shadow" would indicate "no radar coverage" and all radars (including aircraft) would be considered "light sources" - although I guess that would be quite heavy on CPU load, right? multiple light sources? if the shading part was given to the GPU, you could even combine the two with radar being a light source of a different color.
-
Volutar only problem with radar circles is that game use circles on 2d space not 3d (possible Im wrong here, I didnt check that :>).
Small hack, I changed couple of lines in my globe shading, and I have alpha version of radar circle :)
If I use simplest solution I could draw 8 independent radars ranges and have around 40 FPS left.
-
Looks good to me :D
-
40fps for 320x200, and what about 640x400? Maximum 10fps. And where is day/night shade? And how to distinct one radar from another and from terminator line?
And where is screenshot for 8 different radars + day/night? I bet you don't even imagine how ugly it will be looking.
All I see is simple day/night shading with perverted size formulas.
There will be real mess with all these circles, if you try to go such way with 8bpp.
It will look much better if using hue+lighting shift, which is possible only for opengl.
8bpp radar ranges could be anyhow feasible only by drawing sectors of ellipses (as fake sphere sections). Though in this case ugly aliasing is unavoidable.
-
game is always in 320x200 in a sake of my algorithm, second now I run in 640x400 aka 40FPS in 640x400, in 1280x800 will probably take around 20FPS.
third I used only 20% of my CPU to draw it (I used new "slow" version of game :D).
And about look. This is terminator line, it would be hard for it, dont look like this :)
I need create new function that will be 100% dedicated for drawing radars, it would have some tweaks to work faster and look completely different.
Ad as moriarty points out in another topic this will be new globe "mode" with different graphic set.
And about of aliasing, in my vision of this you will see only sum of radar coverage not independents radars (you can toggle them). This will made possible to use monochrome coloring of this and more smooth look.
-
640x400 have 4 times more pixels than 320x200. It doesn't matter how large scaled SDL window is, native SDL resolution only matter.
-
Volutar, I think you are right that in order to combine radar ranges and day/night shading, openGL would be the only feasible solution. But what Yankes is trying to achieve now is something different: A way to look at the geoscape globe where you can actually see your radar coverage. It would be a different globe drawing style that you can toggle somewhere, which shows you the radar circles instead of the day/night shading. It's probably the best we can do for now, and I think it would be nice (and sometimes, really helpful).
Maybe this could be something that would automatically toggle when you are placing a new base: you could immediately see where you should put it in order to get the best land mass radar coverage. That would make sense, wouldn't it? I distinctly remember cutting paper circles and shifting them around on a plastic globe in my room to determine the optimal base placement :) back in the days...
-
Toggling between day/night and radar cover.. seems to be plausible. Though you need to have a distinction between currently selected base and combined others, that would require 3 levels.
And BTW, currently OXC doesn't have such thing as "selected base" in globe view, only in base view.
-
moved form "High-Res Graphics"
640x400 have 4 times more pixels than 320x200. It doesn't matter how large scaled SDL window is, native SDL resolution only matter.
Ok I get what you mean then. Right, when I increase basic resolution to 640x400 I need 4 times more CPU time to draw this, but still this will take around 30FPS on my CPU (100% usage). This is all in case of simplest solution that is drawing it 8 times independently for every radar and every frame. But as radars dont move I need redraw them only one time per "view", this mean I can archive even 100 FPS @ 640x400 when I dont rotate globe.
-
Volutar I moved with discussion to
(we should really move this discussion to that other thread (https://openxcom.org/forum/index.php/topic,322.0.html), since this one used to be about High-Res Graphics.)
-
Do you see a possibility to show dynamic radar ranges when placing a new base?
as in: showing the actual radar range of the existing base(s), but also showing the circle(s) around the cursor while considering where to put the new base? (for starters, I guess having one circle showing the range of a Large Radar would be enough - of course it would be nice to have one circle for Small Radar, one for Large Radar and one for Hyperwave Decoder, which only shows up once the technology is available...)
-
I've moved messages from high res graphic topic to this topic.
-
thank you, michal.
Yankes, how much effort is it to draw a circle on the globe? just a circular line, 1 pixel wide, no shading or anything?
-
right now I have tech to draw disc, trying to draw thin circle will take similar time like drawing full disc. To try using it do draw small lines is ineffective.
drawing dynamically new radar position will not be a big problem.
-
oh, okay. disc is fine, then :)
I think the least game-changing implementation would be to display the radar range for a large radar around the cursor as well as around existing bases when placing a new base.
The next thing would be implementing it as a toggled alternative geoscape view. that is a bigger change from the original, but I think many people would like it.
Yankes, is it possible to label the radar border? that is, display "Large Radar Range" or "Small Radar Range" or "Hyperwave Decoder Range" at the northernmost part of the radar-range disc?
-
Yankes, is it possible to label the radar border? that is, display "Large Radar Range" or "Small Radar Range" or "Hyperwave Decoder Range" at the northernmost part of the radar-range disc?
Surely it'd just be better, and easier to use 3 different colours
-
better for us veterans, yes... but what about new players?
-
better for us veterans, yes... but what about new players?
Maybe have a geoscape toggle which removes the day/night on the oceans (but leave the land), and instead draw radar boundaries - 1 colour per base. That way it doesn't interfere constantly, but you can see when placing new bases.
Also, you'd only really need to see the "maximum" radar range, no? So wouldn't really need to differentiate the three types
-
I thought about showing the "projected" radar ranges when placing a new base. your cursor would have rings around it that indicate your possible radar coverage if the base was placed at the cursor's location. for that, you would need two (or later three) rings for the radar ranges of the different facilities.
-
Yankes doesn't try to draw circles, he simply modifies his shading which totally re-renders whole globe. And I was saying about colored lines drawn over globe, like borders between countries. There is already "tab" button which toggles border view, and we could add some other button for toggling radar circles.
Personally I'm against toggling between day-night and radars, because when watching UFOs flying through radar coverage zones, you just leave night/day line out of control. Specially when chasing ufo craft for some reason in background.
And actully this is unnecessary to get into full rerender just because of radar ranges. It would be a waste of resources.
-
Since showing radar ranges doesn't affect gameplay (it doesn't change the "difficulty") and since it would be awesome (and probably toggleable, too), there's no reason to NOT have it (if you have enought time and enthusiasm to programm it and if it doesn't affect performance too much).
Personally I'd prefer a simple line-ellipse (without shading) showing the actual "vision range" of a base. As for drawing the three ranges while placing a base - I think that that's not necessary. You can save the game before placing a base, then you place it, build a radar (it should probably show the range even if theres a radar in construction) and if you are not satisfied, you can just load it. It would be better to see it while placing the base but as I read drawing the circles at cursor could eat way too much cpu time.
-
you know what would actually be nice? wouldn't it be possible to have a toggleable "information layer"?
what I mean is literally another layer: instead of putting stuff like radar range or UFO flight paths onto the globe with shading and everything, you would draw it on an invisible (hemi)sphere with a radius of (geoscape earth radius + 1).
this second sphere could be used for a whole lot more: all of the content of "Graphs" could be visualized (coloring regions by alien activity, funding change etc.). most of the already existing functions for calculating stuff on the geoscape could be recycled, but since it's not shaded, it wouldn't use that much CPU time, and you wouldn't have to re-calculate the globe every time you toggle a display overlay. it would be like augmented reality goggles for the semi-realistic geoscape globe.
would that work? or am I misunderstanding some basic principle?
-
you know what would actually be nice? wouldn't it be possible to have a toggleable "information layer"?
what I mean is literally another layer: instead of putting stuff like radar range or UFO flight paths onto the globe with shading and everything, you would draw it on an invisible (hemi)sphere with a radius of (geoscape earth radius + 1).
this second sphere could be used for a whole lot more: all of the content of "Graphs" could be visualized (coloring regions by alien activity, funding change etc.). most of the already existing functions for calculating stuff on the geoscape could be recycled, but since it's not shaded, it wouldn't use that much CPU time, and you wouldn't have to re-calculate the globe every time you toggle a display overlay. it would be like augmented reality goggles for the semi-realistic geoscape globe.
would that work? or am I misunderstanding some basic principle?
One thing, we dont have transparency. Second layer will completely hide every thing under.
To show graphs on globe simpler will be to replace land textures. We will need add new one that will be used for graph data.
OXC could in future store more accurate data, not only for continents but for regions too (UFO activity). Only problem with this will be lot of more information that current is available in game, it will simplify a bit looking for alien bases.
-
One thing, we dont have transparency. Second layer will completely hide every thing under.
Maybe just make it an alternative world rendering then.
To show graphs on globe simpler will be to replace land textures. We will need add new one that will be used for graph data.
That sounds pretty good
OXC could in future store more accurate data, not only for continents but for regions too (UFO activity). Only problem with this will be lot of more information that current is available in game, it will simplify a bit looking for alien bases.
Make it scale on the game difficulty level. If the player selected one of the beginner levels, show them the most granular (per region) activity; with the hardest getting continent (because that's available to them in the original).
I think it'd look good, and probably use it more than the graphs, where sometimes it's quite difficult to distinguish all the lines and you have to keep flicking them on and off.
-
oh, no transparency? bummer. how hard is that to implement, though?
-
There is only 100% transparency in 8bit mode (not to draw)
Though, as StarCraft was using number of 8x8bit LUTs of color blending for different transparency levels. But this is rude hack for 8bit mode, I don't think it worth it considering going into 24bit.
-
??? Wait, is there no transparency or is there no partial transparency?
Because basic transparency is really all we need for now. Like I suggested, an additional transparent hemisphere upon which circles (not discs!) can be drawn. And lines for UFO flight paths, if you want.
-
There is no transparancy in 8bit mode. There is only option not to draw something. Is it transparency anyhow? I doubt.
-
??? Wait, is there no transparency or is there no partial transparency?
There's no "alpha blending". ie, you can't get a cyan pixel from a blue pixel by drawing a semi-transparent green pixel.
What actually exists isn't really transparancy. It's basically a single chosen colour from the palette (usually pink) is just not drawn. Allowing you to retain the background when drawing non-rectangular sprites.
Hope that helps clarify how it works.
If might be interesting to add a lookup table of prealpha'd values (ie, palette index A + palette index B = palette index C). It would be a 64KB table. Though it would certainly complicate any painting routines
-
pmprog, yeah, it's what I've mentioned. There could be number of such tables for different transparency values (like 25%,50%,75%).
Actually we may use this for ellipse drawing - it won't get much cpu since it's only lines, not areas.
But I'd prefer to wait until openxcom go opengl with 24bit to have maximum of what we want, without palette perversions.
-
Right, I know about the indexed palette System, with color 0 being not drawn, from working with the soldier and weapon sprites. (It's not necessarily pink, being an indexed Palette system - it's often drawn pink so it's easily distinguishable, but it's really just "color 0", the palette dictates what it will look like )
So again, why not make an overlay sphere? It appears to be easy to implement and will suffice for now, and can be easily adapted to an alpha blend version later.
EDIT: I've added a mockup picture of what I think it could look like.
-
As far as I know they've intended not to accumulate ranges when using multiple radars (this is physically imposible), but increasing detection rate, so one radar detects craft once in 30 minutes, and if alien craft have passed by detection zone between radar waves, it won't be detected. So second radar will make them detectable twice probable (like each 15 minutes), 3rd radar - each 10 minutes, and 4th radar - 7.5 minutes.
-
What actually exists isn't really transparancy. It's basically a single chosen colour from the palette (usually pink) is just not drawn. Allowing you to retain the background when drawing non-rectangular sprites.
I think that it's what we want. And it actually is transparency. AFAIK semi-transparent things (which use alpha blending to draw) are called translucent. And since we need just a solid (non-transparent) line(s) to draw the radar ranges, it shouldn't be really hard to make.
EDIT: I've added a mockup picture of what I think it could look like.
Yes, that's exactly what I thought of :)
-
If might be interesting to add a lookup table of prealpha'd values (ie, palette index A + palette index B = palette index C). It would be a 64KB table. Though it would certainly complicate any painting routines
That will be impossible, because lack of colors in 8bits. When I try mix Red + Yellow but not have any Orange color in palette? What color I should use instead?
Only thing that is possible to mix is brightens of colors. I used it once to create transparent units in Battlescape.
-
Yankes, have you saw Starcraft1 ? they've been using 8bit paletted mode and they've managed to get somekind of semitransparent things.
These LUT tables could be pre-calculated after game started, automatically, to be used to pick _approximated_ color from palette.
can be easily adapted to an alpha blend version later.
moriarty, don't you think to have lines and ellipses drawn over globe in OpenGL as primitives?
-
moriarty, don't you think to have lines and ellipses drawn over globe in OpenGL as primitives?
I'm not sure I understand what you mean.
What I meant is that right now we can simply draw circles and it will look alright. As soon as we have 24bit opengl rendering, we turn the circles into semi-transparent (or "translucent") discs, possibly even with a rotating radial line like the old radar screens in the movies use. The rotation speed could even indicate the detection probability.
My point is, both could be done by adding a second "layer", a slightly bigger transparent sphere that can be toggled.
-
Indeed Volutar, SC1 use 256 colors. I toughs that its use 16bit palette, but after looking on screenshot, I find that its use 8bit.
But still, I say that in OXC is hard to archive similar effects. XC palette was designed to allow easy & realistic shading. We have 16 colors with 16 dark values (with some exceptions). SC1 have lot of more unique colors. I can guess that if you take 2 random colors form SC1 palette and mix them, then you can find color very close it in that palette.
btw, I made another test in experimental radar ranges :) (2 first are fail tests)
-
Yankes, looking at your screenshots I think you've gone wrong way. Why do you rerender __whole__ globe screen just because of 1 pixel thick ellipse overlay? That's unreasonable.
-
That is true :) but my goal isnt to draw 1pixel thick ellipse. I want to draw interior in special way too, maybe something like frog of war? If I do it in correct way, I could still show day/night cycles.
Another think that I can do is merge two radar fields to one field with one border.
-
Good job Yankes with the mixing. That's a nice effect and I was hoping that someone can achieve that.
But still - how will it look like with the day/night cycle (if it even can work together)?
Also I live the "void" on the second screenshot in #56 (https://openxcom.org/forum/index.php/topic,322.msg4507.html#msg4507)
Can you please try to render 1px wide circle? I'm interested in how that would look like.
-
Joining these ellipses could also be done less CPU consuming way.
But anyway I belive this feature is not that necessary to spend such CPU and human resources on "temporary" version.
-
Geez guys, are you really sure it's worth all this effort and resources just to draw radar ranges? :o
I mean, radar ranges aren't even that accurate given detection isn't deterministic. If it was me, I would just draw some lines around bases with little code and CPU cost, seems to be clear enough.
-
This probably will not end up in master branch, but I will still try :D
-
Volutar, I agree that it sounds like too much effort, but I consider this the defining part of openxcom: we can try to implement small changes that make the game a little bit nicer.
I don't want higher resolution graphics, for example, but I'd like to see perhaps some additional armor types and weapons. Or armed civilians. Stuff that doesn't change the game completely, but still improves it.
I think that radar ranges on the geoscape is not that important, but it's kind of symbolic: a few people think that it would be nice, and now we want to do it to prove that openxcom is just that little bit better than the original.
I guess you should just leave us to it, and once we're finished, post it on the main page as an example of what the ox engine is capable of :
-
Volutar, I agree that it sounds like too much effort, but I consider this the defining part of openxcom: we can try to implement small changes that make the game a little bit nicer.
That's exactly how I see it too. Actually, there are already some improvements (like infinite number of saves).
-
SupSuper's screenshot is pretty much what I was thinking in this whole thing; Though Yankes' looks pretty cool.
I'd like to see perhaps some additional armor types and weapons.
TBH, I would like to see some armour available at the start too. I find it odd that you'd have a combat-based association that doesn't have a single type of armour. I did like XCOM:Apoc for that reason (also the mixing and matching of armour, though I don't know how necessary that was). But this is for a seperate topic
-
TBH, I would like to see some armour available at the start too. I find it odd that you'd have a combat-based association that doesn't have a single type of armour. I did like XCOM:Apoc for that reason (also the mixing and matching of armour, though I don't know how necessary that was). But this is for a seperate topic
https://openxcom.org/forum/index.php/topic,511.0.html (https://openxcom.org/forum/index.php/topic,511.0.html) :D
-
The thing is, rendering circles as lines could cause number of small visual uglinesses, when circle is devided by number of linear sectors, which coordinates are rounded. Though there are ways to make them smaller, but it requres drawing them pixel-by-pixel (in order to implement floating-point version of drawline).
That's another reason of not trying to do that before 1.0+OpenGL.
-
but I don't want to wait until v1.0+ ! :'( :'( :'(
sorry.
no, seriously, if it's at all feasible without having to write several pages of code (and I assume that it's really not that hard, since there are already several functions that calculate circular things, and also functions for drawing lines as far as I've seen), I'd say let's try it and see how it looks. of course it will be prettier in openGL. but I think it will be o.k. with 8bit graphics as well.
-
OKay, but what about multiplying ranges of multiple radars? Isn't it illogical?
-
multiplying ranges of multiple radars is highly illogical. who brought that up, anyway? did I? if yes, I never meant it. :-[
of course, building additional radars only increases detection chance, not range.
-
So multiple radars increases detection chance, and how it will be shown? Let's imagine radar circles already there, but how "power" of these radars will be shown? like colored dots near base itself?
-
So multiple radars increases detection chance, and how it will be shown? Let's imagine radar circles already there, but how "power" of these radars will be shown? like colored dots near base itself?
We don't need that, do we? I think that the range is most important.
-
Well range border doesn't mean any alien craft crossed it will be immideately detected, it can even pass through whole radar range withoug being detected, so I suppose power of radars is quite important.
-
I'm not sure we need to show it at all... for me it would be enough to see the area that is covered (even if it doesn't mean that all UFO's are detected within).
if we do want to include a visual cue, how about putting those palette-based gradients to use and making the line pulsate? start with the highest saturation, then decrease saturation step by step over time. if I understood correctly, the detection is checked against a fixed probability every x minutes, with x decreased by additional radar facilities? if so, make one pulsation every x minutes, and you have a direct visual representation.
it gets complicated when you are mixing small and large radar facilities, though... perhaps draw one circle for each type of installation, to give a direct representation of the different areas of detection probability?
-
hmmm, that was a bit complicated, and I based it on faulty assumptions.
I just read in GeoscapeState.cpp that UFO detection happens every 30 game minutes, and the chance is increased by adding radar installations. hmm. in that case, I don't really know how to handle the detection chance visualization. perhaps we should just leave that out until openGL is implemented. :)
unless of course we want to change a game mechanic at that level, and have additional radars increase the detection frequency instead of the chance... :-X
-
That's interesting. What about detection from craft? Is that only every 30 minutes? If so, that adds a whole new dimension to sending crafts for patrol than I ever thought about before
-
as far as I have seen, the game goes into the loop to check for UFO detection every 30 game-minutes. the loop takes every UFO currently flying around, checks first to see whether it is within the range of any radar facility, then checks whether the radar facility is completed, then goes ahead and generates a random number between 1 and 100 and compares that against the facility's detection chance.
so for a base with two large radars, a UFO within the range is simply checked twice for detection: once for each facility.
for craft, UFOs inside the craft's radar range are detected. no probability involved.
did I get that right? I think I did.
see for yourself (https://github.com/SupSuper/OpenXcom/blob/master/src/Geoscape/GeoscapeState.cpp). line 615 to 671
-
moriarty, not only crafts, but alien bases too. Though I haven't looked what mechanics lies behind base detection.
pmprog, craft patrolling was one of most frequently used things while I was playing, for the sake of alien base detections, specially in early stages and over uncovered areas. :P
-
ah, okay. right, alien bases, I totally forgot about them :)
I think the "one check every 30 minutes" is kind of overly simplified, though... just imagine: an interceptor can fly immediately next to an UFO for almost half an hour and never see it, because it came into his radar range after the last check and flew away before the next one.
I think that's not what we want, is it? It might be how it was done in the original, but perhaps only for lack of a better way, because this way saves some CPU time.
I would like to suggest changing the mechanic for craft radar to more frequent but less reliable checks. perhaps every 5 minutes with a chance of 25 percent?
(btw, what's the radar range of aircraft? is it the same for every craft?)
I would also like to suggest changing the mechanic for base radar to "more radar facilities shorten detection intervals" instead of "each radar gets its own check".
I know this changes a more-or-less fundamental game mechanic, but really, in this case the original mechanics suck big time :P
-
new test with radar visualization.
-
So is this for ingame? or just when placing a new base? Are you going to show 3 purple borders (one for each radar type) for the latter?
To me the shading is the wrong way around; I would have expected the covered area to be shaded, with the rest of the world still drawn normally. Suppose it doesn't really matter either way though, as it's still useful.
Good work.
-
I've made simple function which draws circles as line segments with floating point coordinates, in order to make less "jagged" and more precise though aliased figures (you can notify those circles aren't symmetrical). These circles could be drawn as projected to the sphere surface with some segments hidden (if they gone to other side).
Segments drawn with different colours to notify "non regular" nature of these lines.
These lines drawn in software, "pixel-by-pixel" manner (because there is no other way).
-
Yankes, you can try to make "highlight" area for radar cover. I mean literally, make this "combined" zone with maximum brightness (short range), maximum-1 for large radars, and everything else shift 3-4 brightness level lower. So day/night will be visible, and radar coverage too. Radar zones must have "hard" edges.
-
this has been suggested already:
https://openxcom.org/forum/index.php/topic,67.0.html
# In the geoscape, radar type and range could be shown as colored rings around bases. This would give a much better indication of in which areas the player should not expect to detect UFOs.
I have to admit, that was already 2 years ago, but it's too bad the suggestion threads of bramcor got lost in the "archives", he was a professional game designer, and still had the best and most complete lists of idea's to improve xcom I have ever seen on this forum. Although never got any replies in those days... and now people just re-post one of his ideas and everyone goes crazy :p
(however, no offense hellblade, it's still a good idea and maybe just deserved a seperate thread)
his other threads, in case you are interested:
Ideas for improving base usability:
https://openxcom.org/forum/index.php/topic,68.0.html
Ideas for improving research & development usability:
https://openxcom.org/forum/index.php/topic,69.0.html
Ideas for improving xcom craft usability:
https://openxcom.org/forum/index.php/topic,70.0.html
Ideas for soldier usability:
https://openxcom.org/forum/index.php/topic,71.0.html
-
Volutar, something like this?
-
Yes but might be with less contrast and not centered (to get better picture).
-
Next step in radar shader :D
I bit overestimated CPU power need to draw it. right now I can draw 20 independent radars at once without any big performance drop (without any optimization).
-
I bit overestimated CPU power need to draw it. right now I can draw 20 independent radars at once without any big performance drop (without any optimization).
I thought that from the beginning :P
Good job, it looks nice. How's it done? Is it another "layer" or is it drawn "directly on the surface"? Would it be possible to mix the border color? This can be confusing - it can be mixed with the night shadow.
-
It looks to me radars on the night side are too bright.. I thought it should add couple of bright levels that's all. BTW, what those inbetween contour lines doing? I thought there should be no such lines or both of them (from each overlapped circle).
And BTW, the maximum number of radars is 16 (including short and large).
-
line that you can see is leftover after my try to made borders a bit more smooth. It because I draw only first radar that have range there, right now this solution work more like Frog of War, every radar range is equal.
I only count 8 bases now, rest can be used for crafts :)
Good job, it looks nice. How's it done? Is it another "layer" or is it drawn "directly on the surface"? Would it be possible to mix the border color? This can be confusing - it can be mixed with the night shadow.
This is brutal force solution :D To lightning function I send position of radars in vector. then for every pixel I check if this pixel is in range with any of radars in list.
If is then I draw normal lighting divided by 2 in power, else I add 16 "shadow" value to made it darker. When I will be closer to release it I will tweak a bit this values to made it look better.
-
This is brutal force solution :D To lightning function I send position of radars in vector. then for every pixel I check if this pixel is in range with any of radars in list.
If is then I draw normal lighting divided by 2 in power, else I add 16 "shadow" value to made it darker. When I will be closer to release it I will tweak a bit this values to made it look better.
Well that's awful :D there should definetly be something that can improve performance - even if it can't be seen, it's an expensive solution. Maybe add caching? You can save a "map" of all "radared" and "non-radared" pixels and use that to draw the radars; this map could then update only when you build/destroy a base. As for crafts, I think that their radar could be just a 1-pixel colored circle. I think that that would simplify it a lot.
-
Maybe add caching? You can save a "map" of all "radared" and "non-radared" pixels and use that to draw the radars; this map could then update only when you build/destroy a base. As for crafts, I think that their radar could be just a 1-pixel colored circle. I think that that would simplify it a lot.
Although this is a feasible solution but not perfect. You will not see the actual position of the flying UFO.
-
As for me - I'd better stick to 3d circles 1px thick instead of shading.
-
As for me - I'd better stick to 3d circles 1px thick instead of shading.
I agree, shading looks fancy but I like the simple clean look of just 1px circles, keeps the globe clutter-free.
-
Well that's awful :D there should definetly be something that can improve performance - even if it can't be seen, it's an expensive solution. Maybe add caching? You can save a "map" of all "radared" and "non-radared" pixels and use that to draw the radars; this map could then update only when you build/destroy a base. As for crafts, I think that their radar could be just a 1-pixel colored circle. I think that that would simplify it a lot.
Optimization is pointless :) with 400 test "radars" and rotating globe I get 30 FPS and 50% CPU (1 core). Without rotating I get 200 FPS and 30% CPU (2GHz x2).
After this test I think that possible is do directional shading in Battlescape :D
-
Optimization is pointless :) with 400 test "radars" and rotating globe I get 30 FPS and 50% CPU (1 core). Without rotating I get 200 FPS and 30% CPU (2GHz x2).
After this test I think that possible is do directional shading in Battlescape :D
well, you still have the "other platform" users... they will be thankful for optimization. I could imagine playing openxcom on my phone or a tablet, and they don't have fancy processors.
:) optimization is never pointless :)
-
I will fancy reduce numbers of radars to 40 ;P
And second, this will probably end as mod, not part of master branch :)
Behold disco earthscape (because of small bug, when you rotate earth, radars move they position) :D
-
Please Yankes, get rid of those overlapping borders,
-
Looking good so far ;)
"After this test I think that possible is do directional shading in Battlescape :D" What?
-
I'm curious about "directional shading in battlescape" too... Directional shading is used in pencil-drawing, where you draw very thin lines, all in the same direction, very close together to create a certain shading effect.
-
Sorry for maybe very silly question but are you sure that there is no way to make detection ranges be shown this way?
-
Daiky, Yankes was joking... Directional shading will require "fire" tracing for each visible pixel, combined with voxels info. And I really doubt it possible even in 1fps mode.
Zharik1999, sure there is a way. Just nobody is really interested in. I've already made some tests in delphi with circle drawing (as lines with floating point coordinates). But concerning your screenshot - it's quite impossible currently, because currently it's 320x200 screen with hardware scale x2. Screenshot is made as some sort of overlay over it or 640x400 mode with all graphics scaled x2.
-
So, are there any results?
-
Please be more specific. I've already said - your screenshot is quite impossible, because there are TWO different resolutions used. Circle will be more "rough" (same resolution of 320x200).
My test results are fine:
(https://openxcom.org/forum/index.php?action=dlattach;topic=322.0;attach=2147)
But I never tried to draw them within openxcom.
PS: my draw function uses floating point, so some devices without fast FP arithmetics might become slow (though with Yankes' shading it will be waaaay slower).
-
These results looks fine. Can we somehow test them in openxcom?
-
Daiky, Yankes was joking... Directional shading will require "fire" tracing for each visible pixel, combined with voxels info. And I really doubt it possible even in 1fps mode.
I was serious :D Maybe I used wrong word to describe it. More accurate is probably Bump mapping :)
I mean shading that depend of position and direction of pixel compare to light source position.
My idea of this would be exactly like globe shading that is directional. It will ignore anything between light source and pixel. And will be impossible to made any
shadow on surfaces. Light range will be determined by current implementation of light spread (only done independent for every light source).
And about visual aspects of my work, I try find hard limits of my algorithm. Looks isnt important right now, when I will finishing it I will apply most of your suggestion to it :)
-
Yankes, where will you take 3d data of sprites from?
-
Yes, this is one of problems :D This probably need some hand work, but nothing more complicated than drawing that sprites.
Simplest solution can be drawing "depth buffer" of sprites and for that try create normals. This will have some glitch probaby but because low resolution it will be hard to see :)
-
Sorry for maybe very silly question but are you sure that there is no way to make detection ranges be shown this way?
I already did the "radar ranges as just thin lines" approach earlier, if people missed it:
(https://openxcom.org/forum/index.php?action=dlattach;topic=322.0;attach=2105;image)
If you mean something else, I don't know, this thread already seems to have every possible implementation you could ask for. :P
-
SupSuper, I see you haven't correct circles, they seems to be distorted because those circles are in "lat/lon" terms, not actual sphere circles. Considering this you wouldn't get any circle at all when try to put your base near the pole :)
And integer lines looks jagged (better to write floating-point lines drawing function).
Have you implemented this already in openxcom code, or it's just a "5min test without commit"?
-
SupSuper, I see you haven't correct circles, they seems to be distorted because those circles are in "lat/lon" terms, not actual sphere circles. Considering this you wouldn't get any circle at all when try to put your base near the pole :)
And integer lines looks jagged (better to write floating-point lines drawing function).
Have you implemented this already in openxcom code, or it's just a "5min test without commit"?
Yeah I know about the crappy circles (they only have 16 points), it was just a crude 5min test to prove it could be done before everyone went crazy with it, but I was too late. :P
-
SupSuper, I was thinking about real, 3d projected circle drawing (I already have pixe-by-pixel floating point line drawing algorithm, so this is not an issue). And for the moment I have no IDEA how to do it:). There seems to be alot of trigonometry stuff like arccos if I try to do it that way. Though there is another way - by simple ellipse drawing, without actual projecting, just simulating circles of the sphere (but need of tweaking to hide parts of circles).
-
my globe radars matured to beta stage. give me lat&lon and I will draw circle there.
github.com/Yankes/OpenXcom/tree/GlobeRadar source code of this, if someone want try it.
right now I have 400 random circles with different radius for test (most of them are overlapping, this is good because if they would cover all globe this would run faster :D ).
-
Yankes, use circles with variable light level, that will look more "nice". (3 radar ranges per base also should be distinguishable)
-
I will made some test, and after that I can try do it as you want.
-
Yankes, it looks very nice. Is it possible to mix the color? So day/night cycle would be better distinguishible apart of the radars?
-
And this is my experiment for correct globe circles (not like SupSuper's).
It uses arcsin/arctan2 and number of sin/cos for sphere projection of each point of circle. Since those coordinates can be (and should be) cached for each base, it won't be a performance issue of anykind..
-
Voluta, your radar look the best. However, can we see the flying UFO if the radar range is cached?
-
hsbckb, only radar circle point coordinates are cached, they are just for visual. Detection work very simple way, by distance calculation.
The only radar circles which cannot be cached - xcom craft's radars. They are dynamically changing with each game frame. Though because they are smallest - they may require less points.
-
BTW, I've noticed, currently there's a mess with UFO detection process in OpenXCom.
- Range units are not the same as in original ufo (in 1/60 of degree I guess, nautical miles), small radar have 1500 units, and distance calculated by great circles, while in original ufo they are using value of 500 and distance is 3d distance between sphere_points in space (globe has diameter of 2048). But for small_radar (500 units of ufo1) this distance will be slighly less than 1700 nautical miles. Actually I can't get why we should use "geodesic" distance for ranges? 3D distance is much easier and faster to calculate, and moreover result is more accurate (as in original). At least every radar range in ruleset could be rearranged for getting same results. https://volutar.no-ip.org/radi.php?val=500 - my converter from xcom distances to real km/nm (you can pass any val, but maximum is 2048 which is 10800nm)
- probability formulas are totally wrong...
ship:
if dist<200 detect=true;
base:
if (dist<800 && hyperwave>0) detect=true;
else {
size = 15*(3-ufosize);
if (ufoalt=0) visibility=-30; https://ground
if (ufoalt=1) visibility=size-20; https://verylow
if (ufoalt=2) visibility=size-10; https://low
if (ufoalt=3) visibility=size; https://high
if (ufoalt=4) visibility=size-10; https://veryhigh
if (dist<750) radars=20*large_radars;
if (dist<500) radars=10*small_radars+20*large_radars;
detect = xc_RandMod(100) < (radars * (100 + visibility) / 100) );
}And detection should work for every base, not for every radar facility!
-
BTW, I've made my "experimental" circles showing real original xcom radar ranges. Like here:
(https://www.ufopaedia.org/images/5/57/Detection_and_tracking_ranges.png)
But I've got quite different results. I don't know where did they got their range values from? How 200 game distance units of radius became 750nm?.. and 800 became 2400?
https://www.ufopaedia.org/index.php?title=Talk:UFO_Detection
-
Volutar, your radar looks really nice. Plus I love your globe-with-grid-on-it... do you think we could include that as a toggled option? For NW toggled in the .ini, but later through an options screen?
I also agree that detection should be per-base, but how do you Account for multiple radars? Increase detection probability or increase detection frequency?
-
moriarty,
1. I doubt ocean grid will look anyhow nice on 320x200 :). Though radar circles will look jagged too (look at SupSuper's screenshot with large pixelated circles)
2. In original game they are increasing probability. I've sent "pseudocode" listing with this in msg#121 of this topic. Increasing detection frequency IMHO would be better option, though this is quite hard to implement just because we have to get probability values intact (which ain't known for the moment), while changing detection principles.
I'd prefer to have radar sweeping frequency increased while chances decreased (to keep overall probability value the same). I hate when all UFOs are detected at time XX:00 or XX:30, and ain't detected at all in-between.
-
the globe looks better in higher resolution :)
-
the globe looks better in higher resolution :)
So , how do we do that?
-
Easiest way - is to go into 640x400 while zooming all loaded graphics (in loader functions). And scaling all hardcoded coordinates. Everything except globe will stay the same, but we will get 4x performance drop. Software SDL is so software...
-
Maybe we need to switch to Unity, the game engine everyone seems to use these days. You can do isometric games with it :p
-
Daiky, but it won't be openxcom anymore... it will be totally different software :)
-
True. Sorry for going off-topic. But yeah, the globe really has not much pixels to create nice smooth circles at the moment.
That's maybe another good reason why you should be able to hide them, they are not very pretty to look at.
-
I was thinking of drawing radar circles as globe light modifier lines. Like, getting pixels from globe and changing its light level. In spite thick pixelated lines(for 320x200), they won't become visual obstacle.
But don't really know how to do this without getting light range shrinked. In order to have ability to change light level I need to have some levels reserved for that, so I need to stole them from normal light level range. That's not very good.
Other way - to set light level to fixed value, so day zones become brigther than radar line, and night zones - darker. But fixed light level mean clearing some of texture info. That's also not very good.
There is third way, though I'm not sure it will be nice. To have a copy of globe surface before day/night shade applied, and use this surface for drawing "semitransparent" circles.
Anyways, this could be a matter of further experiments after at least getting simple radar circles drawn with color:)
-
I made some test with my globe and I probably hit limit, even having 100FPS game feel laggy.
This are screenshot from this version, I made small mistaken that caused pushed ocean color to another one.
Right now I have still 400 circles, but now I dont stop after first "hit". Because of that circles can overlap.
-
Yankes: How is it possible that around 100FPS feels laggy? I doubt that your screen has greater refresh rate then 75Hz. Even "only" about 30FPS should be impossible to see - human eye sees about 25 "frames per second". So there has to be some great error with openxcom :/
-
BTW, in original xcom there's no need to show different ranged radar circles of one base, just because it doesn't matter - if you have 9 small radars and 1 large, overall detection rating will be about 9*10+1*20=100%, and only largest range used.
But in openxcom SupSuper decided to process radar sweeps per-facility, not per base. This most probably will impact on gameplay. And I'm not sure we should do that.
Having detection working on per facility base we need to show each radar, and their quantity... There could be 10 types of radars in some mod, and each of them could have different range, so 10 different circles will be shown around each base. That will make quite a mess.
1. Get rid of per-facility detection priniciple, and get back to original's (when only largest range is used), so largest radar range will be actual and real. But this is not quite realistic (in terms of real physics). - this will require one cached circle point array per base.
2. Show only largest range radar, and forget about lesser ones, paying no attention on detection chances "gradient" in this case. And probably give some notice on hidden zones of different detection chances. In this case visual radar circle would show less probable though largest zone. - this will also require one cached circle point array per base.
3. Show range circle of each radar. This might create visual mess if number of different radars used in single base. - this will require cached circle point array per facility.
4. Show no radar circles at all.
-
I'd go for #2. we don't really need more information on the geoscape than "this is the maximum range of your radar".
A different case would be placing a new base: for that, I'd go with #3: show the ranges of all detection facilities available at that point, so you can see where you will want to place your base for optimum radar coverage.
-
moriarty, what about totally different detection algorithm? Aren't we going to make the same as in original?
-
Okay, here it is.
Base in the NA has small radar, in the SA - large radar. All ranges are rear and actual (taken from rulesets). It draws only largest radar. Color is "random" :)
-
That's cool!
Volutar, can you show me some pictures for zoom in?
I want to see the line (part of the circle).
-
Currently it's a test, which calculates and draws circle by line segments on-the-fly each frame. It would be better if it use cached coordinates of circles.
And new placed bases of course should have all of radars drawn in hover mode, to adjust position and cover zones you need.
-
And new placed bases of course should have all of radars drawn in hover mode, to adjust position and cover zones you need.
So, the hover Mode work for all zoom levels of geoscape and this can really help me to select base location. Thanks for your testing and suggestion.
-
I have read the "this is a test" paragraph, but for the final version will the ranges be combined in one visual mass without the overlapping circles?
But then again, how will you know that you have all the earth covered? :)
-
is the radar range for the small radar truly that large? I never would have guessed. I like this visualization style - it's clean, simple, easily understandable, doesn't clutter the globe... now we just have to choose a color. 8)
-
moriarty, i need to write custom line function (working with float coordinates), and may try to draw this line semi-transparently.
-
Yankes: How is it possible that around 100FPS feels laggy? I doubt that your screen has greater refresh rate then 75Hz. Even "only" about 30FPS should be impossible to see - human eye sees about 25 "frames per second". So there has to be some great error with openxcom :/
Lag I saw was from mouse movements, is jump form place to place without smooth transition. Rest for graphic work fine.
-
Hello once again audience! :)
I've added my own line draw function which work with floating point coordinates, so "curved" things like ellipses and circles look quite smooth. And tried shade altering instead of color set. Notice - on the terminator line where lighting is "in-the-middle" circle may disappear.
Still no circle caching, butt toggling with "tab" with details.
-
Previous 4 screenshots was made with altering after shading, this one was made with altering before shading.
Notice radar line "inversion".
-
I LOVE this last one. the lines don't obscure anything, because they don't obliterate what's underneath. it's even more subtle, but very visible. when will we see this in an official build? :)
-
Slightly changed ocean/land level altering, to make it more subtle still noticable.
moriarty, in order to add this officialy, it need to get caching, and hover function when creating new base.
-
Looks awesome to me, good work
-
BTW, I've noticed, currently there's a mess with UFO detection process in OpenXCom.
- Range units are not the same as in original ufo (in 1/60 of degree I guess, nautical miles), small radar have 1500 units, and distance calculated by great circles, while in original ufo they are using value of 500 and distance is 3d distance between sphere_points in space (globe has diameter of 2048). But for small_radar (500 units of ufo1) this distance will be slighly less than 1700 nautical miles. Actually I can't get why we should use "geodesic" distance for ranges? 3D distance is much easier and faster to calculate, and moreover result is more accurate (as in original). At least every radar range in ruleset could be rearranged for getting same results. https://volutar.no-ip.org/radi.php?val=500 - my converter from xcom distances to real km/nm (you can pass any val, but maximum is 2048 which is 10800nm)
- probability formulas are totally wrong...
And detection should work for every base, not for every radar facility!
UFO detection is "a mess" because I had to write it only based on the few info available in Ufopaedia.org without any access to the original code, much like most of OpenXcom. :P (and most people can't tell the difference anyways). Geodesic distances and nautical miles are used only because they're readily available.
I would recommend posting a separate thread with all your findings on the original UFO detection algorithm so it can be fixed.
-
Slightly changed ocean/land level altering, to make it more subtle still noticable.
moriarty, in order to add this officialy, it need to get caching, and hover function when creating new base.
(https://who-is-awesome.com/who-is-awesome.jpg)
Can't wait to see it in an official build.
-
I would recommend posting a separate thread with all your findings on the original UFO detection algorithm so it can be fixed.
What for? I already posted all info on UFO detection. Game units could be converted to geodesic units (and btw radar range circle work in geodesic units, i.e. radians). No need to start separate topic in sake of info already posted. IMHO.
-
Does anybody know how practical to show borders between countries? I don't remember myself using those borders... IMHO they are too obstructive while useless.
-
I wouldn't know how to "use" the borders either, but I kind of expect them to be there... just to show me where the countries are. I always thought of it as a geography lesson ;)
seriously, I don't need them, but I like them. they also sometimes aid your orientation while zoomed-in.
-
Yeah they're just a nice little extra so you can tell the funding countries apart from the rest of the world.
What for? I already posted all info on UFO detection. Game units could be converted to geodesic units (and btw radar range circle work in geodesic units, i.e. radians). No need to start separate topic in sake of info already posted. IMHO.
I just like things tidy. :P Fine.
-
So plan is:
1. make FC (Fast Clipping) for my FP line;
2. add cache coord lists (lat/lon) for each base, and draw cached coords (smooth circles);
3. add immediate radar drawing for xcom crafts (less vertices in circles);
4. add multiple radar drawing when placing new base in "hover" mode (probably opaque and colored radars). The thing is - in mods there could be 10 types of radars and that will become a pain for this "feature".
-
Volutar how many radars can you draw using your method?
-
Yankes, I don't think there's a limit except for getting image too messy. The game can handle maximum 8 bases, each base can handle ..say 8 crafts... so 64 craft radars + 8 base radars.
Why are you asking?
-
Yankes, I don't think there's a limit except for getting image too messy. The game can handle maximum 8 bases, each base can handle ..say 8 crafts... so 64 craft radars + 8 base radars.
Why are you asking?
I think he asks for performance (and I'm curious too). What if you drew like 100 those radars? Will FPS drop dramatically?
Also is it possible to "add" those circles together so it makes one plane (if they are overlapping)? I think that someone actually already made this with the "shadowed" version of radar borders.
-
Amunak, what for 100 radars? Are you going to play with this mess on the screen? Or it's just a benchmarking curiosity?
200 radars (2 bases with 100 radars on each). Without line clipping and any optimizations.
Main flaw of "shadowed" version is that it obstructs earth lighting heavily and really can confuse. Same for multiple "circle" radars. I don't think it's a good option.
-
Amunak, what for 100 radars? Are you going to play with this mess on the screen? Or it's just a benchmarking curiosity?
200 radars (2 bases with 100 radars on each). Without line clipping and any optimizations.
Main flaw of "shadowed" version is that it obstructs earth lighting heavily and really can confuse. Same for multiple "circle" radars. I don't think it's a good option.
I think couple steps ahead :) If we have tech to draw circles on globe, what another thing we can use it for? Right now I thinking about my radar "tech" and it is any thing that my radars can do and yours cant :) (limit how many things you can draw is one of this)
If I will not find any niche for my solution I will stop working on it because we dont need two implementation of exactly same thing :)
-
Amunak, what for 100 radars? Are you going to play with this mess on the screen? Or it's just a benchmarking curiosity?
200 radars (2 bases with 100 radars on each). Without line clipping and any optimizations.
It's half of a benchmarking curiosity, but some day there can be mod (or something) that draws on globe a lot (and something that makes sense) so just to see if it'S possible.
Main flaw of "shadowed" version is that it obstructs earth lighting heavily and really can confuse. Same for multiple "circle" radars. I don't think it's a good option.
I didn't meant this; I meant "union" of the circles (see the attachment).
By the way, what's the blue number in the top left corner?
-
yankes, I like your shading visualization. for now, though, I think the simple circle thing is cleaner. and I'm sure we will find a good use for your shading skills :) I'm thinking of on-the-globe visualization of all that info in "Graphs": Alien Activity, XCOM Activity,... those would be perfect as a shading overlay. Have you ever played SimCity2000 and used the direct visualization of pollution or happiness on the map? kind of like that.
-
Amunak, 100 circles on the globe make no sense, not saying about 200. In any globe viewer.
I meant "union" of the circles (see the attachment).
This is not possible. I draw simple circles on the map. For "union" you'll have to ask Yankes, but I'm not sure if he can do 1px "outline", with any zoom level (which I believe is possible).
Blue number is just lighting value under cursor. Debug info.
-
If you were to go for shading visualisation, why not display actual radar scanning process? Like they do in the movies
https://encrypted-tbn3.gstatic.com/images?q=tbn:ANd9GcSAAFZV9hTrYklZb8wr1qI0j_6yv5lBQZ8AueJl5_SwvMWW7qAF
With a little colour difference it should look pretty decent :D (button to display radar ranges might actually help as well, or be it in options)
-
I guess that's what we'll be doing - once we have shading :P
all we have right now is limited color palettes, and some tricksy things to make brightness shifts that look like shading but aren't. :)
-
Great :D Well, the circles look actually best from the currently implemented methods. Having a button to disable them would make it perfect.
I am happy to do correct math for the geoscape btw, if you need any more of the correct traj. planning (no weird spiral bug that was in the original) or even hex-based geoscape :D (I think it is already hex based?)
-
I'm not one of the programmers, but I think the trajectories are already optimized. at least, they appear to be more 3D-shortest-distance than the original :)
hex-based geoscape? I don't think there is any kind of tiling involved, everything is truly 3D-coordinate based. or am I not getting what you are trying to say? ???
-
(https://images1.wikia.nocookie.net/__cb20110823212259/freeciv/images/f/f6/Screenshot.jpg)
Is what I meant :)
-
funny you should mention this... I ran across that program some time ago, and thought it would be a really nice basis for a "Master of Magic"-remake. but I don't really see where xcom would profit from a tile-based geoscape.
-
Not so much as to hex-based landscape, but more for the purposes of the tris visualisation. The original xcom had quite low poly and heavily triangulated meshes, with better quality closer to poles (i.e. usual sin/cos vertex distribution). But I am heavily derailing the topic right now, so I should stop :)
-
:)
take a look at this thread: https://openxcom.org/forum/index.php/topic,543.0.html
originating from this thread: https://openxcom.org/forum/index.php/topic,530.0.html
for now, we are bound by the original data structure, but we can increase the poly count due to having more computing power than "back in the days". I guess completely re-working the geoscape engine and data would be possible, though... in the future :) (for now we are happy it's working as it is)
-
This hex planet isnt hex, more accurate name is football planet or Fullerene planet.
And about Plan position indicator (aka green radar display with fading dots) it will be hard to made and slow to draw, at lest using my globe shading.
I dont see any other solution to made it work, trying draw them directly (drawing polygons or multiple line) will be even harder to do and lot of slower than my solution (only way to made it work is draw one circle and one line, but this will not have any "fading").
-
This scanning line will be useless and actually confusing, just because in [open]xcom globe objects being discovered each 30 minutes (at the same time on whole globe), not with those "sweeps". So they will mislead this process.
Or, you got to rewrite whole detection algorithm, to make those line work not only visually. And that will be quite a hard task. And quite meaningless. I.e. it doesn't worth it.
-
If this idea is implemented, I'd like for it to be optionnal thru some option.
I like knowing the range of my radars but after a few minutes it's going to become annoying, heh.
Good work guys.
-
Officially in git.
Toggled with details (tab).
-
look great :)
-
Great job volutar!
-
@Volutar which github?
-
toggled with R now ;)
@xan: https://openxcom.org/index.php/downloads/git-builds/ (https://openxcom.org/index.php/downloads/git-builds/)
-
i have cloned git supsuper git repo
I tried the system and it's beautiful,
just a problem.... if the circle are true, i never understand the meaning of radars :D
I always thought that increasing the number of radar increased the range, with small radar increased slightly. with large radar would increase more. I see that it is not true, anyone can explain how they work?
thz
-
here. https://www.ufopaedia.org/index.php?title=UFO_Detection
the more radars you have the more chances they will detect ufo. i.e. it affects only on detection chance.
-
I finally got around to trying it, and I have to say I really like the radar circles :)
about the detection mechanism: I have already mentioned that I think the original method (one detection check every 30 minutes, chances increase with additional radars) is crap, but as long as we stick with it (being true to the original mechanics and all ;) ), maybe we could include that in the visualization? perhaps the radar circle could blink every full 30 minutes? maybe it should only do that on the lowest time settings, though ;)
as for the detection mechanics: don't you think it would make sense to increase the detection frequency instead of the detection chance with additional radars? a base with two radars would check every 15 minutes, with three every 10, with four every 7.5 minutes?
-
The radar circle is only really needed for when an active UFO tracking event is happening and when you're placing down a new base.
Outside of those two events, it would probably just be clutter and noise on the Geoscope.