just starting out in java/html

[ninogenio]

very very cool ck!!

just had a two sec mess around if you pass the PAngl and RayAngle var through to moveRayindirection.

and then do this in the floor casting part

syd = truncate(VeiwDist / (Math.sqrt(distX*distX + distY*distY)*Math.cos(PlayAng-RAng)));

that fixes the fish eye effect. it looks really cool but the lines still break up i am not too sure why that is atm ill look deeper.

thanks for all this ck it looks far far better for all your ideas/additions!

[combatking0]

That's certainly improved the geometry!

One possible cause for the lines breaking up is the ray block crossing detection not being triggered. This is only a temporary attempt at floor casting and I'll be replacing it with a texture mapping algorithm just as soon as I've merged our codes together.

[ninogenio]

excellent! i never thought floor casting too be possible so massive props for this. i never thought js was powerful enough too handle stuff like this.. color me impressed

i am in the middle of the sprites atm, so with your floor casting and the sprites this is going too be an awesome little framework for games.

[combatking0]

After much messing about with the code, I admit defeat - I can't do floor casting without either re-inventing webGL or reducing the FPS to less than 10.

[ninogenio]

thats a bit of a shame. but tbh im more than happy with the checkered grid it makes a huge difference too the look of the whole thing. if we can just get the lines too fully draw it is really quite impressive!

i am having some trouble with z ordering the sprites. i can render them properly but its difficult too decide which parts too draw before and after the wall basically as we sweep the rays round casting everything we have too check too see if the sprite is some where inside the fov then check the sprites dist value against each ray and decide if we want the sprites scanline too be drawn before of after the wall scanlines. i am getting closer too success though

[combatking0]

I'll add a function to make the grid - we can put different colours on the ceiling and floor to add a tiny bit more detail too.

edit - I have uploaded the latest version with your newest optimisations and a few changes for the floor line rendering here: http://fx.barcodebattler.co.uk/waveSphere/jsraycaster5.htm

I'll keep trying to improve the grid drawing algorithm. I have an idea to make it more complete and less computationally expensive.

[combatking0]

I'm now confident that I can come up with a solution to the gaps in the floor / ceiling lines. Hopefully I'll have it finished for tomorrow night.

edit - I have improved the existing algorithm in that there are fewer gaps, but the draw order makes it look a bit strange when the player is moving.
I'll try to fix this tonight.

[ninogenio]

excellent thanks ck that new uploaded one looks great! k+

i was up half the night last night trying too bend draw image too my will i almost have the sprite working but for some reason when you get close too it its like it buffer overflows. i am also not sure how too make masking work for the sprite too make only the sprite appear and not its background.

ive attached this just too show atm its still very very roughly done and not working properly. im finding drawimage too be very difficult too work with im used too just going in and grabbing any part of an image and doing as i please with it

- edit pahh just noticed the sprite is badly messed up in firefox i have been developing in chrome and it wasn't quite as bad .

do you know ck if its possible too go too the image byte level it would make my life a bit easyer if i could manipulate the image down at the lowest pixel level.

[combatking0]

I think the main problem with the transparency is that your image does not have transparent sections. I will test this. The Z-ordering problem also looks interesting.

I'm thinking of adding an image buffer which would use Z-ordering in some manner and then draw the objects from the buffer. I'll explain it better when I've done it.

[ninogenio]

i managed too fix up the sprites a lot tonight i edited the above link with the update.. all the clipping is working you will see as you walk round the sprite never draws on parts where its not ment too. the only tiny issue now is that the sprite isn't getting properly stretched on its quad. but hopefully this is fixable.

the way i z order the sprite is i get an absolute z value when i do its position processing then for each scanline we do in our raycaster i get a z value for that strip and if the sprites zval is more than the walls draw a strip of the sprite the same width as our ray strip and if not i don't. its the drawing stretched strips of the sprite with drawimage that's had me pulling my hair out.. i wish drawimage was a little more conventional and let us just grab any segment of the image we want and do what we want with it as this would have been done in five mins

ohh i noticed for some reason chrome and firefox are both processing drawimage differently you will notice in ff the quad stays the proper width but in chrome it shrinks.

[combatking0]

My FF is doing something odd - It's only drawing the left-most strip of the walls and sprites.

I'll delve into the code and figure it out.

[ninogenio]

ahh bummer it sound like a buffer overflow. i actually don't think we are going too be able too properly do the sprite with draw image. i was thinking is it possible too store our image in a div tag and yous styles too clip and grab random parts of it. i think you can resize as well im just not 100% sure if overlaying a div image on a centred canvas would work properly.

-Edit i just noticed you have managed too fix the floor and ceiling casting the code is really well integrated and runs really fast!, Well done mate. that looks really really nice!!

[combatking0]

Thanks. I had to make a few of the local function variables into global variables, but it's working.

I've fixed a line to make the sprite the correct width, given that it is always cut into 29 strips, where it says

Code: [Select]

sprinc += Sprite.RightI have changed it to

Code: [Select]

sprinc += Sprite.GfxHndl.width / (14.5 * Sprite.Right);
I'm not 100% sure how the sprite rendering works, but I've noticed that it always starts from the left of the sprite, even when the left-most strips should be off screen. After looking at the sprite though, I've noticed that it doesn't need to be skewed like the walls do, so it should be possible to draw it in one command instead of in strips, but I need some sleep for work in the morning. We're making progress though, and this is definitely coming together.

