I have read a few messages from people saying that they would like to make a game for the beeb in basic or assembler but feel the whole thing would be too much.I was wondering if it would help to strip down my circus/ripcord code to give a character mapped display with a few sprites.What would the minimum requirements be to be useful?I was thinking mode 4/5 with a character mapped 256x256 display and upto four sprites with. The screen would be mapped as 1024 charters. The sprites would be exclusivity ORed with the characters and each other.The sprites would be specified as x,y, image. For horizontal movement, you need multiple copies of the sprite, which could be different frames of animation if each frame is always used at a specific character (byte) offset.Does anyone have any specific requests?Mode 0/1/2 are also fairly easy, but due to the extra memory, the resolution would probably be better dropped to 256x192 (specky Res).

I think from a reference point of view, having such a framework available, maybe as a wiki, would be hugely useful to those wanting to dig deeper into the world of beeb programming. Including it as a demo along with the beebasm-master source might also be a good way to introduce it to people.

I know when I was starting my Conan project, having RTW's demo source for the rotating globe was a big help, having the game engine framework as a starting point was great and being able to add and play around with code idea's and not having to worry too much about timers, interrupts and vsync made it all very approachable.

The hardest part about having a framework of course is that everyone's idea of what they want is going to be different but at the same time having a common starting point, a coding sandpit of sorts, would be useful for those wanting to break into the art without having to go through the steep learning curve of working out all the low level stuff.

I think what you've laid out sounds really good, happy to be a test subject etc. It's not quite ready yet but my import utility will be able to export various types of sprite and image data so might be able to cater for whatever format you're planning for.

There is a program for the ZX Spectrum called AGD - Arcade Game Designer. It allows someone who has no coding background to write games. It includes a scripting language, sprite editor, map or screen layout designer, sound and background tune editor and compiler. I suppose it's a bit like how they did Repton Infinity but with more freedom.

I've not used it (but have meant to take a look at it for some time), but something similar (that could maybe run from one or more sideways ROMs) would be extremely useful.

I recently wrote a Sokoban game for the Speccy (in Sinclair BASIC) but I have never tried to write anything in Z80 machine code and probably will never learn to, but I do want to bring it to the BBC Micro in one form or another. If I had some simple routines that would allow me to just concentrate on game graphics, for example, I would then be able to write it for the Beeb in machine code.

I suppose an AGD-like tool would be quite good though, and would be very useful for beginners. It may be a large chore to write though.

I'm writing a game where you can change your character from a Wizard to a monkey to a cat.

I'm not very good at lecturing, hence I only did one course at the OU, but I can answer questions all day.I wasn't planning anything in the way of lessons I've been playing with the code and it has reminded me why I write custom routines for nearly every sprite type.For writing turn based games or even simple arcade games, I think the GXR ROM might be the way to go. Most of it is in the Master, or it can be loaded into sideways RAM for all beebs.I was just starting the sprite routine(s) and immediately hit the space/time/flexibility compromises:Should all the sprites be 24x24 character aligned, which would allow 17x17 sprites to be drawn anywhere, but wastes more than 1/3rd of the space if the sprite is only 16x16 and over 1/2 if it stays horizontally aligned to characters.With Circus, it was easy as I only had to fit in what the arcade ROM needed and could arrange things to fit and then optimize drawing to match.

I'm on holiday this week and have been playing a bit with the sprite code from Circus.Here is a demo with 8 sprites (2 stuck together for the galaxian's ship).Drawing the sprites takes a bit under half a frame, but the BASIC is much slower.X%?(0-7) is the left of the sprite in MODE 4 pixels, Y%?(0-7) is the bottom of the sprite, Z%?(0-7) is the offset of the sprite and ?N%=index of last sprite (-1 for none).As this mode 5 is only 128 pixels wide, I am using the even X coordinates for one sprite and the odd for another, so there are four copies of each.Calling U% updates the display and V% does the same after a *FX19 to avoid flickering.The sprites are EORed on and off, so any background can be drawn with EOR and it should all work OK.The sprite positions and offsets are stored in the BPUT work space, &8A,,&8F, &F8 and &28 (BASIC OPT value) are used for temporary work-space.The sprite data is loaded between &5800 and &5FFF, where the screen would have started before it was made narrower and started at &6000.Let me know if this is useful, or if not, what it needs to be made useful.I have also done the character display, both drawn and EORed and will post them when I have a simple demo.The sprites aren't clipped, so this is only really suitable for a single screen game where the sprites stay wholly on-screen.The image to EQUB statements is to follow The beebasm command line is :

This is a really nice engine which I am looking to adapt in my Stellar Rescue rewrite.

The animation is smooth and simple, while I won't use the sprites code this time around, the graphics engine itself is of great use to me so thanks for sharing.

I have a number of projects bubbling away so I will come back to your code for inspiration and blatant plagiarism again and again

I think you're so right with each project being a suited to a unique approach with regards to plotting sprites, there just isn't enough system resources to make a generic approach viable and still get good performance while keeping it simple. Which I guess is kind of the beauty of writing for the beeb, we're forced to come up with something uniquely tailored to the task at hand.

Thanks again for the code samples, they're helping at least me and I suspect many closet coders out there to give it a go

