just starting out in java/html

[ninogenio]

excellent idea with the stripwidth ck!!

yeah that would certainly make this pretty dynamic on most every system and the difference in detail levels between 2 and 3 is very small.

infact we could start the engine with stripwidth = 1 and then just have in the mainloop if fps<30 stripwidth+=1; this then gives users with the available power max detail and users without smooth fps! yes thats an awesome idea.

i started too get excited when looking at the file api yesterday as it makes it possible for our web hosted raycaster game too be fully customized. by the individual users.

they could in theory point our games too a folder somewhere on the hd that has all the levels in txt format with an image folder in there that holds textures. then the engine can just load and parse the level files and related textures when needed.

this would also make the level editor usefull too more than just ourselfs. it would be great too get younger people involed in building a 3d game! my kids would love building there own
3d mazes .

-edit dynamic resolution rescale added. i only poll the fps counter every 6 seconds as there can be momentary frame drips that don't contribute too the average fps counter and i wouldn't like too change resolution based on these and also it takes a little time for the fps counter too warm up.

this works really well! i cant test it thoroughly as i am always above 30fps even with stripwidth set at 1. but under all fake situations i have put on it the program always hits the desired fps. its great k+ ck! i have been coding this pacman clone all day it's really starting too take shape 

one thing i noticed which is really cool is if you apply a sin wave too our workareay var it simulates the players head bobing up and down as he walks. there is loads of cool little things like that that can be done cheaply.

[combatking0]

URGENT BUG FIX!
On line 51 I have mis-typed the wall texture onload function declaration as

Code: [Select]

