Where is my old PDP-8 when I need it? 
News Removal of Win32 support for Elite Dangerous
- Thread starter Edward Lewis
- Start date
So... Guess that means my lil 8-bit 65SC12 is.. not getting a port then?
Darnit.. Just got the new 5 1/4inch floppy for my BBC master too, and moved my usual tools to ROM cart. Oh well, you'll need to port Elite 1 over to x86 then
Darnit.. Just got the new 5 1/4inch floppy for my BBC master too, and moved my usual tools to ROM cart. Oh well, you'll need to port Elite 1 over to x86 then
and old FFE ran on stupidly low resources, I'm sure if FDEV put their coding brains on the game could fit in 4Gb of ram it does now. Surely Thargoid's (which are already in there) don't push that much ram, unless they are gonna push Horizons for free to everyone?
But my Amiga 1200 is 32 bit!
And it runs Frontier Elite 2, Also FFE as it's AGA if fdev released the planned Amiga version
Yes, it does now. But I certainly hope that wont be the case in the future, I think it's fair to expect that ED should have a bit more complex everything than FFE. FFE and FE2 are exeedingly basic games (and I'm not talking about graphics), I think we can have higher standards.
This is 2017, all gaming computers should have at least 8 gigs of RAM (most do have at least 8 gig), it would be a shame for the game to not exploit that.
Last edited:
Also FE2 (and presumably FFE) were written in assembly language - about as low-level as you can get without manually bunging in hexadecimal codes for the machine code
This resulted in very tight, compact code and the Amiga version executable of FE2 was only 400K in size!
Contrast that with today's machines we play E: D on.
E: D is written in a high level language - Visual C++ I believe. Even after compilation, there will still be a certain amount of bloat in the resultant game, and it's not realistic to write game code in assembler these days - you'd have to be mad. Mad I say! Plus the advantage of writing the game in a higher level language is you can port it to other platforms.
The Barben post linked in the OP covers their reasons, including exactly what you're asking.
I bolded
Last edited:
Impressive! It's always the god damn motherboard that lets you down in the end
PS: what fps were you getting in the end?
vsync locks fps at 60 to avoid tearing. When it move to dx12 to implement multithreading. There should be performance boost. I can even run SC..
I wrote assembler, in hex, and octal...
Why 64-bit matters
The amount of yammering by people who have no actual understanding of what's going on inside the Windows OS and Windows apps is astounding. Let me inject some actual facts.
Under the 32 bit version of Windows, applications can address only 2 GB of memory. Desktop versions of Windows (i.e. the non-Server versions) don't have PAE or other bank-switching APIs, and bank switching makes software development significantly more difficult and introduces an entirely new class of bugs that are a real pain to deal with. Even under a 64-bit version of Windows, using the 32-bit version of an app sticks it with the 2GB virtual address space. Moving up to the 64 bit API set gives apps a vastly larger flat address space; terabytes of it.
Under the 32 bit version of Windows, kernel-mode code (including drivers) can only address 4 GB, and the lower 2GB is reserved for the user-mode program running on that core at that instant. The upper 2GB is used for file system cache, page tables, all sorts of other data structures, and the memory ranges that are used to communicate with devices. In particular, the video card. A 32-bit version of the operating system has only a limited aperture through which it can address the memory on your video card. Everything, loading textures, loading and programming shaders, you name it, gets done though that aperture. If you have a 6 GB video card, the kernel may be talking to it through a 400MB aperture; that's kinda like rebuilding the carburetor by shoving tools through the exhaust pipe.
Under a 64-bit Windows kernel, the aperture available to the driver to talk to the video hardware is vastly larger; certainly larger than the amount of memory available on current video cards. Drivers are simpler and faster and more reliable. Other kernel data structures are no longer under memory pressure. More file system blocks can be cached (speeding up disk access by eliminating reads and delaying writes).
While the dev team might be able to shoehorn things into a 32-bit usermode process on a 32-bit kernel, it would come at the cost of reduced performance, increased development time, and larger numbers of bugs. Those three items (performance, time to deliver updates, buggy code) are three of the top five complaints of customers; the latter two are significant drivers of cost to FDEV. Losing some fraction of the .01% of current customers who run the 32-bit game today, that fraction that decides to quit the game rather than upgrade their hardware, is a rational business choice. The 99.99% of customers who already use the 64-bit binary will see improvements in three areas that FDEV knows are important. FDEV itself will have fewer bugs to fix and will ship new updates sooner; fewer bugs means lower cost, faster updates mean new customers which means higher revenue. Higher gross revenue, minus lower expenses, means more profit.
I'm sorry for the fraction of 0.01% who can't afford to upgrade their kit and will have to leave the game. To be honest, if they can't afford to get to a 64-bit chip and OS, they can't afford to buy more stuff from FDEV anyway, which (callously, I know) makes them the best kind of customer to lose - the one who was never going to make you more money and could only cause you to spend money to serve them.
That's the way the software business works.
The amount of yammering by people who have no actual understanding of what's going on inside the Windows OS and Windows apps is astounding. Let me inject some actual facts.
Under the 32 bit version of Windows, applications can address only 2 GB of memory. Desktop versions of Windows (i.e. the non-Server versions) don't have PAE or other bank-switching APIs, and bank switching makes software development significantly more difficult and introduces an entirely new class of bugs that are a real pain to deal with. Even under a 64-bit version of Windows, using the 32-bit version of an app sticks it with the 2GB virtual address space. Moving up to the 64 bit API set gives apps a vastly larger flat address space; terabytes of it.
Under the 32 bit version of Windows, kernel-mode code (including drivers) can only address 4 GB, and the lower 2GB is reserved for the user-mode program running on that core at that instant. The upper 2GB is used for file system cache, page tables, all sorts of other data structures, and the memory ranges that are used to communicate with devices. In particular, the video card. A 32-bit version of the operating system has only a limited aperture through which it can address the memory on your video card. Everything, loading textures, loading and programming shaders, you name it, gets done though that aperture. If you have a 6 GB video card, the kernel may be talking to it through a 400MB aperture; that's kinda like rebuilding the carburetor by shoving tools through the exhaust pipe.
Under a 64-bit Windows kernel, the aperture available to the driver to talk to the video hardware is vastly larger; certainly larger than the amount of memory available on current video cards. Drivers are simpler and faster and more reliable. Other kernel data structures are no longer under memory pressure. More file system blocks can be cached (speeding up disk access by eliminating reads and delaying writes).
While the dev team might be able to shoehorn things into a 32-bit usermode process on a 32-bit kernel, it would come at the cost of reduced performance, increased development time, and larger numbers of bugs. Those three items (performance, time to deliver updates, buggy code) are three of the top five complaints of customers; the latter two are significant drivers of cost to FDEV. Losing some fraction of the .01% of current customers who run the 32-bit game today, that fraction that decides to quit the game rather than upgrade their hardware, is a rational business choice. The 99.99% of customers who already use the 64-bit binary will see improvements in three areas that FDEV knows are important. FDEV itself will have fewer bugs to fix and will ship new updates sooner; fewer bugs means lower cost, faster updates mean new customers which means higher revenue. Higher gross revenue, minus lower expenses, means more profit.
I'm sorry for the fraction of 0.01% who can't afford to upgrade their kit and will have to leave the game. To be honest, if they can't afford to get to a 64-bit chip and OS, they can't afford to buy more stuff from FDEV anyway, which (callously, I know) makes them the best kind of customer to lose - the one who was never going to make you more money and could only cause you to spend money to serve them.
That's the way the software business works.
Last edited:
People in general do not understand the architectural differences, let alone the software development process. Lately I overheard a teenager raging on why new games don't support Windows XP anymore. I politely explained that the cost of maintenance and making sure it works on that prehistorical machines is simply not justifiable and they nodded understandingly ;-)
The sooner we get rid of old hindrances, the better.
The sooner we get rid of old hindrances, the better.
http://store.steampowered.com/hwsurvey/
It is not business wise to support the extreme minorities. Especially when they are talking it's 0.01% of the customer base. Sorry but that's life, unless you're willing to pay them for support (which would still detract them from far more important things). I think if you saw the figure on the invoice for monthly support of that separate branch of code you'd advocate they better spent the resources on the actual game
</thread> ;-)
It is not business wise to support the extreme minorities. Especially when they are talking it's 0.01% of the customer base. Sorry but that's life, unless you're willing to pay them for support (which would still detract them from far more important things). I think if you saw the figure on the invoice for monthly support of that separate branch of code you'd advocate they better spent the resources on the actual game
</thread> ;-)
I do understand the architecture of modern windows as I have been using it since it was a DOS shell. However shoving around a few asteroids, ships, a planet or two and maybe some stations shouldn't require more than 2gb of ram. Yes I do see that today's programming platforms are woefully bloated in all respects (compiling code on Turbo C for disabled chucks a exe of 4Kb, the same in gnu or vc gives a larger executive something to do with console interfaces according to microsoft).
It is a shame that FDEV couldn't write a Lua language or some similar scripting language to move away from Dev tools to a more contained system of their own choosing.
As for the 64bit cpu and OS I have both but the 32bit version runs amazing on my laptop where the 64bit version for all its amazing "drivers and memory access" chugs along at 2-3fps. Yes I know it's a old machine but it ran 32bit fine, yes I will upgrade at some point probably to a PS4 Pro as the pc upgrade cycle is a never ending cash sink.
That takes me back! Hand compiling machine code onto my Commodore 64, running it, the machine freezing, and then trying to debug where the issue was by going through each hand compiled piece of code... Sheesh!
goes back to far programmed in basic with reams of data statement over the years lol. Assembler for the important bits though
Do you remember spending days typing in programs from magazines, including all the data for machine code elements, and then it never working?
When I got my assembler cartridge for my Commodore 64 it was wonderful being able to actually program in machine code in a nice friendly way and debug it!