Announcements

Join the ongoing conversation on Discord: https://discord.gg/w6Tpkp2

Please read the current update for instructions on downloading the latest update. Players with Mac versions of the game will not be affected, but you will have a slightly longer wait for your version of the new maps. Please make a copy of your character folder before running the new update, just to make sure you don't lose any of your custom work.

It looks like we can give everyone a list of minimum specs for running City of Titans. Please keep in mind that this is 'for now' until we are able to add more graphics and other system refinements. Currently you will need :
Windows 10 or later required; no Intel integrated graphics like UHD, must have AMD or NVIDIA card or discrete chipset with 4Gb or more of VRAM
At least 16GB of main DRAM.
These stats may change as we continue to test.

To purchase your copy of the City of Titans Launcher, visit our store at https://store.missingworldsmedia.com/ A purchase of $50 or more will give you a link to download the Launcher for Windows or Mac based machines.

Dynamic Resolution Scaling

3 posts / 0 new
Last post
Lin Chiao Feng
Lin Chiao Feng's picture
Offline
Last seen: 5 days 1 hour ago
Developerkickstarter11th Anniversary Badge
Joined: 11/02/2013 - 09:27
Dynamic Resolution Scaling

There's an interesting article at Ars Technica about Dynamic Resolution Scaling, where they dynamically change resolution (then interpolate up to to keep frame rate up at 60 fps:

Quote:

Instead of just statically setting a low resolution ceiling for the entire game, though, Halo 5 dynamically changes the resolution based on the detail of the current in-game scene. This on-the-fly adjustment takes place on both the X and Y axes, with resolutions jumping from as low as 1152×810 to as high as 1536×1080 [...]

While Digital Foundry says that "the game spends the overwhelming majority of its time well under full 1080p," this dynamic resolution scaling means that pixel counters can get the very best visual fidelity possible at any point without the usual frame rate jumpiness. The game also uses other tricks to preserve the overall frame rate, such as using less detailed, "half-rate" animations for far-off enemies (like many other games, Halo 5 also uses less-detailed polygonal models to save cycles when rendering far-off objects).

Anyone hear anything from Epic about this technique? Would it need to live entirely in UE4 or would you need support from end-game developers? (The last sentence is just describing the usual distance-based LOD stuff that's already on the docket for CoT.)

Has anyone seen my mind? It was right here...

Izzy
Izzy's picture
Offline
Last seen: 6 years 5 months ago
kickstarter11th Anniversary Badge
Joined: 10/09/2013 - 11:09
Hmm.. no clue.

Hmm.. no clue.

I have to wonder about the Half rate animations for far off enemies. Sounds more like the Bone animations are sampled less frequently when farther. So in a way instead of a video playing at 30 frames per second when up close, when farther away, it plays at 15 frames per second, and it still looks good. ;)

Lin Chiao Feng
Lin Chiao Feng's picture
Offline
Last seen: 5 days 1 hour ago
Developerkickstarter11th Anniversary Badge
Joined: 11/02/2013 - 09:27
Izzy wrote:
Izzy wrote:

Hmm.. no clue.
I have to wonder about the Half rate animations for far off enemies. Sounds more like the Bone animations are sampled less frequently when farther. So in a way instead of a video playing at 30 frames per second when up close, when farther away, it plays at 15 frames per second, and it still looks good. ;)

It sounds to me like a variant of frame dropping. You take the set of animated model you want to rate reduce and divide them into two equally-sized groups (or something close). You animate one group on odd frames and the other on even frames, and their animations are only rendered for the current frame, dropping the animation steps when they're not active. This cuts the amount of animation work in half (just hold over the vertex tables from the previous frame on off-frames), and assumes that the animation and rendering to vertex tables is a significant time cost compared to the actual rendering (shading) of the frame.

Alternatively, if you've got animation living on its own thread, you could animate everything every other frame (say, even frames) and hold that data over to odd frames, basically just starting later in the draw call processing with a saved state from the previous frame's call.

Has anyone seen my mind? It was right here...