I can do yes.
Hi nathanc213
It sounds like you installed everything, so the issue is probably just that the planet surface-shader is rendering that area of the planet in darkness as the sun sets. It's been raised before but I've not gotten around enhancing the shader yet. I also need to look at applying shaders to the brightly lit fields and buildings that are around the base.
I want to retain the dark shadowing on planets when they are viewed at a distance or in the planetary view. IIRC FFE originally didn't darken the planet surfaces by much, if at all. I'm thinking that the best compromise might be that the surface would be lit with a minimum light-level that gradually takes effect as the altitude approaches zero. This would keep the terrain dark enough to indicate that it's in shadow/night, but light enough to allow nearby terrain & details to be seen. So as you fly lower the terrain lightens gradually to a point that it is visible, and as you climb it would darken again.
I've just got a prototype working, but it'll require a new .exe build as I'm passing an extra value into the shader.
In the mean time, if you simply want to reduce the shadow effect on planets, and make it more like FFE used to be - then open the file shaders\planet.fx with notepad and find the line "float4 P_Land_With_Noise(".
Then find the next occurrence below it of the text "float nrmd_light = max(0.1,dot(normal, lightDir) * 2.0);".
The 0.1 sets a minimum amount of light for the planet surface, so that it's never totally black. Change it up to 0.3 or 0.35 to lighten the dark side of the planet, save and reload the game.
Hope this helps!
AndyJ
(btw, if you didn't know - you can press 1, 2 or 3 at the intro for alternative start positions)
Thanks I shall try this when I get on my pc, also I didn't know about pressing 1,2,3 for alternative starts.
On my intrepid exploration of the inner core, i've been noticing some glitching around certain contact binaries.
It doesn't happen on every pair, but when it does there's some kind of alpha artifacts in the overlapping coronas...
I've set up a savefile that demonstrates the issue, a quaternary with two pairs of contact binaries lined up on a single vector - just hit autopilot and stardreamer, and you should see the glitching as they loom into view:
http://www.filedropper.com/faedlia
Here's a piccy, in case it's a dodgy graphics setting in my system rather than the game:
At some angles, it displays properly, like this:
..while at others, this happens:
Probably not a major priority considering how edge-case these systems are.. but as i may be the first to ever set eyes on 'em (if not the last), i thought it might be worth sharing..
It doesn't happen on every pair, but when it does there's some kind of alpha artifacts in the overlapping coronas...
I've set up a savefile that demonstrates the issue, a quaternary with two pairs of contact binaries lined up on a single vector - just hit autopilot and stardreamer, and you should see the glitching as they loom into view:
http://www.filedropper.com/faedlia
Here's a piccy, in case it's a dodgy graphics setting in my system rather than the game:
At some angles, it displays properly, like this:
..while at others, this happens:
Probably not a major priority considering how edge-case these systems are.. but as i may be the first to ever set eyes on 'em (if not the last), i thought it might be worth sharing..
Last edited:
Hi Bounder & congrats on the exploration!
Thanks for reporting the issue, it also happens in the 3D system map. It seems to have been fairly straight forward to fix, which is always good! (btw I did send you a PM the other day)
Sorry I've not been keeping up to date with your FFED3D + -SweetFX + 4K thread, but I've spotted your request for reducing the sun glare on the ship dashboard. There'll be a config setting to adjust that in the next build. It was something I'd meant to revisit anyway to prevent the combat console from becoming lost in the glare.
Also to finally get back to you about post #173
I did type a similarly short reply earlier in the summer - but Windows 10 ate it. Honest...
This will be caused by the game still running at a native resolution of 320x200 pixels internally.
Although the graphics can be intercepted and rendered at higher resolutions, and the models drawn with far more detail, screen positions and movement are still tied to the original resolution.
This is why when you move ship slowly by a small amount, it obviously skips over an area rather than moves smoothly across individual pixels. Internally it may move by a pixel, but this translates to perhaps 13 if you are running at 4K.
I had a bit of a look at the FFE assembly/data for anything that's is obviously tied to a 320x200 screen, and yeah - there was enough to put me off any idea of trying to upscale the internal resolution!
The 2D stuff, doable but loads of rework in both asm and the D3D presenation, but I wonder if view rotation etc would "just work" or if it'd turn out to be another can of worms to track down :O
The joystick code is largely unchanged from JJFFE/Windows'95 era.
I have found that the sensitivity is probably half what it should be compared to keyboard roll/pitch and I'll be increasing the xmax/ymax values from 512 to 1024 in the .cfg file in future builds.
Regarding the deadzone and discrepancy between left/right sensitivity. I don't suppose that your HOTAS is a Saitek is it? Is it one with potentiometers and the central value has slipped leftwards? (this happened on my now defunct Cyborg stick)
I'm afraid that the game should get value between -1024 to +1024 for x/y axis, but if the stick is off center then it might not be able to achieve that full range. This isn't something that I can do a lot about I think; the values are via DirectInput from the device. And in the case of my Cyborg, the stick would get progressively worse after about 20 minutes towards its final days - ultimately sending a constant roll or acceleration input despite apparently being centered.
One observation also - changing deadzones in the Windows control panel can also totally confuse the game if it's running at the same time and send the ship into spins.
The game does have it's own deadzone values for both central positions and to limit the range the stick has to be moved to hit the maximum input. These are the xdeadzone/ydeadzone and xmaxzone/ymaxzone values. There is also the ability to apply a curve or linear scale to the inputs by setting the xexp/yexp values. I believe that the value 10 gives a linear scale and and increasing value will give gradual changes closer to the center and extremes, and a curve in between.
If your stick is off-center then perhaps it is tending more towards the curve on one side. You probably want to set the exp values to 10 for linear. (edit: exp values are divided by 10, so 10 is linear, not 1)
Hmmmm. FFE has a "set speed" value in one engine mode, and AFAIK the main/retro thrusters pretty much just fire at full beans to try to achieve that.
In 'engines off' (manual) mode then thrust is again applied full whack for the duration that the key is held.
There isn't incremental throttle levels as such...
...the only mechanism that I can think off would be that FFE applies damage to the thrust values in its calculations. Something similar to this might be used to apply a % multiplier for an analogue throttle I guess in 'engines off' mode... but is this overkill perhaps?
And then there's full range throttle versus forward-only with reverse toggle .... urgh...
Maybe if I'm very bored (and sober enough) over the Christmas break!
FFED3D(AJ) only supports a "standard" joystick as such, IIRC analogue axis only on roll, pitch, yaw and main throttle, so definately not considering individual directional thrusters on analogue inputs before anyone gets too excited!
I had a think about this comment and tracked down where the assembly code branches depending upon the game option for roll or yaw. It looked like it wouldn't be too hard to create a separate input for yaw and wrap the new functionality with a config setting, so I had an experiment and it works great!
So there'll be a new config file setting in the next build that specifically enables analogue yaw on the joystick and retains roll at the same time.
As with the x/y axis there's also dead/max zone and exponent values that can be defined.
The joystick support is fairly basic really so this is aimed at sticks that have twist action for yaw and perhaps joypads that have dual sticks.
For setups with more than one device, then I'd expect a 3rd party utility would have to be used to map various inputs to a virtual stick. I think it'll get too complicated trying to implement this in the config for more advanced joystick support - not just for me but the user who'd probably have to enter hardware id's to identify the various devices. Keeping it Simple...
Took a look and yes it's definately different between Frontier and FFE, although I'm not sure in the way you described as I understood it.
I tested both glFrontier as well as PC Frontier in DosBox and for me, Up on the mouse tilts the map "into" the screen and Down tilts towards you. Left rotates anti-clockwise, Right rotates clockwise.
I then tested original FFE in DosBox as well as JJFFE/GLFFE/FFED3D(AJ).
These seem to be inverted in FFE compared to Frontier. i.e. Right is anti-clockwise and Up tilts the map towards you.
I've added a pair of options in the config file so that they can be reversed to match Frontier.
Other stuff in progress is the planet surface lightening as you get lower towards the surface and are in the dark side, permitting the landscape to be seen. On the flip-side I'm also looking at the lighting on base/city groups so that they are also lit or in shadow more appropriately. This should remove the confusion when taking off from the default spaceport and seeing the bright textures of the town and almost black landscape - often mistook for there being textures missing.
I got a little sidetracked from this over the summer, need to return to it to separate the bright green 'grass' of the biodomes from their framework as well as the pitch of the stadium so that they can be made darker in shadow but the frame/building perhaps less so.
No ETA as yet, and with the project downloads page on SpaceSimCentral gone due to the site refactoring, I may yet need to find an alternative home for it anyway...
Thanks for reporting the issue, it also happens in the 3D system map. It seems to have been fairly straight forward to fix, which is always good! (btw I did send you a PM the other day)
Sorry I've not been keeping up to date with your FFED3D + -SweetFX + 4K thread, but I've spotted your request for reducing the sun glare on the ship dashboard. There'll be a config setting to adjust that in the next build. It was something I'd meant to revisit anyway to prevent the combat console from becoming lost in the glare.
Also to finally get back to you about post #173
I did type a similarly short reply earlier in the summer - but Windows 10 ate it. Honest...
This will be caused by the game still running at a native resolution of 320x200 pixels internally.
Although the graphics can be intercepted and rendered at higher resolutions, and the models drawn with far more detail, screen positions and movement are still tied to the original resolution.
This is why when you move ship slowly by a small amount, it obviously skips over an area rather than moves smoothly across individual pixels. Internally it may move by a pixel, but this translates to perhaps 13 if you are running at 4K.
I had a bit of a look at the FFE assembly/data for anything that's is obviously tied to a 320x200 screen, and yeah - there was enough to put me off any idea of trying to upscale the internal resolution!
The 2D stuff, doable but loads of rework in both asm and the D3D presenation, but I wonder if view rotation etc would "just work" or if it'd turn out to be another can of worms to track down :O
The joystick code is largely unchanged from JJFFE/Windows'95 era.
I have found that the sensitivity is probably half what it should be compared to keyboard roll/pitch and I'll be increasing the xmax/ymax values from 512 to 1024 in the .cfg file in future builds.
Regarding the deadzone and discrepancy between left/right sensitivity. I don't suppose that your HOTAS is a Saitek is it? Is it one with potentiometers and the central value has slipped leftwards? (this happened on my now defunct Cyborg stick)
I'm afraid that the game should get value between -1024 to +1024 for x/y axis, but if the stick is off center then it might not be able to achieve that full range. This isn't something that I can do a lot about I think; the values are via DirectInput from the device. And in the case of my Cyborg, the stick would get progressively worse after about 20 minutes towards its final days - ultimately sending a constant roll or acceleration input despite apparently being centered.
One observation also - changing deadzones in the Windows control panel can also totally confuse the game if it's running at the same time and send the ship into spins.
The game does have it's own deadzone values for both central positions and to limit the range the stick has to be moved to hit the maximum input. These are the xdeadzone/ydeadzone and xmaxzone/ymaxzone values. There is also the ability to apply a curve or linear scale to the inputs by setting the xexp/yexp values. I believe that the value 10 gives a linear scale and and increasing value will give gradual changes closer to the center and extremes, and a curve in between.
If your stick is off-center then perhaps it is tending more towards the curve on one side. You probably want to set the exp values to 10 for linear. (edit: exp values are divided by 10, so 10 is linear, not 1)
Hmmmm. FFE has a "set speed" value in one engine mode, and AFAIK the main/retro thrusters pretty much just fire at full beans to try to achieve that.
In 'engines off' (manual) mode then thrust is again applied full whack for the duration that the key is held.
There isn't incremental throttle levels as such...
...the only mechanism that I can think off would be that FFE applies damage to the thrust values in its calculations. Something similar to this might be used to apply a % multiplier for an analogue throttle I guess in 'engines off' mode... but is this overkill perhaps?
And then there's full range throttle versus forward-only with reverse toggle .... urgh...
Maybe if I'm very bored (and sober enough) over the Christmas break!
FFED3D(AJ) only supports a "standard" joystick as such, IIRC analogue axis only on roll, pitch, yaw and main throttle, so definately not considering individual directional thrusters on analogue inputs before anyone gets too excited!
I had a think about this comment and tracked down where the assembly code branches depending upon the game option for roll or yaw. It looked like it wouldn't be too hard to create a separate input for yaw and wrap the new functionality with a config setting, so I had an experiment and it works great!
So there'll be a new config file setting in the next build that specifically enables analogue yaw on the joystick and retains roll at the same time.
As with the x/y axis there's also dead/max zone and exponent values that can be defined.
The joystick support is fairly basic really so this is aimed at sticks that have twist action for yaw and perhaps joypads that have dual sticks.
For setups with more than one device, then I'd expect a 3rd party utility would have to be used to map various inputs to a virtual stick. I think it'll get too complicated trying to implement this in the config for more advanced joystick support - not just for me but the user who'd probably have to enter hardware id's to identify the various devices. Keeping it Simple...
Took a look and yes it's definately different between Frontier and FFE, although I'm not sure in the way you described as I understood it.
I tested both glFrontier as well as PC Frontier in DosBox and for me, Up on the mouse tilts the map "into" the screen and Down tilts towards you. Left rotates anti-clockwise, Right rotates clockwise.
I then tested original FFE in DosBox as well as JJFFE/GLFFE/FFED3D(AJ).
These seem to be inverted in FFE compared to Frontier. i.e. Right is anti-clockwise and Up tilts the map towards you.
I've added a pair of options in the config file so that they can be reversed to match Frontier.
Other stuff in progress is the planet surface lightening as you get lower towards the surface and are in the dark side, permitting the landscape to be seen. On the flip-side I'm also looking at the lighting on base/city groups so that they are also lit or in shadow more appropriately. This should remove the confusion when taking off from the default spaceport and seeing the bright textures of the town and almost black landscape - often mistook for there being textures missing.
I got a little sidetracked from this over the summer, need to return to it to separate the bright green 'grass' of the biodomes from their framework as well as the pitch of the stadium so that they can be made darker in shadow but the frame/building perhaps less so.
No ETA as yet, and with the project downloads page on SpaceSimCentral gone due to the site refactoring, I may yet need to find an alternative home for it anyway...
Last edited:
Wow mega response, cheers - just replied to your PM too..
Brill, it's a really cool effect and helps keep your bearings as well as melding the internal / external 'ambiance'..
No worries, totally understand now, it makes perfect sense.. and to be honest, i hardly even notice it any more anyway.
Bullseye mate - Cyborg Evo wireless, and yes it sounds exactly like the pot's not centered doesn't it? Was always a lousy POS anyway - nice design, terrible build quality. I apologise profusely for impugning your sterling work with my crappy hardware..
OK here's my addled thought processes behind that suggestion - what got me thinking was that when we change the "set speed", the thrust changes incrementally, represented by the size and shape of the engine flame and the audible pitch of their 'whine'.
As another example, a ship hovering over land is only applying partial throttle, with a small engine flame sustained at that value...
So this is what i'm refering to as "internally incremental" as opposed to the binary full-on or full-off. I appreciate the game engine has no inputs for this control, so i'm wondering if analogue throttling could be hacked in by directly manipulating the corresponding addresses or something - somewhere internally there must be a common 'throttle' value synching the sample pitch and flame proportions, and if that was mapped to the DX analog throttle, then we'd have analog thrust like ED..
For joystick support alone, yeah.. prolly overkill. The game's much more playable and much more fun with mouse and keys anyway... at the time i was just thinking HOTAS support might do for FFE what it did for ED, in terms of 'accessibility' for pew-pew simpletons... Still, variable thrust would be a really nice and useful enhancement for any input mode - try manually scooping cargo with 15 G retros! But also for docking, stalking other ships, etc. etc.
Again, though, no biggie.. if it sounds like more hassle than it's worth then please ignore my inane suggestions. It's a great game already..
Amazing! Although it may be a while until i get a new joystick to try it..
Honestly, forget i ever mentioned it. The game was always designed for mouse and keys. And HOTAS rigs are for nincompoops. IIRC i just wanted to prove an argumentative point that what all the simpletons like about ED's handling can be transplanted into a Fronteir Elite game engine without ruining it for everyone else... But who cares what they think? They're the enablers, 50% responsible for the travesty that is 'speed limits in space' and nerfed yaw...
Yep your description's correct, i'd mis-remembered how it was, but this is fantastic news, it's one those annoyances that still has me shaking my head every time i use the system map.. Thanks so much for fixing this!
Other stuff in progress is the planet surface lightening as you get lower towards the surface and are in the dark side, permitting the landscape to be seen. On the flip-side I'm also looking at the lighting on base/city groups so that they are also lit or in shadow more appropriately. This should remove the confusion when taking off from the default spaceport and seeing the bright textures of the town and almost black landscape - often mistook for there being textures missing.
I got a little sidetracked from this over the summer, need to return to it to separate the bright green 'grass' of the biodomes from their framework as well as the pitch of the stadium so that they can be made darker in shadow but the frame/building perhaps less so.
No ETA as yet, and with the project downloads page on SpaceSimCentral gone due to the site refactoring, I may yet need to find an alternative home for it anyway...
Legend. Sounds awesome, will keep this thread bookmarked...
Thanks for all your incredible work, there isn't any other version of Elite that still scratches the itch for me. You're currently the sole torch bearer for the greatest game ever!
Last edited:
Good, that was so bad at times I ended up switching it off completely in the config file.
Next build? NEXT BUILD??? [smile]
And you never said anything?
Beta test fail Steve. Beta test fail! [haha]
I'll probably do a 1.12 beta and you can redeem yourself of your sins!
Last edited:
Just re-reading your answers in post #188 and #190, I wasn't trying to hassle you into releasing a special beta just to address that issue. I was merely expressing my excitement that there's going to be a new build [big grin]
This_____^^^_____
No worries Steve, I'd have probably thrown something together at the weekend only I've been fighting off seasonal lurgie all week and am fairly sleep deprived. Meh. I was just pulling your leg on those posts, nothing else intended if it re-read differently 2nd time around.
It'll be useful if I can get Bounder to see if the change has fixed the overlapping suns or if he can find any other cases on his travels, and to try the sunlit cockpit settings to see if that fits better with the shader plug-in he prefers.
And there's also the lighting changes to starport/base/city areas that will benefit from another pair of eyes too...
I need to find some brain power first though so that I can revisit that part of the code and make sure it's ok to make a build from, as it's still work-in-progress.
In other news...
It looks like Potsmoke (Gernot) has some new ship models for us all to play with!
He originally converted his FFED3D ships over to the Pioneer project and created some new ones for it too. These are now being converted back to FFED3DAJ.
I'm resisting the temptation to pinch all of his pictures and to post them here (!) but the new Kestrel and Eagle both have some gorgeous curves!
Oooh! [woah]
Gernot has created a new discussion thread for them over on SpaceSimCentral - here.
It'll be useful if I can get Bounder to see if the change has fixed the overlapping suns or if he can find any other cases on his travels, and to try the sunlit cockpit settings to see if that fits better with the shader plug-in he prefers.
And there's also the lighting changes to starport/base/city areas that will benefit from another pair of eyes too...
I need to find some brain power first though so that I can revisit that part of the code and make sure it's ok to make a build from, as it's still work-in-progress.
In other news...
It looks like Potsmoke (Gernot) has some new ship models for us all to play with!
He originally converted his FFED3D ships over to the Pioneer project and created some new ones for it too. These are now being converted back to FFED3DAJ.
I'm resisting the temptation to pinch all of his pictures and to post them here (!) but the new Kestrel and Eagle both have some gorgeous curves!
Oooh! [woah]
Gernot has created a new discussion thread for them over on SpaceSimCentral - here.
Last edited:
Well spotted Andy! I've just been there and downloaded Gernot's new FFED3D ships. I found I didn't have D3D models for the Kestrel, Krait and Transporter (though I could have sworn I had the last one) so they've gone straight into my game. The others I'm going to look through and have a play around with.
Wow, SSC has undergone a lot of changes recently! My old login wouldn't work so I had to re-register to leave a comment. As I said over there, it's great to see FFED3D getting some attention (other than your work, that is!) [praise]
Gernot sure knows how to bring those older Elite ships into the modern day.
Indeed. I like the Adder more than the Adder in E: D.
No worries Steve, I'd have probably thrown something together at the weekend only I've been fighting off seasonal lurgie all week and am fairly sleep deprived. Meh. I was just pulling your leg on those posts, nothing else intended if it re-read differently 2nd time around.
It'll be useful if I can get Bounder to see if the change has fixed the overlapping suns or if he can find any other cases on his travels, and to try the sunlit cockpit settings to see if that fits better with the shader plug-in he prefers.
And there's also the lighting changes to starport/base/city areas that will benefit from another pair of eyes too...
I need to find some brain power first though so that I can revisit that part of the code and make sure it's ok to make a build from, as it's still work-in-progress.
In other news...
It looks like Potsmoke (Gernot) has some new ship models for us all to play with!
He originally converted his FFED3D ships over to the Pioneer project and created some new ones for it too. These are now being converted back to FFED3DAJ.
I'm resisting the temptation to pinch all of his pictures and to post them here (!) but the new Kestrel and Eagle both have some gorgeous curves!
[url]http://i790.photobucket.com/albums/yy187/potsmoke66/sshots/FFED3D/ships%202016-12/new%20models/2016-12-11_142042_zpse6ndjmii.jpg[/URL]
[url]http://i790.photobucket.com/albums/yy187/potsmoke66/sshots/FFED3D/ships%202016-12/alternative%20models/2016-12-11_142831_zpsvy1gpdbt.jpg[/URL]
Oooh! [woah]
Gernot has created a new discussion thread for them over on SpaceSimCentral - here.
Those curves still look great
Yes they are very nice, especially the transporter, but I think praising them belongs in another thread... until you can persuade him to port them over to FFED3D for us to use
Yes, unfortunately creating ships for use in FFED3D is no easy matter. You need the correct software, knowledge of how the whole process works and plenty of time to do it [downcast]Yes they are very nice, especially the transporter, but I think praising them belongs in another thread... until you can persuade him to port them over to FFED3D for us to use