Sadly my only 'true' DOS capable PC (a P166 built to play Daggerfall) was put out to pasture a few years back. I just got DOSBox now
Hope someone can help you out here.
...just had a little brainstorm and managed to get beta4 working - in the previous build, windowed mode ran in the correct resolution when both:
enableBorderless=0
defaultBorderless=0
However with beta4, to disable 'defaultBorderless' (and so continue using regular windowed mode), you have to first enable borderless:
enableBorderless=1
defaultBorderless=0
...et voila, now i can run it at 4K!
However, now that i've got it working i've noticed another issue - the engine sound's all wrong, as if it's using a different audio sample? Sounds muffled and muted - i much prefer the vanilla FX (an acquired taste perhaps, but i've grown used to it, and it's easier to distinguish what the engines are doing over the sound of the radio or music i listen to whilst playing).. if this is an intentional change, a toggle in the config would be nice...
Totally rocking the Anisotropic build ATM... gonna clock it then do the same with the Hellmod... never really bothered with 'em before, but Aniso's is utter chaos, intense combat.. Elite: Ragnarok. I've gotta video some of these battles, it's proper down-to-the-wire, slugging it out tooth & nail.. classic Elite furballs - who's shooting who? Who cares, shoot! AI are crashing into each other, i'm bouncing off them, it's a whirlwind blur of winding smoketrails, cut through with a 3D mesh of laser beams & missiles popping off left right & center.. i'm in my element!
enableBorderless=0
defaultBorderless=0
However with beta4, to disable 'defaultBorderless' (and so continue using regular windowed mode), you have to first enable borderless:
enableBorderless=1
defaultBorderless=0
...et voila, now i can run it at 4K!
However, now that i've got it working i've noticed another issue - the engine sound's all wrong, as if it's using a different audio sample? Sounds muffled and muted - i much prefer the vanilla FX (an acquired taste perhaps, but i've grown used to it, and it's easier to distinguish what the engines are doing over the sound of the radio or music i listen to whilst playing).. if this is an intentional change, a toggle in the config would be nice...
Totally rocking the Anisotropic build ATM... gonna clock it then do the same with the Hellmod... never really bothered with 'em before, but Aniso's is utter chaos, intense combat.. Elite: Ragnarok. I've gotta video some of these battles, it's proper down-to-the-wire, slugging it out tooth & nail.. classic Elite furballs - who's shooting who? Who cares, shoot! AI are crashing into each other, i'm bouncing off them, it's a whirlwind blur of winding smoketrails, cut through with a 3D mesh of laser beams & missiles popping off left right & center.. i'm in my element!
Hey Bounder - thanks for saving the thread from the marching padlocks!
There is/was/maybe a Beta 5 to come but unfortunately RL took an unexpected turn last summer and I had to step away from some things for a while. [blah]
You are correct - the engine noise has changed. It was much higher in pitch in FFED3D than it was in the original FFE - I think anyway... from memory and DosBox and other player's complaints!
There's a setting there to adjust it though. look for enginePitchDivider=3 in the .cfg file or add it (just above "# music") as this adjusts the pitch of the engine tone. IIRC setting it to 1 should put it back to how it was before the change.
I've also reworked the screen config a bit more since beta 4 as it was a bit messy. Also so that it can take a start x,y offset location and size for borderless mode, not just be tied to the resolution of the primary monitor. This will allow it to be run across multiple monitors.
I have started to take a look again at were I left things to get the beta out. Next release may be better named 1.13 anyway just to avoid any confusion with the old FFED3D.
When I left things I was messing with ship shaders to control colours and perhaps display decals/embellishments rather than using various individual skins - e.g. pirate skulls, go-faster stripes. No eta's or promises at the moment though I'm afraid.
Always good to see that it's still being enjoyed though!
@Steve, sorry mate I did get the saves. Thanks very much. I had started to look at tracing the function calls and found a few new routines that were as clear as mud - but a start. I'll try catch up with you soon.
There is/was/maybe a Beta 5 to come but unfortunately RL took an unexpected turn last summer and I had to step away from some things for a while. [blah]
You are correct - the engine noise has changed. It was much higher in pitch in FFED3D than it was in the original FFE - I think anyway... from memory and DosBox and other player's complaints!
There's a setting there to adjust it though. look for enginePitchDivider=3 in the .cfg file or add it (just above "# music") as this adjusts the pitch of the engine tone. IIRC setting it to 1 should put it back to how it was before the change.
I've also reworked the screen config a bit more since beta 4 as it was a bit messy. Also so that it can take a start x,y offset location and size for borderless mode, not just be tied to the resolution of the primary monitor. This will allow it to be run across multiple monitors.
I have started to take a look again at were I left things to get the beta out. Next release may be better named 1.13 anyway just to avoid any confusion with the old FFED3D.
When I left things I was messing with ship shaders to control colours and perhaps display decals/embellishments rather than using various individual skins - e.g. pirate skulls, go-faster stripes. No eta's or promises at the moment though I'm afraid.
Always good to see that it's still being enjoyed though!
@Steve, sorry mate I did get the saves. Thanks very much. I had started to look at tracing the function calls and found a few new routines that were as clear as mud - but a start. I'll try catch up with you soon.
No worries, Real Life™ even encroaches into my life occasionally! But I hope things are resolved for you. Meanwhile I'll just go away and drool over the prospect of v1.13 [haha]@Steve, sorry mate I did get the saves. Thanks very much. I had started to look at tracing the function calls and found a few new routines that were as clear as mud - but a start. I'll try catch up with you soon.
Brill thanks for the update Andy, didn't notice the new engine pitch setting, will give it a tweak...
The new borderless settings sound cool - i get by fine using WindowsBorderlessGaming, but native support would be cleaner n' leaner..
The new shader tricks also sound pretty sweet - great way to add some diversity, if you can pull it off!
Hope RL cuts you some slack after the curveball, and of course none of this carp here really matters... but i would be too embarrassed to admit how much time i spend appreciating your work each week, so do keep it up!
The new borderless settings sound cool - i get by fine using WindowsBorderlessGaming, but native support would be cleaner n' leaner..
The new shader tricks also sound pretty sweet - great way to add some diversity, if you can pull it off!
Hope RL cuts you some slack after the curveball, and of course none of this carp here really matters... but i would be too embarrassed to admit how much time i spend appreciating your work each week, so do keep it up!
I recently inherited a laptop from my mother-in-law (a Dell Inspiron 15 3000 series) thinking that I'd install FFED3D-AJ on it.
Well, it doesn't seem to like having all the models loaded at once, despite having 8GB of memory, but the biggest issue is it refuses to render the planet atmosphere shader.
What I get - in the intro sequence - is this...
and this...
...and loading a save game on a planet with an atmosphere causes the program to crash.
Setting drawAtmosphere=0 allows the game to run but the sky never changes colour and the stars are visible at the same time as the sun [woah]
Device Manager lists the graphics card as an Intel HD graphics 5500 which may not be the best but gives at least 50fps when running the game.
Well, it doesn't seem to like having all the models loaded at once, despite having 8GB of memory, but the biggest issue is it refuses to render the planet atmosphere shader.
What I get - in the intro sequence - is this...
Setting drawAtmosphere=0 allows the game to run but the sky never changes colour and the stars are visible at the same time as the sun [woah]
Device Manager lists the graphics card as an Intel HD graphics 5500 which may not be the best but gives at least 50fps when running the game.
Hi Steve.
If you copied the files over from your main PC, perhaps you still have the .cfg options enabled for caching textures in video memory?
Those settings were experimental to try save system memory and realistically are aimed at cards with 2GB or more once loading in lots of hi-res textures.
Your GPU is built into the CPU I think and doesn't have dedicated memory like a discreet graphics card does - so maybe it doesn't have enough memory available or just doesn't like this approach. (I don't have access to similar hardware, so it'll help if players can feedback what works for them, or doesn't!)
It does look like it hasn't loaded in the hi-res cloud texture. Could you try turning these options off and see if it fixes things:
loadPanelTexturesToVideoCard=0
loadCabinTexturesToVideoCard=0
loadGameTexturesToVideoCard=0
loadPlanetTexturesToVideoCard=0
loadTerrainTexturesToVideoCard=0
You can then experiment turning options back on if all seems OK - Panel and Cabin will use least memory, game textures are the standard set of images for the basic FFE buildings & ships, map images, buttons + journal headings etc. Planet textures are the 'skin' textures that some objects such as gas giants use, as well as the clouds/atmosphere gradients. Terrain textures are those used on the proc-gen landscapes.
At the core of things though, FFE is still a 32bit process which ultimately limits how much system memory the wrapper can make use of too.
And unfortunately as new models and textures get added, there's no guarantee that they'll all be able to get loaded into memory at start up.
Eventually compromises will probably have to be made, such as lower res textures or dynamic loading of models, or using different approaches such as a shader to recolour ships rather than using 10 separate skins like the Skeet & its dish have.
If you copied the files over from your main PC, perhaps you still have the .cfg options enabled for caching textures in video memory?
Those settings were experimental to try save system memory and realistically are aimed at cards with 2GB or more once loading in lots of hi-res textures.
Your GPU is built into the CPU I think and doesn't have dedicated memory like a discreet graphics card does - so maybe it doesn't have enough memory available or just doesn't like this approach. (I don't have access to similar hardware, so it'll help if players can feedback what works for them, or doesn't!)
It does look like it hasn't loaded in the hi-res cloud texture. Could you try turning these options off and see if it fixes things:
loadPanelTexturesToVideoCard=0
loadCabinTexturesToVideoCard=0
loadGameTexturesToVideoCard=0
loadPlanetTexturesToVideoCard=0
loadTerrainTexturesToVideoCard=0
You can then experiment turning options back on if all seems OK - Panel and Cabin will use least memory, game textures are the standard set of images for the basic FFE buildings & ships, map images, buttons + journal headings etc. Planet textures are the 'skin' textures that some objects such as gas giants use, as well as the clouds/atmosphere gradients. Terrain textures are those used on the proc-gen landscapes.
At the core of things though, FFE is still a 32bit process which ultimately limits how much system memory the wrapper can make use of too.
And unfortunately as new models and textures get added, there's no guarantee that they'll all be able to get loaded into memory at start up.
Eventually compromises will probably have to be made, such as lower res textures or dynamic loading of models, or using different approaches such as a shader to recolour ships rather than using 10 separate skins like the Skeet & its dish have.
Hi Andy,
Sorry for the delay in replying. I went away for a few days and forgot to take the laptop!
I had already set the following in the config file
loadPanelTexturesToVideoCard=0
loadCabinTexturesToVideoCard=0
loadGameTexturesToVideoCard=0
loadPlanetTexturesToVideoCard=0
loadTerrainTexturesToVideoCard=0
although the game runs quite happily with all those options set to 1 as well.
I've tried changing various other settings in the config file but nothing gets rid of the problem, other than setting drawAtmosphere=0 in the shaders section.
I will keep trying things though. There must be some way of fixing this
EDIT:
Indeed there is. It turned out to be a component of DirectX - namely d3dx9_43.dll - which wasn't installed correctly. Once I updated DirectX, all worked perfectly!
Sorry for the delay in replying. I went away for a few days and forgot to take the laptop!
I had already set the following in the config file
loadPanelTexturesToVideoCard=0
loadCabinTexturesToVideoCard=0
loadGameTexturesToVideoCard=0
loadPlanetTexturesToVideoCard=0
loadTerrainTexturesToVideoCard=0
although the game runs quite happily with all those options set to 1 as well.
I've tried changing various other settings in the config file but nothing gets rid of the problem, other than setting drawAtmosphere=0 in the shaders section.
I will keep trying things though. There must be some way of fixing this
EDIT:
Indeed there is. It turned out to be a component of DirectX - namely d3dx9_43.dll - which wasn't installed correctly. Once I updated DirectX, all worked perfectly!
Last edited:
Well that's good to hear... if a little bit odd ...
That particular DLL appears to contain all of the important functions used for creating textures, fonts, models and shaders.
So I'm surprised that it would even run tbh - games normally won't even start up and bail out with an error when DirectX isn't installed correctly...
One to add to the 'readme' I guess. Did you do a full reinstall of the "DirectX End-User Runtimes (June 2010)" or something else?
(I'm curious what led you to that specific file!)
Good to hear you're up and running with it anyway!
[edit] I'll just add - if you can leave all the cache options on and it still runs fine, that will leave the most memory available for the replacement models + their skins. It's useful to know that loading all those hi-res textures seems to be ok with a shared-memory GPU setup too.
That particular DLL appears to contain all of the important functions used for creating textures, fonts, models and shaders.
So I'm surprised that it would even run tbh - games normally won't even start up and bail out with an error when DirectX isn't installed correctly...
One to add to the 'readme' I guess. Did you do a full reinstall of the "DirectX End-User Runtimes (June 2010)" or something else?
(I'm curious what led you to that specific file!)
Good to hear you're up and running with it anyway!
[edit] I'll just add - if you can leave all the cache options on and it still runs fine, that will leave the most memory available for the replacement models + their skins. It's useful to know that loading all those hi-res textures seems to be ok with a shared-memory GPU setup too.
Last edited:
I compared which files I had in my FFED3D-AJ folder on my PC compared to the laptop and found I had one extra dll file - which was d3dx9_43.dll - on the laptop. When I removed that file the game refused to load, as you anticipated. The correct place for it was in C:\Windows\system32 but the game generated the same error when I copied it to that location. So I in effect repaired DirectX by going to
https://www.microsoft.com/en-us/download/confirmation.aspx?id=35
which I guess put everything in the right place, the game loaded up fine and I had the planetary atmospheres as well [yesnod]
I tried shoving all the textures onto the graphics card and then loading all the replacement models (modelPreLoadAllx64=1 and modelPreLoad=99) but the game had a hissy fit when it tried to run the intro sequence and I had to Ctrl-Q out of it.
For now it looks like modelPreLoad=2 works best on the laptop, which also has the nice side effect of the game loading much faster, but the city buildings at Simpson in the Facece system take about 6 seconds to pop up in place of the old models :O
https://www.microsoft.com/en-us/download/confirmation.aspx?id=35
which I guess put everything in the right place, the game loaded up fine and I had the planetary atmospheres as well [yesnod]
I tried shoving all the textures onto the graphics card and then loading all the replacement models (modelPreLoadAllx64=1 and modelPreLoad=99) but the game had a hissy fit when it tried to run the intro sequence and I had to Ctrl-Q out of it.
For now it looks like modelPreLoad=2 works best on the laptop, which also has the nice side effect of the game loading much faster, but the city buildings at Simpson in the Facece system take about 6 seconds to pop up in place of the old models :O
It looks to me like the crater that is left behind when you nuke a target for the military, so it's probably something in the program code calling the wrong model.
Over to you, AndyJ! [big grin]
Hi Andy,
Here are some screen captures from the same save game but in JJFFE, GLFFE and FFED3DAJ v1.12 beta 4
First JJFFE
then GLFFE
and finally FFED3D
Sorry the last one's a bit dark but I'm struggling to find a planetoid where this happens where the sun actually shines! It does however show that a giant crater gets drawn over the base and surrounding buildings, although you can fly through it and land as normal. It all looks a bit freaky though, with skyscrapers and factories in a kind of underground cavern!
Interestingly, this location has a crater rendered there - the greeny/yellow shape towards the bottom right of the GLFFE/JJFFE view. Maybe FFED3D is, for some reason, drawing a massive version of that?
EDIT:
In terms of versions, all the betas of v1.12 exhibit this behaviour, whereas v1.11 is ok. In fact, v1.11 seems to handle models better in general; I can pre-load all the models in that version, but in v1.12 I have to use modelPreLoadAllx64=0 otherwise the program falls over, more often than not
Last edited:
..cheers Steve, that's the one. At some bases you get whole clusters of 'em, all overlapping and nested together...
Trying to work it out i'd trawled thru my models folder looking for craters, also thru Gernot's updated models collections, then finally hit on the idea of swapping the models folder with one from an older FFED3D with only a handful of extra models, but the issue persisted.. then i tried launching a copy of the 1.11 .exe from my 1.12b4 folder and voila, craters begone..
Trying to work it out i'd trawled thru my models folder looking for craters, also thru Gernot's updated models collections, then finally hit on the idea of swapping the models folder with one from an older FFED3D with only a handful of extra models, but the issue persisted.. then i tried launching a copy of the 1.11 .exe from my 1.12b4 folder and voila, craters begone..
Thanks for the screenshots Steve.
Yes it's a replacement .x model that's falling foul of an enhancement in the 1.12 betas that you & Bounder both have. (this doesn't affect 1.11)
Some child models are meant to be scaled to different sizes, and previously this wasn't implemented in the FFED3D code - so the crater would just have drawn at a fixed size.
Another example of such a model is the rotating radar dish that's used on ships when a scanner is fitted, as well as on some Coriolis stations and at some military bases.
This one used to look OK when drawn at a fixed size on ships, but when it was used at stations/bases it was tiny - so I'd forced the drawing of the polygon model instead in previous builds. This 'fudge' has now been removed as the radar dish model will scale correctly AFAIK - but feel free to look out for it at military bases on bombing/photography missions and let me know if you spot any that don't!
You can easily fix the crater problem yourselves -
Open up the folder for the crater model (<FFED3D path>\Models\162) and create a new text file in there.
Edit the text file with notepad, paste the following text into it & save it:
finally rename the text file to tris.ini
The value for the scale was arrived at by a quick bit of experimentation, hovering my ship near a few of those craters with the game paused.
The tris.ini file can be updated and saved - and the effect quickly seen by toggling between replacement/polygon models mode (CTRL+F6 key) in game - quitting and reloading isn't required.
This seems to give a very close match to the original large and small craters at that location. If you could check the resulting crater after a bombing mission too that would be great. (as would a save game for a test case if you have one)
I'll include a tris.ini with the core files in future to fix this.
Regarding the model preload failures - I've taken a quick look at memory usage between 1.11 and 1.12 betas and I don't think that they are significantly different from the application point of view. However with the new models that we've had since 1.11, these do take memory usage up above 2GB even with caching textures onto the video card.
I don't have all of Gernot's latest installed and I've chopped a few textures elsewhere - but without loading textures onto the video card, total memory usage was at/over 3GB.
Now, the app is 'large address aware' and ought to be able to use "up to" 4GB on 64bit Windows, but I think that we're definitely into unknown territory now and there's a good chance of hitting issues again pushing it this far.
Yes it's a replacement .x model that's falling foul of an enhancement in the 1.12 betas that you & Bounder both have. (this doesn't affect 1.11)
Some child models are meant to be scaled to different sizes, and previously this wasn't implemented in the FFED3D code - so the crater would just have drawn at a fixed size.
Another example of such a model is the rotating radar dish that's used on ships when a scanner is fitted, as well as on some Coriolis stations and at some military bases.
This one used to look OK when drawn at a fixed size on ships, but when it was used at stations/bases it was tiny - so I'd forced the drawing of the polygon model instead in previous builds. This 'fudge' has now been removed as the radar dish model will scale correctly AFAIK - but feel free to look out for it at military bases on bombing/photography missions and let me know if you spot any that don't!
You can easily fix the crater problem yourselves -
Open up the folder for the crater model (<FFED3D path>\Models\162) and create a new text file in there.
Edit the text file with notepad, paste the following text into it & save it:
Code:
[MODEL]
scale=0.065
scale_y=1.0
scale_z=1.0
offset_x=0.0
offset_y=0.0
offset_z=0.0finally rename the text file to tris.ini
The value for the scale was arrived at by a quick bit of experimentation, hovering my ship near a few of those craters with the game paused.
The tris.ini file can be updated and saved - and the effect quickly seen by toggling between replacement/polygon models mode (CTRL+F6 key) in game - quitting and reloading isn't required.
This seems to give a very close match to the original large and small craters at that location. If you could check the resulting crater after a bombing mission too that would be great. (as would a save game for a test case if you have one)
I'll include a tris.ini with the core files in future to fix this.
Regarding the model preload failures - I've taken a quick look at memory usage between 1.11 and 1.12 betas and I don't think that they are significantly different from the application point of view. However with the new models that we've had since 1.11, these do take memory usage up above 2GB even with caching textures onto the video card.
I don't have all of Gernot's latest installed and I've chopped a few textures elsewhere - but without loading textures onto the video card, total memory usage was at/over 3GB.
Now, the app is 'large address aware' and ought to be able to use "up to" 4GB on 64bit Windows, but I think that we're definitely into unknown territory now and there's a good chance of hitting issues again pushing it this far.
Last edited:
Great stuff Andy! If we were to ever bump into each other in Real Life I would have to consider buying you a beer [haha]
Not only has this fixed the issue with the giant crater(s) I also managed to use it to repair something else. I had downloaded Gernot's replacement model - a factory building - for the grey and white domes (model 269). Unfortunately these models also got scaled to various sizes which meant some huge factories were drawn which dwarfed the starports. I copied the tris.ini file which scales back the craters to the 269 folder, adjusted the scale to 0.35 and now they're a sensible size
There's a zip file here with saves before and after a military base is nuked. It all seems ok; just be ready when you load it up as there are a lot of hostile ships around!
With regard to the memory usage, with all the models pre-loaded and textures cached to the graphics card, the game uses 3375MB of memory and often there are issues with sound not playing, parts of space stations not being drawn etc. Without the pre-load that goes down to about 1000MB, so that's how I'm running it, with the occasional model pop-up. If I get time I'll go through all the models and see if size reductions can be made.
Anyway, thanks again Andy!
Not only has this fixed the issue with the giant crater(s) I also managed to use it to repair something else. I had downloaded Gernot's replacement model - a factory building - for the grey and white domes (model 269). Unfortunately these models also got scaled to various sizes which meant some huge factories were drawn which dwarfed the starports. I copied the tris.ini file which scales back the craters to the 269 folder, adjusted the scale to 0.35 and now they're a sensible size
There's a zip file here with saves before and after a military base is nuked. It all seems ok; just be ready when you load it up as there are a lot of hostile ships around!
With regard to the memory usage, with all the models pre-loaded and textures cached to the graphics card, the game uses 3375MB of memory and often there are issues with sound not playing, parts of space stations not being drawn etc. Without the pre-load that goes down to about 1000MB, so that's how I'm running it, with the occasional model pop-up. If I get time I'll go through all the models and see if size reductions can be made.
Anyway, thanks again Andy!
Last edited:
I did a bunch of optimizations with the textures for the files in my FFED3DAJ. Not sure how that would work with later versions of FFED3DAJ, but feel free to download (link in my sig below) and see if you can reduce the memory usage?
Sadly all the screen-shots are dead due to photo-bucket being lame, and i have no way to get them back, but i posted them specifically to show that the graphics were not worse after the optimizations, and in some cases were actually better.
Sadly all the screen-shots are dead due to photo-bucket being lame, and i have no way to get them back, but i posted them specifically to show that the graphics were not worse after the optimizations, and in some cases were actually better.