Programming Language
- Thread starter efb
- Start date
I have no way to verify this claim but I'm guessing primarily C++.
I may be wrong.
I may be wrong.
Probably. I don't understand why they chose 32bit though. Unless I'm missing something?
My understanding is that providing 32 and 64 would be extra work for no gain. The game doesn't use enough memory to justify 64bit and 64bit doesn't provide any performance boosts over 32 (unless you need the memory).
- - - - - Additional Content Posted / Auto Merge - - - - -
My guess is that bugs have less to do with the game engine (Cobra) and more to do with how that engine is being implemented and the logic around specific scripts and scenarios.
Game engine Cobra.
that answers my question.
new question does Cobra support an Object Oriented prgramming style ?
64bit by definition must be faster surely? each CPU processes 32bits per cycle as apposed to processing 64bits per cycle? so per clock cycle a quad core can process 128bits where a 64bit quad core would process 256bits?
I'm no expert I'm just asking. I know that 64bit can address more RAM though.
What limits performance oriented software these days isn't register width or memory, it's your cache. Moving to 64 bit address space makes pointers twice as wide (for example). But your cache doesn't magically double in size as it's on the chip itself. So you're just as likely to get a performance slowdown rather than boost moving to 64 bit.
Last edited:
Nope, not true, 64 Bit is better when you need extreme mathematical accuracy, but that's not the same as faster.
Also 32 Bit apps runs on 64 bit systems, and the reverse is not true.
SQL also, certainly
Mark Allen (Programmer) : "Almost exclusively C++. On other projects we've used a lot of Lua as well which we may also include in ED - that's an open debate. We use a much wider variety of languages for tools: often C++ or C#, but scattered around the company there's some Python, Ruby, Java and others." ---- https://forums.frontier.co.uk/showthread.php?t=6372
Here the way --- https://forums.frontier.co.uk/showthread.php?t=6372
- - - - - Additional Content Posted / Auto Merge - - - - -
Lol, yeah, and they prolly use words and stuff
SQL Server would be relevant to the databases
it's waaay more complicated than this, once you get down to details. here is an interesting fact: one of the recent innovations AMD introduced into their GPUs was better 16-bit processing. crazy, yes? in fact, highly desirable because smaller mobile devices actually don't need 32-bit graphics so programmers for it can switch to using 16-bit numbers and save battery! i mention this as an example of how much variation there is in actual needs for different register sizes.
let's take your specific question. why is 64-bit faster? because when you need to deal with numbers bigger than can be contained in 32-bit, it saves you a huge amount of low-level bit-wise arithmetic, saves you using multiple memory registers, saves multiple fetches from memory when fewer would do. it's like having a larger bucket - you make fewer trips to the river and back. and you don't have to fill it up, but if you need more water the capacity is there. you don't have to carry two buckets.
but what if you KNOW that you're never going to fill up that bucket? what if the ED programmers are certain that their software will never need to reference more than 4GB of memory and that nearly all of their maths will be with numbers inside of -2,147,483,647 to +2,147,483,647 (that's the range that 32bits gives you, it's actually pretty big). Or more likely that it will never need more than 128 decimal points which is the other way to use it? these scenarios correspond to our "the bucket will never be more than half full". well in that case, as you're really sure, you might as well use smaller buckets.
what do smaller buckets give you? well, they certainly don't give you any slower performance. they absolutely WOULD if you got it wrong and found out that you did need bigger buckets (64-bit) after all, but in this scenario we're assuming that the programmer knows what they are doing (seldom true, ime. and i was one.
). so what are the advantages? well modern CPUS and APUs often have support for 32-bit modes built in so if you're passing them 32-bit values, they are told by the compiled code to handle things differently. so if you have a 4MB L2 cache on your CPU and that can store X numbers in it, well with 32-bit instead of 64-bit, it can now store 2X numbers. (N.b. this is some wild simplification, i'll be honest, it gets really fascinating down there if you ever want to get really into low-level programming). and your software will take up less space. remember all those numbers that are part of your program (planet coordinates, price of luxuries, et al). now take up half as much space.so yes, it can be better to program in 32-bit. but i don't want to oversell this. these advantages are smaller than i make them sound for a variety of reasons. the fact that ED is (if this is true) programmed in 32-bit is FAR less likely for any inherent advantage, than it is that Frontier want to be able to release it on 32-bit platforms. there is still a 32-bit version of Windows 7 out there (not sure about 8). nobody in their right mind should be running it, but millions are. i doubt that Frontier want the headache of those users complaining because the game was advertised as working on Windows Vista / 7. so the much shorter answer to your question is this:
"no, 64-bit software is not inherently faster than 32-bit but there are a enough circumstances where it is that it's common; there are some advantages to 32-bit but they're less than you think; the reason ED is being released as 32-bit (if this is the case, i'm just going off the posts here), is for compatability with the 32-bit versions of Windows that are still out there".
i hope that's been of interest.
Last edited:
SQL Server would be relevant to the databases
I agree
Don't mind me, I thought you meant it as a tongue-in-cheek comment
If a game is being coded to run natively on Windows, it's almost always C++ at the core.
Python is used for Linux programming, in this case probably for custom server modules to support the server side of the game - it has nothing to do with what's on your Windows machine.
Ruby is a web app language and would really never be used for a game - it's also NOT used on their site. (Forums are in PHP using standard vBulletin and elitedangerous.com is in PHP, cached with Varnish and UI is done in JQuery - no Ruby there, either).
Java may be used in game dev along with C++, but aside from their own programming *tools* it would ultimately need to run (client-side) in C++ and Java in order to be built on Visual Studio, which it is (hence the VS Redist packs included with install).
Hope that answers it more clearly.
*edit* Side note - SQL isn't really a programming language, it's a database structure and not one used for games - this would be on the server side. Considering they're running Apache servers it's likely they are using MySQL server-side. You might think they'd use MSSQL "because it's a Windows game" and you'd be wrong - that would be terribly expensive and inefficient. MySQL is far lighter and free.
Last edited:
More about COBRA
https://www.frontier.co.uk/our_technology/
https://www.frontier.co.uk/our_technology/