onLoad = new function(){when it should be

Code: [Select]

onload = function(){This bug causes the fictitious "onLoad" event to fire regardless of a successful load or failure.

On the map builder front, I have managed to add the textures into memory. Please copy the map builder from the server, as running it from the server will cause the textures to not load. This is because the textures are not uploaded to the server and they cannot be loaded from the images/ folder unless they already exist there.

When running the map builder locally, the code is able to check if the texture load was successful or not. Failure results in the program assuming the image file does not exist in the images/ folder and rejecting the texture.

I will next add the ability to click on a certain section of the map and assign it a value / draw onto the canvas.
Removing a texture already in use on the canvas will result in all of the squares assigned that texture being returned to zero.
The following feature will then be enabling multiple texture loads to save time.

As for the game itself, there seems to be some odd behaviour on my computer. If I don't move at all, the FPS stays at about 14/15. This isn't a problem though, as it isn't noticable in terms of rendering. When I start to move, the FPS increases to 20 until the dynamic strip width kicks in a few seconds later, causing it to sky-rocket to over 40.
As you suggested in an earlier post, it may be good to cap the FPS at about 30. If we set the interval to 30ms, the max FPS will be 33.333. It may be possible to check for FPS over 31 and narrow the strip width, but this may cause the FPS to go up and down, reducing the overall gameplay experience.
If the FPS is over 31 for more than a minute, it may be possible to narrow the strips without causing too much of an intrusion.

I like the idea of the head-bobbing code.

[ninogenio]

i really like the way the map builder is progressing mate top stuff!!

thanks very much for the bug fix i would never have noticed that.

As for the fps not scaling while your standing still at the start. that is very strange.. it almost sounds like the timers are not firing properly. i will try too replacate it.

i found a few misc bugs tonight while building the basis for my game. one where the sprite zbuffer gets messed up when you walk in an anti clockwise circle round the sprite which i fixed.

and another where you get a strange gfx glitch at random times i think i am close too sorting.

definitly we should clamp rendering too 30ms intervals that way we can be sure no matter what detail level the game is at. player movements and such all stay the same from system too system. i actually had already implement this in the above upload and fps was at 31.somthing - 33.something

i wouldn't worry about scaling detail the other way. because increments happen at 1 every 6 seconds chances are while you sit at 40fps if you decrease stripwidth by 1 you would drop below 30 so it would just yoyo back and forth and be visually distracting for the player. the good thing about sitting at 40fps is that even if you clamp too 33 you know that you have 7fps for game logic before you would lose any more detail

once i manage too iron all these little kinks out ill upload a fixed up version.

-edit here is a version with lots of bug fixes.

1. fixed the bottom of the sprites not scaling correctly.
2. i now loop the process sprite 20 times before the program runs too populate the sprite z buffer.
3. i have split the sprite zbuffer away from the processing loop too make it work correctly.
4. moved the sprite z calcs too before the if check in the processing loop stops weird sprite movement when they pop into view.
5. locked fps down too 30ms.
6. added the fix you spotted ck.

and lots of little fixes everywhere. i have checked from every angle possible and everything renders properly there is 0 glitching or strange gfx scaling anywhere i can see now.

i have tried everything and cannot replicate the strange problem you have with fps sticking until the player moves. i would like too understand why that happens though so will keep trying too see if i can replicate it. i am going too run this on different systems in the next few days.

[combatking0]

I don't think you need to investigate the low FPS at the start when I'm not moving. It seems to be a quirk of my laptop.

Perhaps we should set the threshold for low FPS to 28. On my laptop it starts to get a bit ugly when the strip width gets bigger than 8.

Other than that it's looking great.

I'll have an update on the map builder tonight.

[ninogenio]

excellent!

Perhaps we should set the threshold for low FPS to 28

are you getting hardware acceleration for the canvas drawing ck??.. i am trying everything i can think of too get more from this. i even switched everything over too web gl using the webgl-2d.js lib but this actually proved slower than our canvas drawing  . i suspect the lib is still in its infancy though and will get faster/less buggy as time goes on.

i am now looking at the pixi.js lib trying too gain enough understanding of how it works too reinvent our code too run with it. i suspect it will take rather a lot of work though. another thing that keeps coming up. is every source i stumble on is suggesting using DOM for our sprites. they say its a more compatible system and usually much faster than draw image. but again it looks like a real head scratcher too use that system. i will certainly come up with something.

if we were too use web gl we could essentially get rid of all the rectangles for shading and simply tint the image pixels as they got passed through so this can be made too run about double the speed.

-edit do you think it would be feasible too create mulitple copy's of each image at startup and apply different shades too them? then we could just index the images based on which one is closest too shade value. the shading would not be quite as smooth as it is now but we stand too gain a massive speed boost. almost double the speed on my system... ideally we could have 9 copy's 0.0 being completely light texture and 1.0 being black so we only need too compute the 9 points inbetween. then pseudo drawimage(imageobject[ind+shadeval]-1......

[combatking0]

I was thinking of dropping the FPS threshold to 28 because a slight drop below 30fps may trigger the widening of the strip widths, even if it is usually slightly above 30. Then again, dropping it if it dips below 30 should keep it above 30, which was the whole point of that development in the first place.

I don't think I have very good HW acceleration on this laptop. My desktops both at home and work run the program well above 30, so it's probably just a lack of raw processing power at this end.

We would encounter two issues with DOM sprites - the sprites would always draw in front of everything on the canvas and in the event of a sprite moving off the edge of the canvas, the sprite would still be visible and would not be hidden by crossing the edges of the canvas.

Creating 9 extra copies of each wall texture will eat up RAM, especially on games with lots of different wall textures. But it will reduce the processing load since there will be less reliance on alpha shading. On the other hand, the webGL option won't use much extra RAM and still grant a speed boost, so that may be worth examining first.

[combatking0]

I've made a few minor alterations:

* Capped the strip width at 4. Mega Man looks really strange when it goes any higher and the performance isn't too bad at 4, though left uncapped it went as high as 11 once.
* Eliminated as many divisions as possible. I read somewhere that multiplication is faster than division, so I've created inverse versions of some popular variables. This may have screwed up the FPS display slightly, sorry. I'll try to fix it.
* Eliminated all "new" calls from the main and associated functions. Again, I'm told creating a "new" version of an object is a little slower than telling it to be empty, so for example [] is better than new Array().
* Removed "var" calls from loops. I'm guessing that creating a new variable takes longer giving it a value, so I have moved the declarations to points before the loops.

All of this has added up to a minor boost in performance.
The latest live version is at http://fx.barcodebattler.co.uk/waveSphere/jsraycaster8.htm

I have also been working on the level editor:
http://fx.barcodebattler.co.uk/waveSphere/jsrMapBuilder.htm

The variables created by the level editor have been moved to one location near the top of the code in version 8 of the engine. They can now be copied and pasted in on top of the existing variables.
The only catch is with the sprite images, as the builder does not support them yet. Pasting the code from the builder over the raycaster variables will result in the loss of the sprite source declarations, so I'll need to put those in.

Future plans for the map builder now include:
* Multiple file selection for faster importing
* Texture order sorting
* Scrolling if the map is larger than the viewable area
* Support for sprites

This project has come on leaps and bounds in only a month!

[ninogenio]

excellent!! the engine feels really nice and solid now ck!

good work with the map builder, i am getting a small bug here. the grid curser is sitting half of the grid away from my mouse pointer too the right so when trying too pull it across too get too the left side of the grid i can only get half way ill have a little look at the source in the morning and see if i can pinpoint why it happens.

all the future plans for the editor sound really great!

well i have spent the whole night teaching my self glsl for the web... i am now fairly comfortable using it with js. i am pretty far along into a replacement drawimage function. what i am hoping for is that i can turn this into is a little wrapper. so i can quickly and easily drop our engine in and it will automatically turbo charge it. at least now i have access too the shaders i can shadow and render everything in just one pass with half the geometry .

the attached code lets us load an image and using my own draw image command blit it with shaders, anywhere on the canvas resizing in width and height as much or little as we like. i really should have done it in shaders from the start. but got carried away with the simplicity of the canvas.

ha i cant believe it has been a month already! we really have made a cool little project here. hopefully i can have the engine running really really fast and fully completed and my first game prototype completely built by next month.

[combatking0]

It will be interesting to see what kind of performance change the glsl provides.

As for the bug you're encountering, it could be that the canvas is being moved a short time after the page loads, but this is only an issue in FireFox.
I'll enable the position debug and we'll see if I can figure out what's going wrong.

edit - It feels like a month, but it's only been 2 and a half weeks.

[ninogenio]

well i have had a pretty rough time getting this up and running all inside webgl but i now am really close every thing works perfectly. i just have a few things too finish..

my draw image differs slightly from the canvas one so i need too figure out how too adapt my sprite rendering algo currently the sprites just render as white rects and i need too code a shader line algorithm so we can paint the floor and ceiling tiles again.

but thats all!.. everything else as you will see when you run it runs perfectly.. too my surprise i have taken too webgl really well. i just had too get used too working inside js with it. the hardest thing with webgl, is that, i so far have had too rewrite everything that we previously had done with the canvas. ie lines rects drawimage rgb stuff alpha etc..

on the plus side i spent about two hours working this webgl version into the android sdk and got the basic textured wall caster running on my tablet. it was very very easy too port.

as for the speed boost this has given....

well its much quicker. i now can hit 100fps at stripwidth=1 in chrome on both my integrated gpu and my gtx650 one. in firefox i get roughly 50fps with integrated and 60ish with gtx.
however when i set stripwidth too 2 its too fast too see whats going on like 200fps!

and this is just roughly done atm once i figuare out how too fix the sprites, and code the shaders too paint the floor and roof tiles back on. i can get even more speed from it.

even though i am not drawing the floor tiles this is still representable against the canvas version as i am having too draw the hud image by image frame by frame again atm. 

[combatking0]

That sounds great, but I've tried testing the latest version under IE9, Chrome and FF and all I can see is the sprite locations on the map.
Everything else is black.

The error messages in Chrome are as follows:

Code: [Select]

PERFORMANCE WARNING: Some textures are unrenderable. webglraycaster.htm:1
RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have  incompatible texture filtering or is not 'texture complete' webglraycaster.htm:1
Uncaught Error: SecurityError: DOM Exception 18 webglraycaster.htm:937
PERFORMANCE WARNING: Some textures are unrenderable. webglraycaster.htm:1
RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have  incompatible texture filtering or is not 'texture complete' The final two warnings are repeated indefinitely.

I'll try to update my version of Chrome.

edit - I've updated Chrome and it still didn't work.
Then I remembered Chrome has the awkward security so I've used the Chrome fix batch file to open the browser and it works! The only issue is that the FPS is 2 when I start and don't move, but it does rise to about 60 once I've moved the camera position.

I have thought of another optimisation - ray casting only needs to be done if the camera position is moved or rotated. It can be done once at the start of the program, and then repeated only if any keys are held down.

[ninogenio]

ahh i should have said sorry ck. yeah when loading textures with webgl you get cross domain security failures. so its not even loading the textures for you atm. basically too get textured webgl locally you either apply the same fix you posted earilier or run through brackets.. for some reason my ff runs this locally when it shouldn't but i wasnt complaining

[Jim]

I can explain some of that.  First of all, IE11 is the first IE to support webgl at all, so you need at least Windows 7 with an upgraded browser.
In that case I think it's still marked as experimental too, so to get your gl object the safest way to do that is

Code: [Select]

var opts = { antialias: false };
gl = canvas.getContext("webgl", opts) || canvas.getContext("experimental-webgl", opts);
The opts thing is needed for IE since otherwise it blurs everything.  Maybe you want that.

texture bound to texture unit 0 is not renderable

This error is caused by the image not being loaded before it's bound into webgl.  Best way I found around that is temporarily to bind in a 2x2 placeholder which will get replaced with the image once it loads.  This way you don't necessarily need to worry about counting how many images to load or waiting for them to complete.  Things will just render in checkerboards until the images are available.

Code: [Select]

function loadTexture(filename)
{
var rv = gl.createTexture();

gl.bindTexture(gl.TEXTURE_2D, rv);
gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, 2, 2, 0, gl.RGBA, gl.UNSIGNED_BYTE, new Uint8Array([255, 0, 0, 0, 255, 255, 255, 255, 255, 0, 0, 0, 255, 255, 255, 255]));
gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MAG_FILTER, gl.NEAREST);
gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, gl.NEAREST);

rv.image = new Image();
rv.image.crossOrigin = "anonymous";
rv.image.onload = function () { bindTexture(rv); }
rv.image.src = filename;

return rv;
}

