BadMood alpha v0.2 - 'Classic Doom'

[22/01/2014]


The purpose of the [alpha] release: -

- To make something available after waaay too long in development. :)
- To find out how well the basic engine works for real users/players.
- To get important feedback before much more is done (bugs etc).

Two further releases are planned:

[beta]
- improve tech, complete engine features which will be used for final game

[final]
- remaining gameplay extensions, art & content modifications


Performance notes:
------------------

Display:

The game will run a bit faster when using an RGB/TV display, because there is
less load on the STRam bus from the Videl chip (in VGA mode, the Videl has to
fetch each image line twice, to double up low resolution, among other things).

The difference isn't huge but it's noticeable.


Fun with low detail modes (XLOD/YLOD):

There are two low detail toggles. One for the horizontal/x-axis, one for the
vertical/y-axis. They can be used together. They can be set via the config file
(see README.TXT) or toggled with the function keys F4,F5.

These flags double the size of pixels on that axis, reducing drawing cost
without reducing the play area size.

In most cases the low detail modes use software pixel doubling, which itself
incurs a small cost. In some cases it will try to use *hardware* doubling when
it has the opportunity to do so. Hardware doubling is cheaper, so drawing will
be quicker for a given window size.

On RGB/TV displays, YLOD (vertical doubling) will *always* use hardware.
However it is a bit ugly to double on this axis. In most cases you'd probably
only use YLOD with the 2 largest window sizes (screenblocks=10/11).
There is no equivalent of hardware XLOD on RGB/TV displays, even if that is the
default (and probably the most useful) low detail mode.

On VGA displays, hardware XLOD (horizontal doubling) is available in fullscreen
mode (screenblocks=11) only. The game can't combine hardware XLOD with the
statusbar showing. There is no hardware YLOD on VGA displays.

Because of this, VGA may actually run faster in fullscreen with XLOD enabled
than with a smaller window and statusbar showing - simply because it uses a
hardware mode.

Note that doubling is always available on both axes on any display - it's just
the 'hardware accelerated' cases that are a bit complicated. If you can't
figure out what's best from these notes, just try some combinations and see
how it feels!

Note also that the statusbar remains in high detail mode at all times.

Enabling XLOD and disabling YLOD closely approximates JagDoom's 160x180 res.


Recommended settings:

 RGB/TV		XLOD + (screenblocks=8)  (or)  XLOD + YLOD + fullscreen
 VGA		XLOD + fullscreen

These are personal choices, balancing blockyness / size / gameplay. Your
preference might differ. Big pixels on VGA look bad, so IMO it's better to
use a bigger window + hardware XLOD only, at the price of a little speed.


Loading data:

The first time you play a level, it will seem to take ages to load. BMEngine
is actually converting all of the needed resources into Falcon-native format
and stuffing them in the BMC folder. This process is very expensive, and slow.

This also occurs when a switch is first thrown, and when animated textures for
walls or floors are first seen in a level. These textures are not indicated in
the leveldata at level start, so they get processed only when visible.

Once this has been done, loading the texture in future is fast, and should not
interrupt gameplay. I run the game from CFLash and don't notice any texture
loading delays from BMC. It will likely be more noticeable from a mechanical HD
but still shouldn't interrupt gameplay.

If the game seems to have hung just as you walk around a corner into a new room
it is probably because of an animated lava or wall texture. It should 'unstick'
within a second or two. You will see this happen in the first 'nukage' room on
e2m1, which contains animated green 'slime vents'.

Note that some floor textures are BOTH animated AND warped by a shader at the
same time. Most are only warped, but a few use extra animation frames and will
cause initial disk reads during play.

In a subsequent release, the game will have a new commandline argument which
preprocesses all textures in the supplied WAD in one go, so this won't need to
occur during play.

Lastly - the BMC cache is persistent. If you boot the Falcon and start the game
some other day, the BMC content is still valid and will still result in quick
loading. It's also worth mentioning that extra memory and some resource
fragmentation occurs when generating BMC entries. The game *may* run a little
bit faster next time you play, after it's all done. The textures will be better
organised in RAM and take less space.

There are some other things to know about the BMC later but they are not
relevant for this release.


Compatibility notes:

This release targets a 16MHz machine with 14MB STRAM.

It seems to work on some accelerated machines, but I expect only if the DSP is
also accelerated to 48MHz or beyond. The problems begin when the DSP starts to
fall behind the CPU/bus/Videl trio. Even speeding up the CPU+bus+DSP by the
same relative % may not work, because the Videl load remains constant and will
make CPU+bus begin to appear a bit faster, relative to DSP.

Basically this is just a guide - you'll need to experiment yourself to see what
really works.

