FPS display incorrect Z-order

[ghost]

I noticed that sometimes when I run game with fps counter on, it may be covered by some of the game objects. For example, in the "Infinity String" main menu the "loops" counter is partially covered by animated grass. And for some reason the counter does not show up in Resonance, at all.

[monkey0506]

When the engine is drawing the FPS, it's drawing it to the room background. This means anything (Objects, Characters, GUIs, mouse) that is in the same area is going to cover it up. It would be useful to have properties such as Game.FPS and Game.LoopCounter (or something similarly named) so that the user can display this on a GUI or such. As for the built-in handling, it probably should be set to draw that last or just before the cursor.

-monkey

On Thu, Jan 3, 2013 at 11:41 AM, Ivan Mogilko notifications@github.comwrote:

the "loops" counte

[rofl0r]

a sane VM does not offer any internal functionality to the user (in this scenario, the scripter) you have to draw a line somewhere, and having access to a loopcounter or even FPS is, if not already insane, on the other side. the game user, not the scripter should decide whether he wants a nervous FPS counter jumping around on his screen.

that said, AGS is a very bad example of VM design, the worst misfeature was when it was made possible to call into custom DLLs. this basically destroys the purpose of the VM, and makes it possible for any script kid to embed malicious code into an external DLL. also, it makes any game using such a DLL non-portable. that means win32-only. many games can not be used with this engine port because of some stupid external feature in some closed source plugin. really sad.

chris jones should have said "NO" way earlier. i hope this guys here learned from the history.

[monkey0506]

I don't understand why exposing information which the engine is already aware of to the scripter is a bad idea in your opinion. Sure, it should be up to the player whether the FPS is displayed, but that's either going to be exposed via a non-customizable built-in function such as the ugly Debug function we have now, or instead it could be exposed via a property which the game developer can then implement in a way which fits their game. Your statements about this seem to indicate that you don't understand the game design process, at least not in terms of an IDE such as AGS.

As for calling custom code, you also make some assumptions about this as well. Plugins are portable provided that the code in question is compiled for the appropriate platform, which means they are not restricted to 32-bit Windows. Furthermore, someone can't just inject malicious code into your game. They would have to devise a legitimate purpose behind you using the plugin in the first place, and then get you to implement it into your game. If the game isn't compiled with the plugin enabled in the editor, then it won't be used. Most plugins that are being released now are being made available with the source code for precisely these reasons. Besides, there are relatively few games that even make use of plugins, and the number greatly diminished after AGS 2.7 introduced script modules, and further with the added features of later engines.

It seems to me that despite all your demands of everything to be open-sourced, your own methods of programming are very close-minded. A lot of what you've said (and done) actually makes me rather skeptical.

On Fri, Jan 4, 2013 at 12:49 AM, rofl0r notifications@github.com wrote:

a sane VM does not offer any functionality to the user (in this scenario, the scripter) you have to draw a line somewhere, and having access to a loopcounter or even FPS is, if not already insane, on the other side. the game user, not the scripter should decide whether he wants a nervous FPS counter jumping around on his screen.

that said, AGS is a very bad example of VM design, the worst misfeature was when it was made possible to call into custom DLLs. this basically destroys the purpose of the VM, and makes it possible for any script kid to embed malicious code into an external DLL. also, it makes any game using such a DLL non-portable. that means win32-only. many games can not be used with this engine port because of some stupid external feature in some closed source plugin. really sad.

chris jones should have said "NO" way earlier. i hope this guys here learned from the history.

— Reply to this email directly or view it on GitHubhttps://github.com/adventuregamestudio/ags/issues/47#issuecomment-11874021.

[rofl0r]

yes, it is the job of the engine to expose the FPS functionality to the gamer in some way. either using the agsconfig functionality or some hotkey.

the primary problem with the plugin system is that it makes it possible to mix real pointers with in-game-managed objects. this makes all safety go away, and is a huge problem because when the engine came out, pointers were always 32bit. nowadays they aren't. and since the engine is powerful enough, there's no good reason why it should be possible to call native, architecture-dependant code. if the game designer needs any functionality that is not already in AGS, chances are very high that what he wants to do is A Bad Idea. and whatever he wants to do outside of AGS, is probably unportable (maybe opening the windows registry, do some direct3d tricks, call some visual basic dll they coded years ago which they now want to reuses, whatever). fact is that most coders and especially windows coders have no clue about portable software.

the secondary problem is that it makes it possible for the game author to do anything that is possible on the host os. this involves logging your credit card number, passwords, contributing to a botnet, formatting your harddrive, etc. and it seems in the past most (if not all) plugins were released binary-only i.e. closed source.

so this basically defeats the purpose of having a VM per se. instead of making a VM, he could just have distributed AGS and the engine as object files and headers which you can then link to your own native code.

monkey0506> "it seems to me that despite all your demands of everything to be open-sourced, your own methods of programming are very close-minded. A lot of what you've said (and done) actually makes me rather skeptical."

interesting. do you have some examples ?

[ghost]

There are at least two different questions: 1) engine displaying FPS (and other info) presumably for debugging purposes, 2) giving game developer an access to engine data.

This issue thread is solely about number 1. If engine wants to draw some debug stuff, it should obviously do that on upper layer (unless that has some more complex purpose). Also, it should not depend on the game, or game developer's ideas on how and where to display the FPS.

And, people, I beg you, may you please open new issue threads for your discussions that aren't directly related to the nature of current bug/feature?

[ghost]

Six years later the Z-order bug was finally fixed by 8bd4d7a2f2819b3278aa40d01eef3642177d9c48 :-)