Mirrored_Repos/freelancer-hd-edition
1
0
Fork 0
mirror of https://github.com/BC46/freelancer-hd-edition synced 2024-08-30 18:32:47 +00:00
Code Issues Packages Projects Releases Wiki Activity
0423ce33c9
freelancer-hd-edition/EXE/dgVoodooReadmeDirectX.html
C.S. Melis dd5c89d34a Add dgVoodoo readmes
2021-08-04 16:08:16 +02:00

656 lines
26 KiB
HTML
Raw Blame History

<!DOCTYPE html>
<html>
<head>
<style>
p
{
max-width:1000px;
word-wrap:break-word;
text-align: justify;
}
li
{
max-width:1000px;
text-align: justify;
}
table, th, td {
max-width:1000px;
border: 0px solid #C0C0C0;
border-collapse: collapse;
text-align: left;
}
</style>
<head>
<meta name="google-site-verification" content="4JMbYsGNl4-uZV9FEQvq56CQDND5NHcIPtMblynaH-Q" />
<title>dgVoodoo2 DirectX Readme</title>
</head>
<body bgcolor="#D97600">
<font color = "#FFFF00">
<h2 align="left">
===============================================================================<br>
<font color = "#FFFFFF">dgVoodoo 2.54</font>: DirectX emulation related stuffs<br>
<br>
===============================================================================<br>
</h2>
<p>
<h2><font color = "#FFFFFF"><u>
Table of contents
</u></font></h2>
<b><h3>
1. Important notes<br>
2. General overview<br>
3. Some technical info<br>
4. Application resolutions and refresh rates<br>
5. About fullscreen and windowed mode<br>
6. DirectX Control Panel (CPL) options<br>
7. Tips and known issues<br>
8. Why doesn't dgVoodoo DX emulation start up?
</h3></b>
</p>
===============================================================================<br>
<br>
<h2><font color = "#FFFFFF"><u>
1. Important notes
</u></font></h2>
<p><font color = "#FFFFFF">
First of all: NEVER COPY DDRAW.DLL AND D3D8.DLL INTO SYSTEM FOLDERS!!
ALWAYS USE A LOCAL INSTALLATION FOR A GAME!<br>
DirectDraw and D3D8 are still existing and widely used system components in Windows.<br><br></font>
For clarifying, let's see what dlls MS and dgVoodoo use for DirectDraw and
Direct3D:
</p>
<ul>
<li>
<font color = "#FFFFFF">
MS:<br>
</font>
<table bgcolor = "#C96600">
<tr><td width="30%">ddraw.dll</td><td>- Contains all DirectDraw implementations up to version 7</td></tr>
<tr><td width="30%">d3dim.dll</td><td>- Contains all Direct3D implementations up to version 6</td></tr>
<tr><td width="30%">d3dim700.dll</td><td>- Contains Direct3D 7 implementation</td></tr>
<tr><td width="30%">d3d8.dll</td><td>- Contains Direct3D 8.1 implementation</td></tr>
</table>
</li>
<br>
<li>
<font color = "#FFFFFF">
dgVoodoo:<br>
</font>
<table bgcolor = "#C96600">
<tr><td width="30%">ddraw.dll</td><td>- Contains all DirectDraw implementations up to version 7</td></tr>
<tr><td width="30%">d3dimm.dll</td><td>- Contains all Direct3D implementations up to version 7</td></tr>
<tr><td width="30%">d3d8.dll</td><td>- Contains Direct3D 8.1 implementation</td></tr>
</table>
</li>
</ul>
<p>
So, dgVoodoo packs all of its pre-D3D8 implementation into one module, d3dimm.dll,
which differs in name from the MS one (note the extra 'm' in the name).<br>
Thus, copying it to the system folder by accident won't cause any harm. In spite
of that, it is not recommended.
</p>
<br>
<h2><font color = "#FFFFFF"><u>
2. General overview
</u></font></h2>
<p>
If you want to wrap an old DirectX stuff then just copy dgVoodoo's dlls to the
application folder and launch that. DirectX rendering is configurable similarly
to Glide. (See DirectX related CPL options)
DirectDraw is usable without Direct3D but there are no 3D rendering capabilities
exposed to the applications in that case.<br>
Direct3D8 is a standalone component, no need for DirectDraw to use it. In spite of
that it is a good idea to copy DDraw.dll along with D3D8.dll because a lot of movie
playback system (e.g. DirectShow) rely on DDraw even in D3D8 games. dgVoodoo DDraw
and D3D8 has the ability and internal support to cooperate if the situation requires.
<br>
<br>
All the interfaces of old DirectX (that is, all DirectDraw interfaces and
Direct3D 3/5/6/7/8 interfaces) are almost fully supported, and existing implementation
is improved version by version by more and more reverse engineering and finetuning.
<br>
<br>
Since DirectX is not a pure hardware-only rendering API, basically two types of
virtual video cards can be used, like back in the old days, hehe. Four extra
video card types are added to utilize different chipset features and provide correct
vendorID/hardwareID.
Available video card types:
</p>
<ul>
<li>
<font color = "#FFFFFF">One that simulates an old SVGA with hw-capabilites only for 2D blitting</font>
operations.<br>With such a card, only a software 3D rendering device can be used.
</li>
<br>
<li>
<font color = "#FFFFFF">One (imaginary) video card that has its custom hw 3D rendering support.</font><br>
This card provides support for full hardware acceleration including
'Transform & Light'.
</li>
<br>
<li>
<font color = "#FFFFFF">GeForce4 Ti 4800</font>
</li>
<li>
<font color = "#FFFFFF">ATI Radeon 8500</font>
</li>
<li>
<font color="#FFFFFF">Matrox Parhelia-512</font>
</li>
<li>
<font color="#FFFFFF">GeForce FX 5700 Ultra</font>
</li>
</ul>
<p>
For more detailed capabilities, see the technical info.
<br><br>
Software rendering devices does not use real software rendering in dgVoodoo. I
think that a software rasterizer has no reason for existence nowadays and didn't
want to write one just for fun so they use hw accelerated rendering in the
background. The point is, towards the applications they logically appear as
software devices.
<br><br>
DirectX renderer needs less GPU power (for general cases) than Glide renderer but
it uses relatively complex precompiled shaders too (since whole of the fixed
function vertex/pixel pipeline has to be mapped to pure shader functionality).
<br><br>
DX emulation has a method for fast CPU-access of locked surfaces. The current
method is not the final version and going to be improved later.
The reason of not using that one all the time but it is up to the user's choice
is that this method is not 100% safe and can cause crashes under certain
circumstances. It depends on the wrapped application.
<br><br>
Important to note that compatibility with MS DirectDraw is not completely
guaranteed, especially with very old applications written in the win95/Win98 era.
Those applications might utilize DirectDraw/GDI interaction which is not fully
supported in dgVoodoo. I would like to improve that somehow, in later versions.
</p>
<br>
<h2><font color = "#FFFFFF"><u>
3. Some technical info
</u></font></h2>
<p>
I say 'almost fully supported' when talking about DX support because there are
some functions on certain interfaces of which functionality is somewhat unclear
or totally unimportant, so they either not implemented at all or just
partially because I did not have time and patience to figure out their exact
behavior. Think about a total of 5-6 functions of all the DX interfaces,
I hardly believe that anything used them.
<br><br>
For DX8.1, the following features are not implemented but planned to be in the
future:
</p>
<ul>
<li>Higher-Order Primitives (maybe some day)</li>
</ul>
<p>
................................................................................
<br><br>
<font color = "#FFFFFF">
Internal virtual 3D card has the following 3D hardware capabilities:
</font>
</p>
<ul>
<li>Supports transforming and all kind of lighting with flat, Gouraud and Phong
shading, max 8 active lights</li>
<li>Supports 6 clipping planes</li>
<li>Supports vertex bending with 3+1 weights</li>
<li>Supports matrix palette of 256 elements for indexed vertex blending</li>
<li>Supports texture coordinate generating & transformation, projective texturing</li>
<li>Supports all contemporary pixel formats for textures and render targets with
four different RGBA order (altough the order is not yet exposed in the CPL app)</li>
<li>Supports compressed textures (DXTC1-5)</li>
<li>Supports volume textures with limited number of texture formats</li>
<li>Supports Z-buffer (of course) and stenciling (but there is no W-buffer)</li>
<li>Supports vertex and pixel fog</li>
<li>Supports colorkeying with one texture (with colorkey blending or
colorkey discarding)</li>
<li>Supports all texture sampling modes</li>
<li>Paletted textures</li>
<li>Depth textures</li>
<li>16 vertex streams</li>
<li>Vertex tweening</li>
<li>Supports point sprites</li>
</ul>
<p><font color = "#FFFFFF">
* Additionally, if dynamic shader compiling IS NOT AVAILABLE then
</font></p>
<ul>
<li>Supports 4 texture stages and all DX7-level texture blending operations and
arguments on each of them including bump mapping</li>
<li>DX8-level vertex/pixel pipeline is <font color = "#FFFFFF">UNAVAILABLE</font></li>
</ul>
<p><font color = "#FFFFFF">
* if dynamic shader compiling IS AVAILABLE then
</font></p>
<ul>
<li>Supports <font color = "#FFFFFF">all of the 8 texture stages and all DX8-level texture blending
operations and arguments</font> on each of them</li>
<li>All types of DX8.1 bytecode shaders are supported<br>
<font color = "#FFFFFF">
vs1.0, vs1.1<br>
ps1.0, ps1.1, ps1.2, ps1.3, ps1.4<br></li>
</font>
<li>256 vertex shader constants</li>
</ul>
<p>
The other 4 card types are not an exact emulation of the given chipsets with some
real ATI/nVidia/Matrox driver version. They are just present to bias the available
rendering capabilities and properties toward a real ATI, nVidia or Matrox card:
</p>
<p><font color = "#FFFFFF">
GeForce4 Ti 4800 capabilities:
</font></p>
<ul>
<li>Same as the internal virtual 3D card, except:</li>
<li>No 32 bit z-buffer support</li>
<li>Full cut colorkeying</li>
<li><font color = "#FFFFFF">No</font> indexed vertex blending</li>
<li>Maximum supported pixel shader version is <font color = "#FFFFFF">ps1.3</font></li>
<li>Max <font color = "#FFFFFF">96</font> vertex shader constants</li>
</ul>
<p><font color = "#FFFFFF">
ATI Radeon 8500 capabilities:
</font></p>
<ul>
<li>Same as the internal virtual 3D card, except:</li>
<li>No 32 bit z-buffer support</li>
<li>Plain colorkeying</li>
<li>Max <font color = "#FFFFFF">57</font> matrices for indexed vertex blending</li>
<li>No paletted texture support</li>
<li><font color = "#FFFFFF">8</font> vertex streams</li>
<li>Max <font color = "#FFFFFF">192</font> vertex shader constants</li>
</ul>
<p>
<font color="#FFFFFF">
Matrox Parhelia-512 capabilities:
</font>
</p>
<ul>
<li>Same as the internal virtual 3D card, except:</li>
<li>No 32 bit z-buffer support</li>
<li>Plain colorkeying</li>
<li>No paletted texture support</li>
<li>Maximum supported pixel shader version is <font color="#FFFFFF">ps1.3</font></li>
</ul>
<p>
<font color="#FFFFFF">
GeForce FX 5700 Ultra capabilities:
</font>
</p>
<ul>
<li>Same as the internal virtual 3D card, except:</li>
<li>No 32 bit z-buffer support</li>
<li>Full cut colorkeying</li>
</ul>
Since I cannot enumerate all the capabilities here, check them out with <font color="#FFFFFF">DXCapsViewer</font> if interested.<br>
Also, those capabilities might be changed in the future if I get more accurate information about the hardwares in question.
<p>
................................................................................
<br><br>
DirectDraw and Direct3D objects supports all types of rendering devices that are
supported in original DirectX.<br>
Direct3D8 support HAL and software device types.
<br><br>
In MS pre-Direct3D8 implementations Direct3D7 is the only one that can be used with
hardware vertex transformation and lighting, through a Transform & Light (T&L)
device (but I guess it casually falls back to software vertex processing if the
device driver does not support the complete vertex operation pipeline that is
currently set).
<br><br>
In all other cases software vertex processing is used. In dgVoodoo vertex
processing is always routed to the hardware when possible.<br>
However, it's not so simple: software vertex processing is unavoidable in Direct3D
in some cases, for example when an application wants Direct3D to do only vertex
processing without rendering or to calculate visibility, or, when the rendering
extent must be updated when drawing primitives through a non-T&L device (this is
not too important in practice but I included it because of full compatibility).
Also, vertex processing for Direct3D3 can only be done in software because of the
execution logic of execute buffers.<br>
It all means that dgVoodoo has a software T&L vertex processing engine like
MS Direct3D for such cases, duplicating the hw functionality. However for
transforming, bending, lighting, fogging and texture coordinate transforming
calculations dgVoodoo uses fast vectorized SSE2 code instead of scalar FPU.
<br><br>
(It should be noted that in newer DX version like DX7 MS uses SSE2 too.
What is more, for software emulation of vertex shader code in DX8, MS seems to
apply an internal compiler, that compiles from shader code to x86 bytecode.
Wow, what a nice feature!! I should do the same, but probably it all is not too
relevant on modern CPUs.)
<br>
<br>
Phong shading (per-pixel shading) is not supported by MS Direct3D, only
Gouraud (per-vertex). However the internal virtual 3D card can externally be
forced to Phong shading through the CPL app but keep in mind that it can cause
heavy GPU usage because Direct3D lighting is quite complex, typical hardware
implementations supports 8 active lights with a lot of properties and components.
Also, Phong shading is only applicable when the application commits all its
transforming and lighting calculations to the D3D runtime. Unfortunately it is
very common that games do their own T&L calcs and use D3D as a lowlevel rasterizer
for the rest. It is especially true when a game is written for multiple platforms
or multiple 3D APIs like Glide, D3D, OpenGL, etc. Direct3D3 always uses software
vertex processing so Phong shading cannot be applied there at all.
<br><br>
DX8 is a horse of another colour from the beginning of a new era. Applications
written for that usually heavily utilize multiple vertex streams through real
vertex and index buffers along with built-in hw T&L pipeline and/or shaders
without any calculations done in software.
<br><br>
Phong shading is only applicable with full fixed function vertex/pixel pipeline
usage. If an application is rendering through a vertex and/or pixel shader in DX8
then Phong cannot be utilized.
<br>
</p>
<br>
<h2><font color = "#FFFFFF"><u>
4. Application resolutions and refresh rates
</u></font></h2>
<p>
An application using DirectX can only detect available resolutions and
associated refresh rates by asking DirectDraw/DX8 to enumerate them. There are two
slight problems with it in practice:
</p>
<ul>
<li>Modern hardware does not necessarily report some low resolutions like 320x200,
640x480, etc.</li>
<li>Old hardware was not able to report refresh rates or query the current one in
general, back then when 60/75Hz CRTs were the standard displays. Thus, most of
the games/applications just used 0 for refresh rate when setting the resolution
which means 'unspecified or default' refresh rate.</li>
</ul>
<p>
To workaround the first case, dgVoodoo keeps a list of 'classic' resolutions.
These are the following:
</p>
<font color = "#FFFFFF">
<ul>
<li>320 x 200 (X-mode is also supported in DDraw)</li>
<li>320 x 240, (X-mode is also supported in DDraw)</li>
<li>640 x 400,</li>
<li>640 x 480,</li>
<li>800 x 600,</li>
<li>1024 x 768,</li>
<li>1280 x 1024</li>
</ul>
</font>
<p>
If a resolution of that list is not amongst the ones that your modern adapter
reports then dgVoodoo forces enumerating it to the application.
<br><br>
As for the refresh rates, if an application does not specifify one of the
enumerated ones but specifies 0 (default) then dgVoodoo finds and applies the
natively supported one that is most closest to 60Hz.
<br><br>
If you want to make sure or would like to use a custom refresh rate then
you can override that through the resolution selector combo box (DirectX tab).<br>
For details, see chapter 'Resolution and refresh rate overriding' in the general readme.
</p>
If the refresh rate is overridden then all resolutions are enumerated with the
overidden value to the applications.
</p>
<br>
<h2><font color = "#FFFFFF"><u>
5. About fullscreen and windowed mode
</u></font></h2>
<p>
Choosing fullscreen or windowed working mode is part of the DirectDraw API. Some
games or demoscene stuffs run only in fullscreen so one could think what cool it
would be to have them running in windowed mode. I thought the same so wanted to
enable by default the same method to switch between them as used for Glide.
There are some problems however: the ways handling fullscreen and windowed mode
via DirectDraw are totally different in the aspect of the driving code. So,
forcing an application into an unexpected situation may cause glitches or crashes.
Also, a game may have its on mechanism for mode switching with which dgVoodoo
could conflict. Due to those theoretic things, and because I experinced some
problems with some games, I decided to emulate the original DirectDraw behavior
by default: when a fullscreen application loses the focus then its window gets
minimized and when it regains that its window is restored and enters fullscreen
again and no manual switch is available. Also, there are no changes applied on the
app window like style and overridden messages, etc.
<br><br>
If you make sure that a given game does not conflict with dgVoodoo's Alt-Enter
thing then you can enable that in the CPL app. Also, you can force it to windowed
mode if 'app controlled fullscreen/windowed' option is disabled at the game
startup (and choose windowed mode in the general settings), without Alt-Enter.
Forcing a windowed application to fullscreen can only be done by manual switch
because there is no way to 1) detect when an application begins its rendering and
2) switch to fullscreen.
<br><br>
(But, think about it, windowed to fullscreen does not make any sense. The
resolution used comes from the window size but the window may get resized or
repositioned when switching mode, so..., it's confusing.)
<br><br>
What is more, since DirectDraw was a one-monitor-API <font color = "#FFFFFF">in practice</font>, integrating windowed
applications in a multimonitor environment is already a problem even for MS,
I think. If such an app is even forced to fullscreen mode then it may crash or
misworks for reasons I do not want to word here.
<br><br>
Lost mode is emulated in default DX emulation mode, namely when switching
between windowed/fullscreen mode by Alt-Enter is disabled. This is because some
DX applications count on losing their surfaces when their window loses focus and
their code paths can be mislead if they remain 'unlost'. (This is a result of bad
programming technique as DX SDKs clearly state that an application shouldn't
rely on window focus lost or any other circumstances.)
<br><br>
On the other hand, there are incomplete or buggy DX applications that can't
restore when they get reactivated and just get stuck. So, introducing lostmode
emulation is up to a potential feature loss, as such applications likely worked
well with older dgVoodoo versions. In order to keep this feature dgVoodoo applies
auto-restore for the needed elements when such a situation is detected.
</p>
<br>
<h2><font color = "#FFFFFF"><u>
6. DirectX Control Panel (CPL) options
</u></font></h2>
<ul>
<li><font color = "#FFFFFF"><b>Disable and passthru to real DirectX</b></font>
<p>
As it says, if you want to disable DirectX without
removing dgVoodoo's DLLs then use this option.
</li></p>
<li><font color = "#FFFFFF"><b>Videocard</b></font>
<p>
You can select between the internal virtual 2D (SVGA)
and 3D accelerated cards.
</li></p>
<li><font color = "#FFFFFF"><b>VRAM</b></font>
<p>
Onboard videomemory of the selected videocard.
</li></p>
<li><font color = "#FFFFFF"><b>Filtering</b></font>
<p>
Various texture filtering modes can be forced here, starting from simple point sampled to high level anisotropic.
Keep in mind however that forcing other than the application default can result in rendering glitches, or it can
completely break some visual effects!
</li></p>
<li><font color = "#FFFFFF"><b>No mipmapping</b></font>
<p>
Disabling mipmappig (forcing largest mip texture level).
</li></p>
<li><font color = "#FFFFFF"><b>Resolution</b></font>
<p>
Here you can override the application resolution and
refresh rate. See detailed explanation of static/dynamic
resolutions in the general Readme.
</li></p>
<li><font color = "#FFFFFF"><b>Antialiasing</b></font>
<p>
For 3D rendered surfaces you can force MSAA.
Option 'Application controlled' is meaningful only for DX8. For DDraw/DX it is equivalent to 'Off'.
</li></p>
<li><font color = "#FFFFFF"><b>Application controlled fullscreen/windowed state</b></font>
<p>
Since choosing this state is part of DirectDraw, you
must disable this option to control that via general
settings.
</li></p>
<li><font color = "#FFFFFF"><b>Disable Alt-Enter to toggle screen state</b></font>
<p>
To prevent conflicting with an application built-in
Alt-Enter handler.
</li></p>
<li><font color = "#FFFFFF"><b>Bilinear blit stretch</b></font>
<p>
2D bitmap copying can involve stretching in DirectDraw.
However the applied stretching filter cannot be controlled
via the API and early hw used simple point sampling.
It can result pixelated appearance here and there but
you can force bilinear filtering which looks cooler for
most cases. But, it can also introduce various artifacts
especially when colorkeying is also applied during
blitting.<br>
Try forcing bilinear texture filtering for achieving similar
effects for D3D8 games.
</li></p>
<li><font color = "#FFFFFF"><b>Apply Phong shading when possible</b></font>
<p>
See technical info.
</li></p>
<li><font color = "#FFFFFF"><b>Force vSync</b></font>
<p>
Forcing vertical retrace.
</li></p>
<li><font color = "#FFFFFF"><b>Fast video memory access</b></font>
<p>
Provides an alternative method for accessing video memory
of DX surfaces by the CPU. Try this one if an application
renders at a low frame rate.
</li></p>
<li><font color = "#FFFFFF"><b>dgVoodoo Watermark</b></font>
<p>
Similarly to 3Dfx watermark in Glide, you can use
dgVoodoo's own one to see if something is driven through
dgVoodoo's DirectX.
</li></p>
</ul>
<br>
<h2><font color = "#FFFFFF"><u>
7. Tips and known issues
</u></font></h2>
<ul>
<li>Always try to run an application with 'application controlled fs/windowed state'
and disabled 'Alt-Enter' for the first time. If 'Alt-Enter' is enabled then
the wrapper makes some changes to the application window which can cause some
applications to miswork or even crash.</li>
<li>Also, always try an application without enabling 'Fast video memory access' for
the first time as that method may be unsafe for the application in question, and,
unortunately can cause inappropriate working.
</li>
<li>
Upscaling (forcing resolution) for old 8 bit paletted DDraw applications are not
recommended. Paletted things and forced resolution don't work well together,
but I want to fix it in the future.<br>
Upscaling scenes by forcing resolution, where no 3D-rendered objects are presents,
has no sense anyway.
</li>
<li>Forcing vertical retrace is not always a good idea. There are games of which
loaders refreshes the screen at maximum speed (without vertical sync) while
loading textures, meshes, etc. If vSync is forced to on then it can take ages
while it all gets over.</li>
</ul>
<br>
<h2>
<font color="#FFFFFF">
<u>
8. Why doesn't dgVoodoo DX emulation start up?
</u>
</font>
</h2>
<p>
I got reports about cases with dgVoodoo DirectX emulation not starting up.
The story is simple, one copies the DX dll files into the given application folder,
next to the executable, makes sure that DX emulation is enabled on the CPL, and in
spite of that, when starting the application dgVoodoo isn't utilized at all, dgVoodoo
watermark doesn't show up in the corner if the app starts at all.
Thanks to the Guys on Vogons, who are helping me a lot, they come out with 2 reasons:
</p>
<ul>
<li>
Some of the DX dlls (ddraw.dll, d3d8.dll) are registered in the KnownDLLs section of
the Windows registry. When they are then the operating system always loads the system
versions of those dlls. Removing the entries from<br><font color="#FFFFFF"><b>
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs"</b></font><br>
is undangerous and can be safely done with <font color="#FFFFFF"><b>Regedit</b></font>.
This issue causes the majority of the problems.
</li>
<li>
A bit marginal but existing problem with DirectDraw is that it can be initialized through
Windows' OLE mechanism which identifies objects with GUIDs. The 'GUID-dll name' pairs are
also stored in Windows registry but Microsoft switched to absolute dll paths in Windows 8(?)
instead of the relative ones present in Windows 7, so the OLE-accessed DirectDraw is always
the system one in that case. The registry entries in question can be changed back to relative paths,
but since <font color="#FFFFFF"><b>Regedit requires TrustedInstaller privilege level for that</b></font>, and you have to search for
the entries yourself, it is a complicated process, I don't recommend you to experiment with it.
Luckily most of the old programs access DirectDraw directly, bypassing OLE.
</li>
</ul>
<p>
I know that these details are technical like hell, and I don't at all expect an average user to
tinker the operating system registry by hand. I just write this info here because I think it's useful for
advanced users and experts to begin with. A dgVoodoo tool doing it all would be fine but currently doesn't
exist one.
</p>
<font>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink