Arena - DOS Box guide

[hoss_streebeck]

(Copied & edited from previous replies per request.)

PART I: Running DOS BOX

DOS Box creates a virtual computer on your real computer. To get it to work, you also have to make a virtual hard drive for it and if you play cd games, a virtual cd drive as well. This is accomplished using the MOUNT command. It looks basically like this:

MOUNT (virtual drive name) (real drive name)

After DOS Box starts you type in the MOUNT commands and then hit enter. Once you figure it out, you can also put the lines at the end of your config file so they will run automatically every time you start.

To make the virtual hard drive, you have to pick a location for it it use. In my case, I use the games folder on my real drive. So it looks like this:

Z:\> MOUNT C C:\GAMES (Enter)

What I’m doing is telling it to make the games folder on my real drive the C drive on the virtual computer.

I use my 2nd cd drive (e) for the virtual cd so my command looks like this:

Z:\> MOUNT D E:\ -T CDROM (Enter)

This tells it to make the e drive on my real computer the D drive on the virtual one. The tag -T CDROM tells it it’s a cd so it can do whatever it needs to do.

After you get those two lines in, you’re ready to rock. Arena is in a folder called ARENA in my games directory. So to start it you do this:

Z:\> C: (Enter) <-- switch to the C drive (I also have this line at the end of my config file)

C:\> CD ARENA (Enter) <-- change to the ARENA folder

C:\ARENA> ARENA (Enter) <-- run the game


PART II: Getting up to speed

The reason Arena runs slow on DOS Box is because you have to increase the speed of the virtual computer. This is shown at the top where it says:

Cpu Cycles: 3000

After you start, hit Ctrl-F12 to increase it. It will prolly go in increments of 500. I just started tinkering with Arena and I'm finding the comfort zone to be somewhere between 15000-20000. Once you find where you like, you can also put this in your config file so it starts at that value automatically.

Oh, and one last thing - to switch to fullscreen hit Alt-Enter.

Hope this helps everyone. Long live DOS - The last thing Microsoft made that kinda worked!

[Bear]

Welcome hoss, I swa that codex offered to sticky this and since he is not here at the moment, I took the liberty. Thank you for your input that should help a few people out.

[hoss_streebeck]

Thanks for the welcome, greetings to all!

[Codex]

Thanks bear. And hoss, hope to see you around in the other forums as well

[Timmeh]

I know I probably don't have to have permission to move this information to the wiki, but do you think I could? Currently the DOSbox guide for running arena sends you to the daggerfall one. And that one wasn't very helpful for me.

[Bear]

Asking hoss through pm or e-mail would probably be the best bet!

[Larsmop]

this was really helpful with all other dos games that i play

[Reaper67]

I figured out my problem. Now I would like to know a couple of things. First, where do I find the controls and second, can I play in full screen?

[Leilah]

The DOSbox controls are in the readme file, for Arena controls, see the the wiki. Alt-Enter takes you into fullscreen.

[Reaper67]

I figured it out on my own over the weekend. Thanks anyway though.

[harryroy]

Hello everyone
And Thanks hoss_streebeck DOS Box guide it's really helpful for me.

[tarianz]

Cannot understand how to make virtual drive?

[achrdili]

hi, I kinda have a problem, so I run Arena and give cycles count to max. when I am in City it works well but in dungeons it sucks and also when I max the details it becomes very slow. any solutions?

[OblivionDuruza]

