Not Quite MineCraft

[Hated Moron]

The world is one object and the latter approach you suggest is the one I have worked with, you can insert and delete blocks from the main object and it is quick enough

In which case I wonder why you chose what is, superficially, an enormously more complicated approach than just using the standard BBC BASIC 3D libraries. Perhaps you wanted to set yourself a very difficult challenge, which is admirable, but it's a shame that cross-platform compatibility has been sacrificed in the process. Personally I'm lazy and always go for the easiest option!

[Ric]

I did try a couple of other methods of rendering, but unless you render all vertices in one buffer, once the number of objects gets beyond a few thousand the whole thing slows down to an unacceptable speed. As mentioned before, 5 FPS or worse. Hence what looks like a massively over complicated way of doing it, but the results speak for themselves. Even with the use of staging textures on every other pass, it still runs at nearly 70 FPS.

Does the video link work?

Kind regards Ric

[Ric]

Mike,
Have you had the latest update working, even if you have to adjust the SCREEN_WIDTH%. In the new version it is S_W% and S_H%.

Kind regards Ric

[Ric]

My apologies, this is the YouTube link

https://youtu.be/8W3kZvjMtLQ

I did say I didn't know what I was doing

Happy viewing

Kind regards Ric

[Hated Moron]

I did try a couple of other methods of rendering, but unless you render all vertices in one buffer, once the number of objects gets beyond a few thousand the whole thing slows down to an unacceptable speed.

Absolutely. But rendering tens of thousands of vertices as one object is, of course, what 3D rendering (including the BBC BASIC libraries) is all about.

The complication is how to edit that object 'on the fly', in order to replace the block which previously had 'focus' and remove the block which now has focus. But I don't see any reason why that should be more difficult when rendering it with the standard library.

Admittedly I've not looked into how to do that in Direct3D at all, whether D3D9 or D3D11, but it looks straightforward enough in OpenGL. I wouldn't be trying to do it every frame, it might not be fast enough for that, but only when the 'focus' block changes.

Hence what looks like a massively over complicated way of doing it

