Topic: Catle Wolfenstein ( continued )

Having spent only 2 evenings on it, the Castle Wolfenstein I entered in the 20 Liners - January 08 - Dynamics contest was a bit rough on the edges. It's exciting to work on such a script. Almost like it was to work on 3D TOMB II.



So here comes the first update:

• new design for the page
• completly rewritten keys handling to allow multiple keys mappings
• move using S, E, D, F or I, J, K, L on desktop or using the d-pad on Nintendo Wii
• 16×16 maze generator with a clear path from top left to bottom right
• attack dogs with "AI" ( they go toward you, dodge some obstacles and bite you when close enough )
• the maze is raycasted only when necessary
• completly rewritten markup generation and map editor to allow the generation of new levels

Known issues:

• the game is still slower in FF than Op :'(
• the online version seem to fire some HTTP request, download the game if this is affect the perfomance too much ... or if my host start seeing red
• still no worky in IE7
• the title of this thread should read Castle Wolfenstein ( continued )

It's 17 lines now, including one for the "attack indicator". I believe I can add the things in the To do list and not exceed 20 lines. Just give me a bit more time.


The address of the Castle Wolfenstein is still the same.

Hope you like it.



(Edited by poi on 02-02-2008 09:36)

most impressive

Very nice work poi. However, the framerate took a pretty significant hit in the last round of changes - do you know why this might be?

Also, has anyone ever experimented with multi-later raycasting in JS? I assumed you'd have to get rid of texturing etc to ever stand any hope of getting usable speed out of it, but...hmm....

Yeah, it's neat to say the least. It seems to reload the back map all the time in Op 9.2 (hence the http requests).

argo navis: the back map ?

wrayal: Just had a look in Op9.5 b9721 and FF3b2. Of course Castle Wolfenstein was never running in both browsers at the same time.


Op9.5 b9721 ( with 16 tabs open )

• Usually spend ~17 ms with the occasionnal peak at ~44 ms on the lines 8->11 , and ~1 ms on the lines 12->16
• There is no reflow in the main function. A reflow occurs between two calls though but it's reported as taking 0-1 ms. I'll have to ask some coleagues but that might be the blit when the function falls out of scope Not sure.
• The time spent on the lines 8->16 is constant regardless of the visibility of the renderArea.
• When the renderArea is NOT visible, the time between two calls is that of the setInteral + ~30 ms +- 10ms.
• When the renderArea is visible, the time between two calls is that of the setInteral + ~30 ms +- 10ms.
• Commenting out the style updates in the lines 8->11 down the time spent there to ~9 ms

FF3b2 ( with a single tab open )

• spend ~46 ms +- 6 ms on the lines 8->11 , and ~1 ms on the lines 12->16.
• I don't know how many reflows occurs
• The time spent on the lines 8->16 is constant regardless of the visibility of the renderArea.
• When the renderArea is NOT visible, the time between two calls is that of the setInteral.
• When the renderArea is visible, the time between two calls is that of the setInteral + ~100 ms +- 20ms.
• Commenting out the style updates in the lines 8->11 down the time spent there to ~25 +- 6 ms

SF3b4 ( with a single tab open )

• spend ~20 ms on the lines 8->11 , and ~1 ms on the lines 12->16.
• I don't know how many reflows occurs
• The time spent on the lines 8->16 is constant regardless of the visibility of the renderArea.
• When the renderArea is NOT visible, the time between two calls is that of the setInteral + ~15 ms.
• When the renderArea is visible, the time between two calls is that of the setInteral + ~50 +- 10 ms.
• Commenting out the style updates in the lines 8->11 down the time spent there to ~12 ms

Looks like the big bottleneck in FF3b2 is the blit. Since I don't know how many reflow occur in FF, I can't know for sure if it's purely a blit issue or if this is more serious like some CSS updates not being optimized and a/some reflow occurs although none of the style property I touch should trigger a one.

Alas it's not the only thing going wrong. JavaScript itself seem a little slow with a 3 fold difference on pure JavaScript processing of the lines 8->11. It might be the extensive use of variables with different scope. I'll try to figure this out.

Does anyone have some experience in that kind optimization ? Scott Schiller might know.


Btw, I'm giving out a unicorn to the first one who can tell me how to get the number of reflows and the time spent reflowing in Firefox, without recompiling it. And I top the offer with a puppy if you can get the same info for the redraws.



(Edited by poi on 02-02-2008 16:36)

Well, I can explain "backmap" but I'll be fine without the unicorn.

