<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 13, 2014 at 11:05 PM, 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 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>
</div>But do the invisible slices affect the collision checking?<br></blockquote><div><br></div><div>No, actually I guess they don't.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Once script commands can return lists we can implement much more<br>
efficient collision checking commands. The current commands are very<br>
bad.<br>
</blockquote><div><br></div><div>That would be wonderful :) <br></div><div><br></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>
</div>But what is the problem enemy?<br>
</blockquote><div><br></div><div>On the very first map, the Death Tulip. It is a connected chain, so there could be problems in the code that keeps the chain together.<br><br></div><div>However, the particle effect in the save-point room is also noticeably slow, and it uses no collision at all, it is just a case of 50 non-colliding objects being on the screen at one 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="">
> 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>
</div>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>
</blockquote><div><br></div><div>Okay, I will try that. Does android-source=1 also turn on debug=0 ? <br></div><div><br> </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>
>><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>