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

James Paige Bob at HamsterRepublic.com
Fri Feb 14 08:12:28 PST 2014 

On Fri, Feb 14, 2014 at 7:56 AM, Ralph Versteegen <teeemcee at gmail.com>wrote:

> On 15 February 2014 04:27, James Paige <Bob at hamsterrepublic.com> wrote:
> >
> > On Fri, Feb 14, 2014 at 7:12 AM, Ralph Versteegen <teeemcee at gmail.com>
> > wrote:
> >>
> >> On 14 February 2014 20:05, 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?
> >> >
> >> > Once script commands can return lists we can implement much more
> >> > efficient collision checking commands. The current commands are very
> >> > bad.
> >>
> >> Oh, looking at the profiling information I see that the slice
> >> collision commands are not the problem. checkpointcollision is the
> >> most expensive script, with 29% of time... but I'm not really sure
> >> why. It doesn't seem to call any expensive commands or do much
> >> looping.
> >
> >
> > Oh, that makes sense to me. "check point collision" is the core of the
> wall
> > collision code, so it doesn't seem surprising that it gets called a heck
> of
> > a lot. It gets called between 1 and 3 times for every collision node on
> > every slice in every tick (and the number of collision nodes varies
> between
> > 2 and several dozen depending on its size and current motion)
> >
> >
> >>
> >> >>> If you are interested in profiling it, the game is at
> >> >>> svn://gilgamesh.hamsterrepublic.com/ohrrpgce/games/vorpalflorist
> >> >
> >> > But what is the problem enemy?
> >>
> >> That was a very easy question to answer by actually trying out the
> >> game! (Actually it runs at less than 18fps even on my desktop unless I
> >> compile with gengcc=1)
> >>
> >> I really like the animations for jumping and attacking, but I still
> >> think the walking animation looks a bit odd.
>
> The carrotmen are my favourites. The animation and the AI are both
> wonderful.
>
>
Thanks! :)
I hope to do more with shields.
Also, not having feet always seems to make animations easier.


> > I can work on it. I can't really do anything about the number of frames,
> or
> > the speed they display, but I could try adjusting the foot position.
> Maybe
> > she just needs to take longer steps.
> >
> >>
> >> The AI for the enemy in the first room seem to misbehave a bit if you
> >> run past it and stand either behind it out of range, or somewhere in
> >> the middle of its range.
> >
> >
> > How would you describe misbehaving?
> >
> > The Death Tulip is by far the most random AI of any of the enemies I have
> > implemented so far. Most of them barely use randomness at all, but the
> death
> > tulip is flailing around randomly at least 50% of the time.
>
> I see I was mistaken; the behaviour does match what you describe. It
> just looked worse than 50% because the top tulip can't reach far in
> that direction anyway, and the bottom one tends to get stuck on the
> other side.
>

I am thinking maybe I should change it so there is just one Death Tulip
there, and maybe give it a less random movement pattern.


> >>
> >> >> 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
> >> >>
> >> _______________________________________________
> >> 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/20140214/fbb38ff7/attachment-0002.htm>

More information about the Ohrrpgce mailing list