<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 14, 2014 at 7:12 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="">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 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>
</div>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><div class=""></div></blockquote><div><br></div><div>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)<br>
</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
>>> 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>
</div>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></blockquote><div><br></div><div>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. <br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
</blockquote><div> <br></div><div>How would you describe misbehaving?<br><br></div><div>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.<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">
>> Actually, I just tried compiling with scriptprofiling, and when I ran, 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 (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 = 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>> wrote:<br>
>>>> > To be more specific about those second thoughts<br>
>>>> ><br>
>>>> > 1) Although the scrunch was working nicely, I had not considered 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 slices<br>
>>>> > to<br>
>>>> > those commands. That would mean i would have to script my own 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 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 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 the<br>
>>>> > frame rate for this game.<br>
>>>> ><br>
>>>> > So that leaves me doubting whether I should leave ScrunchSlice in at<br>
>>>> > all. I<br>
>>>> > am leaning towards removing it, and I can always add it back later 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 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>
>>>> >> <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>
>>><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>