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

Ralph Versteegen teeemcee at gmail.com
Fri Feb 14 07:56:11 PST 2014 

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.

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

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

More information about the Ohrrpgce mailing list