DLL vs SDK

"zeroxygen" wrote:

"lazydodo" wrote:
It's bad from a users perspective and i have to say it's bad from a developer perspective, you fix a bug, the developer gets to recompile and run their apps though a complete QA cycle to push an update out, gee thanks!

Are you suggesting that a third party dll replacement with a newer version is not a significant enough change to running logic to warrant having to go through QA again on the application that makes use of it?

That's a definite point. Can you guarantee that 3rd party code running from a DLL compiled by that 3rd party won't break something in your application?

What happens if people arbitrarily start mixing and matching different versions of the DLL with your application? - I've seen people do it. And while it can fix problems the devs couldn't be bothered with, it is equally capable of breaking a program in a way the programmers might have a hard time understanding.

This is only a more reliable way to write a program if you can be sure the 3rd party stuff you're using isn't flawed in some way, which is a highly optimistic position to take.
(Plenty of windows programs have all manner of bugs that can't be fixed by the devs because they're errors in 3rd party code which they don't have access to...)

"lazydodo" wrote:

2) Define a STRONG C API (Strong meaning, once the SDK supports a certain function it's signature or behavior can NEVER EVER change)

Really? We're going to lock into a permanent API this early? Seems like a tall order to come up with the perfect, never changing API now when half the point of the dev kit is to get the hardware into the hands of developers to experiment with.

I also think the current model is not sustainable. Its equivalent to the DOS days when you had to set up your sound card for every single game (and implement various sound card hardware interfaces in every game you write).

Device manufacturers use a driver model for a lot of good reasons.

* Developers should not have to deal with system-wide settings. IPD, eye cup type, screen distance, and the associated calibrations absolutely do not need to be handled by the game. It is a huge UI burden, and it will be implemented inconsistently or not at all.
We should be able to query the device for these settings and know that they are correct. As a gamer especially I absolutely do not want every game to feel like wearing a different pair of glasses.

* It lets us implement an interface to the device once and not have to release a patch every time you update your software, or even worse your hardware. Developers not keeping up to date is something that simply will happen, and you don't want unnecessary fragmentation.

* Platform and language-specific code should be removed from SDK libraries wherever possible. We should be able to write our code once and have it just work no matter what environment we run it on. This way you can implement the sensor handling in whatever way makes sense for the platform, in whatever language you want, and have it behave consistently no matter what language we use.

* Most importantly for openness, it lets us write our own drivers and have them work in existing Rift supporting games! Making our own DIY HMDs won't really matter if every single game has to compile in support for every single one, that just won't happen.

A DLL would be the best solution, and is very simple to update - even if the game is not supported anymore.

Yeah programming wise it is easier to call a DLL and query or send information to it and get results than to integrate the control into each of the programs. Personally just looking for ease of use in programming myself.

Just FYI: Our Unity implementation actually uses a DLL to interface with the Rift (OculusPlugin.dll in the plugins folder). We don't have any documentation around this, but it may be useful to some people if you can look at the C# code and see how it's working.

for things that aren't likely to change frequently i.e the stereoscopic 3d, i would suggest DLLs seeing as they are going to be the same regardless of the application.

Free-looking on the other hand will be handled differently on an app to to app basis, now that doesn't mean that DLLs are bad way to go but they would need an *.ini or some similar way of selecting the specific the particular options i.e free-look with body follow(look to turn) or independent free-look(TF2)

really the choice isn't really SDK or DLL seeing as regardless of which people would prefer there is still going to alot of configuration needed DLL is more consumer friendly but loses out on versatility

i personally think that a multi-DLL setup is a better way to go, here is why you want MPC/VLC to run in Stereoscopic 3d, you just link S-link the DLL for that rather then calling the entire everything DLL making it take up less computational power, where as for a game you might want something completely different