DOSBox integraded into a source port?

[Blzut3]

7 hours ago, Murdoch said:

Pretty sure this only works in Windows 10 setup. It's definitely mandatory in 11 unless I am even blinder than my contact lenses prescription would suggest. I bypass it by having a generic account I sign into for all my customer computers, then create a local account once that's done. It's definitely a minor annoyance, but not insurmountable. 

While that's certainly one way to bypass it, since it sounds like you're not aware, there is a well documented command you can enter to re-enable the bypass button.

 

7 hours ago, Edward850 said:

You can actually do this. If you setup bitlocker on a drive after setup, including the C drive (i.e it's not initially configured by the OEM), it asks you what you want to do with the backup key. In this situation it doesn't need to be stored on the account and you can just save it to another drive or print it.

If my memory serves this is only possible on the Pro, since the Home edition's encryption is a feature limited version of Bitlocker that does require sending the keys to Microsoft?  It's honestly the only reason I believe you on the account requirement being for that reason, since that would explain why it was originally only a requirement for Home.

 

I do agree with Graf that sending the key to Microsoft kind of ruins the point of encryption, but I do recognize that people will fail to understand the implication of encryption and I suppose it does still help prevent data theft in the case the computer gets stolen.

[Edward850]

It could just be a pro thing, I haven't run or even seen home in a long time now. Though I'm not sure i agree with it being stored on your online account being silly, given you would need a very specific circumstances to have both access to the account (with the additional knowledge of what account it even is and the 2FA web access) and just the lone physical hard drive to gain access to it. That requires very targeted espionage and if that's going on you have far bigger problems to worry about.

[Professor Hastig]

5 minutes ago, Edward850 said:

It could just be a pro thing, I haven't run or even seen home in a long time now. Though I'm not sure i agree with it being stored on your online account being silly, given you would need a very specific circumstances to have both access to the account (with the additional knowledge of what account it even is and the 2FA web access) and just the lone physical hard drive to gain access to it. That requires very targeted espionage and if that's going on you have far bigger problems to worry about.

 

I think you missed the point. It's not about storing the key somewhere in the cloud, but storing it in a personal account on Microsoft's server where the server operator is fully aware what gets stored. Which means that in theory they can hand it over to anyone, including government agencies, for example.

 

[fabian]

Are we getting a bit of topic?

[Murdoch]

4 hours ago, Blzut3 said:

hile that's certainly one way to bypass it, since it sounds like you're not aware, there is a well documented command you can enter to re-enable the bypass button.

 

*googles*

 

Ah yes, that's a solid 60% less annoying. Thanks.

 

2 hours ago, fabian said:

Are we getting a bit of topic?

 

What's everyone's favourite Shakespeare play? Gosh, he was a hell of a writer, am I right?

[banjiepixel]

22 hours ago, fabian said:

Are we getting a bit of topic?

 

In my opinion, we barely even got on topic, but can't blame people for not wanting to waste their time analyzing and hypothesising very niche concept. Atleast this thread has increased my motivation to learn coding and has helped me to form more concrete plan for it, and that was kinda the real point all along.

 

And it is very ironic that thread related to DOSBox would turn into discussion about Windows. Personally as the OP of this thread, it doesn't really bother me that much and I would allow it. It is just taking over because there isn't that much on topic to talk about, unless people want to actually talk about my niche concept and not about me and my personal projects.

[MrFlibble]

EDuke32 has a built-in menu that allows to load, from inside the running game, not only user maps found in that port's folder, but also any of the official levels in DUKE3D.GRP as well. I wonder if that part of EDuek32's code could be incorporated into a Doom source port, certainly not a very bad feature to begin with? I mean, Raze builds off GZDoom to run Build engine games, perhaps it would be productive to go into the opposite direction as well.

 

Being no coder, I also wonder how difficult it would indeed be to have a menu string inside Crispy Doom that says "Run DOSBox" and then runs it in the same window, with Crispy Doom still running in the background? (is that what you have in mind @banjiepixel?) I mean, I suppose that adding a menu item that launches DOSBox externally as a separate programme in its own window would not be that much of a problem in itself?

 

I'd be really interested to hear the opinions of the experienced source port developers here on both issues. (And no, I have no idea why @banjiepixel wants these particular features in a source port, or at least the second one that involves DOSBox, but they do indeed seem to be possible to implement.)

[Graf Zahl]

11 hours ago, MrFlibble said:

EDuke32 has a built-in menu that allows to load, from inside the running game, not only user maps found in that port's folder, but also any of the official levels in DUKE3D.GRP as well. I wonder if that part of EDuek32's code could be incorporated into a Doom source port, certainly not a very bad feature to begin with? I mean, Raze builds off GZDoom to run Build engine games, perhaps it would be productive to go into the opposite direction as well.

 

I have made a similar menu for Raze which even includes a map preview. Porting that to Doom should be possible but there's one gotcha: Build's file system works a bit differently than Doom's and unlike Doom where maps are WADs they are self contained separate files in Build.

This poses a few problems because a) maps are harder to locate and b) place some restrictions on the map WADs. For example, this could only work if the map WADs do not contain other assets than the maps themselves.

 