function bindTexture(texture)
{
gl.bindTexture(gl.TEXTURE_2D, texture);
gl.pixelStorei(gl.UNPACK_FLIP_Y_WEBGL, true);//flip BMP upside down
gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, texture.image);

gl.bindTexture(gl.TEXTURE_2D, null);
}
The "crossorigin" thing is supposed to fix Chrome loading textures from disk.  Currently that doesn't work, but it's supposed to.  Host your textures locally on IISExpress or Cassini or something for dev work.
The other cause of the 'not renderable' error is non-power-of-2 textures.

Jim

[ninogenio]

thats brilliant!!! thank you jim k+

up till now i have been having too keep two sets of variables one for images and the other for gl textures, but with your code there i now just need one. that's much more along the lines of what i am used too!

i have implemented your tip for grabbing the gl object as well again i wouldn't have thought of doing that. thanks mate.

@ck i have added all jims tips into this now so if it doesn't load textures because of cross compatibility you will get red and white checkers all over the walls. i have also fixed the sprites now still getting about 90fps with stripwidth = 1 and 200 = 2 so really fast.

i now just need too get the floor rendering again. but i am having some issues. do you think there is anyway the floor could be stored as a mesh with indexes. sort of like a model mesh but i dont need the z info that can be set too 1.0.  that way i could just send it through too the shader and render it all in one go very very easily. i had a bash before but failed badly ..

i also tried too add the trick of grabbing and storing the hud from the backbuffer as a single texture back in using copysubimage and glreadpixels but all i am getting with those is a black texture. i fear too get this element working i might have too resort too framebuffers/render too texture which i hoped too stay away from for now.

-edit just read you managed too get the original webgl version too work. thats excellent! i will implement your suggestion about not doing raycast's while the player does not move. it should be quite a simple thing too implement.

also another good speed up for the canvas version would be too save the background gradient image into a texture the same as we do for the hud and just blit it with drawimage. at least this way our code does not have too do all the costly gradient calcs every frame.

[combatking0]

I've had a look at the line drawing algorithm for the lines and it looks like we're passing the coordinates into myrgbline() as myrgbline(xStart, yStart, xFinish, yFinish)

But the function is expecting
myrgbline(xStart, yStart, xLength, yLength)

I'll see if I can wrap my head around the code in the myrbgline function.

[ninogenio]

yeah i just did a quick hack inside rgbline when passing the model matrix too the shader i convert too width/height.

1.0*(width-xpos)
1.0*(height-ypos)

but really it would never work like this the most ideal way too do this is too send the floor a tile at a time and group the tiles four points, into two triangles i am not quite sure if the floor draw algo can be grouped into nearest vert groups of 4, if it can i can do filled floor tiles like chess board checkers etc.. very easily.

