Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
abraxas Regular Member Joined: 16/06/2020 Location: CanadaPosts: 99
Posted: 12:44am 27 Jul 2020
Copy link to clipboard
Print this post
Not quite fully grasping the idea on the first read but I will be able to sit at my Maximite in about an hour and will study your code. And of course if there are no issues I'm super excited to incorporate it into the codebase. Thank you so much for spending your time on this, capsikin.
capsikin Guru Joined: 30/06/2020 Location: AustraliaPosts: 341
Posted: 01:09am 27 Jul 2020
Copy link to clipboard
Print this post
In case this helps:
The core concept is that fireflies moving doesn't need to call ADDSCANFORHEAVY if there are no rocks or diamonds near the cell it's leaving empty.
But you don't want to have to check every nearby cell for rocks and diamonds, so instead, you have a flag on a cell to say whether or not any of the nearby cells have rocks and diamonds.
The nearby rocks and diamonds would only need to be added to the scan list if they're not already falling, so the flag isn't cleared for having falling rocks and diamonds nearby, only when they come to a stop.
If the nearby rocks and diamonds were already in a stable position when something moves through a previously empty space, it doesn't need to call ADDSCANFORHEAVY for them, so on entering the empty space, it sets the flag (on its location) saying not to call it when it leaves.
capsikin Guru Joined: 30/06/2020 Location: AustraliaPosts: 341
Posted: 01:17am 27 Jul 2020
Copy link to clipboard
Print this post
It's becoming a bit harder to navigate the program as you've incorporated my speed up suggestions and put lots of code into a single SUB. Maybe add some multi-line comments as section breaks within SUB PROCESSTICK?
MauroXavier Guru Joined: 06/03/2016 Location: BrazilPosts: 303
Posted: 01:40am 27 Jul 2020
Copy link to clipboard
Print this post
Abraxas, don´t give up!
Proud yourself! Your code is clean and very well written, you have some people here that can help you and for sure you are in the right way. I have no doubt that you can do it!
My version of the Wolfenstein 3D now gives me so many headaches but I don´t give up, for example, I got an almost weekend to gain only 2 FPS!
This is the real challenge and you are doing the things very well done!
abraxas Regular Member Joined: 16/06/2020 Location: CanadaPosts: 99
Posted: 02:37pm 27 Jul 2020
Copy link to clipboard
Print this post
Thanks for the kind words of encouragement, Mauro. I'll keep at it for a bit. Things are a bit better with some of the suggestions implemented. Hope a few more incremental improvements will add up to a good progress.
Looking forward to where you take the Wf 3D too! It's amazing that you're getting anything close to interactive gameplay with just the BASIC code!
abraxas Regular Member Joined: 16/06/2020 Location: CanadaPosts: 99
Posted: 02:43pm 27 Jul 2020
Copy link to clipboard
Print this post
Thanks capsikin. I implemented your algo as a flag in the code (as opposed to a separate array). It's named in your honor so you won't have problems finding it :)
That said, when it's being used it causes the stones not to fall after a train of fireflies has passed. Your change either introduced or exacerbated the problem as I can't reproduce it when I remove the optimization. Anyway, have a go yourself. You can switch around both ways by switching whether lines 251 or 252 is enabled.
capsikin Guru Joined: 30/06/2020 Location: AustraliaPosts: 341
Posted: 12:27am 28 Jul 2020
Copy link to clipboard
Print this post
:)
Thanks. I should say what to search for to find my new code, that's a good idea.
I've made a test map for the bug, where you can go underneath a column of fireflies to let it out, so the rock should fall, but it doesn't (with my code enabled). I think the problem is in my code - the version I posted earlier seems buggy in a similar way, and with my code disabled I didn't see the problem either.
I found a bug in my original code's assumption about ADDSCANFORHEAVY, but you've changed ADDSCANFORHEAVY in your new version and that didn't fix it like I expected.
capsikin Guru Joined: 30/06/2020 Location: AustraliaPosts: 341
Posted: 01:09am 28 Jul 2020
Copy link to clipboard
Print this post
Ha, I found it.
I just had to add 2 more scanList lines in the dir = UP% case inside SUB ADDSCANFORHEAVY.
I don't know if there's a better way to fix it, there are quite a few more scanList lines than in the buggy version I first posted, but I think it's working.
This zip file also includes a gameslow.bas for debugging which shows the flag on screen, and also whether items are in the scanlist
changes in gameshow.bas: commented out version of SETTICK for slower timing inscan array, to keep track of whether locations ar in scanlist two box commands in SUB RENDERAREA to display the flags.
update: oops, we may need to fix LEFT and RIGHT cases inside SUB ADDSCANFORHEAVY as well.
The assumptions of my code were that ADDSCANFORHEAVY adds to scanlist: LEFT, UPLEFT, UP, UPRIGHT, RIGHT locations relative to the newly emptied space. Edited 2020-07-28 11:22 by capsikin
abraxas Regular Member Joined: 16/06/2020 Location: CanadaPosts: 99
Posted: 01:25am 28 Jul 2020
Copy link to clipboard
Print this post
Awesome sauce, capsikin! Thanks for chasing it down. I’m about to sit down at the CMM2 and get a bit more work done. Do you have any benchmarks to see the difference in your latest implementation vis a vis the unoptimized code i.e. the version that lacks CAPSIKIN_FLAG% entirely?
abraxas Regular Member Joined: 16/06/2020 Location: CanadaPosts: 99
Posted: 02:50am 28 Jul 2020
Copy link to clipboard
Print this post
I just sat down to work on this and brought in your changes and tested against the last version that lacks the CAPSIKIN_FLAG%. Unfortunately after the fixes you made the latest version that you posted appears to run a at about the same pace (65-85ms/frame) as the version that did not have the flag at all... which starts to put in question the value of the extra complexity that maintaining this flag is introducing.
Thoughts? Edited 2020-07-28 12:51 by abraxas
capsikin Guru Joined: 30/06/2020 Location: AustraliaPosts: 341
Posted: 10:13am 28 Jul 2020
Copy link to clipboard
Print this post
I fixed my earlier version - gamecjm2.bas - and tested against the one of yours I'd based it on.
Before I let the fireflies out, both versions were running at 66-68 ms once it settled down.
After I let the fireflies out, my code was still running at 67-68 ms, without my code it was running at about 84-85.
Not as big of a difference as I'd expected. I guess having lots of extra inert locations in the scanlist isn't as big a slowdown as I thought - I might test some more and see what happens if the fireflies are wandering past lots of rocks and diamonds. Also do more tests with the latest version (I think they're pretty similar in performance to my earlier version though).
From earlier:
This was good for testing the bug, but I also tried using it to test the speed improvement on a map where I'd cleared a big area for the fireflies. With your version of my code, since the CAPSIKIN_FLAG% starts out cleared, the speedup still applies except near rocks and diamonds, or where rocks and diamonds have been in the past.
My tests show it improves things from the worst end of that range to the best end, if the fireflies are free, but has hardly any effect if the fireflies are trapped together in a solid block.
In my opinion it's worthwhile using it, or maybe testing it some more. I haven't really tested how it performs during a large avalanche. There is a little extra code to take the optimisations that were initially only in the firefly movement, and add them to the rock/diamond movement.
But the other thing that's been stopping me is it's harder to test avalanche performance, because the numbers change a lot while it's happening and then change again at the end.
I should ask - have you made maps for testing the avalanche performance? And do you have any other tips on how you do it?
capsikin Guru Joined: 30/06/2020 Location: AustraliaPosts: 341
Posted: 01:46pm 28 Jul 2020
Copy link to clipboard
Print this post
One more post before I think about stopping for the evening.
This version (in game.bas) BDASH.zip has the optimisations applied to rock and diamond movement, that had previously only been applied for firefly movements. One call to CLEARCAPSIKIN, and one test before doing ADDSCANFORHEAVY. So its ready once I decide to test avalanche performance more.
I also removed most of the flag setting in the case of a rock/diamond sitting on a non-round object, leaving only: room(col, row+1)=room(col, row+1) OR CAPSIKIN_FLAG%
I also simplified SUB ADDSCANFORHEAVY, since it was needing to do mostly the same scanlist additions for all directions.
I'm thinking I might want to work on testing more. Before the CAPSIKIN_FLAG% idea, I measured the performance at some point as: about 33ms render. 85 logic. 55 first part (scan), 30 second part (process). Very little for the sort and math set commands. scanning time took about twice the command processing time, and that suggested to me that reducing the scanning time was the biggest thing. But I don't know how the balance is with the flag, and I'd also like to check how much of the time is taken by each type of object, how much time in scanning is taken by duplicates.
Another thought on the complexity of maintaining the flag - it wasn't as much of a speedup as I was hoping for. You could continue development without it, and I might see if I can improve on it or find other speedups.
abraxas Regular Member Joined: 16/06/2020 Location: CanadaPosts: 99
Posted: 02:33pm 28 Jul 2020
Copy link to clipboard
Print this post
No, don't get me wrong. I don't want to see us branch away. If we can provably see even a bit of a performance gain then I think it's worth keeping the optimization even if it's adding complexity - we need our wins wherever we can get them. I might set up a github repo if you want to collaborate on this project as it seems to have piqued your interest.
As for testing avalanches you can change the graphics mode to 1,8 and switch the viewport to 40/22 and things will render a lot more slowly :)
abraxas Regular Member Joined: 16/06/2020 Location: CanadaPosts: 99
Posted: 03:29am 29 Jul 2020
Copy link to clipboard
Print this post
See my other couple of posts about your questions but there is one thing I need to throw out there. I'm testing your branch tonight again and indeed it's quite a bit faster (about 10ms seems to be shaved off the total game tick) which is substantial BUUT I can still reproduce the issue with stones not falling after a train of fireflies chasing Rockford goes along a stone column. I don't know if this can really be solved. The more I think about it the more it seems that the flag can't work, here's why: Let's say Rockford is getting chased with by a firefly with one tile gap between them followed by more fireflies also one tile apart). So rockford makes the corridor, the firefly follows. As rockford marks the column as having scannable tiles around them, the first firefly cancels those marks and the subsequent fireflies hold up the stones not letting them drop. End result is that fireflies leave but the stones stay in a column. I can reproduce it reliably in your code version but not in the implementation that lacks the CAPSIKIN_FLAG. Seems to me that the approach could be fundamentally flawed or am I overlooking something?
thoughts on this?
capsikin Guru Joined: 30/06/2020 Location: AustraliaPosts: 341
Posted: 06:57am 29 Jul 2020
Copy link to clipboard
Print this post
Thanks for finding this! How it's supposed to work:
Say we're looking at one specific rock, that's supposed to roll to the left later, but it currently blocked.
To make sure it doesn't get stuck once the blockage is cleared, at least one of these conditions should hold at all times: 1: the rock can be in the scanlist. 2: the location to the left of the rock should have something in the way and be marked. 3: the location left/down from the rock should have something in the way and be marked. 4: the rock already rolled.
Say Rockford and the fireflies are going upwards past the left of the column. When Rockford leaves the top space, the rock should go on the scanlist. When the rock is processed on the scanlist, it should check that it's sitting on a curved surface but cannot roll, and mark 5 locations next to it, including the ones to the left, and left/down, including what is blocking it from rolling.
Whenever one of the marked fireflies moves (during command processing time) it should put the rock back on the scan list. Whenever the rock comes off the scanlist, it should mark the obstacles that stop it from rolling.
I think I found the bug:
What if the rock thinks it can move at scan time, but is blocked at process command time? There could be a bug there - it should either go back on the scanlist, or mark the blockages, and I don't think it does either yet.
There would need to be two spaces between the leaving rockford and the following firefly (or one of the fireflies and a subsequent one), so the rock thinks it can roll at scan time. Then the following firefly should come from the left, or above the rock (not below/left, but above/left or above/right should work), so it can move before the rock does.
I've had trouble reproducing your report with just one space (maybe you had a double space in the firefly train and I didn't), but if it's the one I just noticed... yes I can do it with just one firefly, if I slow the game to make exact timing easier.
I think this should be easy enough to fix. A rock that had a command to roll/fall, but was blocked, should put itself back on the scanList (same for diamond). Or alternatively it could mark the 5 below/beside locations instead, but that's not as simple.
In retrospect there was a missing step between conditions 1 and 4: 5: the rock is on the cmd list to move.
... yup, here's my game.bas with the fix and the slow down I used to test it.
Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
Page 2 of 2 
Print this page