tarianz, you might like to try the Arena Setup executable if you're having trobules with DosBox. It's safe (I've used it before) and it installs Arena, ready to play.

[Harvey]

core = dynamic

I would really recommend use this in dosbox.conf. Basically, this option enables JIT, and if you know what it is, you won't turn it off unless it makes game glitch. Completely erased any lag for me.

[MrFlibble]

hi, I kinda have a problem, so I run Arena and give cycles count to max. when I am in City it works well but in dungeons it sucks and also when I max the details it becomes very slow. any solutions?

I had the same kind of problem with both max cycles and fixed cycles. At the same speed setting the game would zip ultra fast in cities yet slow down almost to a crawl in the wilderness around the same city.

I discovered that there's an option in DOSBox to limit the maximum amount of CPU cycles it emulates instead of using either as many cycles as the host machine can handle or a fixed amount of cycles. This parameter is described in detail in the DOSBox Wiki here and here. Using this seems to positively affect game performance.

The DOSBox Wiki suggests that 26,800 cycles is a rough equivalent of a 486 66 MHz, so to set this value as the cycles ceiling DOSBox will emulate you need to use the following in dosbox.conf:

Code: Select all

cycles=max 70% limit 26800

I put 70% as an arbitrary value simply by judging that 100% will be too much anyway. You can try another percentage value but the max cycles will be decided by what you put after the limit parameter. Don't use auto because Arena is a real mode programme and will not switch to max cycles automatically.

This can be used in combination with the built-in speed control as described in the game manual. Add the -delay:# command line parameter to ARENA.BAT. The developers suggest -delay:3 as acceptable speed but this is a bit slow for the emulated 486 (may be good for a Pentium though), -delay:2 seems good.

AFAIK the severe slowdown during the fade-in animation of on-screen messages has been found to be caused by the fullscreen double buffering option in DOSBox, so this is suggested to be turned off. However you can also turn off the fade-in animation in-game by pressing F4 according to the manual.

[MrFlibble]

JIC someone misses the other thread, recently I experimented with running Arena in DOSBox with Gravis UltraSound emulation, and have come up with a setup that works rather decently for me, although the speed in the game is still very uneven, down to different frame rates in different parts of the same dungeon.

[SeaGtGruff]

The uneven speed might be due to the view distance. The Detail(s?) game setting, which tends to confuse people because it has no effect on the game's graphics quality, is for controlling the view distance that the game renders. I always set it at the maximum level, which runs fine when emulating a high CPU speed-- say, 50000. But with a lower CPU setting there can be very noticeable slowdowns in towns or dungeons depending on how close you are to the town's walls or dungeon's borders. Basically, it seems like the game doesn't load and render as much data about what to draw if you're closer to a boundary wall than the view distance, so the game can seem to be running slowly-- or at its normal speed-- if you're in the center of a town or dungeon, but then speed up noticeably if you're close to a boundary wall, especially in a corner of the map where you're close to two boundary walls.

[MrFlibble]

The uneven speed might be due to the view distance. The Detail(s?) game setting, which tends to confuse people because it has no effect on the game's graphics quality, is for controlling the view distance that the game renders. I always set it at the maximum level, which runs fine when emulating a high CPU speed-- say, 50000. But with a lower CPU setting there can be very noticeable slowdowns in towns or dungeons depending on how close you are to the town's walls or dungeon's borders. Basically, it seems like the game doesn't load and render as much data about what to draw if you're closer to a boundary wall than the view distance, so the game can seem to be running slowly-- or at its normal speed-- if you're in the center of a town or dungeon, but then speed up noticeably if you're close to a boundary wall, especially in a corner of the map where you're close to two boundary walls.

That seems like a good explanation! I play with max detail settings too, but I think that uneven speeds remain at very high emulated cycle counts too (50,000 is quite a lot), perhaps being less noticeable. On the other hand, higher cycle count makes screen tearing more apparent.

What has always annoyed me is that when you crank up CPU cycles, NPC animations in towns also speed up, but if you use the built-in speed adjustment (pressing the plus or minus keys in-game, or using the -delay command lime parameter), this not only slows down the animations, but also the entire game's speed. In fact, just recently I ran a test with a relatively low amount of fixed cycles and tested various detail settings, and I can confirm that when you max out the details, this also slows down NPC animations along with movement speed. I guess this is yet another example of sloppy coding on Bethesda's part.

[MrFlibble]

What has always annoyed me is that when you crank up CPU cycles, NPC animations in towns also speed up, but if you use the built-in speed adjustment (pressing the plus or minus keys in-game, or using the -delay command lime parameter), this not only slows down the animations, but also the entire game's speed. In fact, just recently I ran a test with a relatively low amount of fixed cycles and tested various detail settings, and I can confirm that when you max out the details, this also slows down NPC animations along with movement speed.

Recently I experimented with DOSBox settings a bit more and settled for a relatively high cycle count (still lower than 50,000) plus a moderate slowdown invoked by the -delay command switch, as described here.

This results in decent NPC animation and movement speed. One thing I noticed though is that some NPCs have their animations played too fast, like the street [&@%!] in a blue dress. Most other NPCs like tavern patrons, innkeep, mages, etc. have their animations played at what seems the intended speed.

[SeaGtGruff]

I've been running Arena at 15000 cycles for a while now, which I settled on after trying out a number of different values. At first it was driving me crazy because it seemed much too slow, but I think the animation of the ambulating characters looks very natural as far as the movement speed of their arms and legs. Eventually I got used to my character's speed when moving forward, turning around, or swinging my weapon.

As far as what I'd said before about how things seem to slow down or speed up depending on how far away you are from the edge of town or the dungeon's boundary, I think a large part of it has to do with the way Arena renders things in layers based on distance, with farther objects and surfaces being rendered first, and closer objects and surfaces being rendered over them. That's how you can see things that are inside of a room through the door's keyhole, or how you sometimes see water or lava through the cracks where two cells are supposed to fit together but the way their edges are rendered will occasionally leave gaps where the pixels of the water or lava show through.

Also, the speed tends to slow down dramatically in fog and precipitation-- but especially in fog-- presumably because the game needs to do additional work to merge or blend the fog's graphics with the normal "clear day" graphics of the buildings, trees, people, etc.

And the colors of everything need to be adjusted based on the time of day, the amount and color of illumination, even differing amounts of illumination at different distances inside dungeons.

When you think about it, the graphics engine was pretty advanced for its time, especially considering how slow computers were back then as compared to today.

[MrFlibble]

I've been running Arena at 15000 cycles for a while now, which I settled on after trying out a number of different values.

What DOSBox build are you using? Also do you force it to switch to dynamic core?

Some time ago I set up 86box to see if that definitely more accurate emulator would be closer to playing the game on real hardware. Unfortunately, even with an emulated 486 most of the issues remained, i. e. unequal speed, general sluggishness and so on. But it's playable, and I guess more or less comparable to what I arrived at with my own DOSBox tinkerings.

We may only hope that maybe a project like DaggerFX would be able to bring the game to a more playable/robust state on modern machines, in the absence of actual source ports? Or maybe not, or at least not without extensive optimizations, since it seems that Arena's many performance deficiencies arise from the original code not having been particularly well optimized. Also perhaps, Arena being a real-mode game, if would be more prone to direct reverse-engineering, like Dune II? OpenDUNE actually works pretty well.

[SeaGtGruff]

I'm using DOSBox 0.74-3. (Hmm, is it odd that DOSBox has been around for so long but doesn't have a version "1.0" yet?)

