option extensions

Extensions in this section are generally fairly noteworthy. They act like master switches, usually for fairly major extension complexes. As a rule-of-thumb you can usually fine tune the extensions via the extensions in the #Detail section, which are all named according to the extensions in this section. There are however no actual rules regarding how extensions may interplay with one another, and it is very often the case Option extensions will dictate or interact with extensions found in other sections.

Note: Updating SomEx.dll has a greater likelihood of affecting the effects exhibited by these extensions than with other extensions. As of SomEx.dll ver. 1.0.0.1 it is not possible to indicate the version of SomEx.dll an Ex.ini file is tailored to. A future release will probably make that a reality, however even in such an event there is no guarantee.

do_aa

Introduced around 1.1.1.5, this extension in the affirmative adds an additional multisample buffer for the purposes of implementing AA (antialiasing). By default the first AA mode provided by the video driver is used. The player can usually override the kind of antialiasing used via an application or "control panel" installed along with the video driver. The player can disable AA the same way.

The additional buffer comes with memory and performance overhead on top of the antialiasing itself. The additional buffer may be used to save the paused picture when displaying text or menus eliminating the need to constantly recompute the picture over and over when it is not changing. Values are limited to binary statements.[#]

If do_aa is not specified overriding the AA mode will not accomplish anything except for possible degradation of the game's performance.

do_alphafog

Introduced around 1.0.0.1, this extension in the affirmative corrects the blending of fog and other transparent visual elements. As of SomEx.dll ver. 1.0.0.1 in order to blend shadows and fog the shadow textures must be marked for shadow correction (correct=shadow) in the images key. You may mark custom textures this way in order to create your own shadows. See #Keygen for details. Values are limited to binary statements.[#]

do_ambient

Introduced around 1.0.0.1, this extension in the affirmative effects ambient and diffuse lighting. As of SomEx.dll ver. 1.0.0.1 by default it borrows from diffuse light and contributes a proportional amount of ambient light. This generally has the effect of creating more natural lighting, simulating how photons scatter as their energy is absorbed by surrounding materials. Values are limited to binary statements.[#]

Note: ambient lighting is non-reflective. It will appear on the outside of doors even when the light source itself is on the inside. Care must be taken to not situate lamps near doors just as lamps will normally illuminate objects on the opposite side of a thin wall.

do_analog (obsolete)

This functionality is automatic as of Ver. 1.1.1.5. #do_dpad may be used to emulate a digital Sword of Moonlight.

Introduced around 1.0.0.1, this extension in the affirmative allows for analog play in terms of player movement etc. As of SomEx.dll ver. 1.0.0.1 this is still largely experimental. Mouse controls support analog like behavior but they are bumpy around the edges. The #Joypad section can be used to setup an analog controller which are also bumpy. Without doing so a controller in game will not produce analog behavior. Traditionally analog controls are achieved by feathering the digital inputs. With some smoothing of the players point of view this will probably be a viable option. Another simple technique is to modulate the speed of the player while otherwise offering 8-way digital movement. It's unclear at this point what kind of approach will ultimately amount to the best analog experience. Values are limited to binary statements.[#]

do_anisotropy

Introduced around 1.0.0.1, this extension in the affirmative repurposes the "Texture Mode" setting in the options menu. It will read "Anisotropy" instead. The 3 settings then change the anisotropic filtering state. In order for anisotropic filtering to be effective, #do_mipmaps should also be enabled. Values are limited to binary statements.[#]

do_antialias (obsolete)

Changed to #do_aa in ver. 1.1.1.5. do_antialias is reserved for future use.

Introduced around 1.0.0.1, this extension in the affirmative enables hardware antialiasing if available. You may be able to produce nice screenshots with this extension, the implementation however is not yet final, and therefore cannot yet be recommended for play. Values are limited to binary statements.[#]

do_bob

Introduced around 1.1.1.5, this extension in the affirmative replaces the walking effect with an effect that is optimal for analog input; and also takes the liberty of inverting the effect, both because that is how people actually walk, and because the old way of bobbing permits players to see over things into places that they should not be able to. Values are limited to binary statements.[#]

This is one of those odd extensions that would be default behavior except that it would be even more odd if that were the case, logistically speaking. Switch it on unless you have a good reason not to.

do_bpp

Introduced around 1.1.1.5, this extension in the affirmative simply changes the terms for 16bpp and 32bpp in the Options menu's Colors setting to High Color and True Color respectively. This is merely a technical correction as bpp stands for bits per pixel which may or may not be 16 or 32 depending on the extensions in play. In practice both modes are usually 32bpp, where High Color is emulated for some effect. Values are limited to binary statements.[#]

If and when "Deep Color" becomes available and is enabled and is supported by the player's device environment this extension will advertise True Color and Deep Color respectively. Note that #do_highcolor and possibly other extensions hijack the Colors setting superseding the utility of this extension.

do_cursor

Introduced around 1.0.0.1, this extension in the affirmative results in a much more expressive cursor when the mouse is hovered over the game window. This extension is generally recommended for window play. Values are limited to binary statements.[#]

A minimal cursor will appear in window mode even if this extension is not enabled.

do_dash

Introduced around 1.1.1.5, this extension in the affirmative enables management of dashing. Dashing happens when the player holds down the "action" button if dashing is not currently disabled. Specifically do_dash slows the player down when dashing sideways and more so going backwards. #do_walk does the same while walking. When the two are combined the effect is spread across both extensions so that no additional slowdown is incurred overall. Values are limited to binary statements.[#]

do_disasm

Introduced around 1.1.1.3, this extension in the affirmative turns on the disassembler. In earlier versions disassembly could occasionally lead to crashes so this extensions was invented since disassembly is not always required. It was probably a good idea however because the Sword of Moonlight EULA makes a point to forbid disassembly, though it is unlikely this is precisely what the lawyers had in mind. Still if you want to adhere strictly to the EULA you should not switch this on.

When do_disasm is on, assuming things do not crash, you can see the disassembled code in the memory inspector overlay (F11) if available (see #Output) and extensions which depend upon the disassembler can work their magic. Values are limited to binary statements.[#]

do_dither

Introduced around 1.0.0.1, this extension in the affirmative causes a hardware dither effect to be applied in 16bit colour modes. Sword of Moonlight requests (of the graphics hardware/drivers) dithering in 16bpp mode, however almost no modern hardware will accommodate the request. Therefore this extension restores a little piece of Sword of Moonlight lost to the eons. Classic KING'S FIELD games have all been dithered. And the dithering better compliments the 15bit textures which come with Sword of Moonlight. It's arguably better looking than a linear filter which tends to stretch texels out and make the 16bit colours look flat. Print media has used dithering for centuries.

It's recommended you combine this extension with #do_highcolor since that will force all modes into a 16bit colour mode. By default do_dither has no effect when playing in 32bpp (True Color) modes. Values are limited to binary statements.[#]

If anyone would like to supply their own custom dither mask, this kind of feature can be facilitated in short order on demand.

do_dpad

This extension did not make it into 1.1.1.5. It will be implemented when convenient or as soon as anyone thinks that it is actually necessary. Its purpose is to emulate Sword of Moonlight; like #do_gamma, it is probably only useful to players who want a taste of how things worked out of the box circa 2000.

Note if you just want to disable analog input, this is probably not the extension for that. do_dpad will impose several constraints beyond the scope of input as the analog framework itself facilitates much more than that. Furthermore the analog framework itself cannot be disabled. This extension merely counteracts it with as little effort as possible.

do_escape

Introduced around 1.1.1.5, this extension in the affirmative adds the Escape key, aka. Esc: usually the top-left most key, to the keyboard. As of 1.1.1.5 pressing the Esc key when in-game and not in the title screens or menus changes the "Analog Mode" with respect to #escape_analog_modes.

Eventually (ideally sometime in 2013) pressing Esc will open a new System menu that will make the Analog Mode function obsolete. The original menu will no longer be available. By default it will be replaced by a Save or Load menu depending on if the game allows save anywhere-anytime. Save/load functionality should also be provided by the new menu as soon as possible. In which case authors will probably want to put something else in that slot. A Journal (beastiary etc.) menu for example. #do_system is provided to keep the original menu. Values are limited to binary statements.[#]

do_fog

Introduced around 1.1.1.5, this extension is equivalent to setting #do_alphafog and #do_rangefog (both are highly recommended) independently. Note that extensions in the #Detail section still begin with alphafog_ and rangefog_ respectively, and that do_fog may assume additional meaning in the future. Values are limited to binary statements.[#]

do_gamma

Introduced around 1.0.0.1, this extension in the affirmative uses modern shader technology to reproduce the gamma ramps employed by Sword of Moonlight. Reproducing the effect perfectly is computationally fairly expensive. If there is much demand for this extension, in the future the default behavior will probably be to approximate the ramps via a parametric function of some kind. At present there is no extension in the #Detail section to indicate you don't want an approximation. Values are limited to binary statements.[#]

The Sword of Moonlight Extension Library generally speaking always defers to Sword of Moonlight's original behavior in lieu of an extension, however this is one of the few cases where doing so is just neither practical nor ideal.

do_green

Introduced around 1.0.0.1, this extension in the affirmative uses the 565 High Color model. 565 means 5 red bits, 6 green bits, and 5 blue bits. This is the model Sword of Moonlight uses in 16bit mode. However the Sword of Moonlight Extension Library uses 555 by default. The extra green bit is said to add a great deal more realism to a picture, however it tends to shift color to the green spectrum, especially at low light levels, resulting in an all around sickly hue, and somewhat psychedelic banding in the lower strata of colors. Its not bad if you want a green hue or more psychedelic coloring. However the textures that come on the Sword of Moonlight compact disc are all 555 like the PlayStation, so 555 color seems like a better fit. It's unclear why the Sword of Moonlight runtimes look for 565, it may have been a more standard or more popular color mode when dithering was commonly implemented in hardware. Modern day hardware has dropped dithering support almost universally, making banding artifacts the norm for older games.

See #do_dither for a dithering extension. And see #do_highcolor for an extension that lets the player choose which mode they prefer. Values are limited to binary statements.[#]

do_hdr

Introduced around 1.0.0.1, this extension in the affirmative enables "High Dynamic Range" lighting. What the opposite means is when you take a perfect white light and shine it on a 3D graphic with a texture applied, the pixels intersecting the graphic on screen can never be brighter than the texture itself. With HDR lighting, the pixels can go over white, meaning a very bright white light will make any texel in the texture that is not perfect black eventually reach perfect white; in other words the colour is not clamped at 1. For a long time color was always clamped at 1 because frame buffers that store video images were assumed to be at most 1 byte per colour channel. 1 byte can be at most 255, which meant perfect white. 255 still means perfect white, except nowadays we can store numbers larger than 255 in memory, so microchips are able to do calculations outside that limited range, and that's what HDR means.

Without HDR lights may interact in very unnatural ways, even by real-time lighting standards. Values are limited to binary statements.[#]

do_highcolor

Introduced around 1.0.0.1, this extension in the affirmative repurposes the "Colors" setting in the options menu. It will read "High Color" instead. 32bpp will no longer be available. The player will get the option of 5:5:5 and 5:6:5, for 555 High Color and 565 High Color respectively.

This setting is generally recommended. Especially in combination with #do_dither. Add #do_anisotropy to give your game a uniform appearance regardless of display settings. Values are limited to binary statements.[#]

do_invert

Introduced around 1.0.0.1, this extension in the affirmative flips the Sword of Moonlight Extension Library brightness model in the following way. Normally the brightness of every pixel is calculated when the pixel is being drawn. Sometimes pixels are drawn many times over, which can be especially problematic for transparent pixels because the brightness tends to double down. When inverted everything is drawn without regard for brightness, then in the end the whole screen is brightened. Menus and other elements meant to be unaffected by brightness changes are darkened so when the screen is brightened they are restored to their original levels.

This extension is generally recommended and should yield better performance if anything performance wise. It does have some side effects which come into play at the ends of the colour spectrum. Mainly when darkened pixels can never be perfectly white, and when brightened pixels can never be perfectly dark. The discrepancy will depend upon the level of the adjustment. Any black mattes will still be perfect black.

A "Deep Color" buffer if available could be used to prevent the loss of information. There is however no extension implementing a deep colour buffer and it might not be worth it unless there were other deep colour extensions already at play. Values are limited to binary statements.[#]

do_ko

This extension did not make it into 1.1.1.5. It will be implemented as soon as it is convenient and or necessary to do so. Its purpose is to allow the player to be knocked out when being knocked back by the #do_pedal extension. The knockout effect itself will be identical to #do_palsy except that the duration will be dependent upon the force of the knockout hit.

Since the player cannot move while knocked out, it opens up the possibility of increasing the movement speed temporarily so that the player character can be thrown around at a rate faster than would otherwise be possible.

do_lights

Introduced around 1.0.0.1, this extension in the affirmative will take Sword of Moonlight out of the business of object lighting (lamps) completely. This is computationally fairly intensive, however it is generally recommended because Sword of Moonlight is generally not reliable in the object lighting dept. Mainly if the player changes the display settings, object lighting will go way at least until the player crosses over into a new map. This is considered an undesirable bug, in which case the alternative is do_lights. #do_fix_lighting_dropout is a round about way of turning on do_lights and setting #lights_maximum_lamp_lights to 3.

The default behavior of do_lights is to support as many simultaneous lamp lights as necessary. The current hard limit is around 16 per object. The Sword of Moonlight Extension Library currently has no model for knowing or guessing what lights Sword of Moonlight would normally apply to an object, so it just applies all lights that overlap with the object. The lighting will be different if there are many light sources involved. If this produces unnatural results, consider #do_hdr and or adjusting the lighting (see #Details)

The Extension Library decides which lights to turn off and on per object (in reality chunks of pieces of objects) by building a database of bounding boxes which it matches to various characteristics of the objects being displayed. In the future the Extension Library may more and more take over the responsibility of rendering things altogether. In which case some of the database and object recognition business will become obsolete or at least less round about.

In the future there will be unified lighting models where the map pieces are lit with the same lights as the objects. In this future do_lights will apply to map pieces in the same way it does to objects. Values are limited to binary statements.[#]

do_log

Introduced around 1.0.0.1, this extension in the affirmative enables logging. A file will be written to the tool or game folder. For the runtimes for example, db.log would apply to som_db.exe and rt.log to som_rt.exe. Main.log for SOM_MAIN and so on. The same events which would be written to the log in the future will also be sent to the SOM_EX console with or without do_log. You can change the log levels in the #Output section. The log levels apply to console output as well. This extension however refers to writing to files. You can disable console output via #do_console or doing something like log_bar=-1 in the Output section. Values are limited to binary statements.[#]

do_mipmaps

Introduced around 1.0.0.1, this extension in the affirmative generates mipmaps for all textures on the fly. This is generally a very good idea. It's also required if you want to take advantage of the images key (see #Keygen for details)

Sword of Moonlight TXR files seem to include mipmap data. However none of the textures which come with Sword of Moonlight do. In general Sword of Moonlight mipmaps look really bad, mainly because anisotropic filtering is not managed. Not having mipmaps is really bad, because its slow and creates "shimmering" artifacts. Having mipmaps without anisotropic filtering is also bad, because the unfiltered mipmaps become infinitely blurry at more oblique angles. Use #do_anisotropy to let the player adjust anisotropic filtering to their preference. It can be a real trade off in terms of performance and quality. Indiscriminate anisotropic filtering can be costly. Unfortunately there is no real practical way to tweak things on a situational basis. You can however use the images key to tweak things on a per texture basis. See #Keygen for details. Values are limited to binary statements.[#]

A little trivia, the "Trilinear" texture mode in the options screen actually means a linear filter with a linear mipmap filter.

do_mouse

Introduced around 1.0.0.1, this extension in the affirmative adds a universal mouse to the mix. This mouse is simple to configure via the #Detail section.

The mouse has two modes of interaction. A strong capture mode and a weak capture mode. The weak mode is only available in-game outside of title screens and menus. It is accessed by clicking the 3D game area of the window. Strong mode is accessed by spinning the mouse wheel until the cursor changes, then clicking anywhere in the window's client (read: non title bar) area. The wheel must then be turned in the opposite direction to exit the strong capture mode. The further the wheel is turned (up to a limit) the stronger the capture.

Strong capture persists inside of menus and does not interact with onscreen elements. The mouse can be "floated" temporarily by pressing the Alt keys or the F10 key. These keys are traditionally used to access a window's File menu. Values are limited to binary statements.[#]

do_numlock

Introduced around 1.0.0.1, this extension emulates a Num Lock key in case the player's keyboard cannot do numlock or the player would like numlock to be independent of the keyboard's actual numlock status. As of 1.1.1.5 emulation is still not supported for numpad play, however the function overlay is and always has been fully functional. Refer to #...function_overlay_tint. Values are limited to binary statements.[#]

do_palsy

This extension did not make it into 1.1.1.5. It will be implemented as soon as it is convenient and or necessary to do so. Its purpose is to replace Sword of Moonlight's Palsy status ailment in order to better incorporate the knock back effects provided by the #do_pedal extension. Specifically it should be possible for the player character to be knocked around while paralyzed.

By default the paralysis will transition to slow status (see #do_slow) once it begins to wear off. Furthermore all in-game (excluding pause and other out-of-game functionality) input will be short circuited. If the player attempts to open the menu a digital clock will appear in the middle of the screen counting down until the menu is able to be accessed; the menu will not be opened automatically when the clock disappears.

In contrast the original Palsy effect permits the player to use magic spells and items, and of course the menu, while paralyzed. Without access to any of these time (or forethought) is the only means of escape in a single player scenario.

do_pause

Introduced around 1.0.0.1, this extension in the affirmative adds a pause feature to the mix. This extension comes highly recommended. It's a good idea to take advantage of #do_auto_pause_window_while_inactive while you are at it. Values are limited to binary statements.[#]

do_pedal

Introduced around 1.1.1.5, this extension in the affirmative generates a number of movement effects including knock back and sliding. It does so by driving the keys on the keyboard as if the player is pressing the keys themself. Consequently the player is able to counteract the effects of the effects by moving the player character in the opposite direction. Refer to #do_ko, #do_palsy, and #do_slow. Values are limited to binary statements.[#]

do_rangefog

Introduced around 1.0.0.1, this extension in the affirmative uses a different kind of fog model which is based on distance rather than depth. Without it the fog at a certain point will appear to change as the player turns around. Values are limited to binary statements.[#]

do_red

Introduced around 1.1.1.5, this extension in the affirmative modulates the intensity of the red flash if and when the player has taken damage. The default formula will lessen the red flash when the player character is hit for between 0% and 50% of HP. So if 50% (or more) of HP is lost the flash is 100% red. If 1% is lost then the flash is 2% red. Use #red_flash_tint to change the colour and or intensity of the flash itself. Values are limited to binary statements.[#]

do_slow

This extension did not make it into 1.1.1.5. It will be implemented as soon as it is convenient and or necessary to do so. Its purpose is to replace Sword of Moonlight's Slow status ailment in order to better incorporate the knock back effects provided by the #do_pedal extension. Specifically it should be possible for the player character to be knocked around (at full speed) while slowed. Rather than the movement speed being slowed, slowdown is to be implemented at the analog input signal level.

do_smooth

Introduced around 1.0.0.1, this extension in the affirmative performs a fairly inexpensive kind of smoothing over every pixel on a given screen. Under most circumstances there comes a point where a screen buffer must be copied over the entire screen in order to perform some effects in screen space. Without do_smooth the pixels will be mapped one to one during this copy for a crisp presentation. With do_smooth the pixels will be mapped in the middle, so all pixels will be a blend of their surrounding pixels.

Whether your prefer your vision crisp or smooth, where smoothing really pays off is around objects in the far distance. It creates a kind of "depth of field" effect on the horizon, but more dramatically for spindly things like grass in the distance, the effect adds a kind of fullness which arguably amounts to a more natural rendering. See for yourself. It's a trade-off but the pros usually outweigh the cons. Values are limited to binary statements.[#]

do_sounds

Introduced around 1.0.0.1, this extension in the affirmative ensures that virtually all sound effects are played to completion. Normally Sword of Moonlight will play a very small number of sounds at one time (figure needed) and drop the rest. Currently this extension supports up to 8 instances of a single sound effect being played simultaneously before any sounds of the same sound effect will be dropped.

The limit can be increased if required, however 8 instances of the same sound usually means adding one more will not be distinguishable. However if the 8 instances are far away and the sounds being dropped are nearby a stronger case can be made. Unfortunately prioritizing like sounds according to distance does not really help unless you are willing to allow sounds to be cutoff midway through. Values are limited to binary statements.[#]

do_st

Introduced around 1.1.1.5, this extension in the affirmative changes the on-screen elements so to emulate Shadow Tower. This can be seen as an esthetic decision, however the ST elements are textual and font based. Only the gauges are graphical. This makes localizing games much easier for translators. And takes the burden of crafting HUD graphics off the back of weary authors. Still this is ultimately a player preference and as such a game should work either way.

Just like Shadow Tower do_st sacrifices the compass. But it adds a damage output indicator. The bad status (or health) indicator can be turned off independently of the gauge/points displays. In future releases the square dot in the map screen will be replaced with a pseudo compass needle so that the player can access a compass that way. It should even be possible to equip a compass in the spare hand, and or glance at the compass in the item or equip menus. A Quick Select extension is even pretty far up on the "todo" list. And the compass itself can even be added back to the status indicator, even if that would be very un Shadow Tower like. Values are limited to binary statements.[#]

do_sway

Introduced around 1.1.1.5, this extension in the affirmative adds a whole host of walking effects on top of the traditional vertical bob effect. The effects are all conveyed by means of a side to side sway that is by default equivalent in amplitude to the bob sine wave; however the motion is generally aligned with the player character's hips, which may not always be facing forward. When walking sideways for instance the sway will move back and forth as well as side to side, and will even be off center at times in order to convey face forward sideways movement. Values are limited to binary statements.[#]

do_syncbgm

Introduced around 1.0.0.1, this extension in the affirmative synchronizes background music (BGM) as with sound effects. Note that this extension will probably have no effect if #do_fix_asynchronous_sound is not applied. This is handy if your BGM is meant to correspond to real-time happenings in your game world, or if you want to use timers to determine when music should change. And for the record do_syncbgm recreates the way the BGM works in KING'S FIELD II.

This means menu and message screens will not play BGM. There is currently no extension to play an alternative BGM in menus. You can however play BGM over message screens (for dramatic effect) if you start the BGM in the same event that displays the message. In the future it might be possible to not pause BGM during messages, however doing so would negate the real-time synchronization benefits of the extension. An alternative could be adding more popup messages. No extensions exist for that yet, but one could definitely be added if need be. Values are limited to binary statements.[#]

do_system

Introduced around 1.1.1.5, this extension in the affirmative causes #do_escape to revert back to providing an "Analog Mode" function making use of the original System menu (instead of the new menu provided by do_escape) so that everyone can, "have their cake and eat it too." Note that this extension does nothing in 1.1.1.5 but if you don't like the idea of your game changing when the new menu finally comes online then do_system can be enabled in order to prevent that. Values are limited to binary statements.[#]

do_walk

Introduced around 1.1.1.5, this extension in the affirmative does the same thing for walking that #do_dash does for dashing. Psychologically it may feel weird when do_walk is not combined with do_dash. A player can always decide otherwise if they feel otherwise. Values are limited to binary statements.[#]

do_wasd

Introduced around 1.0.0.1, this extension in the affirmative adds "WASD" walking controls to the keyboard as if they were always there (meaning you can then remap them via the #Keymap) and mirrors "PL;'" controls for left handed players. Values are limited to binary statements.[#]

Accessibility features are one of the few non-optional changes imposed by the Sword of Moonlight Extension Library. Ie. some of Sword of Moonlight's keys have been changed around to accommodate left handed players. See Sword of Moonlight Extension Library#Accessibility for more information.