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.