Blood and DN3D switch the CPU to protected mode, and with the default setting of core=auto in DOSBox that causes a switch from normal to dynamic core. If your programs run in real mode, which seems likely, then you can probably get the same kind of speed increase with the core=dynamic setting, and then maybe combine that with the cycles=max setting.

DOSBox IS NOT SUITED TO RUN YOUR NON-GAMING DOS APPLICATION

ripsaw8080 wrote:

Blood and DN3D switch the CPU to protected mode, and with the default setting of core=auto in DOSBox that causes a switch from normal to dynamic core. If your programs run in real mode, which seems likely, then you can probably get the same kind of speed increase with the core=dynamic setting, and then maybe combine that with the cycles=max setting.

Hi. I tried this and it did not work, same slow speed.

r.cade wrote:

DOSBox IS NOT SUITED TO RUN YOUR NON-GAMING DOS APPLICATION

Hi. It says repeteadly many times that DOSbox is not for non-game applications. But how DOSbox can know if the program is a "game". all programs are bunch of codes. Also, my program can be considered a "game". Because I am actually trying to write one as a hobby. fifty cubes and pyramids rotating around and user flying around them is just a beginning. if it doesnt work, I am blocked from writing a dos-game.

mhdbox385 wrote:

Hi. I tried this and it did not work, same slow speed.

Perhaps your code needs more optimization or a nice rethink? If you're using Borland's graphics unit, I'm not entirely sure how fit it is for writing the fast paced graphics a game requires, perhaps looking into assembler (Turbo Assembler in that case) may be worth it (there are some tutorials, specific for Turbo Pascal floating around the web still).
If you want a more modern platform...why not use Free Pascal? Your existing code should be mostly compatible and it produces native binaries (at least for Windows, OS X and Linux), bypassing DosBox entirely.

Keep in mind, even with cycles set to max, you likely won't get the same speed out of DosBox that you will running your programs natively, since DosBox essentially has to emulate a whole separate machine in software.

bloodbat wrote:

mhdbox385 wrote:

Hi. I tried this and it did not work, same slow speed.

Perhaps your code needs more optimization or a nice rethink? If you're using Borland's graphics unit, I'm not entirely sure how fit it is for writing the fast paced graphics a game requires, perhaps looking into assembler (Turbo Assembler in that case) may be worth it (there are some tutorials, specific for Turbo Pascal floating around the web still).
If you want a more modern platform...why not use Free Pascal? Your existing code should be mostly compatible and it produces native binaries (at least for Windows, OS X and Linux), bypassing DosBox entirely.

My program uses 320x200x256 mode13h graph regime. just like games like duke nukem or blood. I am not using pascal graph libraries. I am using only crt unit, dos unit and my own mhd3d unit. I was wrong. It runs about 100 times slower in dosbox. In ms-dos 6.22 it runs about 80 fps, in dosbox it runs about 0.8fps.

Maybe blood and duke nukem are more optimized at writing graphics to the screen than your program is.
Are you perharps doing some waits for retrace or something like that, which could cause a massive slowdown ?

Qbix wrote:

Maybe blood and duke nukem are more optimized at writing graphics to the screen than your program is.
Are you perharps doing some waits for retrace or something like that, which could cause a massive slowdown ?

No, there's absolutely nothing that would slow down my program, no waits, not other stuff. Mode 13h (320x200x256) is really very simple. to put pixel I just change the byte value at needen memory and that's it. My program works really fast on ms-dos. like I said about 80 frames per second the screen memory is updated. when I put textures and use z-buffer (right now I don't) and make it a real game it would probably slow down to about 25-35 fps. I could do a few more speeds up (at the expense of more complexity) but that would probably only bring me to about 100 fps, my current program.

You can easily expect dosbox to run 10-20 times slower than the machine you're running on.
Run using dynamic core for highest speed and hope you're program doesn't make heavy use of self modifying code since that kills performance

If you change every pixel by writing immediately to the frame buffer your program won't run very fast in general. 3D games where the whole screen changes each frame first render to memory and then copy everything to the screen buffer. I suppose the difference will be more pronounced when using dosbox.

Also, what CPU are you using? If you are using a modern CPU and your program still runs at 80fps in Mode 13h your program is either really demanding, inefficient or both.

idspispopd wrote:

If you change every pixel by writing immediately to the frame buffer your program won't run very fast in general. 3D games where the whole screen changes each frame first render to memory and then copy everything to the screen buffer. I suppose the difference will be more pronounced when using dosbox.

Also, what CPU are you using? If you are using a modern CPU and your program still runs at 80fps in Mode 13h your program is either really demanding, inefficient or both.

That's exactly how I am doing, first rendering in separate memory then movind it to screen buffer very fastly.

about your cpu question, I don't think so. 80fps (not having textures and z-buffer) is good result, because, although my cpu is modern, neither ms-dos nor my program can utilize all of its capabilities, they are for 286 !! and they definitely can't or don't use graphics card that modern games are using like ATI or NVIDIA... I think I am a good programmer and my skills are good. I am sure there's no problem with my little 3D program. what fps would expect it to have in real dos? 1000fps ? 😁

Also I was about something else as well, I just check out and found out that There actually about 102 pyramids and 102 cubes in my program. that makes about 1600 polygons being rendered all having different solid colors (but no texture or z-buffering yet). anyway, I'll work on it a little more and I'll get back to you and tell about my status. maybe I can improve it a little more.

By the way is it possible that DOSbox has problems with emulating 8087/80287 ? Because my program is using it. Could that be the source of slowlyness ?

mhdbox385 wrote:

That's exactly how I am doing, first rendering in separate memory then movind it to screen buffer very fastly.

OK, sounded different to me.

about your cpu question, I don't think so. 80fps (not having textures and z-buffer) is good result, because, although my cpu is modern, neither ms-dos nor my program can utilize all of its capabilities, they are for 286 !! and they definitely can't or don't use graphics card that modern games are using like ATI or NVIDIA... I think I am a good programmer and my skills are good. I am sure there's no problem with my little 3D program. what fps would expect it to have in real dos? 1000fps ? 😁

If your program runs with "only" 80 fps natively on a modern CPU it doesn't make much sense to write it using 16 bit code. It would probably run with much less than 1 fps on a 286. You could try PCem if you want to have an approximation of the precise speed. I would use at least 32 bit code. If you use lots of floating point 32 bit code might not even matter that much, maybe for transferring data to the frame buffer, that should be done with REP MOVSD.

I don't think that x87 speed is the problem. Although I remember Turbo/Borland Pascal inserts FWAIT instructions after each x87 instruction, maybe that would slow things down.

You could to test you program once with nothing drawn (only transfer to frame buffer), and than with only drawing (no transfer to frame buffer). Maybe that will give some insights.

To be sure that it has nothing to do with my program I tested a very simple program. The program just adds two real numbers a 100 million times and then displays how many seconds have passed. I run it on dos it takes about 1 second. I run it on dosbox it takes about 100 seconds. the program pseudo-code is like this:

a=3.4767643
b=7.3463465
get time t1
do 100 million times: c=a+b
get time t2
display t2-t1

So you see slowlyness has nothing to do with my program. it about dosbox.

Yes

Harekiet already answered that.

Use DOSEMU or other virtualization programs if you require speed. DOSBox is a emulator for DOS games. Speed for us is not a good thing (within reason).

I read about DOSEMU in wikipedia. it is said the that DOSEMU can achieve almost native speed of dos. but it is for Linux only. Aren't there such good emulator for windows that you can suggest ?

Not emulator, virtualization software. Like VMware, Virtual PC or VirtualBox.