71–80 of 136 posts
Usually upstream projects would reject such PRs under the reason they just increase maintenance cost with little to no benefit to the userbase.
Uhm... excuse me? Why? Is there anyone even using DOS for anything serious these days?
Earlier quoted context omitted.
Who said anything about "serious"? (FWIW: I suspect there are more than a few old industrial control systems and such out there that are still running DOS, just because of an "if it ain't broke, don't fix it" attitude)
My brother is in manufacturing. DOS is everywhere . Older things too (PDP-11? DG Nova? Seen both, semi-recently). Not just because "ain't broke, don't fix", but because when you have a cloth dying machine or brick forming machine you spent >US$5M for, that is often a bespoke install for your plant, you don't replace it because some guy who prolly slings Javascript all day sez "DOS is oooold, boomer".
All that's left now is SDL for UEFI, and then all our games can run in a pre-OS environment.
That... Shouldn’t be terribly difficult? Though I don’t believe UEFI has sound drivers (you’ll have problems writing one yourself because even frickin’ sound-codec chips have NDA-only datasheets these days), and the stupidest thing is that the “graphics output protocol” doesn’t indicate vsync so you can’t do tear-free blitting, which is literally worse than VGA.
The problem is that people don't use onboard audio anymore (because its incredibly and audibly noisy). They use USB or Bluetooth.
Bluetooth absolutely isn't standardized and is a mess, and USB miiiiiiight be okay if you limit to a subset of EHCI and USB Audio Class 1.0 devices.
At this point, its easier to just use Linux and run your game as pid 1.
Joystick calibration: what a blast from the past! Blast from the past I encountered recently...
Joysticks had to be "calibrated" and it was something you had to do for each game that supported joysticks. These would give back analog values and they'd depend on the phases of the moon or the room temperature or both. I'm not making this up: this was a serious pain point both for players and coders.
FWIW in that DOS game of mine from 1991 or so for which I still had the .ASM source code files (about 30 000 lines of assembly code, 15 000 of which were auto-generated code to do very fast sprites drawing in the VGA 320x200 "tweaked" mode) and which I managed, at long last, to get to compile again a few days ago thanks to UASM (and quite some LLM help), I found lines like these:
ul_corner_ch:
db 63,"PUT YOUR JOYSTICK IN THE UPPER LEFT CORNER AND PRESS A BUTTON "
lr_corner_ch:
db 63,"PUT YOUR JOYSTICK IN THE LOWER RIGHT CORNER AND PRESS A BUTTON "
p1_choose:
dw 1 ;1 keyboard 2 joystick
p2_choose:
dw 0 ;0 none 1 keyboard 2 joystick
So you can understand that "auto-calibration" as in TFA is quite a selling point!
I'm more impressed by the fact they accepted it upstream, specially for an OS target that is long gone from the market and has virtually no users. Usually upstream projects would reject such PRs under the reason they just increase maintenance cost with little to no benefit to the userbase.
Earlier quoted context omitted.
Stupid question but... would bundling the binary with an ASM port of something that could run this technically make it possible to run without the OS? I realize this is basically doing docker for DOS games and incredibly stupid, I'm just curious about the thought experiment
Well, the "ASM port of something that could run this" would be the OS...
Uhm... excuse me? Why? Is there anyone even using DOS for anything serious these days?
Most computers in Turkey come with FreeDOS preinstalled because there's a law that states all computers must be sold with an operating system. FreeDOS turns out to be the cheapest and easiest. That's why you don't let people who have never touched a computer write tech laws. You get results like this.
All that's left now is SDL for UEFI, and then all our games can run in a pre-OS environment.