Not Quite MineCraft

[Ric]

Sorry for the slow reply Mike, I don't know why the screen sizes are returned with those results, I have used SYS "getSystemMetrics" to return the values, which on my machine are correct. Which version of windows are you using?

Kind regards Ric

[Hated Moron]

I have been through my code and it doesn't look like it would be an easy conversion to the current d3d library routines. Simply from the library routines are d3d9 and my code is d3d11

What aspects of your game are D3D11-specific and won't work in D3D9? I'm pretty sure there are no performance benefits, an app will run just as fast in D3D9 as in D3D11 on the same hardware.

being able to directly access many of the buffers and screen textures (staging).

There's no particular problem with accessing, and dynamically changing if necessary, textures when using the BBC BASIC 3D libraries. There are existing games which do that (e.g. Treasure Tower which uses the 3D rendering system to wrap what is basically a 2D game around a cylinder).

I've not come across the term "staging" in the context of 3D graphics, what do you mean by that?

An easier option may be to convert my library routines to opengl. Something I would have to give great thought to.

As I said before, doing that would involve maintaining compatibility with (desktop) OpenGL, (mobile) OpenGL ES and (browser) WebGL, which could be quite an overhead.

The approach which I would suggest is to find out precisely what (if anything) you can't achieve using the existing BBC BASIC 3D libraries and investigate how those shortcomings can most easily be addressed without sacrificing cross-platform compatibility.

Also bear in mind that shaderlib.bbc (supplied with both BBC BASIC for Windows and BBC BASIC for SDL 2.0) provides direct access to shader (GPU) programming, which would allow you to do more than even D3D11 can, in a fully cross-platform way.

[Ric]

Staging is a term that relates to the creation of a render to texture that can be accessed by the CPU not just the GPU to allow feed back from the outputted texture. I can't see a way of changing the buffer contents without initialising them with the library, for example MAPPING.

Kind regards Ric

[Ric]

Here is the latest version

https://1drv.ms/u/s!AqibHqCkE1VQge1FnVX ... g?e=YOkldq

To play/explore

z - rotate anticlockwise
x - rotate clockwise
c - straif left
v - straif right
; - run forward
. - run backward
Enter - jump

r,t,y,u,i - initiate the menu
these letters can also be used to toggle between the tabs on the menu, alternatively you can click on the tabs (some parts of the menu are unpopulated)
To close the menu either click on the open tab or press the associated key (r,t,y,u,i)
The menu can be moved with the mouse
You can choose for the menu to display either grey objects or the textured by using the toggle at the bottom right corner

l - shrink menu and side bars
p - increase menu and side bars

left mouse - place block
right mouse - delete block

up arrow - }
down arrow - } rotate the highlighted block
left arrow - }
right arrow - }

To select an item from the menu, click and drag it to the object side bar on the left
To select a texture from the menu, click and drag it to the texture side bar on the right

To select the object and texture to be placed by left mouse click, highlight them on the side bars and left click

The file to load is "AA File Pointer XVIII"


Dont run off the world, it causes a bad DIM error


Have fun

Kind regards Ric

[Hated Moron]

Staging is a term that relates to the creation of a render to texture that can be accessed by the CPU not just the GPU

That sounds like something Direct3D-specific (and indeed a Google search confirms it). There is no direct equivalent in OpenGL, you would need to use glReadPixels() (which can be quite slow) or a Pixel Buffer Object (PBO) but even then I don't think performance is great because the data flow is in the 'wrong direction'.

Unless speed is unimportant, I would recommend that no BBC BASIC app relies on reading a GPU texture or buffer, they should be treated as 'write only'. That's why my gfxlib library for BBCSDL supports collision-detection using surfaces, not textures, because surfaces are resident in main (CPU) memory and can be accessed very quickly.

To get a feel for what features your game needs I tried running it, but it doesn't seem to behave properly on this laptop. I get the screen shown below, with flickering numbers (that I wasn't able to capture) in the black panel on the left. I'll try today's version to see if it runs any better.

minecraft.jpg

[Hated Moron]

I'll try today's version to see if it runs any better.

I'm afraid It produced a Bad Subscript error almost immediately. Sorry.

Would you be able to upload a video (e.g. to YouTube) of you playing it, so I can see what should happen?

Thinking about how one might reproduce something similar using the existing 3D libraries the most obvious approach would be for each 'block' to be a different object. However given the number of those blocks, I'm pretty sure that the performance wouldn't be acceptable (the library iterates through the objects using a FOR...NEXT loop in BASIC).

So a better way would probably be for the entire 'world' (multiple blocks) to be just one object, which would render very quickly, with only the block currently being edited (added, deleted, moved, re-orientated) being a separate object. However that would mean that when changing 'focus' from one block to another the main 'world object' would have to be rebuilt to incorporate the block that was previously being edited and omit the new one.

I think that could be done quickly enough to be acceptable, but experimentation would be required to demonstrate that (and it couldn't be done in a way which was compatible with both BB4W and BBCSDL). What's the maximum number of blocks in your 3D 'world'? Do you use pruning to avoid rendering blocks that aren't visible?

[Ric]

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, running at 60+ FPS on my i5. The collision detection is done using an array of the blocks in the CPU and is almost instant.

The whole world is calculated/built before hand only using faces which are visible so any blocks which are "buried" are not used, then each time a block is placed or deleted it calculates on the fly which faces to remove from the world and which to add.

The program works on both machines I have but I will try to upload a video to YouTube, but I have no idea how to do it so don't hold your breath.

The direct access to the render target is used to detect which block you are hovering over in the world. It has speed implications, but nothing to write home about for what I am doing. Initially I tried to render all the blocks as different objects and use picking for detection but it ran at 5 FPS!

There are a maximum of 256*256*256*3 blocks and I am looking at that becoming 32768 times as many.

[Ric]

Does anything appear on the screen or does it error during the initialisation stage?

[Ric]

Think this is the link to the video ive posted

https://youtu.be/iDLjz0yUZCk

Cab someone let me know if it works?

Kind regards Ric

[hellomike]

During initialization. In this line

Code: Select all

VDU 23,22,SCREEN_WIDTH%;SCREEN_HEIGHT%;12,16,16,0

And with List Variables I found the mentioned content of SCREEN_WIDTH%, SCREEN_HEIGHT%.

Mike