BasicBoy(Maizie Bones, BB4W game)has finished in 1st place in a Maze theme game programming contest!!!

[kigohhere]

Well done.
https://www.syntaxbomb.com/index.php/topic,4989.0.html

Full details!!!
https://www.syntaxbomb.com/index.php/topic,4956.0.html
https://www.syntaxbomb.com/index.php/topic,4958.0.html
https://www.syntaxbomb.com/index.php/topic,4977.0.html

Congratulations!!!

[guest]

Well done.

Indeed. Three wins for BBC BASIC now!

Reading one of the related threads over at SyntaxBomb, 'BasicBoy' states that "The assembler code was for 'fake-mapping' a bitmap image to a sphere … or a cylinder ... BBC Basic (being an interpreted language) just isn't fast enough to do this at an acceptable speed". I'd slightly take issue with that comment: of course interpreted BASIC code wouldn't be fast enough to do the mapping in real-time, but nor is it fast enough to blit individual pixels to the screen to draw 2D or 3D graphics. It's the availability of graphics library routines (e.g. Windows GDI or SDL 2.0), typically coded in C, to do the 'heavy lifting' that makes any of this possible.

And so it is for mapping a 2D image onto a 3D object like a cylinder or a sphere. This is the sort of thing that 3D libraries like Direct3D or OpenGL can do very easily, and by leveraging them it is possible to reproduce the effects described without resorting to assembler code. Here's a proof-of-principle demonstration: a partial simulation of the Treasure Tower subgame written in 100% BBC BASIC code and running in BBCSDL (this is on Windows but in principle it should work on Linux, MacOS, Android and iOS as well). The graphics are initially rendered onto a 2D surface and then wrapped around a half-cylinder using OpenGL:

http://www.youtube.com/watch?v=PqZYOeNA95Y

[David Williams]

Excellent stuff, Richard. I really want to see how you did that (at the code level).

There's probably going to be another code-a-game contest coming up soon at SyntaxBomb, and I'm intent this time on submitting a cross-platform entry for it (I think it's pretty much expected now). I believe I have more-or-less everything I need in terms of (your) BBCSDL examples to start off on the right foot.

In the meantime, there's another (huge) game-coding contest starting in 31 days: the world-famous 'Ludum Dare' compo & jam:

https://en.wikipedia.org/wiki/Ludum_Dare
https://ldjam.com/

Ludum Dare, which is about to begin its 43rd contest, now attracts literally thousands of submissions. That means a lot of exposure for one's preferred programming language (for those who wish to look at it that way!).

I do hope that some BBC BASIC users will give it a crack. They will have to work very quickly though, as the contest runs for only 72 hours (for the compo), and 48 hours for the jam. That's quite some pressure to work under.

Personally, I've sworn allegiance to SyntaxBomb, so that precludes my participation in Ludum Dare.


David.
--

[guest]

Excellent stuff, Richard. I really want to see how you did that (at the code level).

I do of course intend to publish the code, but it's not at that stage yet and I'm juggling a few things at the moment. Something else I've recently succeeded in doing (also demonstrated in that video) is outputting both music and sound effects in a cross-platform context - without having to link with SDL_mixer. As a useful side-effect you can output multiple overlapping sounds without any being truncated, which would have been helpful in my reworking of FOD for BBCSDL. It does however imply that if you give the player the choice of disabling the background music you must stream 'silence' instead!

[p_m21987]

Congratulations on winning!

There's probably going to be another code-a-game contest coming up soon at SyntaxBomb

Do you know when it will happen? I'd be interested in trying to submit something if it's scheduled for a time when I won't be busy.

[David Williams]

Do you know when it will happen? I'd be interested in trying to submit something if it's scheduled for a time when I won't be busy.

Probably within the next few weeks, and hopefully by the end of November at the latest. Best to keep an eye for any announcements at SyntaxBomb.


David.
--

[kigohhere]

Indeed. Three wins for BBC BASIC now!

Looks unbelievable but really happened.

These BBC Basic users showed audience their creative ideas and awesome programming knowledge.

I really look forward to a lot of wonderful entries from BBC Basic users in the near future!!

http://www.youtube.com/watch?v=PqZYOeNA95Y

The above partial simulation video is nice and very excellent!

[guest]

I'm intent this time on submitting a cross-platform entry for it (I think it's pretty much expected now).