No, you misunderstand, What seems much more complicated, to me, is using D3D11 rather than the BBC BASIC library. Using a single object to represent the world (which is what I suggested, before you said it's what you already do) isn't particularly complicated, so long as you can figure out how to edit it.

Anyway, we are where we are. I agree that there's no practical way your program could be ported to BBCSDL.

[Ric]

Exactly. The edit is quite easy, if you order the vertices as triangles with X + Y shifted a bit + z shifted a bit more all the triangles(faces) align numerically and then a simple search to find the place in the list.

Have you managed to run the code yet?

Kind regards Ric

[Hated Moron]

Have you managed to run the code yet?

I haven't tried it since getting the 'Bad subscript' errors.

One comment on the general appearance: the lighting is very 'flat'. Something you get for free from the BBC BASIC libraries (sorry to keep banging on about them!) is up to five lights, which can be point source, directional or spotlight, plus specular reflections. I don't know how easy it is to add lights in D3D11, but if you can the subjective appearance would probably be greatly improved.

Getting the lighting to work in the web (browser) edition of BBCSDL was fun, because I had to write shader code from scratch to emulate what the OpenGL and OpenGLES Fixed Function Pipelines provide, but WebGL doesn't. It gives similar, but not identical, results; my spotlight is far better than theirs because it uses per-pixel calculations (in the fragment shader) rather than per-vertex calculations as the Fixed Function Pipelines do.

[Ric]

The lighting is just a simple directional light, if needed I will add more later, they are mainly generated in the shaders too, so pixel accuracy is achieved. I posted some d3d11 tutorials for the different types of light, when the game has objects like torches, I will implement more light then.

I don't know about d3d9 but in d3d11 when you want more lights with little or no speed implications, you use a render to texture that accepts as output the normals from the scene, then one pass as a 2d textue and multiply by all the lights in the scene ( this then only performs light calcs on the pixels that can be seen) which can be added all as one using a matrix, so many, many lights can be used, and then add to the original scene. Sounds complicated, but once you get to grips with d3d11, most of this type of function can be added with simple loops.

Kind regards Ric

[Hated Moron]

Sounds complicated, but once you get to grips with d3d11, most of this type of function can be added with simple loops.

Lighting is much easier when using the BBC BASIC libraries because it's built in as a standard feature. You need only look at any of the supplied 3D examples which use lighting (most do) to see how straightforward it is. The most complicated lighting arrangement is used in bbcowl.bbc because it was designed to match the BBC's original OWL rendering, here is the relevant code (BBCSDL version):

Code: Select all

      DIM light{(4) Type%, Diffuse{r%,g%,b%,a%}, Specular{r%,g%,b%,a%}, \
      \ Ambient{r%,g%,b%,a%}, Position{x%,y%,z%}, Direction{x%,y%,z%}, \
      \ Range%, Falloff%, Attenuation0%, Attenuation1%, Attenuation2%, \
      \ Theta%, Phi%}

      light{(0)}.Type% = 1 : REM point source
      light{(0)}.Diffuse.r% = FN_f4(1)
      light{(0)}.Diffuse.g% = FN_f4(1)
      light{(0)}.Diffuse.b% = FN_f4(1)
      light{(0)}.Position.z% = FN_f4(-1000)

      light{(1)}.Type% = 1 : REM point source
      light{(1)}.Specular.r% = FN_f4(.6)
      light{(1)}.Specular.g% = FN_f4(.6)
      light{(1)}.Specular.b% = FN_f4(.6)
      light{(1)}.Position.x% = FN_f4(-10)
      light{(1)}.Position.y% = FN_f4(100)
      light{(1)}.Position.z% = FN_f4(-100)
      light{(1)}.Range% = FN_f4(200)
      light{(1)}.Attenuation0% = FN_f4(1.0)

      light{(2)}.Type% = 1 : REM point source
      light{(2)}.Diffuse.r% = FN_f4(2)
      light{(2)}.Diffuse.g% = FN_f4(2)
      light{(2)}.Diffuse.b% = FN_f4(2)
      light{(2)}.Position.x% = FN_f4(-4)
      light{(2)}.Position.y% = FN_f4(4)
      light{(2)}.Position.z% = FN_f4(5)
      light{(2)}.Range% = FN_f4(200)
      light{(2)}.Attenuation0% = FN_f4(1)

      light{(3)}.Type% = 1 : REM point source
      light{(3)}.Diffuse.r% = FN_f4(2)
      light{(3)}.Diffuse.g% = FN_f4(2)
      light{(3)}.Diffuse.b% = FN_f4(2)
      light{(3)}.Position.x% = FN_f4(4)
      light{(3)}.Position.y% = FN_f4(4)
      light{(3)}.Position.z% = FN_f4(5)
      light{(3)}.Range% = FN_f4(200)
      light{(3)}.Attenuation0% = FN_f4(1)

      light{(4)}.Type% = 1 : REM point source
      light{(4)}.Diffuse.r% = FN_f4(2)
      light{(4)}.Diffuse.g% = FN_f4(2)
      light{(4)}.Diffuse.b% = FN_f4(2)
      light{(4)}.Position.x% = FN_f4(0)
      light{(4)}.Position.y% = FN_f4(-5)
      light{(4)}.Position.z% = FN_f4(5)
      light{(4)}.Range% = FN_f4(200)
      light{(4)}.Attenuation0% = FN_f4(1)

As far as the number of lights is concerned, the limit of five is arbitrary (and was probably based on this program, because I felt it was unlikely that more would ever be needed, and they haven't been to date). But it would be easy enough to increase the number by creating a custom version of the library, for example in webgllib it would just be a case of editing these two lines:

Code: Select all

      DIM Light@webgl{(4) position%,direction%,ambient%,diffuse%,specular%,angle%}
...
      DATA "#define MAXLIGHTS 5"

[Ric]

I have a query about crashing BB4W.

I can replicate the circumstances in which my program crashes BB4W, but i cant trap it. Is there a way to find out why? I think it is to do with moving bits of memory about but cant be sure, can anyone help?

kind regards Ric