Info-icon.png We have moved to https://openmodeldb.info/. This new site has a tag and search system, which will make finding the right models for you much easier! If you have any questions, ask here: https://discord.gg/cpAUpDK

Difference between revisions of "Upscaling Build Engine Games"

From Upscale Wiki
Jump to navigation Jump to search
(→‎DEF Files: Minor edit, rephrased EDuke32 def loading behavior to be more clear)
Line 77: Line 77:
 
|}
 
|}
  
In BuildGDX-based ports, multiple ZIP files can use the default DEF file. Note that you do not need to include everything in the same DEF file, you can load a separate file inside the DEF file with the include command. EDuke32-based ports are more complicated, as only the last DEF file loaded is parsed.
+
In BuildGDX-based ports, multiple ZIP files can use the default DEF file. Note that you do not need to include everything in the same DEF file, you can load a separate file inside the DEF file with the include command. EDuke32-based ports are more complicated, as only the last DEF file of a given name is parsed.
 
 
  
 
=== Palette swaps ===
 
=== Palette swaps ===

Revision as of 18:01, 19 January 2020

Making Upscale Packs for Build Engine Games

Note that everything on this page assumes you are using either an Eduke32 or BuildGDX-derived port. This will not work on NightDive’s Blood Fresh Supply.

Extracting tiles

Your first task is to extract tiles from the games ART files, for some games the ART files are already in the game’s main folder (Blood, Witchaven, TekWar) for others they are stored inside a GRP file (in case of Powerslave it is called STUFF.DAT but programs that support GRP files will also open that although you may need to change the file extension) which can be extracted by several tools, for example SLADE.

ART files can be opened in M210’s BAFED, which is preconfigured with palettes for most Build Engine games. This may be more user friendly for the novice user and the resulting exported file will have transparency already applied. The downside is the exported tiles no longer retains the original color indices, which we’ll get to later.

Instead, my preferred method is a commandline tool called ART2TGA. You can extract an ART file by dragging it onto the executable. However you may find the palette comes out wrong. To resolve this, place the file PALETTE.DAT from your game in the same directory as ART2TGA.

If you have many ART files to work with, a more convenient approach though is with a batch script

for %%f in (*.art) do (art2tga %%f)

This will extract all the art files in the folder you run it in. They will be in TGA format so you will want to use the image processing tool of your choice to convert it to a format supported by ESRGAN. You will also notice the lack of transparency.

DEF Files

Once you’ve made your upscales you need to define them in a DEF file. This is how you define a hightile:

texture 1170 { pal 0 { file "filename.png" nocompress nodownsize }}

Here 1170 is the tile number, pal 0 defines the new image as replacement using the base palette (which will also override any non-defined palette)

Note that tiles defined this way will only show up in Polymost (and for EDuke32 Polymer) renderers. In its current form, hightiles are unaffected by palette swaps, you have two options, either define a separate image for each palette swap, or use tints. This is how you define a tint in EDuke32-based ports:

tint { pal 5 red 255 green 255 blue 255 flags 1 }

pal 5 is the palette being tinted, while the three following values are multipliers for each channel, finally flags have special properties.

0 Nothing
1 Greyscale
2 Invert
3 Greyscale + Invert

The greyscale and inversion effects are applied before the RGB multipliers. For BuildGDX the syntax for defining tints is slightly different:

definetint 5 255 255 255 1

You can have both forms in the same file however. At the moment the function flags aren’t implemented in BuildGDX so you’re limited to the RGB multipliers (as such the example here does nothing)

Now, if you got 23000 tiles it’s a pain in the ass to write definitions individually, so here’s a helpful batch script

setlocal EnableDelayedExpansion for %%f in (tile*.png) do ( set tmp=%%f if "%%f"=="!tmp:~0,8!.png" ( echo texture !tmp:~4,4! { pal 0 { file "upscale/%%f" nocompress nodownsize }} >> new.def ) else ( echo texture !tmp:~4,4! { pal !tmp:~9,-4! { file "upscale/%%f" nocompress nodownsize }} >> new.def ) )

In this case, files need to follow the format tileXXXX_YY.png where XXXX is the tile number and YY the palette. The script also allows for omitting _YY for tiles using the base palette. Place the files in the upscale folder. For compatibility with the BuildGDX you’ll want a def file specifically named for the port. Then you zip them up and place in the game’s autoload folder.

Blood bloodgdx.def
Duke Nukem 3D dukegdx.def
Powerslave psgdx.def
Redneck Rampage rrgdx.def
TekWar twgdx.def
Witchaven whgdx.def

In BuildGDX-based ports, multiple ZIP files can use the default DEF file. Note that you do not need to include everything in the same DEF file, you can load a separate file inside the DEF file with the include command. EDuke32-based ports are more complicated, as only the last DEF file of a given name is parsed.

Palette swaps

Most Build Engine games have some sort of palette swaps. Extracting them varies from game to game.

If you plan to define separate images for each palswap you have two choices

  1. Swap palette before upscaling
  2. Palettise your upscaled image and swap palette afterwards.

Both have their advantages and disadvantages. If you apply the palette swap before upscaling there is no risk of mismatch between similar colors with wildly different palette swap results, but you are also duplicating the amount of upscaling work that needs to be done. If you palette swap afterwards the upscale process generally has the benefit of having more colors to work with, however there’s the risk of mismatching. You’re also limiting the result to the colors in the palette.

Upscale of Blood's Cultist with palette swap applied before vs. after upscaling