That's good, but it still leaves some choices. For example would it be 'desktop platforms only' (i.e. relying on a keyboard and mouse) or also suitable for running on touchscreen devices? Would the supported platforms include iOS, thus ruling out assembler code and/or compiled binary blobs?

Personally I find the challenge of doing everything acceptably fast In 100% BASIC code (leveraging the available libraries via SYS to the full) quite stimulating, but you may see it as too much of a limitation.

[David Williams]

I'm intent this time on submitting a cross-platform entry for it (I think it's pretty much expected now).

That's good, but it still leaves some choices. For example would it be 'desktop platforms only' (i.e. relying on a keyboard and mouse) or also suitable for running on touchscreen devices? Would the supported platforms include iOS, thus ruling out assembler code and/or compiled binary blobs?

Depending on what kind of game it's going to be (the upcoming contest is still only at the 'ideas' stage over at SyntaxBomb), I'm probably going to go for a 'multiple builds versions' approach, rather than producing a single cross-platform program. This is mostly for code efficiency reasons. Assuming it's an 'arcade video game' (for which I will always prioritise performance!), there will be a dedicated BB4W version, a BBCSDL Android version, and almost certainly a BBCSDL Linux (x86) version. As for the Raspberry Pi edition of BBCSDL - well, I'm unhappy with the overall performance prospects (I'll e-mail you privately about this). I'm also probably going to produce a version for RISC OS (because the process will be fun and nostalgia-filled).

Summary:
BB4W (with my usual graphics drawing methods) pretty much guarantees excellent performance.
Same with BBCSDL for Android (only if I use my custom plotters; the 100% BASIC/SDL-only approach just doesn't produce good performance on my mid-range phone).
I think BBCSDL for Linux (x86) will be fine performance-wise, and I look forward to producing a build for it.
MacOS should be fine, I guess.
The BBCSDL for Raspberry Pi version currently looks like a non-starter judging by some tests conducted earlier today.
The RISC OS version will be fine in terms of performance (even if I have to limit the colours to 256).

Personally I find the challenge of doing everything acceptably fast In 100% BASIC code (leveraging the available libraries via SYS to the full) quite stimulating, but you may see it as too much of a limitation.

In the arcade/action video context, 'acceptably fast' for me means high frame rates (60 fps for 60 Hz displays, etc.), and silky smooth animation and motion. I'm not a BBC BASIC purist (obviously!), and I'll be more motivated by getting the game done and dusted before the deadline than worrying about the implementation (hence my willingness to resort to assembler or C (the latter just saves time in some cases)).

I'm looking forward to the next contest. I just hope that an interesting concept is decided for it, and that I can come up with an idea.

(I might turn to this forum for ideas!)


David.
--

[guest]

In the arcade/action video context, 'acceptably fast' for me means high frame rates (60 fps for 60 Hz displays, etc.)

I'm sure you'd agree that what matters most is that the animation speed (and therefore gameplay) is independent of frame rate. Personally I don't see anything wrong with the frame rate falling on a slower device, so if it runs at a full 60 fps on a fast PC but only 20 fps on a Raspberry Pi, say, that seems perfectly reasonable to me and only to be expected. 20 fps should be easily fast enough to play a game.

Same with BBCSDL for Android (only if I use my custom plotters; the 100% BASIC/SDL-only approach just doesn't produce good performance on my mid-range phone).

Again, achieving only "mid-range" performance on a "mid-range" phone is what I would expect! It's quite normal for a video game to work at its best only on the very latest and fastest hardware. I would judge that supporting iOS should be a higher priority than achieving some arbitrary threshold of performance on Android.

I think BBCSDL for Linux (x86) will be fine performance-wise, and I look forward to producing a build for it.
MacOS should be fine, I guess.

Remember that although the current Linux and MacOS releases of BBCSDL are 32-bits, they are both under 'sentence of death'. Arguably I should have already replaced the Linux edition with a 64-bit build, and Apple have announced that support for 32-bit apps in MacOS is going to be discontinued soon, probably within months. There is currently no assembler in the 64-bit editions so you may want to take that into account.

My recommendation, for what it's worth (you may think very little!), would be to write just one BBCSDL version that will run on all the supported platforms (which means no assembler or compiled code in order to support iOS and 64-bit x86). If that means that a full 60 fps and "silky smooth" animation can only be achieved on the fastest machines, I don't think anybody should be surprised or disappointed.