[Kinsie]

My extremely-layman level understanding is that loading in new content to an extent that anyone would want (custom assets etc.) requires restarting the engine, which kind of defeats the point. The Unity port does this relatively seamlessly with some fun cheating, by killing and restarting the Doom engine instance inside of the crunchy Unity shell, but doing it for more traditional engines is going to be a very painful road.

[Edward850]

19 minutes ago, Kinsie said:

My extremely-layman level understanding is that loading in new content to an extent that anyone would want (custom assets etc.) requires restarting the engine, which kind of defeats the point. The Unity port does this relatively seamlessly with some fun cheating, by killing and restarting the Doom engine instance inside of the crunchy Unity shell, but doing it for more traditional engines is going to be a very painful road. 

Eternity and Odamex manage this fine without restarting the engine, and in fact Odamex does it while maintaining even the network (remember it has on the fly wad changing as a maplist function). Doom's old zone allocator is a bit easier to clear out if you keep track of the statics (I.e the title screen and colourmap) and then rebuild the wad directory.

 

Unity is nearly right though with an additional detail; Unity doesn't restart Doom, Doom restarts itself. All globals are chucked in a class which just gets deleted and remade, which is also how it does splitscreen by simply creating additional classes. It's a change that was made back with the OG Xbox port. This method actually worked against it for doing dehacked support from what I hear, and the Eternity/Odamex method would be better.

[Graf Zahl]

20 minutes ago, Edward850 said:

Eternity and Odamex manage this fine without restarting the engine, and in fact Odamex does it while maintaining even the network (remember it has on the fly wad changing as a maplist function). Doom's old zone allocator is a bit easier to clear out if you keep track of the statics (I.e the title screen and colourmap) and then rebuild the wad directory.

 

Only that this does not work if you do not use the zone allocator anymore or have to clean up external resources like hardware rendered textures, or have to take care of other code holding references to the assets that just got erased.

In GZDoom an engine restart is a complex undertaking that has to be careful taking down all allocated resources in the correct order and then rebuilding them, including all scripted content.

[banjiepixel]

18 hours ago, MrFlibble said:

Being no coder, I also wonder how difficult it would indeed be to have a menu string inside Crispy Doom that says "Run DOSBox" and then runs it in the same window, with Crispy Doom still running in the background? (is that what you have in mind @banjiepixel?)

 

Basically that, running DOSBox on top of Chocolate/Crispy session. Of course it would be probably easiest to just remove whole menu system of the source port and build new system that would be free from limitations of actual Doom engine. Loading the actual Doom engine is pretty fast and the I think there should be no problem with the menu system being more of a separate overlay. And maybe this overlay menu system could be then used to also launch DOSBox sessions within it, just like it could already run a source port within the overlay. DOSBox would just take over things so overlay's menus would be disabled while DOSBox is running so there would be no confict with menus inside games running in DOSBox.

 

18 hours ago, MrFlibble said:

I'd be really interested to hear the opinions of the experienced source port developers here on both issues. (And no, I have no idea why @banjiepixel wants these particular features in a source port, or at least the second one that involves DOSBox, but they do indeed seem to be possible to implement.)

 

It would be atleast an interface to use with DOSBox that would work great with a controller. I am not actually sure about the actual controller support of DOSBox but simply reusing existing controller support of source port does atleast sound easier in many ways. It wouldn't even need to be that complicated for my own personal need, just translating controller inputs to keyboard inputs for DOSBox to read.

 

And I know, probably many easier routes, but in general this was supposed to be more of a thought exercise.

[MrFlibble]

@banjiepixel, just out of curiosity, what is the difference, to you, between playing Chocolate Doom and playing vanilla Doom in DOSBox?

[banjiepixel]

5 hours ago, MrFlibble said:

@banjiepixel, just out of curiosity, what is the difference, to you, between playing Chocolate Doom and playing vanilla Doom in DOSBox?

 

Not much I guess, especially if the DOSBox user experience would be more like using a source port. Both being together would be a neat package and OOSBox could be used to play other games too, not just Doom. And if it would be a very easy feature to add, what source port wouldn't want to have have built in DOSBox? It seems pretty natural thing to have in my opinion.

 

And I do trust the DOSBox emulated Doom to have potentially less bugs/differences than native port like Chocolate Doom. But mostly it is just the extra step towards purism.

[Individualised]

22 minutes ago, banjiepixel said:

And if it would be a very easy feature to add, what source port wouldn't want to have have built in DOSBox?

Why should Doom source ports, other than your own hypothetical one intended for a specific purpose, include an entire DOS virtual machine?

 

A fibbonaci sequence generator, a Minesweeper game, and an embedded NES emulator should also be just as easy to add to a Doom source port, doesn't mean it's a good idea. Your DOSBOX idea maybe works for your own specific purpose, but most people do not want an "everything" program.

[MrFlibble]

29 minutes ago, banjiepixel said:

what source port wouldn't want to have have built in DOSBox? It seems pretty natural thing to have in my opinion.

 

I guess we're getting spoiled by the rapidly expanding computing capacity of modern PCs. Even some ten years ago, let alone 15-20, running a game like Quake or Duke Nukem 3D (especially in any resolution higher than 320x200) emulated in DOSBox would consume noticeably more resources than using a source port, up to not being really playable at higher resolutions, if we're talking about 15 years or so back.

 

DOSBox essentially emulates an entire PC with all its internals and peripherals, which is bound to always take up more host system resources compared to a source port, which in the case of Doom only emulates OPL synthesis at best (please correct me if I'm wrong). The benefits of integrating such a resource hog into a source port are as doubtful as the "benefits" of integrating it into any other programme really, except perhaps the browser, because playing DOS games online is a really nice thing to have. 

 

Pardon me for the Captain Obvious Mode, but a source port is essentially the opposite of an emulator, in that it exactly bypasses the need to emulate an entire PC, instead allowing you to run a game natively under the host OS.

34 minutes ago, banjiepixel said:

I do trust the DOSBox emulated Doom to have potentially less bugs/differences than native port like Chocolate Doom

I've heard similar opinions from other users (not specifically related to Doom) that generally distrust source ports for being potentially less accurate than the original game. But when a source port is done properly (i.e. no substantial changes are introduced either deliberately or by error), it should actually provide a 1:1 playing experience on the target system. And while I don't use Chocolate Doom extensively, I believe that it is one of the better examples of how accuracy and fidelity is maintained in a conservative port. I don't remember if Chocolate Doom fixes any of the bugs that do not affect vanilla compatibility (like the Ouch face bug or the really needed medikit message) though.

[banjiepixel]

2 hours ago, MrFlibble said:

I guess we're getting spoiled by the rapidly expanding computing capacity of modern PCs. Even some ten years ago, let alone 15-20, running a game like Quake or Duke Nukem 3D (especially in any resolution higher than 320x200) emulated in DOSBox would consume noticeably more resources than using a source port, up to not being really playable at higher resolutions, if we're talking about 15 years or so back.

 

I can emulate Dreamcast version of Quake 3 Arena on my Dell Optiplex 380 (Core 2 Duo, Radeon HD5450) that was released in 2009. Granted, it is not very accurate emulator but it is still more advanced hardware than old pc being able to run Doom. And based on very quick testing, Doom 2 and Quake seem to work just fine. So there should generally no issues on actual modern hardware, and keep in mind this was while the image was being rescaled to 1080p similar manner as Chocolate Doom does it. And personally 320x200 is all the rendering resolution I need for these games.

 

2 hours ago, MrFlibble said:

DOSBox essentially emulates an entire PC with all its internals and peripherals, which is bound to always take up more host system resources compared to a source port, which in the case of Doom only emulates OPL synthesis at best (please correct me if I'm wrong).

 

I mean it would be resource hog only when DOSBox portion itself would be running. And why are we so worried about it taking some extra resources?

 

2 hours ago, MrFlibble said:

I believe that it is one of the better examples of how accuracy and fidelity is maintained in a conservative port. I don't remember if Chocolate Doom fixes any of the bugs that do not affect vanilla compatibility (like the Ouch face bug or the really needed medikit message) though.

 

I don't doubt the accuracy of Chocolate Doom, it is more of a personal preference, I like to use the untouched original code. And I just happen like emulation, I play mostly retro console games these days and those already use emulation.

[Dark Pulse]

5 hours ago, banjiepixel said:

I like to use the untouched original code. And I just happen like emulation, I play mostly retro console games these days and those already use emulation.

This is when I blow your mind and tell you the DOS version is, itself, a source port of the original code. :P

[PKr]

I honestly hope you'll persevere with your project, @banjiepixel. I'd really like to hear your thoughts on your own ideas present in this thread in a retrospect, once you'll fully understand what were you putting yourself up to.

[MrFlibble]

On 11/2/2023 at 10:24 PM, banjiepixel said:

And I just happen like emulation, I play mostly retro console games these days and those already use emulation.

And that just brings us back to step one, namely if you prefer the original DOS version and DOSBox is the most accessible way to play it, then what would be the purpose of integrating that into a source port?

 

Further on, since I don't believe there can be a way to insta-switch between playing Doom in a source port and in DOSBox (that is, smooth transition with keeping your progress, current map position, etc.), the only conceivable way to do so would be to a) quit the playing session in the port and b) launch DOSBox and start playing. What you seem to suggest by "integrating" DOSBox into a port would be being able to run DOSBox directly from the main menu in such source port, if I understood your previous posts correctly. Yet, since you would have to first quit your source port playing session before running Doom in DOSBox anyway, how much difference would there actually be between selecting "quit to menu" if DOSBox were accessible from the in-game menu, and "quit to desktop" where you could launch DOSBox from a desktop shortcut? Because this kind of integration that you suggest does not appear to really create any new features in either the source port or in DOSBox, other than the option to run one inside another, which is something one could do with probably any two arbitrary software products.

 

BTW, I keep forgetting to ask, you probably know about @kgsws' experiments with code injection that allow to run Chocolate Doom inside DOS Doom (literally inside, not in the way you seem to suggest with your source port concept). I wonder what you think about this?