Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

Entire forum
MUSHclient
Miniwindows
animation techniques

Home \| Users \| Search \| FAQ
Username:	Register forum user name
Password:	Forgotten password?

(New message)

Subject:	animation techniques
Name:	Your forum user name. Register forum user name
Password:	Your forum password. Forgotten password?
Message:	[quote=Nick Gammon] The first thing to think about is the difference between Redraw () and Repaint (). Redraw schedules an update of the whole MUSHclient window next time the Windows event loop is otherwise empty (eg. no outstanding keystrokes or mouseclicks). In practice, MUSHclient calls Redraw internally when new output arrives from the MUD (and is placed on the screen), and you do a WindowShow, and at various other spots. There is no particular harm in calling Redraw hundreds of times, they simply will result in a single screen update when there is nothing else to do. Usually this results in a quite responsive screen update. However Repaint () causes a screen update now. And if a dozen plugins all call Repaint () then you get a dozen screen updates. Now this is likely to slow things down, what with all the text drawing, copying of miniwindow images etc. Having said that, there might be a case for calling Repaint. In another thread recently it was pointed out that the mapper "seemed unresponsive" as you quickly speedwalked from one place to another, because this caused so much incoming data to arrive, that the redrawing of the screen was deferred so much that the mapper seemed jerky. I definitely don't think every plugin should call Repaint "just to make sure" its changes are seen. This is likely to cause major slowdowns. However OTOH not calling it at all may make the system seem slow to respond. If you are implementing sprites, then you probably need to call Repaint to make sure the sprites are actually visibly moved around. Bear in mind that repainting the screen 25 times a second might impose quite a load on the system. One possible approach might be to make sure that Repaint is called at least a few times a second (eg. every 5th time through the tick callback) and at other times call Redraw. That way you are guaranteed that at least some sprite movements will be drawn, and with luck, more will be. Remember, on a slower PC, forcing 25 repaints a second might actually be using so much of the CPU that there is none left for actually doing something useful. [/quote] Message to be posted (in English, please).
Forum codes:	Check this if your message uses 'forum codes' or templates (auto-detected for new posts). Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Posted by

Nick Gammon Australia (18,772 posts)

bio Forum Administrator

Date

Fri 19 Nov 2010 10:57 PM (UTC) [ quote ]

Message

I had a reasonable size 3D window going a while back. It updated quite well as you walked around. However that might not have been 25 times a second.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Retnur (9 posts)

bio

Date

Fri 19 Nov 2010 10:06 PM (UTC) [ quote ]

Message

That's kinda what I was afraid of. :(

So far I've only been animating small 32*32 areas 4 times a second. Its been doing okay. That may change once I have more than a few.

top

Posted by

Worstje Netherlands (867 posts)

bio

Date

Fri 19 Nov 2010 02:22 PM (UTC) [ quote ]

Message

I tried animating miniwindows in the past, and long story short: don't.

Even on fast computers it is painfully obvious MUSHclient was designed with miniwindows changing 'infrequently', as opposed to a number of times every second. My testcase was a bar that counted down as a visual indicator of when I'd be able to do something again, but it was either too jerky to use (or not get distracted by), or MUSHclient got so sluggish due to all the updates that it made the timer a bit of a moot point.

However, I must say.. I did that test with gradient thingies. With those updated in a recent version, I might retry it some time, but I'm not sure how big the difference would be.

top

Posted by

Retnur (9 posts)

bio

Date

Fri 19 Nov 2010 12:41 PM (UTC) [ quote ]

Message

No, that's not me. I'm using mushclient for a dedicated client for a from scratch project I've been quietly been working on for a few years. Its actually coming along nicely. I'm just not looking forward to digging into the cpp that's inevitably coming.

I actually got sprites working pretty smoothly. I have animated boxes and animated sprites currently finished.

I'm really debating going relatively fully graphical. Some other things I'm trying to work out on MC includes drag and drop functionality for various objects, a robust sound system for smooth transitions in loops, and text boxes for forms.

top

Posted by

Twisol USA (2,229 posts)

bio

Date

Fri 19 Nov 2010 09:27 AM (UTC) [ quote ]

Message

Looks like that person is using an external window with MUSHclient, since they're using C# and there's a visible second window.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

top

Posted by

Nick Gammon Australia (18,772 posts)

bio Forum Administrator

Date

Fri 19 Nov 2010 06:31 AM (UTC) [ quote ]

Message

I spotted this on YouTube yesterday:

http://www.youtube.com/watch?v=e3f_h9tPLVs

Someone (is that you?) seems to be making a 3D interface to Aardwolf, using MUSHclient.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Nick Gammon Australia (18,772 posts)

bio Forum Administrator

Date

Fri 19 Nov 2010 06:27 AM (UTC) [ quote ]

Message

The first thing to think about is the difference between Redraw () and Repaint ().

Redraw schedules an update of the whole MUSHclient window next time the Windows event loop is otherwise empty (eg. no outstanding keystrokes or mouseclicks). In practice, MUSHclient calls Redraw internally when new output arrives from the MUD (and is placed on the screen), and you do a WindowShow, and at various other spots.

There is no particular harm in calling Redraw hundreds of times, they simply will result in a single screen update when there is nothing else to do. Usually this results in a quite responsive screen update.

However Repaint () causes a screen update now. And if a dozen plugins all call Repaint () then you get a dozen screen updates. Now this is likely to slow things down, what with all the text drawing, copying of miniwindow images etc.

Having said that, there might be a case for calling Repaint. In another thread recently it was pointed out that the mapper "seemed unresponsive" as you quickly speedwalked from one place to another, because this caused so much incoming data to arrive, that the redrawing of the screen was deferred so much that the mapper seemed jerky.

I definitely don't think every plugin should call Repaint "just to make sure" its changes are seen. This is likely to cause major slowdowns. However OTOH not calling it at all may make the system seem slow to respond.

If you are implementing sprites, then you probably need to call Repaint to make sure the sprites are actually visibly moved around. Bear in mind that repainting the screen 25 times a second might impose quite a load on the system.

One possible approach might be to make sure that Repaint is called at least a few times a second (eg. every 5th time through the tick callback) and at other times call Redraw. That way you are guaranteed that at least some sprite movements will be drawn, and with luck, more will be.

Remember, on a slower PC, forcing 25 repaints a second might actually be using so much of the CPU that there is none left for actually doing something useful.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Retnur (9 posts)

bio

Date

Fri 19 Nov 2010 06:10 AM (UTC) [ quote ]

Message

I'm venturing into animated sprites, scrolling images, animated selection boxes, etc. I'm working on handlers for various animation types. I'm interested in tips or pitfalls based on the miniwindows implementation details. Currently I'm using the ontick callback for granularity in progressing frames.

top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

2,172 views.

Reply to this subject Start a new subject Refresh page

Go to topic: Search the forum

top

Comments to: Gammon Software support
Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )