Retrocade FAQ
-------------

This document is designed to answer the frequently asked questions with
regard to all versions of Retrocade. DOS/Windows/UNIX/Mac specific sections
will be indicated by those tags in parenthesis:

1. Why does Armor Attack flicker sometimes?
2. Why does Demon flicker really badly?
3. Why can't I get any backdrops with any of the games that support it?
4. How can I make a given game fit better with the screen?
5. I get "Game 'x' not supported no matter what I do. What's wrong?
6. I get no sound on *ANY* games. Why?
7. Some games have sound and some don't. Why?
8. I get a black screen whenever I try to run any game in Retrocade, or the
   machine locks up.
9. Is Retrocade (DOS) supposed to run under Windows?
10. Retrocade doesn't see my mouse/Wingman Warrior. Why?
11. Asteroids runs too fast
12. How can I alter the speed that a game is playing?
13. Where do I stick the ROM images?
14. Where do I stick the .PAK files?
15. I've modified my defctrls.ini file to make changes to the emulator's
    assignments, but nothing changes when I try the altered game again.
16. I'm really offended by the splash screen. How can I get rid of it?
17. How can I get screeshots of my game in progress?
18. What do the fields in the performance monitor actually mean?
19. Why don't you provide a way to have a smaller sampling rate to increase
    game emulation speed?
20. I want to use my own sample files with Retrocade. Can I do that?
21. The onscreen display does not come up at all when I hit F5. Why?
22. Why doesn't game 'x' save my high scores?
23. Retrocade shows the correct fps, but the game is running too fast.
24. Why doesn't Retrocade support all ROM revisions of a particular game?
25. Why is Retrocade so big? Wouldn't it be better/faster to break it up
    into smaller files?
26. Why are the games that use antialiasing and translucent vectors so much
    slower than the rest?
27. Why I can't turn the brightness all the way down to black?
28. Retrocade isn't as fast as everyone makes it out to be on my machine, but
    everyone else seems to be having great success. Why is my machine slower
    than people with equivalent or lesser powered machines?
29. I have a Riva128 chipset based video board, and I get a squished image
    on the left quarter side of the screen. What's going on?
30. What are the minimum requirements for all games to run full speed with
    Retrocade?
31. My Logitech Wingman Warrior spinner doesn't work, but the Wingman itself
    works just fine.
32. Why can't I set the FPS lower than 20?
33. What is Retrocade's purpose?
34. Why did you choose JPG over GIF or some other format for screenshots?
35. What video card(s) do you recommend for Retrocade for a PC?
36. The Williams games (Bubbles, Stargate, etc...) just sit there looking
    at me with "Factory settings restored" on the screen and won't start.
    What do I do to get it to go?
37. My Microsoft Sidewinder Gamepad doesn't work when I'm running Retrocade
    in a DOS box under Windows. Why not?
38. I get "Unable to copy screen contents into clipboard" whenever I try to
    get a screenshot.

--------

Q1. Why does Armor Attack flicker sometimes?

A. That is how the original game operated. This is normal.

--------

Q2. Why does Demon flicker really badly?

A. That is how the original game operated. This is normal.

--------

Q3. Why can't I get any backdrops with any of the games that support it?

A. It depends. 

First off, make sure you've downloaded the appropriate .PAK file and placed
it either in Retrocade's directory, or in the ./paks directory one level 
below the Retrocade directory. 

Secondly, make sure that the game you're trying to play really does have a
backdrop or an overlay.

Lastly, if you are running any of the vector games and aren't getting
backdrops when you think you should, most likely your video card does not
support 16 bit per pixel mode, or does not have access to the linear
framebuffer. If you have a VESA 1.x compliant card, you will not have
a linear framebuffer, and all graphics operations will need to be paged.
Retrocade never supports backdrops in 8 bit per pixel modes, and supports
backdrops/overlays in 16 bit per pixel mode only if your card has linear
framebuffer access.

A possible solution to this problem is to get a copy of Scitech Display
Doctor to enable this functionality in your card (www.scitechsoft.com).

--------

Q4. How can I make a given game fit better with the screen?

A. Try enabling the tweaked mode support (256x256, 224x288, and 288x224)
with the -tweak parameter (DOS). These modes are not included by default
since they can be problematic, and performance in these modes is not
optimal.

--------

Q5. I get "Game 'x' not supported no matter what I do. What's wrong?