If I remember correctly, most of my configuration settings were taken from recommendations on the UESPwiki site, but I did tinker with them a bit, especially any graphics-related settings and the CPU speed setting. Following are some of the settings I use:

fullscreen=false
fullresolution=original
windowresolution=1536x960
output=openglnb
aspect=false
frameskip=0
scaler=none
machine=svga_s3
memsize=32
core=dynamic
cputype=auto
cycles=15000
cycleup=20
cycledown=20

The 1536x960 resolution, no aspect ratio adjustment, and no scaler is to get the largest possible window that will fit on my desktop, with square pixels and minimal stretching of pixels. Since the original resolution is 320x200, 1536x960 gives pixels which are magnified by 4.8, so there's some variation in the pixel sizes-- I guess most pixels are magnified by 5, and every 5th pixel is magnified by only 4, or something like that-- but it isn't enough to be obvious. I like square pixels because they make the maps and the drawings at the start of a new game look better-- squares are square and circles are circular-- and I think the character screen also looks better with square pixels, although NPCs and monsters do seem to be designed more for a 4:3 screen ratio. My reasoning for using square pixels is that back in those days most people had CRT monitors rather than LCD monitors, and most CRT monitors had controls for adjusting the display size and position. Regular TV sets were designed to deliberately overscan the image so consumers wouldn't complain to TV manufacturers about how the new TV set they'd bought was defective because there were black areas around the sides of the picture instead of the picture filling up the entire screen. Computer screens were a different animal entirely, because people want to be able to see the entire image instead of having it be chopped off (or offscreen) at the four edges of the screen, so the image is deliberately underscanned such that a border is visible around the image-- but then the nicer CRTs would let you shrink or expand the vertical and horizontal size of the picture, as well as shift it up, down, left, and right, so you could try to minimize the amount of border shown and get the image centered as perfectly as possible. I'm sure you know all of that, but my point is that people who played Arena on their CRT monitors back in the day could try to adjust the width and height of the image to get as close to square pixels as possible, if they wanted to-- and I'm the kind of person who used to do that sort of thing back then with other games and programs.

I have a theory as to why Arena's graphical performance can be so much slower than Daggerfall's, given that (as far as I know) they both have very similar engines and were designed for pretty much the same computer specs.

If you look at Daggerfall's pixels, I think they are always solid colors. Due to the number of colors used, that means the palette needs to be adjusted or redefined sometimes. You can see this in the little preview images used with the saved games-- a given save's image might look like some of the colors are wrong, because whatever color IDs they'd used for those pixels were different colors than are used in the currently-loaded palette. Most of the color IDs of the palette were probably set to "fixed" or unchanging colors, to minimize the "wrong color" effects of looking at six saved game previews at the same time when the palette of each preview might be a bit different than the palettes of the other previews. But it looks like a certain number of color IDs in the palette were redefined as needed so the designers had a much broader range of colors to work with despite there being a finite number of color IDs in the palette.

But if you look closely at Arena's pixels, you can see that many, if not most, are actually 2 different colors dithered together. This is most evident when an object's pixels are greatly magnified to make the object larger, such as trees or the textures on the surface of a wall. It looks like they were using a palette of fixed colors, with the colors chosen to allow for the greatest potential range of hues to draw with, but then they used dithering to "expand" the number of hues. It isn't as obvious as with graphics modes that have palettes with a relatively small number of colors, such as a 16-color mode. But if you can look closely, you can see that they dithered colors "A" and "B" to get a color halway between, or "C" and "D," etc. That would be perfectly fine if displaying a still picture, but instead the engine needs to display moving pictures. And because of how the engine uses (I assume) a sort of pseudo-ray-tracing layering, such that we can see through keyholes or between the bars of cell doors; and because of how stored images of textures and trees with widths and heights of a specific number of pixels are magnified or shrunk as we get closer to, or farther from, them; and because of how the game modifies the colors of individual pixels to simulate the effects of things like fog or different amounts of lighting; the end result is that the engine must be doing an incredible amount of "heavy lifting" just to display a single frame. I've been wondering if there might be a way to hack the game's graphics data to try to eliminate as much of the in-between dithered colors as possible, so there would be one less chore for the graphics engine to deal with when magnifying or shrinking the pixels of textures and objects.