Maizie Bones (new game)

[David Williams]

Um... well for next Halloween I could start on a major project.. I doubt I will have the skill (or willpower) to beat anyone by the next deadline,

The trouble is, the bar will be even higher by then!

[mikeg]

The trouble is, the bar will be even higher by then!

Yeah, probably. I will attempt to reach that bar. Challenge accepted.

[mikeg]

I would be honored if David Williams would also compete against me for the Christmas Syntax Bomb challenge. No holds barred. I am going to create the best action game I am able to make. I plan to win.. It is a challenge of wills.. It is already partly made. Please accept.

[David Williams]

I would be honored if David Williams would also compete against me for the Christmas Syntax Bomb challenge. No holds barred. I am going to create the best action game I am able to make. I plan to win.. It is a challenge of wills.. It is already partly made. Please accept.

We are all competing against each other aren't we? I haven't made much progress myself, but hopefully things will pick up a bit over the next week.

Have you seen Qube's work-in-progress effort? ---> https://www.youtube.com/watch?time_cont ... R5ce7DE8_c

Makes me feel like giving up.

Good luck with your entry, and getting it done before the deadline.


David.
--

[guest]

Have you seen Qube's work-in-progress effort?

Even if Qube's entry is the best (as it was when Rob Jeffs won with Blue TIGAR) he's not allowed to take the prize! Anyway I've been experimenting with dynamic 3D textures (changing the texture map every frame, by combining 2D sprite animation with 3D rendering) so even in BBC BASIC some pretty impressive effects should be possible.

It's well known that projecting a moving image of a face on a vaguely head-shaped convex surface fools the brain into thinking it's a full 3D animation, and I can imagine that trick being used to make convincing 3D objects that have a simple geometry. With the next release of BBCSDL there'll be an example program which animates a simple object that looks as though it has a lot of 3D detail, when it doesn't.

[David Williams]

Have you seen Qube's work-in-progress effort?

Even if Qube's entry is the best (as it was when Rob Jeffs won with Blue TIGAR) he's not allowed to take the prize!

Qube is no longer participating. I hope it wasn't because of some possibly perceived 'nitpicking' by a SB forum member.

Anyway I've been experimenting with dynamic 3D textures (changing the texture map every frame, by combining 2D sprite animation with 3D rendering) so even in BBC BASIC some pretty impressive effects should be possible.

Sounds interesting, and I look forward to seeing the demo(s). For my current project I'm sticking with simple Minecraft-eqsue graphics, if I'm to have any chance of getting the game completed in time for the deadline.

It's well known that projecting a moving image of a face on a vaguely head-shaped convex surface fools the brain into thinking it's a full 3D animation, and I can imagine that trick being used to make convincing 3D objects that have a simple geometry. With the next release of BBCSDL there'll be an example program which animates a simple object that looks as though it has a lot of 3D detail, when it doesn't.

Bump mapping can also increase apparent complexity, and it can produce pleasing results.


David.
--

[guest]

I'm sticking with simple Minecraft-eqsue graphics, if I'm to have any chance of getting the game completed in time for the deadline.

Minecraft-esque graphics would be impressive enough.

