Not Quite MineCraft

[Ric]

Sorted. That was a major headache, how can one byte cause so much pain . I think I have closed a few more loop holes too and will post the latest version tomorrow, the file will require a large space on the disc, I'll let you know how much in tomorrow's post.

Kind regards Ric

[Ric]

I have added a few objects to the landscape and now given the ability to make the landscape as big as you like, memory allowing! (each 32*32 block takes about 2.5MB). The example here

https://1drv.ms/u/s!AqibHqCkE1VQgfUgHaE ... Q?e=a9s5sD

uses 32 * 32 cubes which are 32 *32 blocks in size giving 1024 * 1024 individual blocks.

The keys are as last posted and the main program is " A Not Quite Minecraft"

If you change the gameMode% variable to 0 then you can also fly and rotate the world along the screen x axis, keys should be "@", "/","K","M"

The extracted file is about 4GB

Happy viewing , Ric

[Hated Moron]

https://1drv.ms/u/s!AqibHqCkE1VQgfUgHaE ... Q?e=a9s5sD

Extracting it now - Windows tells me it's going to take 7 hours and 30 minutes!

Is there a particular reason why you're not distributing it as a 'compiled' self-extracting exe?

[Ric]

Yes, I don't know what that is.
I can send a link to the original uncompressed version. The main program is of fairly nominal size, but the landscape is 4GB, if there is a quicker way please let me know

[Hated Moron]

I don't know what that is.

I was simply asking why you chose to distribute a BBC BASIC application in the form of (albeit zipped) source code. Obviously that's not a common - or convenient - way of distributing a program, whether in BASIC or any other language, not least because it reveals the source code to everybody who receives it! You may not worry about that, but many software authors do, and want their code to remain confidential.

If one of your concerns is the degree of compression that the 'compilation' process achieves, that is valid to the extent that it probably is somewhat less efficient than ZIP. But on the other hand the BBC BASIC code will be shortened by the removal of REMs and all the other crunch processes, even before it gets compressed. This will compensate to a degree for the less efficient compression.

However since such a large proportion of your overall package isn't BASIC code but rather data of various kinds (e.g. bitmaps) I have to concede that the likelihood is that a 'compiled' executable will be significantly larger than your current ZIP. The only way to find out how much bigger, and whether that increase is acceptable, would be to try it.

If you do want to try it, you will inevitably need a large number of REM!Embed directives. The highly modular nature of your program means that the automatic scan for embedded files isn't going to be useful, since it won't see the great majority of the files it needs to embed; to that extent it's very similar to some of David Williams's games.

(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 ability to create a single-file, standalone EXE is, of course, one of the few benefits which BBC BASIC for Windows has over BBC BASIC for SDL 2.0, and is probably one of the main reasons why a few people choose to pay good money for BB4W when they can get BBCSDL for free! So not to use it feels a little wasteful.

[Ric]

Ok, I think I get what you are saying. If I compile my program, it will try to include many of the files it uses, but there are 1024 landscape files at 48000*44bytes, I can not work out how to link these as they are linked in a need to see basis, and therefore at crunch time, none of them are seen by the main program.

[Hated Moron]

they are linked in a need to see basis, and therefore at crunch time, none of them are seen by the main program.

As I said, the solution to that is to add a whole load of REM!Embed directives to your 'main' program, but with so many files that is going to mean a lot (you can list multiple files in a single directive, but you won't fit in very many before the maximum line length is exceeded)! In your position I'd probably want to automate that process (write a program which generates the directives) because doing it manually could take hours.

There is another way, which is to include the necessary embedded files using the Add @dir$ button in the Compile dialogue. That does allow the selection of multiple files 'in one go' (not sure what the limit on the total number is) but you'd then be reliant on the list being refreshed from a previously-compiled executable on a subsequent build. Otherwise you'd have to do it every time!

So I would say the REM!Embed approach is the better one, but I do appreciate that the sheer number of files needing to be embedded is quite daunting. Conceivably you might hit a limit somewhere, but there's only one way to find out.

A quick bug report on the program if I may: if you click on the Maximize button and then click on it again, which you would expect to return it to how it was previously, that's not what happens (here). The Maximize-Restore Down sequence seems to leave the 3D 'canvas' displaying in a small rectangle in the top-left corner.

[Ric]

I think the best option is to distribute the scene creation routine with the main program, this takes about 45 mins to run, but compared with 7 hours 30 to extract, seems paltry. I know about the sizing issue, just haven't got round to sorting it. It relies on resizing the viewport as well as the window and lost interest when other aspects of the project cropped up.

It hasn't been 7 and a half hours since I posted the code, so did Microsoft lie?

[Hated Moron]

It hasn't been 7 and a half hours since I posted the code, so did Microsoft lie?

I don't think you can call it a "lie", but the estimate was very pessimistic, yes. What tends to happen is that when it's extracting lots of very short files the overhead is much greater, and it bases its estimate of the total time on the assumption that the entire archive consists of files that small. But when it encounters larger files it revises its estimate, sometimes quite drastically. It probably took about 30 minutes in practice.

[Hated Moron]

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

Well, that took about 1 minute to unzip on my system.

I'm guessing it's a high performance 'gaming grade' desktop. Mind you I wouldn't have expected this Core i7 laptop to be as comparatively slow at unzipping (30 times or so) as it seems to be, perhaps the charger wasn't plugged in at the time.

But running A Not Quite Minecraft.bbc instantly produces a Bad Mode error

How big is your screen? Ric's code seems to get the screen size from GetSystemMetrics() and sets the window size slightly smaller (which is a little convoluted, I wonder why he doesn't simply maximize the window). This will fail with a Bad Mode error if the requested window size (after High DPI scaling) is larger than 1920 x 1440 pixels, or 20" x 15" in old money. I don't have any monitors that big, but you may.

As I've said dozens of times, my preference is for a program to use a window no larger than about 800 x 600 pixels (MODE 20), by default; that's a size which virtually any desktop can accommodate. By all means allow the user to maximize the window, if he wants to; even remember the fact that he has done that and do so automatically the next time the program is run. But I'm not keen on programs that try to claim the entire screen initially.