-edit about the issue where the fps sticks until you move. have you tryed settimeout instead of setinterval just too see if there is any change? i was messing around earlier and noticed the two commands give slightly different results. i guess its worth a little shot

[combatking0]

I've thought of a way to find the corners of the floor tiles.

I don't understand webGL very well, so I'll try it under the 2D canvas model as a test.

As for the low starting FPS, I'll give your suggestion a try. I'll also test different starting angles and positions.

[ninogenio]

that would be excellent thanks very much mate!

i have figured the floor and ceiling line code out 

i only played for 5 mins on my morning break. but i have got it going, i had too poke the x,y,lx,ly into a basic vertex buffer. at first it was really slow as i was then creating a vbo in gpu ram each *frame*. so i just loaded an initial buffer into vram at startup and set it too STREAM. then i stream the new line data each frame. my line function is at the very LEAST as quick as the canvas draw line so im happy. 

ill upload the complete webgl version when i get home. cheers.

oh and it would still be good if we can group the 4 points of the floor into indexed verts as we could then implement floor and ceiling textures 

-edit

attached the new version with floor and was able too get the hud trick re implemented. i had too write some render too texture stuff too get it too save all our tiles into a single texture.i have spent a half hour optimizing and cleaning the code i was doing some silly things before that was holding the speed back it now renders quite a bit faster.. i have only attached htm file as the image folder is in my last link.

im now getting 200fps in firefox and 250fps in chrome and this is with everything back in...not too shabby i think

this is about as fast as this will go there may be some small things that could be done but its not worth chasing the speed down imho..

[ninogenio]

pahhhhh that last upload only renders the floor and ceiling properly in chrome for me  ..

ff is not drawing the floor and ceiling but still works.

firefox for some reason is not allowing me too stream data into my vbo's but chrome is :confused:..
oh well only one bug left!

has anyone else experienced similar? or can shed some light on this. i am begining too feel like ff has got it in for me

[combatking0]

On Chrome on my laptop I'm seeing the floor and ceiling perfectly.

The framerate still starts low but quickly improves once the strip width gets to 3 if I stand still, or runs well above 60 if I start to move.

The results of my position / rotation tests are as follows:

Setting the starting rotation to 50 degrees or 150 eliminates the slowdown.
Setting the Y starting position to 200 eliminates the slowdown.
Setting the X start to 145 eliminates the slowdown.

I'll work a bit more on the map builder tonight and have an update. I'm close to getting multiple texture imports working properly.