Not Quite MineCraft

[Ric]

For the bad mode problem insert

Code: Select all

      IF S_W% > 1920 THEN S_W% = 1920
      IF S_H% > 1080 THEN S_H% = 1080

immediately after

Code: Select all

      SYS "GetSystemMetrics", 0 TO S_W%
      SYS "GetSystemMetrics", 1 TO S_H%

in PROCBASICVariables

The reason for the big screen was to test the speed of the program, the bigger the screen the slower it runs.

[Hated Moron]

On 16/02/2023 19:38, Andrew Cool wrote (cross-posted from the Discussion Group):

It's a 4k monitor, so yes, beyond BB4W's windowing capability.

And a high performance desktop that I use for crunching astronomical (literally) data.

Perhaps Ric should opt to create the largest window that will fit if he's keen on large windows for his game?

An 800x600 window would be a postage stamp in some corner...

I can't agree with that last comment. Remember that BBC BASIC assumes that High DPI Scaling will be active (i.e. not disabled in the program's Compatibility settings) and that the pixel pitch will be approximately 96 Dots Per Inch. Therefore an 800 x 600 window should be around 8" x 6". I've never seen a postage stamp that size!

This assumption arises because of the dimensions of the BBC Micro-compatible modes, such as MODE 3 and MODE 7 (640 x 500 square pixels) which need to be legible whatever the monitor's size and resolution. If you disable High DPI Scaling you can expect some BBC BASIC applications not to work correctly. That's down to you rather than the developer.

[Hated Moron]

BBC Micro-compatible modes, such as MODE 3 and MODE 7 (640 x 500 square pixels) which need to be legible whatever the monitor's size and resolution.

I should add that one of the big advantages of BBC BASIC for SDL 2.0 over BBC BASIC for Windows is the @zoom% variable, which allows you to scale the 'logical' window that your BASIC program sees to a potentially much larger 'physical window' on the screen itself.

Indeed you can easily make your program adapt to whatever the physical window size is (even fullscreen) without having to change the working of the code at all, by incorporating an ON MOVE handler as follows:

Code: Select all

      ON MOVE PROCresize(@msg%, @lparam%, @size.x%, @size.y%) : RETURN
...
      DEF PROCresize(M%, L%, X%, Y%) IF M% <> 5 ENDPROC
      LOCAL W%, H%
      W% = L% AND &FFFF
      H% = L% >>> 16
      IF W%/H% > X%/Y% THEN
        @zoom% = &8000 * H% / Y%
      ELSE
        @zoom% = &8000 * W% / X%
      ENDIF
      IF @zoom% < &8000 @zoom% = &8000
      IF (@platform% AND 7) < 3 THEN
        @panx% = (X% - W% * &8000 / @zoom%) / 2
        @pany% = (Y% - H% * &8000 / @zoom%) / 2
      ENDIF
      ENDPROC

You can see this in action in programs like tower.bbc supplied with BBCSDL v1.34a.

[Hated Moron]

On 18/02/2023 01:14, Andrew Cool wrote (cross-posted from the discussion group):

It's a relative postage stamp at MODE 3.

I'm not sure if I'm failing to make myself clear, or whether I am misunderstanding you. But once again:

• BBC BASIC assumes that High DPI Scaling is active.
• If High DPI Scaling is active the logical resolution (as seen by BBC BASIC) will be approximately 96 Dots Per Inch.
• At 96 DPI resolution MODE 3 (640 x 500) is approximately 6.7" x 5.2".

If MODE 3 is a "relative postage stamp" your PC is misconfigured and you should enable High DPI Scaling for BBC BASIC.

[Richard Russell]

(As an aside, had REM!Embed been able to accept wildcards it would have made this very much easier, but that's a 'nice to have' feature which never got incorporated, and never will now).

The "never will" comment turned out to be pessimistic, because I recently - albeit nearly two years later - implemented exactly that. Although there's very little I now attempt in terms of software writing, that was just about within my remaining abilities.

Was this MineCraft 'clone' ever finished? I can't remember what stage of completeness it had reached when I last ran it.

[Ric]

The game is not finished yet, I have come across a slight stumbling block. I can't produce shadowing! This means it's extremely difficult to make it go dark underground. I am working on it slowly, the game now has inventory and objects that can be placed here and there or exchanged for others. When I have finished my lighting app I will be back on it. In order to run the game and send the landscape models requires a vast amount of memory so it will be difficult to make the game playable to anyone immediately,but I will make a YouTube link and video.

[Richard Russell]

I can't produce shadowing! This means it's extremely difficult to make it go dark underground.

'True' shadows are extremely difficult, and even some mainstream video games don't attempt that. But isn't "making it go dark" simply a case of turning the lighting down? Or perhaps turning some lights down more than others (so surfaces at some angles darken more than others)? Not really shadows, but I would have hoped the effect could be made acceptable.

Currently the WEBGLLIB library (available for both BBCSDL and BB4W) supports up to 8 lights but that's largely arbitrary and it could easily be modified if you need more. WEBGLLIB uses custom shader code (written by me) which means it's in principle more flexible that the older 3D libraries, if you don't mind getting your hands dirty!

WEBGLLIB also does 'per pixel' lighting calculations whilst OpenGL (and DirectX 8/9) only does them per-vertex, so the resulting quality is much better. This can easily be seen in this old teapot rendering:

https://www.youtube.com/watch?v=nYJeknayxkw

[Richard Russell]

This can easily be seen in this old teapot rendering:

And here it is for running in your own browser: https://wasm.bbcbasic.co.uk/bbcsdl.html ... ps/teapot2

[Ric]

Thanks for the reply Richard, the delayed response is because i am extremely busy at work at the moment and i am barely spending any time sat at my laptop.
The problem of shadows is not one of understanding how to produce them, i have converted the DirectXTutorials.com lessons to BBC Basic and have posted them on line. Shadow mapping is not difficult but calculating the right height to produce the shadow map from is causing me a headache.
I have looked at the teapot code and i dont think this approach would be possible, because one would have to calculate if the light was underground or behind the main "sunlight", this is easiest accomplished with shadow mapping and thus back to the height calculation. I am moving forward with other parts of the game as they can be done with limited time on the code. I will post a video on youtube very shortly.

[Richard Russell]

Shadow mapping is not difficult...

This article describes it as "not that hard" but requiring "a lot of background knowledge" which I simply don't have! DirectX tutorials are unfortunately not directly relevant to BBC BASIC for SDL 2.0, since they are Windows-only, unless you fancy adapting them to OpenGL/WebGL.

I'm also conscious that the average BBC BASIC user isn't going to be able to, or to want to, write shader code themselves so any approach which requires that degree of understanding isn't going to be widely relevant.

If it was feasible to create a 'shadow library' which hides the complexity behind a friendly wrapper that's another matter.

I have looked at the teapot code and i dont think this approach would be possible, because one would have to calculate if the light was underground or behind the main "sunlight"

I based my comment on you wanting to "make it go dark underground" which sounds like it would be easy to achieve with directional lighting, but probably the effect you are after is more subtle than that would produce.