I recently downloaded a detailed 3D model of an organ console (don't ask): it has 260,000 vertices, 500,000 faces and the .fvf file created by my OBJ2FVF utility is 46 Mbytes! I expected it to be highly unlikely that BBC BASIC would render this at all, let alone at a reasonable refresh rate, but it does! BBCSDL/ogllib manages over 16 fps on a Windows 10 laptop.

The conclusion I draw is that BBC BASIC can render an extremely complex model but what it won't cope with efficiently is rendering a large number of different objects. So the moral is to put all your 'fixed' objects (i.e. those that maintain a constant position/orientation relationship with each other, such as buildings, scenery and so on) in a single FVF file rather than having one file per 'object'.

You can still colour or texture the component objects differently, either by including RGB values in the FVF file or by tiling a large multi-texture image map and using the UV coordinates to pick out the required parts for each 'object'. The only thing you can't do is assign different materials to different objects, but textures can do the same job. By switching textures from frame to frame (this is very fast) you could even achieve some dynamic effects like flashing Christmas decorations.

If you restrict the creation of different objects (i.e. calls to FN_load3d) to those which need to move independently you should be able to render a complex scene using pure BASIC code in BB4W or BBCSDL. I'd like to see what can be achieved by pushing that technique to its limits.

P.S. If you're building a 3D scene and need some off-the-shelf models, I've found Turbosquid to be an excellent and inexpensive source. That's where the 'tin soldier' came from for example.

[DDRM]

Guest wrote:
>The conclusion I draw is that BBC BASIC can render an extremely complex model but what it won't cope with efficiently is rendering a large number of different objects. So the moral is to put all your 'fixed' objects (i.e. those that maintain a constant position/orientation relationship with each other, such as buildings, scenery and so on) in a single FVF file rather than having one file per 'object'.

That's interesting. When I was playing with my flight sim I tried rendering the "whole world" as one object, and hit the buffers, so there IS an upper limit, not surprisingly. With a world of 1024 square (so a million points/squares, and 2 million triangles) it started to grind to a halt... My planned solution, yet to be implemented because it is not immediately obvious how to flow between "centres", is to break the world up into smaller sections (maybe 128 square), and have 9 on the go at any one time, centred on the current position of the plane.

Best wishes,

D

[guest]

When I was playing with my flight sim I tried rendering the "whole world" as one object, and hit the buffers, so there IS an upper limit, not surprisingly.

I'm not sure we are talking about the same thing. I am talking about the relative performance benefit that can accrue from combining a large number of small objects into a smaller number of large objects, given the same overall complexity.

With a world of 1024 square (so a million points/squares, and 2 million triangles) it started to grind to a halt...

But that sounds like it was an overall complexity issue, not one specifically related to whether there were many small objects as opposed to few large objects, which is the point I was making.

My planned solution, yet to be implemented because it is not immediately obvious how to flow between "centres", is to break the world up into smaller sections (maybe 128 square), and have 9 on the go at any one time, centred on the current position of the plane.

I hope it was obvious that, in suggesting that several small objects can be beneficially combined into one large object, the assumption I was making is that all those small objects would be 'active' in the model at the same time. A flight simulator is an entirely different kettle of fish; in a situation in which you can only ever 'see' a small proportion of the world at any one time the emphasis must be on efficiently culling objects which don't need to be rendered because they cannot contribute to the current 'scene'.

[David Williams]

I'm sticking with simple Minecraft-eqsue graphics, if I'm to have any chance of getting the game completed in time for the deadline.

Minecraft-esque graphics would be impressive enough.

Emphasis on the '-esque' part!

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

The conclusion I draw is that BBC BASIC can render an extremely complex model but what it won't cope with efficiently is rendering a large number of different objects. So the moral is to put all your 'fixed' objects (i.e. those that maintain a constant position/orientation relationship with each other, such as buildings, scenery and so on) in a single FVF file rather than having one file per 'object'.

The trouble with that in the context of a game like I'm making is that while all the 'rooms' are in a fixed relationship with each other, and could be sent to PROCrender() as a single (but large) object, the GPU still ends up Z-buffering potentially hundreds of occluded objects (especially walls, floors & ceilings) that can never ordinarily be seen from a particular vantage point, and that is very inefficient (and does cause slowdown). The way I've approached it is to divide the 'world' into rooms (or 'cells' as I call them), and each cell maintains a list of which other cells are visible from it (seldom more than 10, say). So the visible cells get switched on, all the others get switched off so that the GPU doesn't process them. Also, dynamic objects (baddies, collectables etc.) know which cell they're in, and so you get a kind of free occlusion culling because those aren't 'processed' by PROCrender() either (or rather, they're not sent to the GPU). This has meant tweaking PROCrender() to ignore 'inactive' objects, and in fact I recently implemented a chunk of it in assembler for speed (because we're talking about a lot of dynamic objects, potentially).

If you restrict the creation of different objects (i.e. calls to FN_load3d) to those which need to move independently you should be able to render a complex scene using pure BASIC code in BB4W or BBCSDL. I'd like to see what can be achieved by pushing that technique to its limits.

Someone else will have to take up that challenge! My priority is to get a fun-to-play adventure game written by the deadline, by hook or by crook, and have it running at a high frame rate (preferably the same as the monitor's refresh rate).

I previously stated that I would target most of BBCSDL's available platforms, but that was before I knew what type of game I was going to try to make. As things currently stand, I'm targetting Windows, Linux (x86) and MacOS-X, except I won't be able to 'build' the last one myself as I have no access to a Mac.

You might remember that with the 'Blue Monster Hunter' subgame in Maizie Bones, the 3D graphics were rendered via Direct3D inside a 'static box'. I will probably need to figure out how to do that with BBCSDL. I will of course read the SDL2.0 docs, but I might need to tap you for assistance with this if I stumble!

P.S. If you're building a 3D scene and need some off-the-shelf models, I've found Turbosquid to be an excellent and inexpensive source. That's where the 'tin soldier' came from for example.

Thanks, I'll check it out.


David.
--