Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[adonf]

I'd like to suggest a couple of script functions to stop rendering the scene for a while in order to have whole chunks of script execute in an atomic fashion.

Here's an example: if I update 50 script Objects in a loop like this myobject[ i ].Update(), the engine might suspend script execution to render the scene before each Update. If VSYNC WAIT is enabled (typically in full screen mode), then I could be waiting for up to 50 times the screen refresh time, and that's a lot ! And the worst part is that if the Update method doesn't draw anything on screen then all those 50 renders could produce exactly the same image...

Something like Game.StopRendering() / Game.ResumeRendering() would be nice. It might impact the physical FPS (expecially if VSYNC WAIT is disabled), but if used carefully it could help speed up script execution tremendously and thus the game logic.

Cheers,
 Olivier

[Mnemonic]

Ok, I added an attribute for suspending rendering. If it's going to be of any use remains to be seen.

[adonf]

Ok, thank you. I'll try it as soon as wme_latest.zip is back online and let you know if i'm getting any speed improvements...

[Mnemonic]

Could you please also check if the video card selection now remembers the right device on your dual-screen system?

[adonf]

http://dead-code.org/download/wme_latest.zip returns an error. Was it moved to another location ?

[Mnemonic]

There is no "wme latest" currently available. The latest release is 1.6 beta 3. I'll be probably releasing next beta with the rendering suspend thingie.
But the dual screen fix is already present in beta 3.

[adonf]

oooops, sorry

[adonf]

So I did a couple of test, and here's what I'm getting:

The screen settings are saved and read correctly, but there are still a few problems with dual screen:
- in windowed mode the game opens in the first screen, regardless of the screen that was selected
- in full screen mode the game opens in the correct screen but if the user selects the second screen then the mouse pointer is stuck in the first screen; alt-tabbing out of the game and back in moves the pointer into the correct screen
- when the game is run in windowed mode and the window is in the wrong screen, the frame rate gets very, very low. In my case the game runs at 400 FPS in one window and 20 in the other one (but that's a good thing in a way because it lets me test the game as if I had a super slow PC)

I also tested the SuspendedRendering flag and I got a 40% speed increase when running at 20 FPS (see point 3 above). This is good, but not as much as I expected, because when I remove all calls to custom methods i get a 300% speed increase. I need to look into that in details.

But anyway, it means that custom object methods do *not* need to be avoided at all cost in minigames, and that's a relief for me.

Cheers,
  Olivier

[Mnemonic]

1) dual screen
Yes, thanks. I did some research in the meantime so I'll be looking into improving the multimon support.
The framerate drop when you move the window to secondary monitor is by design (by *Windows* design, that is). The Direct3D device is always bound to a specific monitor. Even if you move the window to another monitor, it's still rendered by the original device and the resulting image is then copied to the other device, hence the slowdown.
But WME should originally position its window to the correct monitor.

2) SuspendedRendering
Errm, there must be some confusion going on, because it's not yet included in beta 3 (or any other publicly available build). It will be present in 1.6 beta 4. Although I could release some working version now, for your testing purposes, since wme.exe is once again in publishable state

[adonf]

2) SuspendedRendering
Errm, there must be some confusion going on, because it's not yet included in beta 3[...]

note to self: run more than one test before drawing conclusions 

[adonf]

Hi Mnemonic,

I tried Game.SuspendedRendering with a version of the engine that actually supports it (1.6b4) and I'm happy to tell you that on a low frame rate (15-20) the the scripts for our minigame run almost ten times faster than before. That's even better than when I removed all calls to custom object methods and put all the functions in a single script file.

On very high frame rates (~440 fps) I still get a speed increase of about 100%...

Thanks for this feature !

Olivier