Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: ChaosUnlimited on October 21, 2015, 09:51:52 am
-
is there anyway to get this engine to run in 64bit instead of 32bit since we have the source code or would that require to much work? also is there any news on directx support for the game/engine would love to see freespace in dx12 if possible.
-
I believe the engine does compile for 64bit already. However, there are no discernible gains that I'm aware of from running 64bit so we haven't been bothering to build 64bit alongside our existing 32bit is the way I understand it.
DirectX would only benefit Windows users, and we are currently still trying to simplify our graphics pipeline rather than complicate it further, so I doubt we will see any DX implementation. You probably wouldn't see much difference anyway as we would probably need to upgrade assets to take advantage of DX12 features. It is also fairly likely that OpenGL will catch up to DX12 and those features will be available eventually anyway.
-
Compiling for 64 bit is possible (for Windows), I compiled such a build some time ago and it worked quite well but we don't have a need for more memory so it's not a priority (Linux builds also have been 64-bit capable for quite some time and it runs pretty stable).
DirectX will never happen because it's a MS API which is not available on other platforms. Once the Vulkan (the cross platform alternative to DX12) specification has been released I would like to take a look at adding a graphics backend for that API but that will probably require a lot of work.
-
You mean to say that FSO doesn't need access to all of my 32GB of RAM? :p
-
ahh ok so i was wondering since i thought i could make even bigger battles with the large ships it running in 64-bit instead of 32-bit or do like massive carrier battle with carriers spawning in like 20-30 fighters per carrier (including bomber wings) no i havnt played with fred much i just initially thought it wassnt possible with 32bit in this 1999 engine.
how would i go about compiling it to 64bit when i tried i got over 800 errors ( i just wanna see how many big ships i can get in with 64-bit vs 32-bit)
and i know directx is a windows thing i just thought that maybe by now both opengl and directx would be in the engine
what about vulkan(when it comes out) it looks like its as powerful as dx12
i ask this because while the game is awesome to play and still has decent graphics (with media_vp or whatever their called can't recall of the top of my head) i just thought mybe an all out hd remake with like 2014 graphics and effects would be a neat thing and i think the game deservers a remaster kinda like homeworld 2 got. (again not saying it looks bad just on my end it still looks 2004ish mybe 2006.
is there a mod that adds cockpits to all the default ships thats really my only real issue with the game
i was interested in all this since i just started taking CPA in college (computer programming anaylst) i have love everything so far though we have only done basic java. so no i don't know much but i'm learning start c++ next semester
-
I really don't think 64-bit is going to help with any of the technical bottlenecks related to making large battle missions.
-
why not? 64-bit allows more ram each ships uses x amount of ram 32-bit limit is 3.5gigs (i know that limitation at least) the only thing i'm running out of when program would crash is ram and i have 8 gigs my vram has not even gone up to 1 gig yet and i have 2 gigs of that though i might be wrong on something maybe just the engine itsself is crashing i dunno i'm just starting on learning fundamental programming in java lol next semester is c++ though.
This community as far as i know started in 2002 i could be wrong as i have only been following since last month. when the source code came out for the engine (not the game right?).
I could be wrong as i have only been following since last month. just made my account to ask questions finally since i started taking a programming course
and i have been just curious on why old hardware is only really supported. (as in there is nothing for the game that would make say a 9800gt have troubles with the game. over 10 year old video card( i think) probably pick one up for $20 probably cheaper. is there no way to say have extra settings that (like low-ultra -med-ultra or high-ultra) for people with what is considered today low-mid range computers. or is opengl just that bad?
sorry if this sounds like i'm complaining or anything i just want to understand and i'm horrible at typing out how i want to say.
also sorry for how long my post are i should learn how to make these not so long.
i want to become an active member of this community. ( i might even learn how to make my own mods but i think that will have to wait till i have free time to learn how this engine/game works more.)
and i jsut read the rest of the others posts he said he was gonna look at vulkan my bad didn't read all the way.
this is in c++ right or is it c or c#?
computer specs
amd 6100 fx six core
8 gigs ddr3 1600mhz
evga 660 superclocked (worst buy of my life)
500gb HDD 5600rpm currently failing can hear loud ticking from drive (OS drive)
1TB HDD 7200prm (data drive should swap this to OS drive)
-
why not? 64-bit allows more ram each ships uses x amount of ram 32-bit limit is 3.5gigs (i know that limitation at least) the only thing i'm running out of when program would crash is ram and i have 8 gigs my vram has not even gone up to 1 gig yet and i have 2 gigs of that though i might be wrong on something maybe just the engine itsself is crashing i dunno i'm just starting on learning fundamental programming in java lol next semester is c++ though.
Even in the largest missions in FSO to date, memory use rarely climbs above 2 GB. Most of that memory goes to art assets, texture maps and models; only a minuscule portion is used for actual gameplay data. I am not saying it's impossible for someone, somewhere managing to make a mission that requires more than 3.5GB, but so far, noone has even come close.
-
Even in the largest missions in FSO to date, memory use rarely climbs above 2 GB. Most of that memory goes to art assets, texture maps and models; only a minuscule portion is used for actual gameplay data. I am not saying it's impossible for someone, somewhere managing to make a mission that requires more than 3.5GB, but so far, noone has even come close.
ok take away missions then.( not really as they are important) but wouldn't 64-bit allow better texture maps and models? and art assets i just get the feeling that all these things could be better. ( i think i mentioned them above might not have i know i mentioned effects)
not saying make the textures 4k. but add more detail in the model its self or something don't get me wrong the visuals from the normal 1999 version to the 2014 media's look good (espicailly the glass over the cockpits) ibut like i said i just get the feeling they could be better now espiacilly since there should be n (hardware wise for the game) ( unless someone goes way overboard) woudn't 64-bit allow for all this to be better then it is now?
again i could be wrong as i barely know what i'm talking about or i'm just one of them people who thinks to much i dunno.
asking again anybody know if there are any mods for cockpits on all ships that you fly in the campaing
-
ok take away missions then.( not really as they are important) but wouldn't 64-bit allow better texture maps and models? and art assets i just get the feeling that all these things could be better. ( i think i mentioned them above might not have i know i mentioned effects)
not saying make the textures 4k. but add more detail in the model its self or something don't get me wrong the visuals from the normal 1999 version to the 2014 media's look good (espicailly the glass over the cockpits) ibut like i said i just get the feeling they could be better now espiacilly since there should be n (hardware wise for the game) ( unless someone goes way overboard) woudn't 64-bit allow for all this to be better then it is now?
There is nothing in the engine that we can do to make models better in terms of their textures and geometry. That's always going to be the domain of the modellers and texturers.
And again, this is not something 64-bit compatibility or DirectX 12 helps with.
-
Now step back a second though. The 3.5GB limit is the limit 32bit Windows itself can let all running applications and itself access. That doesn't really have anything to do with the limit for a given 32bit process on 64bit Windows. I was thinking that might be 4GB, but found some interesting articles after a quick google search.
http://stackoverflow.com/questions/639540/how-much-memory-can-a-32-bit-process-access-on-a-64-bit-operating-system
http://www.viva64.com/en/k/0036/
Now I am starting to wonder if the fact that we are hitting 2GB means we _are_hitting the current memory limit already, and need to adjust some things to allow a higher ceiling within the 32bit realm? I hadn't heard of this /LARGEADDRESSAWARE switch before, and it's not in our codebase.
What we're getting at though, is we will probably not look at moving to 64bit until the assets are clearly hitting the memory ceiling of the 32bit binary. Then such a move might be worthwhile.
http://stackoverflow.com/questions/3109543/what-to-do-to-make-application-large-address-aware has some tips on what to do with the code before enabling that switch.
-
We could enable LAA, sure.
-
Not sure it's safe to just enable that, I just edited my last post with another link after you responded.
-
ok i can understand that.
ill just reading the source code while i learn to see if i can ever understand it at least a little bit (most likely not this year maybe next year)
-
Here's another good SO page on how to go about enabling the flag and some of the repercussions.
http://stackoverflow.com/questions/2288728/drawbacks-of-using-largeaddressaware-for-32-bit-windows-executables
In short, if we enable it, we should test a build with a TopDown AllocationPreference on 64bit Windows, as any issues we have with pointers in our memory should crop up immediately. If they are in our code we can fix them, if they are in third party DLLs we just can't safely enable LAA without somehow getting those rectified.
Lots of other good insight on why 32bit apps are normally limited to a 2GB virtual address space too.
-
While we're on the subject of compiling FSO to make use of CPU improvements, I'll bring up the one subject that often follows suggestion for 64-bit compiling... support for multi-core processor support. I don't recall all of the arguments, but I expect that compiling FSO to take advantage of multi-core CPUs is something far less trivial than 64-bit compiling. The usual conclusion is that the best thing you can do at this point, is use Windows' Processor Affinity options to slave the game to run on a specific core.
-
Actually I think we _stopped_ doing that because it was causing some other issue.
-
Actually I think we _stopped_ doing that because it was causing some other issue.
were the issues fixable but just not worth it? or just not fixable
-
Hello ChaosUnlimited,
Great to see you have an interest in the technical features of the FS2Open engine.
The best way to learn is by building and reviewing the source code, and for this engine all of that is publicly available.
A couple of your points have been responded to above, but thought I'd also add:
* 64bit: We already build 64bit executables on OS X and Linux, so there's no fundamental technical issue.
* DirectX: The engine actually used to be DirectX only when released by Volition. As part of our team's work to provide cross platform support, an OpenGL renderer was added. In the interests of maintainability, the DirectX renderer was subsequently dropped as it add too much complexity.
-
While we're on the subject of compiling FSO to make use of CPU improvements, I'll bring up the one subject that often follows suggestion for 64-bit compiling... support for multi-core processor support. I don't recall all of the arguments, but I expect that compiling FSO to take advantage of multi-core CPUs is something far less trivial than 64-bit compiling. The usual conclusion is that the best thing you can do at this point, is use Windows' Processor Affinity options to slave the game to run on a specific core.
If you start the exe with -set_cpu_affinity, it will start on the Processor defined in the ProcessorAffinity registry key.
were the issues fixable but just not worth it? or just not fixable
Not worth it, really. It turns out that the OS usually has a better idea which processors are free than we do.
-
* 64bit: We already build 64bit executables on OS X and Linux, so there's no fundamental technical issue.
ah but u don't for windows and as i am a windows user os x and linex have little to no use for me :P
i attempted to compile the source code my self in 64 but got like 800 errors so i probably did something wrong
i think i said it earlier but ill say it again i just started learning programming and its not in the c family of programming its java though i should be moving onto c++ in 2nd semester and we just started mid terms.
therefore i know next to nothing. basically nothing when it comes to engine/game coding and so i have no clue on what i'm doing ( its fun trying to figure it out though)
Not worth it, really. It turns out that the OS usually has a better idea which processors are free than we do.
ahh ok
anyhow it 3am need some sleep have my last midterm in the mornin and my driving test
-
I don't recall all of the arguments, but I expect that compiling FSO to take advantage of multi-core CPUs is something far less trivial than 64-bit compiling.
If by "far less trivial" you mean "the entire engine would need to be rewritten, basically from scratch," then yes, that's correct.
-
i think i said it earlier but ill say it again i just started learning programming and its not in the c family of programming its java though i should be moving onto c++ in 2nd semester and we just started mid terms.
therefore i know next to nothing. basically nothing when it comes to engine/game coding and so i have no clue on what i'm doing ( its fun trying to figure it out though)
The best way to learn C these days is LCTHW (http://c.learncodethehardway.org/book/). I highly recommend it, as it also teaches fundamental programming concepts that Java will "hide" away from you.
You'll need a Linux (VM is fine) or OS X system though to follow through the free LCTHW book.
-
The best way to learn C these days is LCTHW (http://c.learncodethehardway.org/book/). I highly recommend it, as it also teaches fundamental programming concepts that Java will "hide" away from you.
You'll need a Linux (VM is fine) or OS X system though to follow through the free LCTHW book.
oh the engine is in c not c++ ?
if so then ill start reading that book/webpage u sent when i get a chance (i can deal with linux for learning purpose but not as a main OS i really don't like linux)
-
The engine is C++ masquerading as C, as it's been said before, although we've moved many areas to more definitely-C++ patterns. On the surface though, C and C++ are very similar languages.
-
ahh ok ill just stick with my college courses then.
is there anything i can do my side (not coding or modeling) to increase the look of the game like force AA apon it or something (everything looks edgy and the graphics look like 2008 ish with the 2014 mediavps is that opengl problem or did i do something wrong?
-
You could try adding these command line parameters to enable nVidia's FXAA? (preset 9 is the highest IIRC)
[ -fxaa ] - Enable FXAA anti-aliasing
[ -fxaa_preset ] [ INT ] - FXAA quality (0-9), requires -post_process and -fxaa
-
did a bunch of things with nvidia control panel 3d config to the exe that the launcher uses to run the game game looks better