Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

How are shader mods made?

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 mrheisenberg   Members   -  Reputation: 356


Posted 15 January 2013 - 01:53 AM

How do the modders,who introduce new shader effects,know what input layout they must be expecting in the vertex shader and what constant buffers are being set,etc..are they reverse engineering the shader files?
For example:Freelancer

The game originally used a forward renderer and it didn't have bloom,how did they alter the renderer if they don't have access to the source?

Edited by mrheisenberg, 15 January 2013 - 01:58 AM.


#2 Bacterius   Crossbones+   -  Reputation: 10559


Posted 15 January 2013 - 02:02 AM

This isn't really a complete answer but there are lots of GPU debugging tools (pix, etc..) that'll catch the DirectX calls with their arguments, intercepting the raw shader code (if it wasn't already available) and everything relating to constant buffer layout, vertex layout, etc... so I would assume they reverse-engineer and study it this way.


If the mod can be fully self-contained within the shader, it's a lot easier, but otherwise they could be injecting new additional code in the executable (kind of like Fraps does to capture DirectX frames) to enable additional behaviour and special effects. This is also possible if the source can be decompiled and made sense of to some extent (like Minecraft, the code is obfuscated but you can still kind of understand where you need to add your modding code, and then recompile the jar file).

Edited by Bacterius, 15 January 2013 - 02:04 AM.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.


- Pessimal Algorithms and Simplexity Analysis

#3 Karsten_   Members   -  Reputation: 1731


Posted 15 January 2013 - 05:40 AM

There was a "hack" to add bloom to Half-Life 1 engine games (pre-steam) a while back.


As I recall, it provided it's own OpenGL32.dll which when placed next to the half-life .exe would take precedent over the normal one (provided by WIndows or driver).

It would then simply pass through the calls to the original one, but hook the parts needed to add bloom.


This probably isn't a very conventional way (though a lot of multi-player cheats are made this way) but I thought it was quite clever.

Mutiny - Open-source C++ Unity re-implementation.
Defile of Eden 2 - FreeBSD and OpenBSD binaries of our latest game.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.