On a sort-of related note, I was watching episode 1 of "8-bit Pwny Club" and their number 1 toilet in video games (the subject of the video) was from Duke Nukem. The rendering engine looks much like the one we're developing, only with textured floors and ceilings.[youtube]capDUGdxo2U[/youtube]

[ninogenio]

Code: [Select]

sprinc += Sprite.GfxHndl.width / (14.5 * Sprite.Right);


k+++++++++++++++++ ck you just made my night with that, i spent hours staring at this and just could not get it correct. now im looking at it, i am kicking myself for spending so much time on it.

I'm not 100% sure how the sprite rendering works, but I've noticed that it always starts from the left of the sprite, even when the left-most strips should be off screen. After looking at the sprite though, I've noticed that it doesn't need to be skewed like the walls do, so it should be possible to draw it in one command instead of in strips, but I need some sleep for work in the morning. We're making progress though, and this is definitely coming together.

yeah i tried for this at first but quickly realised it was a bit more involved. when the sprite is half obscured by the edge of a wall if drawing it in a complete form its very very hard too clip the part of the sprite away that should sit behind the wall. the only way of achiving this is too unfortunately draw the sprite in the raycasting sweep. checking the sprites z values against each rays sqr(x*x+y*y) and if the sprite strip is further than the ray hit point you just don't draw it this gives the nice illusion that the sprite is moving behind the wall when infact its actually just disappearing. now that you fixed that part for me i can add some cull checks and clipping against sceen edges.

On a sort-of related note, I was watching episode 1 of "8-bit Pwny Club" and their number 1 toilet in video games (the subject of the video) was from Duke Nukem. The rendering engine looks much like the one we're developing, only with textured floors and ceilings

yep i would say for just two guys developing in an interpreted script language we have done a some really awesome stuff here so far..

next up ill clean all the sprite code up. make it a lot more readable. then ill integrate all your code into mine and make it so we can have as many sprites as we need.

[ninogenio]

fixed this up lots so far today, i got it too render multiple sprites as well as some other things.

i decided too go a different but quicker way i store all the ray z values in a buffer then draw the sprites in there own function. the multiple sprite system turned out quite clever i think.. at init time you push all your sprites onto a stack and the little engine does everything else for you.

i also got sprite too scene z clipping working properly. And i managed too get spriteZ ordering working too. i store each sprite index in a list and based on there z value move the indexes around too make sure the draw in the correct order. so if you stand in a position where one sprite falls behind another, the one closest will always draw first.

still left too do is clip the sprites against the left side of the screen... my poor brain is sore from fixing all that atm so i will come back too it. and i need too figure out how image masking works. then i can animate the sprites.

ohh and i added code too shade the wall textures, i commented it out because i wasn't sure i liked it. if you un-comment the code you will see the effect.

-edit sprites are pretty much done now they have transparency the clipping is 100% fixed and they are all animating. yay!

[combatking0]

Brilliant! This is definitely coming together.

I'll have a look at the wall shading tonight and see how well it works.

edit - The wall shading looks great. We would need to change the floor and ceiling so that they use a gradient fill instead of a solid colour for added effect, but that's not difficult.

I'll leave the sprite functions in your capable hands and see how it looks when you're happy with it.

[ninogenio]

cheers mate,

well after doing a half nighter the sprites are pretty much finished! they have transparency they clip 100% everywhere and they are animating through there keyframes.

if you look closely you will see the animation is happening at a different offset on each sprite this was just too show they are all being processed completely separate.

phew i am glad thats taken care of

if its ok i will leave the floor gradients up too you. i think from me next it will just be speed optimizations and organizing everything better. then we can go make our own games with this.

i have edit my last post with the new animated fully working sprite version. 

[combatking0]

I've just uploaded a version with floor / ceiling gradients here:
http://fx.barcodebattler.co.uk/waveSphere/jsraycaster6.htm

I'll take a look at your improvements over my lunch break - I look forward to seeing how far they've come.

[ninogenio]

excellent! the gradiants make a big difference,

i have a few ideas for hopefully big speed ups but ill wait too hear if you have any suggestions with the sprite's first.

also i am going too clean up the code and group all the variables into objects. then at any time ie a key press we can do level.shading = 1; or level.detail += 1;

i also need too add static sprites and a little code too allow sprites too be removed off the stack and when ever needed new ones added this can be done with a simple function call.

i want too keep it as basic as possible because when we head in different directions too make different types of games the engine will change quite a bit depending on the type of game we make and that particular games requirements.

[combatking0]

I've noticed the sprites tend to use the bottom-left corner as their "origin" (I'm not sure what the correct term is) point, which causes the sprite to turn about that particular corner when it is approached from various angles. If the sprites were drawn to the left of this point they would then turn about their bottom-centre instead. Other than that I have no suggestions as it looks great.

Putting all of the variables into objects is a good idea as it makes the code more portable.

When managing the sprite stack, you can use the "splice" function on the array which holds the sprite objects to remove particular array entries, but you probably knew about that already.