edrevolution / pywright

Automatically exported from code.google.com/p/pywright
0 stars 0 forks source link

fade argument too restrictive #66

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Not sure what to do here. Feels pretty bad to add a bunch of controls to the 
char command to enable something like:

char bob fade_speed=2 fade_mode=fade_in

etc. That command is pretty full of arguments as is. When the rendering update 
works like it should, something like this should work properly:

char bob
fadein name=bob speed=100

(We can make a fadein/fadeout command since only rarely do you need the full 
control of fade to allow fading in to half transparency etc).

It's also kind of ugly in the code to check for the fade argument - might want 
to deprecate it. I am leaning toward making the language simpler rather than 
more complex, trying to remember all of the arguments that can go on the char 
command is worse than remembering that you can use char to load a char, and you 
can do effects to him with things like fade, tint, etc.

But I'm not sure.

Original issue reported on code.google.com by saluk64007@gmail.com on 27 Mar 2011 at 8:49

GoogleCodeExporter commented 9 years ago
After some time away, looking back at this I do think fade as an argument 
should be deprecated. Not sure when to actually remove it from the language 
(maybe never?). 

We could make "in" and "out" be tokens on the fade command that set the start 
and end to the right amount:

fade in name=bob

fade out name=bob

This should all work great when the frame update stuff is fixed.

Original comment by saluk64007@gmail.com on 22 Apr 2011 at 11:54

GoogleCodeExporter commented 9 years ago
Issue 49 has been merged into this issue.

Original comment by saluk64007@gmail.com on 22 Apr 2011 at 11:56

GoogleCodeExporter commented 9 years ago

Original comment by saluk64007@gmail.com on 2 Nov 2012 at 6:09

GoogleCodeExporter commented 9 years ago

Original comment by saluk64007@gmail.com on 2 Nov 2012 at 6:24