Jump to content

View more

Image of the Day

WIP title screen for #DeathOfAPartisan #screenshotsaturday #gamedev https://t.co/qJNhfZCvd4
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

Engines - What to keep fixed and what not to

4: Adsense

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
3 replies to this topic

#1 Migi0027 (肉コーダ)   Members   


Posted 12 August 2013 - 01:24 PM

Hi guys, happy.png


developers love to give the user the freedom they want, but sometimes, too much freedom is quite bad, as some things are just too complicated, or just not practical, or might mess stuff up if done wrong.


One example of this was where I had to decide whether to use fixed functions for normal mapping, or leave that to the user to do while editing their custom material. But normal mapping isn't just something that's done within a seconds (copy... paste... tongue.png ), so I decided to make it fixed, like: (And it's used so much, and if you mess it up, features like, ssao, lighting, just doesn't work!)

// Enable Normal Mapping

// Set the texture


Is leaving the normal mapping to a fixed function the way to go, or not? What experiences do you have where you needed to decide whether making a feature fixed, or leave it to the user?


Thanks! wink.png


PS. I don't know if this is too specific, if so, please say!

FastCall22: "I want to make the distinction that my laptop is a whore-box that connects to different network"

Blog about... stuff (GDNet, WordPress): www.gamedev.net/blog/1882-the-cuboid-zone/cuboidzone.wordpress.com/

#2 GuardianX   Members   


Posted 12 August 2013 - 02:23 PM

I would like to hear opinions on this subject as well. I personally think that it is completely up to you to decide. Some kind of "design" decision. But it is really hard to decide when you should really stop making things flexible.

#3 Jason Z   Members   


Posted 12 August 2013 - 07:29 PM

My take on this is to make the system as flexible as possible, and then if there are 'norms' that you want to include in the engine then you just implement them for the user in the flexible system.  This serves multiple purposes - they provide functionality out of the box, they serve as examples for others to use, and they force you to use your own system to implement something that you could reasonably expect your users to be able to do.  Sometimes that experience can be eye opening, and it will help you improve the usability of your engine.


By maximizing flexibility, this also lets you update things over time without breaking your whole engine.  Encapsulate your rendering code into logical chunks that are easily interchanged and supported by the structure of your engine, and you will be much happier in the long run.  Especially if you are the sole maintainer of the project, this will really be useful if you work on the engine for a long time (like I have with Hieroglyph 3!).

#4 nfactorial   Members   


Posted 14 August 2013 - 04:21 AM

From the example you gave, I would say you don't need the SetFlag( MAT_FLAG_NORMALS ) call. The fact someone calls the SetNormalMap should be enough for the lower level API to realise they want normals which reduces it to a single call and reduces the chance of someone making a mistake.


I actually think this should all be completely hidden at the high level, so no code outside the core renderer has an API like that at all. But I guess that's not really the direction your engine has taken and requires tool support. Consider for example, the high level code states 'I have a mesh that I render' and the game engine gives it a mesh along with the material. Suddenly the high level code can now render anything the designer wants it to with no code change. Anyway, that's a long discussion and a bit of a tangent so I will leave it as perhaps thought for the future.



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.