Thanks, I'm glad someone found it useful.I'm going to tidy it up a bit and post the image converter with the option of 5 sprites with 8 frames (can be used as 10 sprites with four frames in mode 5) using 8 pages (those saved by the narrower mode 5) and a version with 16 sprites with 8 frames each, using 24 pages (6k).As you can use for text and drawing routines, I think just sprites is enough, especially as copying bytes in blocks of 8 or 16 for text is fairly trivial.I'm going to make sprites with y=0 invisible, which should be enough for speeding up simple basic games.I was tempted to add an 8x8 mode 4 sprite with ?Z%=0, but I doubt it is necessary.Good speed with your game.

This is the kind of thing that would be amazing for the BBC/Electron/Master community. But I know its not going to be something easily done if at all. A nice sprite routine that is at least functional from Basic would be a massive step toward making games easier for the creative but less knowledgeable coders/artists.

Just tried the demo..... niiice. They are running around pretty quickly I like it. Just what I'd want. I think to make it useful for people like me (no machine code experience) is a very simple and detailed (step by step) documentation on how this all works, what I need to do to get my software to the point of calling sprites and throwing them at the screen. Or you could package it up so that its super simple to use. With strict rules for instance.....Max 4 or 8 sprites depending on the mode (1,2,4 or 5 I reckon). With the option for more if you have the coding experience.Maybe give us a starting basic program structure, which sets up the mode and loads the routines and then the Sprite Data. Then keep the commands to Call Sprite(x) (x being 1 - 8 )That would do me. Oh and give us an easy instruction on how to create these Sprites. Whether its through BeebSpriter or some other package or workflow.

Then may be as time goes on we (the community) could start to build routines based around this (could be assembler etc.) that can utilize better/faster control routines or expand the number of sprites or help with better AI etc. Then we could be building towards a proper AGD style package for gamers to really start creating.

I am including the code to convert 24/32 bit uncompressed TGAs into sprite data that beebasm then packages and puts on the .ssd as well as an exe in a separate .zip so you don't have to download it.The converter is written in basic C++ and has a VisualStudio solution and project file.

-cols:01 (mode 4) or -cols:0123 (mode 5) where 0123 are the letters for which colour gets converted to which palette entry.K:BLACK, R:RED, G:GREEN, Y:YELLOW, B:BLUE, M:MAGENTA, C:CYAN, W:WHITEI haven't tested mode 4, so best stick with mode 5 for now (TGA uses square pixels - half width).-sprites:800 (5 graphics x 8 frames) or -sprites:1800 (16 graphics * 8 frames)filespec.tga the files to convert to filespec.equ (you can list as many of these as you like.The -cols and -sprites apply to all images converted before the next -cols or -sprites.The defaults are: -Characters (which isn't implemented yet) and -cols:KRYW

The -sprites:800 has 8 blank pixels on the left, these were for an additional 18x8 (8x8 mode 5) sprite that I haven't added the code for.The -sprites:1800 is pretty much as you would expect with the 8 pixel offsets/frames down the screen in 16 pixel rows and the graphics across.

ORG &9D0 ; Speech buffer, CFS/RFS BPUT (not SAVE), change this to assembler to a different location.SPRITES = &800 ; set to &800 for 5 graphics with 8 frames each or &1800 for 16 graphics, 8 frames - 24 pages

I have left the code loading into the speech and tape BPUT buffers.This is obviously risky if the disc driver has had the same idea, so you can change where it load by changing the ORG statement.The code uses &8A..&8F, &28 (BASIC OPT value - should probably change this to &F9) and &F8 (unused by OS1.2) temporarily while drawing.To change to the 16 sets of graphics modes (x 4 offsets x odd/even sets) change SPRITES to &1800

There is quite a lot of talk here for less than 300 bytes of code, but hopefully it won't put anyone off.

I have tried to explain the minimum so that anyone wanting to use this will learn a little to use it and hopefully have more success for it.

If anyone has any questions, even if you have no intention of ever using this code, please ask away, it will save someone else asking

I developed AGD on the Spectrum and did the CPC conversion too. While a conversion of AGD might be more than a little optimistic, I'd be happy to provide any assistance I can if it would help. If there are ideas that can be used/adapted on Acorn machines to develop a game development tool, I'd gladly share Speccy/CPC source or contribute ideas/suggestions.

Obviously, the core of any game development tool is the sprite engine - and it seems you already have something pretty neat here. After that a user needs to be able to define a sprite's behaviour. In AGD I provided a simple scripting language which was designed so that each command would translate into very simple sequences of Z80 instructions. Everything was kept simple, so no complex expression evaluation. A simple COBOL 74-style ADD 5 to B, DIVIDE X BY 8 etc was sufficient. No labels, no GOTOs, no subroutines. AGD's engine went through the sprite table and had a look-up address table of compiled scripts to call for each sprite type to move it around. I don't know if something along those lines would be part of the grand plan for this project? Combine it with a character editor and a screen editor and you'd be onto a winner...

I would be happy to support someone doing this and chip in with help and bits of code, but the whole thing isn't something I have enough enthusiasm for.I seem to remember someone porting some of this or something similar a couple of years ago, on here or on RS.Thanks for the offer, I'm sure there are people on here who would love to use your tool on a beeb. I love doing the "tricky" bits, but loose enthusiasm once they are done.