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

[Ralph Versteegen]

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?

Once script commands can return lists we can implement much more
efficient collision checking commands. The current commands are very
bad.

>> If you are interested in profiling it, the game is at
>> svn://gilgamesh.hamsterrepublic.com/ohrrpgce/games/vorpalflorist

But what is the problem enemy?

> 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.)

> ---
> James
>
>>
>>
>>
>> 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
>