Note that the game will benefit greatly from acceleration combinations which do
work. Also note that low-detail modes might be more successful, since it takes
a bit of pressure off the DSP, for floor texturing at least (which is at risk
from acceleration).

The game is compatible with Fast(TT)RAM, to the extent that it knows not to use
this type of RAM for video or audio buffers. However if the FastRAM raises
CPU performance relative to DSP, it could cause the game to hang or crash.


Emulation:

This game will run under Hatari 1.6.x (and later). It was developed/tested
using Hatari so it should work pretty well.

The game performs differently under Hatari however - it is often a bit slower
than it is on a real machine. It depends on the complexity of the level being
drawn. The Falcon is faster at shading surfaces. Hatari is faster at digesting
scene complexity. This may change as Hatari is developed further.

The status bar uses a hardware trick on the Falcon, but is 'spoofed' to work
semi-properly in Hatari, by detecting Hatari and using a different code path.
It currently looks a bit glitchy on Hatari (but 100% correct on a Falcon).

The statusbar requires '--natfeats yes' to be passed to Hatari on startup, in
order to detect and implement the statusbar drawing 'workaround'. If you see
no statusbar and just black strip, it's probably because 'natfeats' is disabled
in Hatari.


Version v0.2 changes [22/01/2014]:

- Fixed game saves generating 0 byte files
- Completed JagPad support
- Better physics at 12Hz tick, making some unreachable puzzles reachable
- Fixed faulty statusbar stealing CPU time in fullscreen under Hatari emulation
- Fixed incorrect VGA monitor detection
- Slowed down title/attract page flipping
- Insufficient memory message issued on 4MB machines
- Fixed problem causing game to crash under emulation sometimes
- Fixed missing sound on TOS versions below 4.04 (the audio went 404?!)
- Fixed bug leaving statusbar on top of attract/title pages after ending game
- Added more configurability via .cfg file for JagPad, keys etc.
- Restored a 'lost optimization'


Version v0.1 [16/01/2014]:

Omissions/Limitations:

- No visible indication of health damage / pickups (original uses palette
  switches, truecolour mode needs alternative).
- Game-triggered texture switches on flats don't work yet, so some surfaces may
  change to/from lava (etc) without being visible.
- Some 'secret' walls are not drawn (typically a 'solid' wall texture being
  drawn as transparent midwall) even if the player can't walk through them
  until opened.
- No scrolling textures.
- No ingame music.
- No demo replay compatibility with other (e.g. PC) versions of Doom.
  Falcon demo recording/replay untested, although may work.
- Finale sequence untested (likely doesn't work - at least not properly).
- Atari Joypad support incomplete.
- No ingame 'messages' from pickups, progress etc. Text drawing from original
  C code is way too slow, needs replaced.
- Automap shows all walls from start of level, instead of those which have been
  seen by the playerview.
- No network play (no DM, no co-op)
- Doom II support disabled for now.
- Alpha version will likely freeze with accelerated CPU/bus. Aimed at 16MHz
  CPU/bus (but should work well with accelerated DSP!)
- Can't quit back to TOS.

Bugs:

- Status bar remains onscreen in attract mode on RGB, when game is quit early
  with F7 key (and maybe some other cases)
- Can be very occasional refresh glitches, but doesn't affect gameplay.
- First renderframe following a newly flipped switch can result in corrupt
  texture on the switch (e.g. end of e1m1).
- Mouse movements can rarely be interpreted as keypresses - can cause the menu
  to appear during play.
- Status bar draws 1 pixel too low on RGB when YLOD (y-axis low detail, F4 key)
  is enabled.
- Some visible flickering on last line of largest game window on VGA.
- Some glitches in sprite drawing, can cause parts of sprites to be occluded
  when overlapping a floor texture boundary.

Other known issues:

- Physics recalibration for 12Hz gametick is incomplete - it's impossible to
  make the timed secret door on e1m1 of doomu.wad, a hard landing from a high
  fall causes the player to sink into the floor in a strange way, and to float
  into stairs while running up them. Some secrets may be unreachable. Some
  levels may even be non-completable due to some of these problems.
- Automap clipped linedraw is slow (still original C version, not optimized),
  making map a bit annoying to use
- Using different WADs in sequence can cause stale .\BMC\ (locally cached)
  textures to show ingame, if those WADs use the same name for different
  looking textures.
- Loading a new texture for the first time is *slow*, due to lack of a WAD
  preprocessing command.
- Rapid fire weapons cause some FPS drop due to cost of AI code and raycasts.
- Uses too much memory overall, code hasn't been optimized for space.
- stdout messages get printed to TOS display memory instead of being rerouted
  to BMEngine console after display init. Most of these are suppressed now but
  this hasn't been reviewed.


