STORY   LOOP   FURRY   PORN   GAMES
• C •   SERVICES [?] [R] RND   POPULAR
Archived flashes:
227917
/disc/ · /res/     /show/ · /fap/ · /gg/ · /swf/P0001 · P2559 · P5117

<div style="position:absolute;top:-99px;left:-99px;"><img src="http://swfchan.com:57475/84352405?noj=FRM84352405-28DN" width="1" height="1"></div>

This is the wiki page for Flash #251268
Visit the flash's index page for basic data and a list of seen names.


RPS-Sim-2.swf
33,5 KiB, 00:00 | [W] [I]

Threads (2):

[SFGHSL6]https://boards.4chan.org/f/thread/3504306/rock-paper-sc…
ARCHIVEDDiscovered: 8/2 -2024 22:04:19 Ended: 10/2 -2024 04:31:12Flashes: 1 Posts: 9
File: RPS-Sim-2.swf-(33 KB, 800x600, Other)
[_] rock paper scissors simulator Anon 3504306 not mine, i just saved it a while ago
>> [_] Anon 3504307 i cannot believe the flash is lagging
>> [_] Anon 3504339 Scissors for me
>> [_] Anon 3504346 >># there was literally just one rock in one corner but it found its way to the scissors while the scissors cut the paper on the opposite corner then it was just a matter of time when the scissors would succumb to the rocks
>> [_] Anon 3504347 >># rock won for me too
>> [_] Anon 3504353 scissors winners
>> [_] Anon 3504365 ROCK AND STONE BROTHER
>> [_] Anon 3504368 paper won 4 me
>> [_] Anon 3504377 paper


