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

[James Paige]

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.

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

I know someday we will have arrays, and then I can rather easily retrofit
my scripts to store all the hero and enemy and object metadata in arrays
rather than cramming it into the members of invisible child slices. I
suspect that will help a bit.

---
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20140213/3876648f/attachment-0002.htm>