Not Quite MineCraft

[Ric]

Dear All,

I have been working on a game similar to minecraft. You can place blocks(left mouse button), delete blocks(right mouse button) and rotate blocks(arrow keys). Some of the blocks interact with others, eg corner slopes will automatically be placed when a slope(block2) is used between two slopes in different planes.

Other keys
Z,X - rotate world about Y axis
C,V - straife left and right
H,B - zoom in and out
J,N - straife up and down
K,M - rotate world about X axis

The numbers in the top right are the block to be placed and the texture to be used.
The first 3 columns are the blocks to be selected(click on them)
The forth column is the texture to be selected(click on them)

There are almost no checks so it is reasonably easy to break the code but these will be introduced in the next update.
You can walk through blocks for now!

My problem is that after four runs of the program it crashes BB4W, this must be something to do with the cleanup routine but i can not see the wood for the trees, if someone could have a look at this and give me a BIG clue as to the problem i would be extremely grateful.


The code can be found here

https://1drv.ms/u/s!AqibHqCkE1VQge1CHey ... A?e=ZGayyW

Kind Regards Ric

[Ric]

sorry, forgot to say the file to run is "AA Interactive XXXXI add delete rotate"

[Pete]

I have several computers only one of which has the full version of BBC Basic for Windows, currently on a trial version computer. I look forward to trying this when I'm back from a weekend away on Monday.

[Ric]

I have now added block collision, of sorts. It is a very simple detection and is not perfect, for example if you approach a row of blocks at a very steep angle they may disappear and leave the view to blocks behind. But you still can't walk through them. The problem of crashing after 4 runs of the program still exists and I would greatly appreciate some help here ( please Richard ). Otherwise the new version can be loaded at

https://1drv.ms/u/s!AqibHqCkE1VQge1EODQ ... g?e=mzzdTW

Kind Regards Ric

[Hated Moron]

I have been working on a game similar to minecraft.

Would you consider porting this to BBC BASIC for SDL 2.0, to make it available to MacOS and Linux users, and perhaps even enable an online (web) version? If there aren't too many Windows-specific features it hopefully wouldn't be too difficult.

Since SDL was developed as a cross-platform games framework (albeit that it has evolved into more of an OS abstraction layer) BBC BASIC for SDL 2.0 is particularly well suited to games, and things which you might have to do at quite a low level (e.g. assembly language) in BBC BASIC for Windows can often be done in pure BASIC in BBCSDL.

[Ric]

I have no issue porting the program, just not yet. I would be concerned with converting the direct3d to opengl as I know nothing about the latter and there are a lot of sys calls, mainly to shift memory, which I assume have a BBCSDL equivalent.

The assembly is mainly to perform float4 maths, if BBCSDL can handle them then there is no need for the assembly. Here's hoping.

I still have a problem with the code crashing on a regular set of "runs", it is directly linked to the length of the main vertices buffer. Concluding that the buffers are not closing properly. Please could you look at the code that creates the buffers and the clean up routine and hopefully point out the error.

The idea has been developed further since I last posted. I will put an update on here when I get chance, probably early next week.

Kind regards Ric

[Ric]

Sorry Richard I forgot to say,
Buffers are created with FNcreateBuffer() which is in library file D3D11 Buffers and the clean up routines are in the library file D3D11 Clean Up III.

Thanks Ric

[hellomike]

Seems awesome, however on my system, your program determines the SCREEN_HEIGHT% and SCREEN_WIDTH% to be 1324 and 2530 and so I keep getting "Bad MODE" error.

Regards,

Mike

[Hated Moron]

I would be concerned with converting the direct3d to opengl

Assuming your usage of Direct3D is entirely or mainly via the D3DLIB library, porting should be straightforward, because an almost 100%-compatible library (ogllib) is supplied with BBCSDL.

The following example programs run equally well in BB4W (using Direct3D) and BBCSDL (using OpenGL): cradle.bbc, entertainer.bbc, figleaf.bbc, pinball.bbc, pyramid.bbc, Rubik.bbc and spotlight.bbc.

Typically the only version-specific code is similar to this:

Code: Select all

      IF INKEY$(-256)="W" INSTALL @lib$+"d3dliba" ELSE INSTALL @lib$+"ogllib"
...
      IF INKEY$(-256)="W" device% = FN_initd3d(@hwnd%, 1, 0) ELSE device% = FN_initgl(@hwnd%, 1, 0)

If you make any direct calls to Direct3D, bypassing the library, it may be more difficult, depending on what they are. But in that case I'd be interested to know why, because there are no major limitations in what the D3DLIB library can achieve that I've been made aware of.

If and when you do port it, don't make direct calls to OpenGL (at least not without extensive testing) because that would be likely to break cross-platform compatibility. The reason is that desktop platforms (WIndows, MacOS, Linux) run 'full' OpenGL, mobile platforms (Android and iOS) run OpenGLES and the in-browser (web) version runs WebGL. Although similar they are not fully compatible.

there are a lot of sys calls, mainly to shift memory, which I assume have a BBCSDL equivalent.

Yes, there's no problem calling SYS "SDL_memcpy" or SYS "SDL_memset" if you need to,

The assembly is mainly to perform float4 maths, if BBCSDL can handle them then there is no need for the assembly. Here's hoping.

I didn't realise there was any assembler code. Generally you won't need to deal with 32-bit floats because the libraries do all the conversions for you. But if you do need to do a conversion yourself you can call the FN_f4() routine which converts a regular BBC BASIC value to a 32-bit float.

Please could you look at the code that creates the buffers and the clean up routine and hopefully point out the error.

I have occasionally had problems myself with PROC_release() seemingly not clearing everything up. I've never traced why, but I've put it down to the way BBCSDL switches between two different OpenGL contexts (the 2D context used by SDL 2.0 and the 3D context used by the 3D library).

Generally it's not an issue, because BBCSDL (or more correctly SDLIDE) doesn't try to do what BB4W stupidly does, which is to run your BASIC program in the same process as the IDE! With hindsight that was a silly decision.

Admittedly the mobile editions (Android and iOS) do run the BASIC program in the same process as the 'IDE' so cumulative memory leaks can become a problem in that environment.

[Ric]

Richard,
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, to being able to directly access many of the buffers and screen textures (staging). An easier option may be to convert my library routines to opengl. Something I would have to give great thought to.
And require a lot of help.
How Much do you know about initializing openGL?

Kind regards Ric