There is that uniform background gradient, which I assumed to be a unique image, since it doesn't really change - as it should.
That one gets reloaded a plenty in Op 9.2 on my laptop from way back.

Oh, thanks!

I had FUBAR'ed a background:url(path); to disable a background image I didn't need anymore, and Opera was, of course, trying to fetch it. No more HTTP request once the page is loaded.

New features:

• exit door
• generation of a new level : reset the player's coordinates and health and display an alert( "ENTER ROOM "+ M.level )
• create an increasing number of attack dogs per level
• fixed the markup generated. Very slight speed increase in FF3b2

quote:

---

poi said:
Looks like the big bottleneck in FF3b2 is the blit. Since I don't know how many reflow occur in FF, I can't know for sure if it's purely a blit issue or if this is more serious like some CSS updates not being optimized and a/some reflow occurs although none of the style property I touch should trigger a one. Alas it's not the only thing going wrong. JavaScript itself seem a little slow with a 3 fold difference on pure JavaScript processing of the lines 8->11. It might be the extensive use of variables with different scope.

---

I have not done any concrete tests on this, but I had a script for a DOM transformation mechanism that, in it's first iteration, was very reliant on variables in different scopes.

I later separated out all the functions to the global scope and sent the values I had earlier used through scoped variables as arguments, and the result took less than half the time to transform a big document (>50k nodes) than the original. There could exist other sources for the speedup than variable lookup, though, but I didn't really make any changes to the processing.

--
var Liorean = {
abode: "http://liorean.web-graphics.com/",
profile: "http://codingforums.com/member.php?u=5798"};

You mean putting everything in the window object ?

I tried to put just the U & V in the window object, and the time spent on the raycasting ( previously lines 8->11, now lines 9->12 ) went up by 10ms in FF. I might take a lot more elements/calculations to be worth it.


Mmmh, it seems that the rendering of the attack dogs is killing FF3b2.

If I comment out their rendering OR set the parents of the dogs to display:none; , the time between two calls drops to that of the setInteral + ~30 ms +- 10ms. Which I interpret as being just the redraw of the maze.

Setting the image of the dog in display:none; alone makes the delay climb back up to updateDelay + ~100 +- 20 ms. Which is too big a difference for being just a redraw and therefore look more like a reflow.


this alas look very much like a case of unecessary reflow in Gecko. Will keep looking, but if I'm correct, there's not much I can do. Sorry guys.




(Edited by poi on 02-02-2008 23:13)

quote:

---

poi said:
You mean putting everything in the window object?

---

Nope. It looked more like this, actually:

var
    transform=
        function(fn1,fn2,fn3,...){
            ...
            return function(transformpattern){...};
        }(
            function(objects,that,were,scoped,variables,in,first,version){...},
            function(objects,that,were,scoped,variables,in,first,version){...},
            function(objects,that,were,scoped,variables,in,first,version){...},
        ...);
transform(transformpattern);

Basically, all data including all functions needed passed as arguments instead of contained in variables in the scope of transform. That means no variable in any function need to be looked up in a containing scope at any point, including function names.

--
var Liorean = {
abode: "http://liorean.web-graphics.com/",
profile: "http://codingforums.com/member.php?u=5798"};

(Edited by liorean on 02-03-2008 01:29)

Declaring the update function in the global scope downs the processing time to ~35 ms in FF3b2, has no impact in OP9.5 and SF3b4.

Really got to find a rendering technique that don't trigger a reflow in FF

I haven't anything constructive to add, but have to say I'm impressed. I actually didn't get past the first room because I was so busy locking the attack dogs in boxes. Teehee!

dogs in boxes doh, you must have hit the page when I uploaded a test version.

Thanks.


Just noticed that OP9.2+ suffers a simillar reflow problem as FF3b2

Test version?

The same version is still up. I was running backwards, dropping blocks over the dogs as they approached, and clearing all other blocks on the editor box. Pointlessly, I managed to trap all of the attack dogs on the first level inside one block - they could be seen peeking through the walls of the block, and could still inflict damage on me if I got too close to it.

I know - it's not what you intended, but I'm just that sort of fiddler...

Aah I thought you meant there was like a border:2px solid gold; around the doggies.

Hehe, trapping the doggies can be fun too.


Not sure exactly where to go with the gameplay. I guess scoring a few points for stabbing the dogs but not for reaching another room, and maybe have some food plates lying around to increase you HP, should be enough fore a 20 liner.

Great work Po1, I've enjoyed playing it.


Those who look for monsters should look to it that
they do not become monsters. For when you gaze
long into the abyss, the abyss also gazes into you.

Great work indeed.