J2ME Ray Caster

[Slick]

Hi everyone, newbie to the forums here. I've been reading around for a while now it seems like a nice community

I thought I'd post a 3D engine I have just started working on for J2ME phones. It's a ray caster with textured walls, floors and ceilings. Fairly simple at the moment, I'm currently working on a map system and sprites. I had been wanting to make something like this for a while but I was under the impression this would be impossible in real-time and I believe a lot still think so.

It was actually Bad Sector's engine that made me decide to give it a shot after seeing it could be done. If you read this Bad Sector, I was the guy who sent you the email regarding your engine, I was wanting to see what the performance was like before making an attempt



Cheers

[Rizimar]

Looks pretty good so far

[Bad Sector]

Hey nice shots . How do you render the ceiling and floors? Do you support different ceiling/floor texture per cell or its the same everywhere? In Beg3D i had no texturing in floor/ceiling because i wanted it to run in older phones (i had it running in one of the first Series 40 models ever made! Although the screen had a lot of lag so turning the camera was blurry ).

In what phones does this run?

For maps you might want to check out my Mapas tool. It is what i used for RayFaster 1.

Sprites are easy to do, just bring them to camera space (just rotate them to be in view and scale them according to their distance) and to clip them use a horizontal 1D depth buffer which you fill with the distances from the wall slices when rendering the walls. You might want to use a "maximum distance" value (i used one in Beg3D) to avoid even considering sprites which are farthest than the most distant wall slice. Another optimization you might want to do is split the map cells in clusters like:

XXXXYYYYZZZZ
XXXXYYYYZZZZ
AAAABBBBCCCC
AAAABBBBCCCC
OOOOVVVVPPPP
OOOOVVVVPPPP

(O, X, Z, etc are cells)

Put a list with the sprites in each cluster and when you render a cell/wall to that cluster, mark it as visible (basically add it to another list if it is not marked yet as visible). Then when all walls are drawn, follow the list of clusters marked as visible and render the sprites in them while marking them back as invisible (for the next frame). This way you can ignore most of the sprites in the map .

Update us with your developments

[Slick]

Hey nice shots . How do you render the ceiling and floors? Do you support different ceiling/floor texture per cell or its the same everywhere? In Beg3D i had no texturing in floor/ceiling because i wanted it to run in older phones (i had it running in one of the first Series 40 models ever made! Although the screen had a lot of lag so turning the camera was blurry ).

In what phones does this run?

For maps you might want to check out my Mapas tool. It is what i used for RayFaster 1.

Sprites are easy to do, just bring them to camera space (just rotate them to be in view and scale them according to their distance) and to clip them use a horizontal 1D depth buffer which you fill with the distances from the wall slices when rendering the walls. You might want to use a "maximum distance" value (i used one in Beg3D) to avoid even considering sprites which are farthest than the most distant wall slice. Another optimization you might want to do is split the map cells in clusters like:

XXXXYYYYZZZZ
XXXXYYYYZZZZ
AAAABBBBCCCC
AAAABBBBCCCC
OOOOVVVVPPPP
OOOOVVVVPPPP

(O, X, Z, etc are cells)

Put a list with the sprites in each cluster and when you render a cell/wall to that cluster, mark it as visible (basically add it to another list if it is not marked yet as visible). Then when all walls are drawn, follow the list of clusters marked as visible and render the sprites in them while marking them back as invisible (for the next frame). This way you can ignore most of the sprites in the map .

Update us with your developments

Thanks guys,

The floors are rendered in vertical strips from the bottom of the wall slice, getting each pixel's distance with the formula dist= h / (2.0 * y - h) from this tutorial. Then gets the exact floor coordinates using playerx + cos(ray) * dist etc, so implementing different textures for cells would just be a matter of seeing if the floor coordinate is in a certain area.

I've only tested this on my Sony Ericsson z750 and a ZTE F850, the ZTE is quite an older phone and surprisingly it ran at a playable rate. Blazes along on my SE. I'll have to take a look at your tool, since I'm after a map editor right now

I've wrote some 3D engines in the past (polygonal) that used the method you said for sprites, so that's good to know it will fit in nicely! Splitting the map into cells or sectors sounds likes a good idea too, will keep that in mind, thanks

Currently I'm rewriting most of it, I started mixing coordinate systems and got everything and myself confused Should have it all up and running tomorrow.

[Bad Sector]

Well make sure you don't do my mistake: i tried to fix some things and broke the engine so much i lost my will to fix it and moved on (also the sucky state of J2ME in general didn't helped much) :-p

[Slick]

Been quite a busy start at school this semester which means I have only just found some time to work on the engine. But I've come across a problem, on the corners of walls at certain positions I keep getting holes..



I have tried just about everything but I can't for the life of me work out why this is happening If you look closer it seems as if the wall behind is being drawn instead, as if the the rays are somehow "peeking" through the corners.

I noticed Bad Sector, in an early screen shot of your old engine here you had the same problem. Hopefully you or someone can shed some light on the situation

Thanks

[Bad Sector]

This is from fixed point imprecision, i never fixed the problem, i just increased the fractional bits to make it happen less .

But there is a way to fix it and also improve the rendering quality aswell: instead of drawing walls directly to the screen, record the spans in some buffer. Then scan the buffer and find leftmost and rightmost groups of spans with the same texture and small difference in depth. If there is a span which uses another texture and/or has a greater depth (which basically means the span is much shorter) and the span left of it was big and the span right of it was also big, then ignore this span and replace it with one having the same texture as the previous and size the average of the left and right of it. Once you find all groups, draw textured quads with them.

Here is an image showing what i said above:

[Slick]

Well after putting the project aside for a while again to pursue other things while I wasn't procrastinating I got back into it the other day and well, its not far from completion!



The object rendering is actually quite unique in a sense that sprites are "streamed" into view, rather than being split into sectors etc and sorted every frame. Instead, objects are partially sorted during each frame and over time an accurate depth sorted list is formed.

Next on the list is collision detection and map loading as currently the map is hard coded in the source. I also plan to write a system to handle animated sprites and actors. This should be fairly straightforward as every object is currently declared with position and texture coordinates. All I should need to do is have those change dynamically.

Performance wise, the engine is capable of running at 60-100fps on my Sony Ericsson, although thats only due to the fact I have a frame skipping setup going on. With different parts of the rendering split into separate frames. So it actually feels like 15-30fps, but its nice to know I have all those other frames left for game code!

But TBH the engine does require a pretty meaty phone to run at a nice rate, so I'm hoping by the time I make something out of this your average phone will handle it ok.