A. Several possibilities. Make sure you're launching Retrocade with:
retro -g "game name", with the full game's name - NOT THE ZIP filename. If
the game is multi-worded, make sure you use quotes! Make sure that you have
the appropriate ZIP file for the game you want to run in either the current
directory where the Retrocade executable is launched, or in the subdirectory
where you have -romdir pointing. Make sure your ZIP archive is good, by
doing a pkunzip -v zipfile.zip on the game in question.

--------

Q6. I get no sound on *ANY* games. Why?

A. Do you have a Sound Blaster Pro (or better) in your machine? Retrocade
requires that you have a Sound Blaster Pro (or better/compatible).

Is there a BLASTER= environment variable set? If not, Retrocade cannot find
your sound card.

Is the interrupt set higher than IRQ 7? If so, Retrocade will not function,
as DOS4GW will not handle interrupts higher than IRQ 7. Other DOS extenders
that DO support higher interrupts have been tried with varying success.
DOS4GW Is by far the most stable.

Are you certain that the game you're trying to run really does have sound?
If not, you will get silence. Some of the games we have either not gotten
the samples for or 

If all else fails, and you think you should be getting sound but aren't,
add the -log command to Retrocade when you start it and run your game, play
it for a few moments, and exit. It will create a game.txt file. Send that
file (zipped, please) to the Retrocade alliance.

--------

Q7. Some games have sound and some don't. Why?

A. The easy answer is some games do have sound engines in them, and some
don't. Retrocade is a continuing work in progress, and thusly everything
isn't complete.

Some games require samples, too. Do you have the appropriate sample files
(.PAK) for the games in question (if they exist)? Check the Retrocade
homepage at (www.retrocade.com) for the appropriate .PAK files. If you have
a corrupt .PAK file for any given game, the sound effects will not load up
or make any sound at all. You also may have an older .PAK file. Check the
size on the www.retrocade.com web site to ensure that what you have is
the correct size, and is also the most current.

--------

Q8. I get a black screen whenever I try to run any game in Retrocade, or the
    machine locks up.

A. Wow. Real bad!

If you're running under Windows, reboot into DOS mode and try it again. Some
video card VXDs that provide VESA support are problematic, and the VESA
support may be buggy.

If you get the same results under straight DOS, add the -log command line
option to the Retrocade executable so that it will generate a game.txt file
and log debugging information. Send this file (zipped, please) to the
Retrocade alliance for examiniation. Also note the kind of video card you
have.

--------

Q9. Is Retrocade (DOS) supposed to be able to run under Windows?

A. A cautious "yes". We've found that Retrocade runs fine under Windows on
a myriad of machines. However (and a *BIG* however):

Many problems can arise from running under Windows. Joystick control may
be erratic, games may not run at totally proper speeds, some video modes
will not be available, sound might not be available, certain controllers
will not work properly (Wingman Warrior spinner for example), and other
potentially oddities. Windows is an ugly world where there's no guarantees
that two "identical" installations will work the same. Windows virtualizes
quite a few things for DOS programs, such as interrupts, timers, and
controller support. The reports may come in erratically and cause flaky
and inaccurate operation under Windows.

So the official stance is that if it works OK in DOS, but doesn't in Windows,
we're sorry, but RetroDOS is not officially supported under Windows.

However, if you're experiencing system lockups, protection faults, or other
crashing uglies, please invoke Retrocade with the -log option, zip up the
game.txt file it generates, and mail it to the Retrocade alliance for
examiniation. Retrocade should not crash under Windows - only certain options
should not work or work erratically.

--------

Q10. Retrocade doesn't see my mouse/Wingman Warrior. Why?

A. Do you have a mouse driver loaded? The best way to tell is to do a mem /c
at a DOS prompt. If you're running in a DOS box under Windows and your
mouse works OK there, then a mouse driver is not needed. If you are running
under straight DOS and get no mouse support, make sure you have a mouse
driver loaded.

In the case of the Wingman Warrior, you must have the Logitech driver
that supports the Wingman Warrior and the mouse, and it must be invoked
with the DUAL option so that they both work.

--------

Q11. Asteroids runs too fast

A. Asteroids does not run too fast.

There were two versions of Asteroids produced - a 1MHZ and 1.5MHZ version.
The most common are the 1.5MHZ versions (which yeilds 60fps), and that is
what Retrocade defaults to. They were not different ROM revisions, only a
master clock divider chip on the board that was modified to make the game
run faster.

See Q12 below for how to change the speed at which it plays if you're
too much of a wimp to play the faster version. ;-)

--------

Q12. How can I alter the speed that a game is playing?

A. Bring up the onscreen display with the ` key (you know, like Quake!).
Scroll through the options with the up/down arrow keys until you get to the
"Frames Per Second" display. Use the left/right arrow keys to adjust the
game's speed. This can be done while the game is paused or is playing. Hit
the ` key to drop the onscreen display.

