<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 14, 2014 at 7:56 AM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 15 February 2014 04:27, James Paige <<a href="mailto:Bob@hamsterrepublic.com">Bob@hamsterrepublic.com</a>> wrote:<br>
><br>
> On Fri, Feb 14, 2014 at 7:12 AM, Ralph Versteegen <<a href="mailto:teeemcee@gmail.com">teeemcee@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On 14 February 2014 20:05, Ralph Versteegen <<a href="mailto:teeemcee@gmail.com">teeemcee@gmail.com</a>> wrote:<br>
>> > On 14 February 2014 07:55, James Paige <<a href="mailto:Bob@hamsterrepublic.com">Bob@hamsterrepublic.com</a>> wrote:<br>
>> >> On Thu, Feb 13, 2014 at 7:26 AM, James Paige <<a href="mailto:Bob@hamsterrepublic.com">Bob@hamsterrepublic.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> I haven't done profiling, but I strongly suspect that the slowdown is<br>
>> >>> simply when there are large numbers of slices on the screen that have<br>
>> >>> to do<br>
>> >>> collision testing with each other.<br>
>> ><br>
>> > But do the invisible slices affect the collision checking?<br>
>> ><br>
>> > Once script commands can return lists we can implement much more<br>
>> > efficient collision checking commands. The current commands are very<br>
>> > bad.<br>
>><br>
>> Oh, looking at the profiling information I see that the slice<br>
>> collision commands are not the problem. checkpointcollision is the<br>
>> most expensive script, with 29% of time... but I'm not really sure<br>
>> why. It doesn't seem to call any expensive commands or do much<br>
>> looping.<br>
><br>
><br>
> Oh, that makes sense to me. "check point collision" is the core of the wall<br>
> collision code, so it doesn't seem surprising that it gets called a heck of<br>
> a lot. It gets called between 1 and 3 times for every collision node on<br>
> every slice in every tick (and the number of collision nodes varies between<br>
> 2 and several dozen depending on its size and current motion)<br>
><br>
><br>
>><br>
>> >>> If you are interested in profiling it, the game is at<br>
>> >>> svn://<a href="http://gilgamesh.hamsterrepublic.com/ohrrpgce/games/vorpalflorist" target="_blank">gilgamesh.hamsterrepublic.com/ohrrpgce/games/vorpalflorist</a><br>
>> ><br>
>> > But what is the problem enemy?<br>
>><br>
>> That was a very easy question to answer by actually trying out the<br>
>> game! (Actually it runs at less than 18fps even on my desktop unless I<br>
>> compile with gengcc=1)<br>
>><br>
>> I really like the animations for jumping and attacking, but I still<br>
>> think the walking animation looks a bit odd.<br>
<br>
</div></div>The carrotmen are my favourites. The animation and the AI are both wonderful.<br>
<div class=""><br></div></blockquote><div><br></div><div>Thanks! :)<br></div><div>I hope to do more with shields.<br></div><div>Also, not having feet always seems to make animations easier.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
> I can work on it. I can't really do anything about the number of frames, or<br>
> the speed they display, but I could try adjusting the foot position. Maybe<br>
> she just needs to take longer steps.<br>
><br>
>><br>
>> The AI for the enemy in the first room seem to misbehave a bit if you<br>
>> run past it and stand either behind it out of range, or somewhere in<br>
>> the middle of its range.<br>
><br>
><br>
> How would you describe misbehaving?<br>
><br>
> The Death Tulip is by far the most random AI of any of the enemies I have<br>
> implemented so far. Most of them barely use randomness at all, but the death<br>
> tulip is flailing around randomly at least 50% of the time.<br>
<br>
</div>I see I was mistaken; the behaviour does match what you describe. It<br>
just looked worse than 50% because the top tulip can't reach far in<br>
that direction anyway, and the bottom one tends to get stuck on the<br>
other side.<br><div class="HOEnZb"><div class="h5"></div></div></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
>><br>
>> >> Actually, I just tried compiling with scriptprofiling, and when I ran,<br>
>> >> all<br>
>> >> the output I got was<br>
>> >><br>
>> >> OHRRPGCE wip 20140212.6396 gfx_sdl+fb/music_sdl FreeBASIC 0.90.1<br>
>> >> (07-17-2013) -g -exx script_profiling Linux 32-bit<br>
>> >> Runtime info: gfx_sdl "SDL 1.2.14 (0 joysticks) Driver:x11" music_sdl,<br>
>> >> SDL_Mixer 1.2.11 (22050Hz)<br>
>> >> Playing game<br>
>> >> /home/james/src/ohr/wip/../games/vorpalflorist/vorpalflorist.rpgdir<br>
>> >> (Vorpal<br>
>> >> Florist) 02-13-2014 10:52:14<br>
>> >> Could not open /home/james/.ohrrpgce/vorpalflorist/gameconfig.ini<br>
>> >> Partial game data upgrade...<br>
>> >> script profiling information:<br>
>> >> #switches is the number of times that the interpreter switched to that<br>
>> >> script<br>
>> >> (switching time is relatively neglible and included to help determine<br>
>> >> calls to other scripts, which are more expensive)<br>
>> >> Total time recorded in interpreter: 0.000sec (timer overhead =<br>
>> >> 1.96us)<br>
>> >> %time time time/call #calls #switches script name<br>
>> >> cleaningup<br>
>> >> /home/james/src/ohr/wip/../games/vorpalflorist/vorpalflorist.rpgdir and<br>
>> >> /home/james/.ohrrpgce/ohrrpgce20140213105213.795.tmp/<br>
>> >> Could not rmdir(/home/james/.ohrrpgce/ohrrpgce20140213105213.795.tmp/):<br>
>> >> Directory not empty<br>
>> >><br>
>> >> Is scriptprofiling broken right now?<br>
>> ><br>
>> > I completely forgot about this problem (and it took me a while to<br>
>> > realise what was going on). The script profiling information is only<br>
>> > printed when you quit the game normally; it doesn't get printed when<br>
>> > you quit with alt+F4/etc.<br>
>> ><br>
>> > Also, don't forget that you should compile with scriptprofile=1<br>
>> > debug=0, because -exx greatly slows things down, but release builds<br>
>> > are built with debug=0. Actually if you're investigating performance<br>
>> > on Ouya you should compile with gengcc=1. (And we should probably<br>
>> > compile release builds with gengcc=1 on all platforms to speed things<br>
>> > up if it's stable enough.)<br>
>> ><br>
>> >> ---<br>
>> >> James<br>
>> >><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> On Thu, Feb 13, 2014 at 4:54 AM, Ralph Versteegen <<a href="mailto:teeemcee@gmail.com">teeemcee@gmail.com</a>><br>
>> >>> wrote:<br>
>> >>>><br>
>> >>>> On 13 February 2014 18:02, James Paige <<a href="mailto:Bob@hamsterrepublic.com">Bob@hamsterrepublic.com</a>><br>
>> >>>> wrote:<br>
>> >>>> > To be more specific about those second thoughts<br>
>> >>>> ><br>
>> >>>> > 1) Although the scrunch was working nicely, I had not considered<br>
>> >>>> > the<br>
>> >>>> > fact<br>
>> >>>> > that it means that the position and size of the child slices are<br>
>> >>>> > effectively<br>
>> >>>> > in different units. I had expected to deal with this manually in my<br>
>> >>>> > script,<br>
>> >>>> > until I noticed that it makes the "slice edge x" and "slice edge y"<br>
>> >>>> > commands<br>
>> >>>> > useless. I am reluctant to add special-case handling for scrunch<br>
>> >>>> > slices<br>
>> >>>> > to<br>
>> >>>> > those commands. That would mean i would have to script my own<br>
>> >>>> > versions<br>
>> >>>> > of<br>
>> >>>> > them for my game, and that will probably have performance impacts.<br>
>> >>>> > Those<br>
>> >>>> > commands do get use a whole lot in collision detection.<br>
>> >>>> ><br>
>> >>>> > 2) After further testing, I doubt I can get my scripts to work<br>
>> >>>> > reliably<br>
>> >>>> > at<br>
>> >>>> > 36 FPS on the OUYA. Some existing enemies drag fps down to 17 fps,<br>
>> >>>> > which is<br>
>> >>>> > not a big deal when 18.3 is my target, but is game-killing when<br>
>> >>>> > 36.6 is<br>
>> >>>> > my<br>
>> >>>> > target. Considering that the game looks nice and controls nice and<br>
>> >>>> > feels<br>
>> >>>> > pleasant at 18.3, I have flip-flopped back to not wanting to change<br>
>> >>>> > the<br>
>> >>>> > frame rate for this game.<br>
>> >>>> ><br>
>> >>>> > So that leaves me doubting whether I should leave ScrunchSlice in<br>
>> >>>> > at<br>
>> >>>> > all. I<br>
>> >>>> > am leaning towards removing it, and I can always add it back later<br>
>> >>>> > if<br>
>> >>>> > somebody is working on a project that would benefit from it.<br>
>> >>>> ><br>
>> >>>> > ---<br>
>> >>>> > James<br>
>> >>>><br>
>> >>>> That's too bad.<br>
>> >>>><br>
>> >>>> I would consider sliceedgex/y returning the wrong results a bug<br>
>> >>>> though. When scaling is implemented they will have to return<br>
>> >>>> positions<br>
>> >>>> in the slice's coordinate system.<br>
>> >>>><br>
>> >>>> Have you tried running the game with the script profiler or a regular<br>
>> >>>> profiler to see where all the time is spent? I would be quite<br>
>> >>>> interested to know. (Assuming that it's whole due to scripts.) I<br>
>> >>>> believe that the slice commands are quite inefficient, which is a<br>
>> >>>> problem because a script interpreter won't change that (unless direct<br>
>> >>>> access to slice data as object members is added).<br>
>> >>>><br>
>> >>>> > On Wed, Feb 12, 2014 at 3:55 PM, <<a href="mailto:subversion@hamsterrepublic.com">subversion@hamsterrepublic.com</a>><br>
>> >>>> > wrote:<br>
>> >>>> >><br>
>> >>>> >> james<br>
>> >>>> >> 2014-02-12 15:55:07 -0800 (Wed, 12 Feb 2014)<br>
>> >>>> >> 66<br>
>> >>>> >> Remove docs for Scrunch slice because I am having second thoughts<br>
>> >>>> >> ---<br>
>> >>>> >> U wip/docs/plotdict.xml<br>
>> >>>> >> U wip/docs/plotdictionary.html<br>
>> >>>> >> U wip/whatsnew.txt<br>
>> >>>> >> _______________________________________________<br>
>> >>>> >> Ohrrpgce mailing list<br>
>> >>>> >> <a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.org</a><br>
>> >>>> >><br>
>> >>>> >> <a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" target="_blank">http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org</a><br>
>> >>>> ><br>
>> >>>> ><br>
>> >>>> ><br>
>> >>>> > _______________________________________________<br>
>> >>>> > Ohrrpgce mailing list<br>
>> >>>> > <a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.org</a><br>
>> >>>> ><br>
>> >>>> > <a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" target="_blank">http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org</a><br>
>> >>>> ><br>
>> >>>> _______________________________________________<br>
>> >>>> Ohrrpgce mailing list<br>
>> >>>> <a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.org</a><br>
>> >>>><br>
>> >>>> <a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" target="_blank">http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org</a><br>
>> >>><br>
>> >>><br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> Ohrrpgce mailing list<br>
>> >> <a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.org</a><br>
>> >> <a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" target="_blank">http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org</a><br>
>> >><br>
>> _______________________________________________<br>
>> Ohrrpgce mailing list<br>
>> <a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.org</a><br>
>> <a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" target="_blank">http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Ohrrpgce mailing list<br>
> <a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.org</a><br>
> <a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" target="_blank">http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org</a><br>
><br>
_______________________________________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" target="_blank">http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org</a><br>
</div></div></blockquote></div><br></div></div>