Get rid of the other process(es) that steals CPU time, then it is not required to start with high priority.

That's NOT the problem.
I'm asking about how to launch a game with VDM sound support with high or realtime priority, I'm NOT saying any process is stealing my cpu cycles: I KNOW every process running in my Windows system. My reasons are quite different, if you don't know how to do it, then don't answer this thread,
Thanks!

My reasons are quite different

So is this some secret conspiracy where you aren't allowed to talk about your
reasons but rather beat on somebody who gave a perfectly useful answer?

gaula92 wrote:

That's NOT the problem.
I'm asking about how to launch a game with VDM sound support with high or realtime priority, I'm NOT saying any process is stealing my cpu cycles: I KNOW every process running in my Windows system. My reasons are quite different, if you don't know how to do it, then don't answer this thread,
Thanks!

Who made you a moderator? 😜

Anyway, using a script qualifies you as a bottom-feeder in the programming hierarchy... 😁 Here is some Visual Basic code which could be adapted to your requirements for setting a higher process priority. You could then call said program in a script.

Remember, you are trying to change the process priority of a particular NTVDM process, not of VMDsound or the VDMsound LaunchPad. Now it would be possible to modify the VDMsound code in DOSDRV.EXE which would raise the process priority of the particular NTVDM process in which DOSDRV.EXE was executing, feel free to modify the DOSDRV.EXE source code and re-compile. We would all benefit...

dvwjr

You're righ, guys: I sounded rude.
I'm very sorry, Hal. I just didn't read twice what I wrote... I meant something like "that's not the kind of solution I am looking for, but thanks for trying to help me", and in the end it sounded very different.
My sincere apologies.

The only "secret reason" is that DOS games seem to run a lot better if they're launched in realtime priority: there's no AV or other shit in my software, only 5 system processes running in a very minimalistic enviroment, but priority affects the games performance anyway (not the speed, but the smoothness of scrolling routines, for example).

I'm trying the code you gave me, even if VB is not my cup of tea...scripting is lame, I know.

Thanks guys!

dvwjr wrote:

Anyway, using a script qualifies you as a bottom-feeder in the programming hierarchy... 😁

I beg to differ. With the right scripting tools, I can do the equivalent of 50 lines of code in 5 lines of scripting. 😜

MiniMax wrote:

I beg to differ. With the right scripting tools, I can do the equivalent of 50 lines of code in 5 lines of scripting. 😜

I'm just teasing... 😁

Too many people became hooked on Vlad's LaunchPad, which hides from them that just a PIF file and two custom AUTOEXEC.NT and CONFIG.NT were being setup and used. Therefore they never seem to realize that all they need is DOSDRV.EXE and possibly a command-line pointer to a custom VDMS.INI file.

So for the original poster, he does not even need to use a script, just a WinXP CMD file and a WinXP PIF file to call a DOS batch file.

Say he has the game SYNDICATE WARS located in M:\DosGames\SWARS, which uses MAIN.EXE to start the game.

Inside said sub-directory would be:
****************************
There would be a MAIN.PIF with the parameter set properly for the MAIN.EXE file but actually calls the PLAY.BAT file.

There might be a custom AUTOEXEC.NT file for the game called by the PIF.
There might be a custom CONFIG.NT file for the game called by the PIF.

There would be a MAIN.EXE for the SYNDICATE WARS main executable.

There might be a custom VDMS.INI file for VDMsound configuration for SYNDICATE WARS with all the proper VDMS configuration parameters.

There would be a PLAY.BAT that has the execution of DOSDRV.EXE, then the SYNDICATE WARS executable MAIN.EXE command-line parameters.

The DOS batch file PLAY.BAT might look as follows:
****************************************
@Echo off
cls
DOSDRV.EXE -i:VDMS.INI
MAIN.EXE /w /g
****************************************

The DOSDRV.EXE is picked up in the WinXP PATH, since if VDMsound is properly installed the VDMsound sub-directory is in the PATH statement.

So to start the NTVDM for the SYNDICATE WARS DOS executable program MAIN.EXE via the WinXP START command:

START /HIGH /DM:\DosGames\SWARS M:\DosGames\SWARS\MAIN.PIF

This gives him what he wants without a script, just using a lowly CMD and BAT file to run some DOS game at HIGH priority in the WinXP NTVDM with the VDMsound DOSDRV.EXE (Virtual Device Driver (VDD) that Vlad wrote) loaded before the DOS game is executed.

It is what he really wanted to do, not try to make the LaunchPad shell scriptable. 🤣

dvwjr

@dvwjr: WOW!!! And I really mean ...WOW!!!
I need to get home and try some Jazz JackRabbit action in my Atom machine! 😁

Thanks!!

well, Jazz is just PERFECT now. Smooth scroll, perfect control and sound...

what else can I ask for? 😁

Long live VDMSOUND! DosBOX is SLOW! (yeah, get a dual core machine to emulate a 486 class computer, sure... I can use my cheap and ecologic ATOM machine to run dos games at full speed!!)

I actually hate those people who are too stupid to configure dosbox correctly
but that's not my problem. Works perfectly fine for me on a non-dualcore machine.

wd: you're totally wrong. I KNOW AND UNDERSTAND every little configuration parameter in dosbosx.cnf: I've used it for years now.

If I set 8000 cycles/sec, jazz will INTERNALLY run fullspeed even in bonus stages, but my computer won't cope with the emulation. You sure get it, you'e a developer. 😀
Now I CAN get it to cope with emulation if I set a large sound buffer, on top of the block size. A large block size will cause some delay, and I'm VERY sensitive to delay. Same goes for a large sound buffer.

I can gain some speed by setting the pcm rate at 48Kz, so my shitty azalia audio chipset won't have to scale, but it's not good enough.
For the last bot not least, I can use OpenGL or DDraw over the lame un-accelerated GDI buffer. That's great, my computer can cope with emulation...if I don't set DOUBLE BUFFER on. With db on, it can't cope anymore unless I change to a large sound buffer...etc...

you get it, wd?? I CAN play with settings, I understand the benefits and disadvantages if playing with each setting: I am noy even in front of the cnf file, damnit: I know it by memory because I have configured dosbox a hundred of times. I have compiled it on my gentoo linux systems dozens of times, too. On linux it just lacks a double buffer setting, and I've even added it to the source code in the sdl init code.

I've even compiled sdl for an accelerated directfb backend, but the bottleneck of dosbox is in complex timmings (cpu, lowlevel chipset emulation, vga...) so that didn't help.

Next time, think twice when you put yout hatred on someone. Configuring dosbox is a kid's play. It's just taht it's accuracy-for-speed tradeoff ON MY COMPUTED doesn't satisfy my expectations. Then again, it's free and somehow great, just not for me. I can get full speed, zero delay, with vdmsound. Native execution is better. Emulation is great for major architecture differences, but it's not the case with this machine. slow, but x86 after all.

Thanks!