--------

Q13. Where do I stick the ROM images?

A. Wherever you'd like!

* In the current subdirectory where Retrocade's executable is
* In the ./roms subdirectory off of where Retrocade's executable is
* In a user defined subdirectory specified by -romdir

If you have a common ROM subdirectory, specify -romdir c:\romdir (or
wherever) to indicate where your ROMs are. There is no need to reissue
this command more than once. It is sticky, and is stored in Retrocade's
registry.

--------

Q14. Where do I stick the .PAK files?

A. One of two places:

* In the current subdirectory where Retrocade's executable is
* In the ./paks subdirectory off of where Retrocade's executable is

--------

Q15. I've modified my defctrls.ini file to make changes to the emulator's
     assignments, but nothing changes when I try the altered game again.

A. Aha! You assume too much from the great defctrls.ini file!

The defctrls.ini file is only read when you run a game for the first time
(hence the name, DEFault ConTRoLs). After that, it pulls all settings out
of the registry, which is where your controller assignments are stored.

If you want to load your new default configuration, then use Retrocade's
GUI to load up your controller configuration for that game.

--------

Q16. I'm really offended by the splash screen. How can I get rid of it?

A. We're very sorry you're offended by a fully-clothed woman. Use the 
-nosplash option to keep her from popping up.

--------

Q17. How can I get screeshots of my game in progress?

A. Hit printscreen! You will get filenames like astdelu0.jpg, and other
various abbreviations for the other games as well. It uses the ZIP filename
as a basis for naming these, and sequentially replaces the rightmost
major part of the filename with numbers. They will be placed in the /scrnshot
subdirectory where your Retrocade executable was launched from.

--------

Q18. What do the fields in the performance monitor actually mean?

A. Various things:

Cpu Emu:

This indicates the percentage of time spent in the processor emulators of
the various games.

Render :

With Raster games, this is the percentage of time Retrocade is spending
updating the offscreen backbuffer. With vector games, this is the percentage
of time spent traversing the vector generator engines and creating a
linelist.

Blit   :

This is the percentage of time that Retrocade is spending transferring the
offscreen image to the video card itself. In vector games, this is the time
spent in the linedraw routines actually drawing/erasing the lines. NOTE:
When you have -vsync on, you'll notice your blit percentage go through the
roof. This is because when you are sync'd to vertical retrace, the speed
control is throttled to the update rate of the video card. The transfer of
of the offscreen image to the video card itself is done only during vertical
retrace and it must wait until it is complete before it can transfer the
image.

Idle   :

Percentage of time Retrocade is spent waiting at the system timer to allow
the next frame to be generated.

Don't be alarmed if it says 100% idle. Retrocade does statistical sampling
at an even pace as to where it spends its time. It does this at a rate of
twice your game's framerate. If less than 40% of the overall processor is
being used, then you will see 100% idle because the sampling rate is just
not fast enough to grab the statistical samples. We could increase the
sample rate, but it would slow emulation down significantly. Besides, it's
only really meaningful when things are not running as fast as you'd expect,
right?

--------

Q19. Why don't you provide a way to have a smaller sampling rate to increase
     game emulation speed?

A. In Retrocade's case the sound engine is efficient enough that a lower
sampling rate across all games has a miniscule effect on performance, and
thusly we decided not to bother enabling lower sampling rates.

--------

Q20. I want to use my own sample files with Retrocade. Can I do that?

A. No. The samples that are within the .PAK files are specially treated
samples. They come from a source of 16 bit samples, all at 44.1khz and
require that the zero crosspoints and loop points be set. This is not a
trivial process.

However, if you have good quality samples (44.1khz, 16 bit, and *CLEAN* -
not distorted or overdriven) that you would like us to include in games
that use them, contact the Retrocade Alliance and we'll work with you to
get them added.

--------

Q21. The onscreen display does not come up at all when I hit F5. Why?

A. You're running a vector game, right? The onscreen display requires the 
presence of a linear framebuffer to work. If you do not have VESA 2.x or
higher, you will not get a linear framebuffer. A linear framebuffer is not
required for raster games, and thusly will always work.

--------

Q22. Why doesn't game 'x' save my high scores?

A. Because game 'x' doesn't have high score saving abilities, or you've
deleted the hiscores.reg file, or the game itself does not have a high
score saving ability (Cinematronics games for example).

--------

Q23. Retrocade shows the correct fps, but the game is running too fast.

