guest wrote: ↑Thu 01 Nov 2018, 09:27
David Williams wrote: ↑Tue 30 Oct 2018, 17:21
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.
--