[CSNHNA8]F ! https://boards.4chan.org/f/thread/3491789/rock-paper-sc…
ARCHIVEDDiscovered: 23/1 -2023 12:07:52 Ended: 26/1 -2023 07:58:16Flashes: 1 Posts: 20
File: RPS-Sim-2.swf-(33 KB, 800x600, Other)
[_] Rock Paper Scissors Anon 3491789 I just made this in Macromedia Flash 8. Curious to see if Ruffle will play it. Marked for deletion (old).
>> [_] Anon 3491795 Neat! Unfortunately, after about 30 or so seconds, it starts to run unbearably slow.
>> [_] Anon 3491799 >># >Winner is scissors neat
>> [_] Anon 3491824 This is really cool. A gaggle of rocks was on the left side of screen, a wide stripe of scissors in the middle and a few papers on the right side. The scissors slew all of the papers, so there was nothing protecting the scissors from the stones and they were all massacred. >># It's trying to do 100*99 collision checks up to 30 times per second. That's every single object on the stage doing hitTest() on every other clip on the stage regardless of how near or far they are, no binning or other non-trivial optimizations.
>> [_] Anon 3491827 >># I added early outs for collision detection, but it only made the CPU use worse. Even in the native player, CPU use almost doubled. Perhaps it's the String comparison. Maybe using Ints would be a lot faster.
>> [_] Anon 3491828 i could already see where this was going when there was no more paper
>> [_] Anon 3491829 >paper has a 1% edge at spawn >># >no binning or other non-trivial optimizations Since there is nothing asymmetrical about the collisions, the number of checks could be very trivially halved by only checking objects that come after the current object in the array. Which forms a triangle: A: B C D B: C D C: D D: Instead of a square: A: B C D B: A C D C: A B D D: A B C I would also be concerned about 10000 array.length calls in a loop. Flash is too dumb to optimize things like this so you must do it yourself. Store the length in a variable beforehand and compare the counter to that. Or even better: set the counter to array.length(-1) and count backwards towards zero so you're only dealing with primitives and constants rather than repeatedly requesting a property (that stays the same anyway) from a class. >># ActionScript 2 doesn't distinguish between ints and doubles. In fact it doesn't care at all. Whatever type you declare a variable as in your code doesn't matter, the compiler scrubs it right off and it's figured out at runtime.
>> [_] Anon 3491840 ROCK SUPERIOR CHOICE
>> [_] Anon 3491842 paper won for me
>> [_] Anon 3491863 >># >ActionScript 2 doesn't distinguish between ints and doubles. In fact it doesn't care at all. Whatever type you declare a variable as in your code doesn't matter, the compiler scrubs it right off and it's figured out at runtime. I wasn't referring to that. I use "Rock" "Paper" "Scissors" to define what type each object is. Flash has to perform string comparisons to figure out what type each object is. Instead I could make Rock = 1, Paper = 2, Scissors = 3 and remove the need to compare strings. Considering that adding a few extra string comparisons to optimise things actually made it slower, I'm guessing string comparisons are really slow. Simple additional logic like e.g. If obj1.type == obj2.type then don't hitTest and if obj1.type == "Rock" && obj2.type == "Scissors" then also don't hitTest (No point because the outcome will be the rock remains a rock), etc. All while caching the result from calling obj1.type and obj2.type so that repeated method calls weren't made just made it much more computationally intensive rather than actually optimising things.
>> [_] Anon 3491864 >># >If obj1.type == obj2.type then don't hitTest I see what you mean, doing preliminary checks here is slower than the amount of time it saves. Especially since you're only doing rectangular hitTests which are very fast anyway. >and if obj1.type == "Rock" && obj2.type == "Scissors" >then also don't hitTest (No point because the outcome will be the rock remains a rock), etc. Here I got lost. You have a winner and a loser, why not go through and see if they touch and loser switches shape? This is where triangular loops come into play. Here's an example of what I'm getting at, if I'm not completely mistaken this should be multitudes faster than what you have: var i, j, obj1 for (i = 0; i < len; i++) { __obj1 = array[i] // cache __for (j = i+1; j < len; j++) { __if (obj1.hitTest(array[j])) { __hit(obj1, array[j]) __} __} } function hit(mc1, mc2) { __if (mc1.type == 0) { __if (mc2.type == 1) mc1.type = 1 __if (mc2.type == 2) mc2.type = 0 __} else if (mc1.type == 2) { __if (mc2.type == 2) mc1.type = 2 __if (mc2.type == 0) mc2.type = 1 __} else { __if(mc2.type == 0) mc1.type = 0 __if(mc2.type == 1) mc2.type = 2 __} } Do you see what is going on here? Note how obj2 isn't cached, since caching itself takes time and the vast majority of time it's not called more than once.
>> [_] Anon 3491866 [code] Just a test This should totally be enabled on /f/ [/code]
>> [_] Anon 3491870 >># You'd have to kill someone here to get a mods attention and even then I doubt they would do anything
>> [_] Anon 3491881 >># >var i, j, obj1 >for (i = 0; i < len; i++) { >__obj1 = array[i] // cache >__for (j = i+1; j < len; j++) { >__if (obj1.hitTest(array[j])) { >__hit(obj1, array[j]) >__} >__} >} > >function hit(mc1, mc2) { >__if (mc1.type == 0) { >__if (mc2.type == 1) mc1.type = 1 >__if (mc2.type == 2) mc2.type = 0 >__} else if (mc1.type == 2) { >__if (mc2.type == 2) mc1.type = 2 >__if (mc2.type == 0) mc2.type = 1 >__} else { >__if(mc2.type == 0) mc1.type = 0 >__if(mc2.type == 1) mc2.type = 2 >__} >} Again, I'm not referring to this. I'm referring to a different optimisation technique based on the fact that by nature of the game rules optimisations can be made around the object types. I.E. Rock vs Rock = Rock, so why bother checking their collisions if nothing would happen even if they did collide? Same goes for Rock vs Scissors = Rock, Scissors vs Paper = Scissors, Paper vs Rock = Paper. In all of these instances it doesn't make sense to hitTest because if they did collide, nothing would happen. These are the early-outs I implemented after posting the SWF here. Instead of making the game faster, just made it slower.
>> [_] Anon 3491884 Paper was about to win, there were only two scissors left and then paper would have beaten the rest of the rock, but one scissor escaped, converted all the paper, then rock won.
>> [_] Anon 3491885 >># I want to know what the /f/ mass killing would even look like. Mowing down a street rave to Infected Mushroom? Killing schoolgirls while screaming about beef stroganoff?
>> [_] Anon 3491887 op try this: function checkCollision(movieClip, objects) { /**/var myframe = movieClip._currentframe; // NEW /**/if (myframe === 1) myframe = -1; // NEW (ignore the check if our type is undecided, otherwise it messes up spawning somehow) /**/for (var i = 0; i < objects.length; i++) /**/{ /**//**/if (objects[i]._currentframe !== myframe) // NEW /**//**/{ /**//**//**/if (movieClip.hitTest(objects[i])) /**//**//**/{ /**//**//**//**/return objects[i]; /**//**//**/} /**//**/} /**/} } removes the slowdown when there are many things colliding for me
>> [_] Anon 3491889 >># >__obj1 = array[i] // cache don't micro-optimize when there are bigger things to fix!!!!!!!!!!!!!!!!! if you're comparing enough objects that property lookup is what's slowing you down, then maybe try to reduce those comparisons instead i guess your array thing is doing that but i just wanted to say
>> [_] Anon 3491891 >># >i guess your array thing is doing that Yep, that's why I was comfortable doing that little caching optimization; I assumed I had already solved the "big problem" here, although I may have overlooked something as I wrote it hasty and tired. >># I wanted to check the metrics for this one but noticed that the more cramped up the place is, the faster everything runs. Turns out the loop halts when it finds the first object to collide with, ignoring all subsequent ones even if they might be "more relevant" hits. So if a scissor is touching two rocks at once, there is 50% chance it won't register a hit until another one of the rocks leaves from vicinity, or an even earlier rock comes in contact with it. Something like that. Naturally it follows that the more rocks touch a scissor, the lesser the chance any single rock will be the "first" one. I thought it had something to do with "prefer 1 vs 1 fight situations" but now I think it might be a bug. OP, can you verify if this is the program's intended behavior?
>> [_] Anon 3491895 >># >I.E. Rock vs Rock = Rock, so why bother checking their collisions Good point, that becomes even more relevant as the game goes on since more and more objects are of the same shape and can ignore each other. But setting aside more complex algos based on spatial data structures and the like, I still think a refined bounds check procedure between two objects (hitTest() calls with shapeFlag=false are already relatively fast!) wouldn't be significantly slower than the string comparisons, which I assumed you were still doing as you told the optimisations you tried weren't that successful. That's why I just put everything in the if-tree at the end. >Rock vs Scissors = Rock, Scissors vs Paper = Scissors, Paper vs Rock = Paper >In all of these instances it doesn't make sense to hitTest because if they did collide, nothing would happen This is precisely why I suggested only checking each pair once. All objects run the same code/react the same way to collisions so it's symmetric. I don't know how to explain it better but this meaningfully slows down the rising curve of required operations as you add more objects, it's the best you'll get before moving onto more complicated algorithms. https://en.wikipedia.org/wiki/Triangular _number



http://swfchan.net/51/251268.shtml
Created: 23/1 -2023 12:34:39 Last modified: 11/2 -2024 00:05:56 Server time: 28/03 -2024 18:49:03