Original post by Zemedelec
I was talking about the shader-into-DLL approach,
Me too. The plugin shader concept is fully able to do what you desribed.
Original post by Zemedelec
As for DLL updating as is, a rant:
Software, that do that and have plugin structure have serious requirements to do so - it is developed often by large teams, that create/update parts independantly.
And games aren't ?
And for other concerns, like stability. Nothing of that concerns the typical game scenario, games imho are not so big software.
Excuse me, but this made me laugh ! Look, the software industry, and the game industry even more so, is a very competitive market. Budgets are becoming larger every year, and the code complexity of games increases. But the timescale to finish a game gets shorter and shorter. The market forces this.
In order to survive, you need to find innovative solutions to increase both quality and productivity. Of course, you could code a game the "old school way", with hardcoded and manually optimized render paths for each effect and each target hardware. It would probably even take less time than creating a flexible plugin based approach, if starting the latter from scratch. So you sell your game, and everything is nice and fine - until a year or two later, when you need to release the next game. Unfortunately, hardware has changed a lot, so you need to completely rewrite your hardcoded engine: new effects, new hardware features, shifted bottlenecks, new shader structuration. If, however, you invested the time into the plugin system, updating your engine to the newest standards is a breeze, without even sacrificing backwards compatibility for older hardware.
Reusability is the key word. Todays and tomorrows development must target reusable frameworks that are easily extendable and scalable over time, maybe even by completely different development teams. Think third party licensing, for example. With your hardcoded solutions, you won't go anywhere in the future, especially not from a financial point of view. Until you have adjusted your hardcoded shader paths to the new hardware requirements, your competitor has updated a few DLLs (or static libs) and is already selling his brand new eyecandy ladden game.
If we target system complexity, that could be good point to start... :)
Don't underestimate the complexity of a modern game.
My personal decidion would be not to trade the design/implement time for pluggable system that can update everything, for the sake of uploading 1.5M more. I would go for stable-old (KISS) solution... but its just me, yes.
It's not about filesize, it's about competitivity and scalability.
Can't see how this is more predictable and easy-to-develop for a typical not-shader intensive game.
In what time are you living ? Typical not shader intensive games ? All new 3D engines targeted at Dx9/10 cards, XBox 360, PS3, etc, almost drown in shaders ! The time of not-shader intensive games is long over.
For me, it's like having quite many renderpaths, and being unable to guarantee the visual quality in one of them. Maybe it is suitable for software, but for games - can't agree.
I think I have the better argument here: I actually have such a system running on a commercial base for a couple of years now :) And it works very well. No, it might not be for a game - but our software has very similar requirements compared to a very high end game from the graphical side. In fact, you could probably turn the application into a game quite easily, if you have the artwork, change the interface and add AI.
The current system might not be what we would like to see in the medium term future (as I mentioned above, we're looking more into meta shaders), but we will certainly not go back into the stoneage of hardcoded renderpath graphics development.
My suggestion: just try it out before bashing it. You might be surprised about what extreme flexiblity it can offer you.