A. The first question is do *ALL* games run too fast? If not, then it could
be that you're starting the game on a higher level (Star Wars, for example,
on Medium and Hard will run the games faster than if you choose Normal).

Did you bump the frames per second accidentally in the onscreen display?
Hit ` and scroll through the options using the up and down arrows. The
correct (original) rate of the game will be shown in parenthesis.

It's possible that we've botched the framerate of a given game. If you think
so, let the Retrocade alliance know the game you have an issue with and
a rate that "feels" better. We've been known to make mistakes, since some of
us don't have access to these games to compare.

Another thing - If you're running DOSRetro, don't run under Windows to get
accurate timing. The virtualized nature of timers and such (that Retrocade
relies on to throttle correctly) will cause Retrocade to give you inaccurate
results speed-wise.

If all games are running too fast, you may have shut off speed throttling.
Hit F6 to turn it back on again.

--------

Q24. Why doesn't Retrocade support all ROM revisions of a particular game?

A. That's not Retrocade's focus. It's to get the most "playable" versions
of the games. Besides, the ROM revision differences are usually not
something that the end user would even notice, so we don't bother with doing
it.

--------

Q25. Why is Retrocade so big? Wouldn't it be better/faster to break it up
     into smaller files?

A. No. This is a common misconception. Just because an executable gets
bigger doesn't mean it will run slower. You might have seen other emulators
get bigger and slower, but not only was the size changing, the internal
main execution code was changing as well, which is the entire reason things
got slower.

Now, to give you an idea of the breakdown of the .EXE itself:

Retro.exe					3MB
68010 Emu					500K
68000 Emu					500K
Z80 Emu					190K
6809 Emu					215K
6809 Banked 				275K
6502 Zero paged emu		59K
6502 Regular emu			86K
6808 Emu					82K
Cinematronics CPU			43K
Compression libraries      100K
GUI Code					250K
Controller code			25K
Graphics library			200K
JPG Library                250K
Sound code					100K

That's 2.8 megabytes so far. The rest is taken up by the infrastructure
and the platform extensions themselves. So currently a game that would
require a 68000, a 6502, the sound core, the graphics library, the the
other support code would still be around a megabyte.

Breaking up the executable would also make it more difficult to maintain.
And besides, Retrocade is designed to be an all-in-one style of emulator
anyway, and would go against its goal.

In other words, bad idea.

--------

Q26. Why are the games that use antialiasing and translucent vectors so much
     slower than the rest? Why am I getting flicker?

A. This is a very good question, and I'm glad you asked, though the answer
is very long and involved. Now would be a good time to go get a beverage
of your choice:

I want to illustrate just what the linedraw code must go through to be able
to do regular, antialiased, translucent, and translucent/antialiased lines. 
I have taken a sampling of each of the linedraw code for the different modes.
What I have exceprted is the routine which does nothing more than set the
pixel and advance the pointer. If you know something about programming, you'll
understand right away. If not, then you should be able to glean how much is
required to do these modes by the sheer size of the code.

First, this is the main loop for a regular piece of linedraw code:

alignymSkip20:
		mov	[ds:edi], ax	; Store our full strength pixel
		sub	edi, esi	; Move back!
		add	bp, bx	; Add our slope value
		jnc	nocarryov120
		add	edi, edx	; Advance Y coordinate
nocarryov120:

That's it. Only 5 lines of code to do a regular single-thickness pixel
linedraw. Now, let's try the translucent vector only code:

alignaSkip220:
		mov	ax, [ds:edi]	; Get our source data
		mov	edx, eax	; Get our color
		and	eax, 007ffh	; 16bpp - no red
		and	edx, 0f800h	; 16bpp - Just red
		add	edx, [colorred]	; Add in our red color band
		test	edx, 0ffff0000h	; Did we overflow red?
		jz	noRedOv21	; Nope!
		mov	edx, 0f800h	; Red full
noRedOv21:

		or	eax, edx	; Put it back in with the color tuple
		mov	edx, eax	; Get our color
		and	eax, 0f81fh	; 16bpp - no green
		and	edx, 007e0h	; 16bpp - Just green
		add	dx, [colorgreen]	; Add in our green color band
		test	edx, 0fffff800h	; Did we overflow green?
		jz	noGreenOv21	; Nope!
		mov	edx, 007e0h	; Green full
noGreenOv21:

		or	eax, edx	; Put it back in with the color
tuple
		mov	edx, eax	; Get our color
		and	eax, 0ffe0h	; 16bpp - no blue
		and	edx, 0001fh	; 15 or 16bpp - Just blue
		add	dx, [colorblue]	; Add in our blue color band
		test	edx, 0ffffffe0h	; Did we overflow green?
		jz	noblueOv21	; Nope!
		mov	edx, 001fh	; blue full
noblueOv21:
		mov	[ds:edi], ax	; Store our translucent pixel
		sub	edi, [x_sign]	; Move back!
		add	bp, bx	; Add our slope value
		jnc	nocarryov210
		add	edi, [x_sign]	; To our video surface
nocarryov210:

Jumped from 5 lines to 30 lines. Lots more expensive. Remember, that this
is on a *PER PIXEL* basis. Also note that transluscency is reading from
the video memory to get good looking translucent vectors. This is a slow
process, since arbitrary line angles (Which this code handles) are not
sequential in memory, so no bursts can take place. Now that things
are starting to get a bit tougher, let's take a look at the antialiased 
only code:

alignymSkip20:
		mov	ax, [color]
		mov	edx, ebp	; Get our weighting
		shl	ebp, 16	; Save our weighting count for later
		mov	bp, dx	; Get our weighting back!
		and	bp, 0f000h	; Only the upper nibble matters
		shr	bp, 1
		mov	edx, eax
		and	eax, 007ffh	; 16bpp - no red
		and	edx, 0f800h	; 16bpp - Just red
		sub	dx, bp	; Sutract it!
		jnc	noredaaov0	; Nope!
		xor	edx, edx	; Screw that!
noredaaov0:
		or	eax, edx	; OR Our color back in!
		mov	edx, eax
		shr	bp, 5		; Shift 5 for 16bpp
		and	eax, 0f81fh	; 16bpp - no green
		and	edx, 007e0h	; 16bpp - Just green
		sub	dx, bp	; Sutract it!
		jnc	nogreenaaov0 ; Nope!
		xor	edx, edx	; Screw that!
nogreenaaov0:
		or	eax, edx	; OR Our color back in!
		mov	edx, eax
		shr	bp, 6		; Shift 6
		and	eax, 0ffe0h	; No blue
		and	edx, 0001fh	; Just blue
		sub	dx, bp	; Sutract it!
		jnc	noblueaaov0 ; Nope!
		xor	edx, edx	; Screw that!
noblueaaov0:
		or	eax, edx	; OR Our color back in!
		shr	ebp, 16	; Restore our weighting
		mov	[ds:edi], ax	; Store our full strength pixel
		add	edi, [x_sign]	; Move over pixel!
		mov	ax, [color]
		mov	edx, ebp	; Get our weighting
		shl	ebp, 16	; Save our weighting count for later
		mov	bp, dx	; Get our weighting back!
		mov	dx, 00014h	; Get our base
		shr	bp, 12	; Lower byte
		sub	dx, bp	; Subtract our weight
		shl	dx, 11	; Back to our position!
		mov	bp, dx	; And make it our weight target
		mov	edx, eax
		and	eax, 007ffh	; 16bpp - no red
		and	edx, 0f800h	; 16bpp - Just red
		sub	dx, bp	; Sutract it!
		jnc	noredaaov1	; Nope!
		xor	edx, edx	; Screw that!
noredaaov1:
		or	eax, edx	; OR Our color back in!
		mov	edx, eax
		shr	bp, 5		; Shift 5 for 16bpp
		and	eax, 0f81fh	; 16bpp - no green
		and	edx, 007e0h	; 16bpp - Just green
		sub	dx, bp	; Sutract it!
		jnc	nogreenaaov1 ; Nope!
		xor	edx, edx	; Screw that!
nogreenaaov1:
		or	eax, edx	; OR Our color back in!
		mov	edx, eax
		shr	bp, 6		; Shift 6
		and	eax, 0ffe0h	; No blue
		and	edx, 0001fh	; Just blue
		sub	dx, bp	; Sutract it!
		jnc	noblueaaov1 ; Nope!
		xor	edx, edx	; Screw that!
noblueaaov1:
		or	eax, edx	; OR Our color back in!
		shr	ebp, 16	; Restore our weighting
		mov	[ds:edi], ax	; Store our antialiased pixel
		sub	edi, [x_sign]	; Move back!
		add	bp, bx	; Add our slope value
		jnc	nocarryov120
		add	esi, [x_sign]	; Add our X throw
		add	edi, [x_sign]	; To our back surface, too
nocarryov120:

Gee - that one is getting a bit hairier, eh? 70 Lines of assembly
instead of 5! The 16bpp 5-6-5 red/green blue gradients must be broken
out, added, checked for overflow, and fixed up if so, then put back in
the original position. Of course, the antialiased routine above does
TWO pixels, but that's the nature if Antialiased lines - you need
to do two pixels - one that's full strength and one that's the halftone.

Now we meet the monster of all monsters. The antialiased/translucent
vector routines. Keep in mind that this is the *DEFAULT* mode for games
with backdrops:

alignymSkip180:
		mov	ax, [color]
		mov	[step], ebx	; Save our step size back
		mov	bx, [edi]	; Get our current pixel
		mov	dx, bx
		shl	ebx, 16
		mov	bx, dx
		mov	edx, ebp	; Get our weighting
		shl	ebp, 16	; Save our weighting count for later
		mov	bp, dx	; Get our weighting back!
		and	bp, 0f000h	; Only the upper nibble matters
		shr	bp, 1
		mov	edx, eax
		and	eax, 007ffh	; 16bpp - no red
		and	edx, 0f800h	; 16bpp - Just red
		and	bx, 0f800h	; 16bpp - Just red
		sub	dx, bp	; Sutract it!
		jnc	noredaaov8	; Nope!
		xor	edx, edx	; Screw that!
noredaaov8:
		add	dx, bx	; Add in our red color band
		jnc	noRedaatvOv16	; No overflow
		mov	edx, 0f800h	; Red full
noRedaatvOv16:

		and	edx, 0f800h	; Red full
		or	eax, edx	; OR Our color back in!
		mov	edx, ebx
		shr	edx, 16
		mov	bx, dx
		mov	edx, eax
		shr	bp, 5		; Shift 5 for 16bpp
		and	eax, 0f81fh	; 16bpp - no green
		and	edx, 007e0h	; 16bpp - Just green
		and	bx, 007e0h	; 16bpp - Just green
		sub	dx, bp	; Sutract it!
		jnc	nogreenaaov8 ; Nope!
		xor	edx, edx	; Screw that!
nogreenaaov8:
		add	dx, bx	; Add in our red color band
		test	dx, 0f800h	; Did we overflow green?
		jz	noGreenOv16	; Nope!
		mov	edx, 007e0h	; Green full
noGreenOv16:

		or	eax, edx	; Put it back in with the color
tuple
		shr	ebx, 16
		and	ebx, 01fh
		mov	edx, eax
		shr	bp, 6		; Shift 6
		and	eax, 0ffe0h	; No blue
		and	edx, 0001fh	; Just blue
		sub	dx, bp	; Sutract it!
		jnc	noblueaaov8 ; Nope!
		xor	edx, edx	; Screw that!
noblueaaov8:
		and	edx, 01fh	; Only the blue gradient
		and	eax, 0ffe0h	; 16bpp - no blue
		add	dx, bx	; Add in our blue color band
		test	edx, 0ffffffe0h	; Did we overflow blue?
		jz	noblueOv16	; Nope!
		mov	edx, 001fh	; blue full
noblueOv16:

		or	eax, edx	; OR Our color back in!
		shr	ebp, 16	; Restore our weighting
		mov	[ds:edi], ax	; Store our full strength pixel
		add	edi, [x_sign]	; Move over pixel!
		mov	ax, [color]
		mov	bx, [edi]	; Get our current pixel
		mov	dx, bx
		shl	ebx, 16
		mov	bx, dx
		mov	edx, ebp	; Get our weighting
		shl	ebp, 16	; Save our weighting count for later
		mov	bp, dx	; Get our weighting back!
		mov	dx, 00014h	; Get our base
		shr	bp, 12	; Lower byte
		sub	dx, bp	; Subtract our weight
		shl	dx, 11	; Back to our position!
		mov	bp, dx	; And make it our weight target
		mov	edx, eax
		and	eax, 007ffh	; 16bpp - no red
		and	edx, 0f800h	; 16bpp - Just red
		and	bx, 0f800h	; 16bpp - Just red
		sub	dx, bp	; Sutract it!
		jnc	noredaaov9	; Nope!
		xor	edx, edx	; Screw that!
noredaaov9:
		add	dx, bx	; Add in our red color band
		jnc	noRedaatvOv17	; No overflow
		mov	edx, 0f800h	; Red full
noRedaatvOv17:

		and	edx, 0f800h	; Red full
		or	eax, edx	; OR Our color back in!
		mov	edx, ebx
		shr	edx, 16
		mov	bx, dx
		mov	edx, eax
		shr	bp, 5		; Shift 5 for 16bpp
		and	eax, 0f81fh	; 16bpp - no green
		and	edx, 007e0h	; 16bpp - Just green
		and	bx, 007e0h	; 16bpp - Just green
		sub	dx, bp	; Sutract it!
		jnc	nogreenaaov9 ; Nope!
		xor	edx, edx	; Screw that!
nogreenaaov9:
		add	dx, bx	; Add in our red color band
		test	dx, 0f800h	; Did we overflow green?
		jz	noGreenOv17	; Nope!
		mov	edx, 007e0h	; Green full
noGreenOv17:

		or	eax, edx	; Put it back in with the color
tuple
		shr	ebx, 16
		and	ebx, 01fh
		mov	edx, eax
		shr	bp, 6		; Shift 6
		and	eax, 0ffe0h	; No blue
		and	edx, 0001fh	; Just blue
		sub	dx, bp	; Sutract it!
		jnc	noblueaaov9 ; Nope!
		xor	edx, edx	; Screw that!
noblueaaov9:
		and	edx, 01fh	; Only the blue gradient
		and	eax, 0ffe0h	; 16bpp - no blue
		add	dx, bx	; Add in our blue color band
		test	edx, 0ffffffe0h	; Did we overflow blue?
		jz	noblueOv17	; Nope!
		mov	edx, 001fh	; blue full
noblueOv17:

		or	eax, edx	; OR Our color back in!
		shr	ebp, 16	; Restore our weighting
		mov	[ds:edi], ax	; Store our antialiased pixel
		mov	ebx, [step]	; Get our step size back
		sub	edi, [x_sign]	; Move back!
		add	bp, bx	; Add our slope value
		jnc	nocarryov1180
		add	esi, [x_sign]	; Add our X throw
		add	edi, [x_sign]	; To our back surface, too
nocarryov1180:

Wow! That's a bit over 120 lines of assembly code on a *PER PIXEL* basis!
The aa/tv linedraw code above is roughly 30 times slower (including the
PCI overhead) than the regular linedraw code at the beginning of this
message.

And this isn't crappy compiler-output code (compiler output is MUCH worse)
It's reasonably well optimized assembly.

Also, consider that translucent vector lines must be erased and redrawn
every single frame, whereas in the antialiased or regular linedraw modes,
they only need to be erased if they have moved from the last frame.

The bottom line is, antialaiasing is an expensive process CPU-wise.
translucent vectors are not quite as expensive CPU-wise, but are very
expensive PCI-bus wise. When you combine the horrors of antialiasing
and the expensive PCI-bus reads to video memory, it gets many times slower
and that's why you see flicker in some cases.

We're currently using a dirty linelist and a video card backbuffer to
be able to keep things steady. If your card does not support more than 1
video page at a given resolution, then God help you. Any modern card with
a megabyte or more of RAM will have 2 or more pages available, so I'm
suspecting that this is not the problem. All vector games with backdrops
default to 640x480 @ 16 bits per pixel, which winds up using about 1.2
megabytes of RAM.

And no, using a memory buffer and blitting dirty tiles will not help
performance - it will hinder it - especially when things get busy. Already
tried this approach.

Retrocade is clocked to the system timer, and will update the vectors at its
rate. The problem with this is that the video card may not be synchronized
with the system timer, and you'll get updates during the middle of a vertical
retrace, and you see flicker. Some cards will wait until the retrace is
complete before flipping the page and you won't have this problem, but a
good number don't. That's when you should use the -vsync option. This will
synchronize the updates to the vertical blanking period. If you still get
flicker after using this option, then you need more CPU horsepower to be
able to eliminate it. Either that, or shut off transluscency with the -notv
option.

We're currently looking at using MMX to handle the color gradient saturation
to help improve performance.

So when you run games with these kinds of features on your P90 and they
don't perform well or flicker, don't be disgusted that you have to disable
transluscency or antialiased vectors to get flicker free performance.

--------

Q27. Why I can't turn the brightness all the way down to black?

A. Because people fuss with the brightness controls sometimes, forget they've
turned them down all the way, and then complain that a given game gives them
a black screen. This prevents that from happening.

Besides, are you really going to be playing a game with the brightness
turned all the way down? We think not.

--------

Q28. Retrocade isn't as fast as everyone makes it out to be on my machine, but
     everyone else seems to be having great success. Why is my machine slower
     than people with equivalent or lesser powered machines?

A. It's a tough question to answer accurately in all cases, but slowness can
be attributed mostly to cards that do not have native VESA 2.x compliancy.
The only solution there is to either get a different video card or use
Scitech Display Doctor to enable linear framebuffering with VESA 2.x.

The second thing is the size of your system's cache, especially with 68000/
68010 games since the code breadth is fairly wide. 256K Cache is OK, but
512K cache or bigger will do *MUCH* better. Most systems today come with
512K cahce on them already.

Thirdly, are you running under Windows? That can knock performance down by
5-10%, and even more if you have other applications running.

--------

Q29. I have a Riva128 chipset based video board, and I get a squished image
     on the left quarter side of the screen. What's going on?

A. The Riva 128 chipset's BIOS (STB Velocity and Diamond Viper 330 boards)
incorrectly program up the CRTC registers when making VESA 2.x calls. The
early STB/Diamond boards would not program the CRTC registers up no matter
what VESA API was used. This is a buggy VESA BIOS, not a Retrocade bug!

Currently this problem will not occur in PCI Diamond or STB RIVA 128 boards
when running under straight DOS, as we've coded a workaround for it. However,
the problem is still persistent and the only known workaround for the Windows
version is to get the latest Scitech Display Doctor and use it.

Make sure your BIOS is the latest and greatest. Check with your
card's manufacturer and download and flash upgrade your BIOS if it's not
the latest.

--------

Q30. What are the minimum requirements for all games to run full speed with
     Retrocade?

A. A Pentium 133 (non-MMX is fine) with 32MB of RAM, and a good PCI video
card that natively supports VESA 2.x or higher. A Pentium 166 is required
if your video card does not support VESA 2.x or higher. A good video card
would be an ATI or a Matrox board, *NOT* A Cirrus Logic or Trident card
(both are poor performers).

--------

Q31. My Logitech Wingman Warrior spinner doesn't work, but the Wingman itself
     works just fine.

A. Running under Windows, are we?

You can thank Logitech for this one. The mouse VXD for the Wingman Warrior
does not support the spinner when event callbacks are used (Retrocade uses
callbacks for mouse & Wingman Warrior support since it's much cleaner and
requires no host CPU power unless the controller is moving). Logitech has
not fixed this problem. I've contacted them, and they are unwilling to
fix it.

There is no workaround except to load the DOS device driver under straight
DOS and use it.

--------

Q32. Why can't I set the FPS lower than 20?

A. Because the timer chip under DOS cannot go lower than 20fps accurately.
It slows all games down to unplayability at that rate. 

--------

Q33. What is Retrocade's purpose?

A. High performance emulation, ease of use. It is designed to be an end-user
product for people to play. Retrocade's goal is not to emulate every game
under the sun, but the games that are desirable to most end users. All
Retrocade developers have different areas of interest with regard to games.
We can be influenced. ;-)

--------

Q34. Why did you choose JPG over GIF or some other format for screenshots?

A. Several reasons:

* JPG Supports more than 256 colors
* JPG Is a file format that is widely used/accepted in the internet
  community (very common to have screenshots on web pages, right?)
* JPG's File format is free
* JPG Is supported by even the most primitive web browsers

--------

Q35. What video card(s) do you recommend for Retrocade for a PC?

A. We've had excellent luck with the ATI series, starting with the Pro 
Turbo PC/2TV board through the Xpert @ Work and Xpert @ Play. All cards are
excellent performers, and work great right out of the box, and are also
compatible with all of the tweaked video modes.

Other beta testers have reported that the Matrox G200 is also an excellent
choice.

---------

Q36. The Williams games (Bubbles, Stargate, etc...) just sit there looking
     at me with "Factory settings restored" on the screen and won't start.
     What do I do to get it to go?

A. Providing you haven't remapped the keys, hit F8. This is mapped to the
"Advance" button on the Williams hardware. The original games required you
to hit this button the first time you powered it up with a clear CMOS.

---------

Q37. My Microsoft Sidewinder Gamepad doesn't work when I'm running Retrocade
     in a DOS box under Windows. Why not?

A. As stated before, Retrocade/DOS is not designed to run under Windows,
and problems like this will crop up.

Retrocade talks directly to the game port to get Sidewinder Gamepad
information. Having the Sidewinder gamepad drivers installed under Windows
will cause collisions between Retrocade's polling routines and the Windows
driver for the Sidewinder. There is no workaround to this, other than to
uninstall your Sidewinder Gamepad drivers from Windows or run it in straight
DOS mode.

---------

Q38. I get "Unable to copy screen contents into clipboard" whenever I try to
     get a screenshot.

A. Windows is trapping your printscreen key. To get around the problem:

* Create a shortcut to the Retrocade executable
* Right click on the shortcut
* Click on properties
* Click on the "misc" tab
* Unclick PrtSc, Alt+PrtSc, and Alt+Space
* Click Apply
* Click OK

Just double click on the icon to start up Retrocade, and this problem will
not occur.

