Programmer or engine responsibility ?

When I think of my library code, most are simple helpers. However some are very much required for all my projects.

One of them is a Display framework, that maintains panels scaling and positions regardless of game resolution, It also detect maximum screen resolution for fullscreen and windowed ( as window must be smaller then desktop to fit a window + frame). It also choose between base images that are low res, mid res and high res - As scaling a very low res image to fit a very high res screen resolution causes very ugly images.
It's a set of core functions that, since I must use it for every project, I feel should be the responsibility of the engine not the programmer. PANELs could have a few simple flags to control this, such as NO_SCALE NO_ALIGN NO_LOD.

At some point we all want more things moved into the engine, but somethings are indeed better as programmer responsibility, and easily managed by maintaining a code library. However something need to be managed by the engine. This is my primary example. Please feel free to rant about your examples or opinions.

Mal

Well I know that Shiva3D, Unity, Unreal all handle those options you are specifying. I understand that this is just a "rant", but, and sorry for asking what has already been asked....is this engine ever going to see any meaningful updates anymore. I have followed this engine for a little while and love the way it works, I can get along with it just fine. The other threads I read about this subject never got a definitive answer.

I am curious is all, the answer, explicit or not, won't waver my decision to use it, I am probably just a bit ocd and need closure lol, and you seem to be a very informed forum member.

^--- Have you ever meet a person that promises always and almost never fulfills the promise? Have you ever heard, some day, only to watch the years tick by? Have you ever bought the ring, but never saw the change you need to give it, in spit of all the words, actions failing ever so? Then you know.


Dumbest user in the last 10 years in the forum and life. Let the rest speak their peace.

I AM
MALICE

Thanks for a response, and I guess it is what it is. Software is functional for my purposes.

Dumbest user, yeah you may be a tad bit hard on yourself. Regardless, best of luck in your future endeavours.

Hm it depends! If you can write a piece of code that is very generic, you can discuss if it is part of the engine API. But you always have to ask the question "is the engine entirely responsible for this feature?".

A game engine should be in my oppinion as versatile as possible. Bringing some GUI code into the engine set might be a good idea, but when it doesn't fit e.g. other genres, it is not versatile anymore. GUI code for first person shooters like Battlefield or COD is very different to what you need for RTS games like Age of Empires or the Settlers.

So if the engine developer thinks "ok lets do something!" he will end up in a very limited set of functionality that *has* to be extended of course to match your needs, or he is making a super-versatile super-generic piece of code that enables you to make any super-GUI you can wish for .. but at the same time it might be too complex, to much overhead.. so will you end up writing your own

In my oppinion, there are always three layers, which shall be independent and are sorted from generic to specific:

1) engine layer
2) framework layer
3) game layer

Application Layer (hardware, OS, core libs and main loop)
Game Logic (game state, physics, events, ...)
Game View(s) (presentation of game state, meaning graphics, sound, input interpretation)

Your point is very well seen by me. And the answer is NO!



Well my though is just to have some limited functions, and of course expanding is the very heart of the versatile idea.
In most cases, we want panels to keep there relative size in location through-out resolution changes. However there is no need to force that choice, and so I offered flags to disable the behavior if you so choose...
The use of LOD images is I guess a personal choice. When a image designed for fitting in 800X600 scale to 1920x1080, switching to a higher resolution source image looks better. But again that's a personal preference , but also a simple flag could give freedom to not use the functionality.

We currently can grab the current screen res and the engine will not tick-out-of-bounds, it will not (unlike the old days) set to a res to large and then present a problem. So there truly is nothing about the stepping I use the get the "next best windowed size" that should be a part of the engine... I Agree!

I have a solution for this as a #include. My question is misspoken( miswritten?), I think the question is better stated "Should the engine include a Library for these issues with panels?" The only real thing that make me want more engine support is the idea of moving my handling from the skill_x to a simple flag. Sure I am solving a problem I don't have, I work with a lot of people who do have this issue and don't have my solution.

Ok
Mal

A few extra flags for panels would be nice, but I personally can live without it. I always use some functions to set up the interface properly anyway.

Probably if the engine developer would develop a game with it, we could get a better framework with more features and flexibility.
Or if there would be a pressure on the developer by game studios using the engine to add more game ready features.
Or if the developer would invest in buying packages made by game studios using the engine.
Or if the developer would be interested in it at all.

Most reasonable one.

+1