[Ohrrpgce] SVN: james/6397 Remove docs for Scrunch slice because I am having second thoughts

Fri Feb 14 07:16:45 PST 2014

On 15 February 2014 04:04, James Paige <Bob at hamsterrepublic.com> wrote:
>
> On Thu, Feb 13, 2014 at 11:05 PM, Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>>
>> On 14 February 2014 07:55, James Paige <Bob at hamsterrepublic.com> wrote:
>> > On Thu, Feb 13, 2014 at 7:26 AM, James Paige <Bob at hamsterrepublic.com>
>> > wrote:
>> >>
>> >> I haven't done profiling, but I strongly suspect that the slowdown is
>> >> simply when there are large numbers of slices on the screen that have
>> >> to do
>> >> collision testing with each other.
>>
>> But do the invisible slices affect the collision checking?
>
>
> No, actually I guess they don't.
>
>>
>> Once script commands can return lists we can implement much more
>> efficient collision checking commands. The current commands are very
>> bad.
>
>
> That would be wonderful :)

Not that it seems to be a problem at all for Vorpal Florist

>> >> If you are interested in profiling it, the game is at
>> >> svn://gilgamesh.hamsterrepublic.com/ohrrpgce/games/vorpalflorist
>>
>> But what is the problem enemy?
>
>
> On the very first map, the Death Tulip. It is a connected chain, so there
> could be problems in the code that keeps the chain together.
>
> However, the particle effect in the save-point room is also noticeably slow,
> and it uses no collision at all, it is just a case of 50 non-colliding
> objects being on the screen at one time.
>
>>
>> > Actually, I just tried compiling with scriptprofiling, and when I ran,
>> > all
>> > the output I got was
>> >
>> > OHRRPGCE wip 20140212.6396 gfx_sdl+fb/music_sdl FreeBASIC 0.90.1
>> > (07-17-2013) -g -exx script_profiling Linux 32-bit
>> > Runtime info: gfx_sdl "SDL 1.2.14 (0 joysticks) Driver:x11"  music_sdl,
>> > SDL_Mixer 1.2.11 (22050Hz)
>> > Playing game
>> > /home/james/src/ohr/wip/../games/vorpalflorist/vorpalflorist.rpgdir
>> > (Vorpal
>> > Florist) 02-13-2014 10:52:14
>> > Could not open /home/james/.ohrrpgce/vorpalflorist/gameconfig.ini
>> > Partial game data upgrade...
>> > script profiling information:
>> > #switches is the number of times that the interpreter switched to that
>> > script
>> > (switching time is relatively neglible and included to help determine
>> > calls to other scripts, which are more expensive)
>> > Total time recorded in interpreter: 0.000sec   (timer overhead = 1.96us)
>> >  %time        time    time/call      #calls   #switches  script name
>> > cleaningup
>> > /home/james/src/ohr/wip/../games/vorpalflorist/vorpalflorist.rpgdir and
>> > /home/james/.ohrrpgce/ohrrpgce20140213105213.795.tmp/
>> > Could not rmdir(/home/james/.ohrrpgce/ohrrpgce20140213105213.795.tmp/):
>> > Directory not empty
>> >
>> > Is scriptprofiling broken right now?
>>
>> I completely forgot about this problem (and it took me a while to
>> realise what was going on). The script profiling information is only
>> printed when you quit the game normally; it doesn't get printed when
>> you quit with alt+F4/etc.
>>
>> Also, don't forget that you should compile with scriptprofile=1
>> debug=0, because -exx greatly slows things down, but release builds
>> are built with debug=0. Actually if you're investigating performance
>> on Ouya you should compile with gengcc=1. (And we should probably
>> compile release builds with gengcc=1 on all platforms to speed things
>> up if it's stable enough.)
>
>
> Okay, I will try that. Does android-source=1 also turn on debug=0 ?

No. So I suppose you've been creating debug builds.

>>
>> >>
>> >>
>> >> On Thu, Feb 13, 2014 at 4:54 AM, Ralph Versteegen <teeemcee at gmail.com>
>> >> wrote:
>> >>>
>> >>> On 13 February 2014 18:02, James Paige <Bob at hamsterrepublic.com>
>> >>> wrote:
>> >>> > To be more specific about those second thoughts
>> >>> >
>> >>> > 1) Although the scrunch was working nicely, I had not considered the
>> >>> > fact
>> >>> > that it means that the position and size of the child slices are
>> >>> > effectively
>> >>> > in different units. I had expected to deal with this manually in my
>> >>> > script,
>> >>> > until I noticed that it makes the "slice edge x" and "slice edge y"
>> >>> > commands
>> >>> > useless. I am reluctant to add special-case handling for scrunch
>> >>> > slices
>> >>> > to
>> >>> > those commands. That would mean i would have to script my own
>> >>> > versions
>> >>> > of
>> >>> > them for my game, and that will probably have performance impacts.
>> >>> > Those
>> >>> > commands do get use a whole lot in collision detection.
>> >>> >
>> >>> > 2) After further testing, I doubt I can get my scripts to work
>> >>> > reliably
>> >>> > at
>> >>> > 36 FPS on the OUYA. Some existing enemies drag fps down to 17 fps,
>> >>> > which is
>> >>> > not a big deal when 18.3 is my target, but is game-killing when 36.6
>> >>> > is
>> >>> > my
>> >>> > target. Considering that the game looks nice and controls nice and
>> >>> > feels
>> >>> > pleasant at 18.3, I have flip-flopped back to not wanting to change
>> >>> > the
>> >>> > frame rate for this game.
>> >>> >
>> >>> > So that leaves me doubting whether I should leave ScrunchSlice in at
>> >>> > all. I
>> >>> > am leaning towards removing it, and I can always add it back later
>> >>> > if
>> >>> > somebody is working on a project that would benefit from it.
>> >>> >
>> >>> > ---
>> >>> > James
>> >>>
>> >>> That's too bad.
>> >>>
>> >>> I would consider sliceedgex/y returning the wrong results a bug
>> >>> though. When scaling is implemented they will have to return positions
>> >>> in the slice's coordinate system.
>> >>>
>> >>> Have you tried running the game with the script profiler or a regular
>> >>> profiler to see where all the time is spent? I would be quite
>> >>> interested to know. (Assuming that it's whole due to scripts.) I
>> >>> believe that the slice commands are quite inefficient, which is a
>> >>> problem because a script interpreter won't change that (unless direct
>> >>> access to slice data as object members is added).
>> >>>
>> >>> > On Wed, Feb 12, 2014 at 3:55 PM, <subversion at hamsterrepublic.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> james
>> >>> >> 2014-02-12 15:55:07 -0800 (Wed, 12 Feb 2014)
>> >>> >> 66
>> >>> >> Remove docs for Scrunch slice because I am having second thoughts
>> >>> >> ---
>> >>> >> U   wip/docs/plotdict.xml
>> >>> >> U   wip/docs/plotdictionary.html
>> >>> >> U   wip/whatsnew.txt
>> >>> >> _______________________________________________
>> >>> >> Ohrrpgce mailing list
>> >>> >> ohrrpgce at lists.motherhamster.org
>> >>> >>
>> >>> >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>> >>> >
>> >>> >
>> >>> >
>> >>> > _______________________________________________
>> >>> > Ohrrpgce mailing list
>> >>> > ohrrpgce at lists.motherhamster.org
>> >>> >
>> >>> > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>> >>> >
>> >>> _______________________________________________
>> >>> Ohrrpgce mailing list
>> >>> ohrrpgce at lists.motherhamster.org
>> >>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > Ohrrpgce mailing list
>> > ohrrpgce at lists.motherhamster.org
>> > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>> >
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>