Sprites that can be used from BASIC

[tricky]

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).

[FourthStone]

If you build it, they will come

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.

[daveejhitchins]

Yes, I'd like to see a tutorial dealing with sprite/graphics etc. It's one thing I've had no experience with - in BASIC or m/c.

Dave H

[lurkio]

Yes, please!

[SimonSideburns]

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.

[lurkio]

There is a program for the ZX Spectrum called AGD - Arcade Game Designer.

Speaking of game tools, does anyone know anything about GOAL -- the Graphic Oriented Arcade Language -- supposedly created by Neil Raine of Acornsoft, author of several arcade games for the Beeb?

I recently found a reference to GOAL in an issue of Laserbug magazine:

Extract from Laserbug magazine mentioning GOAL by Neil Raine

EDIT: Arcadian has tipped me off that GOAL is mentioned in the Acornsoft Reunion Abug video, about 1hr 13mins in:

http://abug.org.uk/index.php/2020/09/05 ... t-reunion/

So GOAL did exist! Its name might actually have stood for Games Oriented Animation Language, but it looks like it was indeed created by Neil Raine and used by him to write Hopper and the unreleased game Bandit. Thanks, Arcadian!

[tricky]

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.

[tricky]

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 :

Code: Select all

beebasm.exe -i game.asm -do game.ssd -opt 3

N.B. OUTBASIC doesn't seem to support . abbreviations.

[FourthStone]

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

[tricky]

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.

[Dethmunk]

Yes there would be interest.... definitely.

As Simonsideburns mentions AGD is a great piece of software and I've been able to write 2 games so far. 1 is finished and can be found on my website...
http://johnblythe5.wixsite.com/rucksackgames/foggy


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.

[Dethmunk]

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.

Anyway thats my 2p. Thats the dream.

[tricky]

I have tidied things up a bit and here is the basic program which does all setup and demos the sprites and some assembler that when run through beebasm generates an .ssd ready to run the demo.

Code: Select all

beebasm.exe -i game.asm -do game.ssd -opt 3

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.

Code: Select all

tga2equb.exe -cols:KRYW -sprites:800 sprites800.tga -sprites:1800 sprites1800.tga

-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:WHITE
I 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.

Code: Select all

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

[tricky]

OK, fixed one line in tga2equb to stop an erroneous error message.

Code: Select all

		else if (4 == colc && index(col0) >= 0 && index(col1) >= 0 && index(col2) >= 0 && index(col3) >= 0)

Added else!

Added mode 4 to the demo, so it plays a bit and then swaps to the mode 5 one.

To run the sprites at full speed, change the 7 to a 2 in

Code: Select all

190   FOR z%=0 TO 7

With this, the sprites take less than a quarter of a frame and BASIC the rest!

[JonathanC]

This is exciting!

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...

Just a few thoughts from a Spectrum (and occasional CPC) developer.

[tricky]

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.

[sydney]

I'd thought about doing something like this last year but decided not to as I'm a bit of a novice myself. However, with some guidance from both Jonathan and Richard maybe it'd be doable.

[BigEd]

Bump! Did anyone have a go with tricky's sprite library? Looks like it should take a load off the budding Basic games programmer.

[tricky]

If anyone wants to use this, I'm happy to make some tweaks and help if I can.
The idea is that you get 8 mode 4 or 5 sprites which you can set the position of our hide.
For something like space Invaders, you would need your ship, your shot and up to three Invader bombs (I think). Only one alien moves per frame, so that could just be done with user defined graphics and print.
Pacman is for ghosts and you, plus the fruit for Ms Pacman.
You can just put sprites next to eachother for less but larger sprites.
If you are careful, you can make the animation take no extra memory like the Pacman example.

[sydney]

I've not properly reread the thread yet so this might be a dumb question. Is the reduced width screen mode a requirement? If so is the operation of 'PRINT' affected by this? Not a huge problem but something to bear in mind.

edited to clarify PRINT question.

[sydney]

So I've had a little play around with this for a couple of hours today and I present my first BASIC game : Fruit Muncher!
It's rubbish but shows how easy Trickys work has made writing a game in BASIC.
I have a pile of questions and ideas for Tricky but I'm busy for the next few hours.

Edited to add the aim of the game is to collect as many apples as you can in 30 seconds, though the timing seems to be out - I have questions about that too!

[tricky]

1200, good game for such a quick turn-a-round.
Good point about printing too!

It uses the smaller screen as an optimisation and so that X fits in 256 for MODE 4!
I can't remember if there is a hack to make print work, but full screen MODE 5 would be fine.

The other part of the project was the character mapped bit where the screen is 32x32 characters and changing 1 bytes makes that character change. This is how many of the early arcade games work. Circus for example has only one sprite, which is the clown and everything else is characters. It has pairs of characters where a balloon move from one to the next, before going back to the original pair but moved over by one.
This is OK for my ports/emulators where that is how the game has to work, but a bit of a waste as it has to scan all 1024 characters every frame.

I could add a print that could be optimised for MODE 5.

The sprites work by EORing, and the print could too.

[sydney]

There are so many questions, comments and ideas floating around in my head UI don't where to start and don't want to dump a screenfull of questions at you all at once.

Question 1:

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).

X% and Y% I get, Z% and ?N% I'm unsure of.
Actually, after rereading a few times, I think I may have them:
Is N%:

Code: Select all

Y%?N% = 0  (sprite N off)?

Is Z% this:

Code: Select all

Z%?1 = 1 (use frame 1 of sprite 1's frames)?

Question 2:
Could you post an example or describe how to use the character mapping of the screen?

Question :3
Changing the graphics. I need to create a TGA and use the TGA2equb program to produce a .equ file which I then 'assemble' into the sprite data file using beebasm? Is that correct?

Question 4:
There are two modes of use as follows?
1: 5 sprites, 8 frames each
2 16 sprites, 8 frames each
In the example program SPRITES = &800 and there seems to be 8 sprites.

Question 5:
As I found out changing mode wipes the sprite data stored in the screen memory saved by reducing the screen size. This means reloading the sprite data every time you use another mode. Is there any way around this by programming the CRTC to preserve the data meaning MODE 7 could be used for Attract screens/Menus/High score tables?

That's 5 questions to start with and is probably enough for now.
Before having a play with this I thought it looked really good, now I think it is brilliant and could be a very easy route for budding games programmers to get started. What I've written there is well on the way to being what my 'Happy Mrs Chciken' game was and it only took me a couple of hours, compared to weeks using assembler.
Had something like this been available back in the day I'm sure there would have been hundreds of games written with it.

[RobC]

Great stuff - would be good to have a run through of this on one of the Dev nights if possible.

It uses the smaller screen as an optimisation and so that X fits in 256 for MODE 4!
I can't remember if there is a hack to make print work, but full screen MODE 5 would be fine.

I'm sure there is at least on the B & B+. It's used in the overscan demo on the GLM8 disk from GLM PD.

It sets &352 and &353 to the number of bits per line (e.g. 512) and then sets &30A to (number of horizontal characters -1). So that would need to be 31 in mode 4 and 15 in mode 5.

It also sets up a table for the row multiplication (so by 512 rather than 640 in your case) and sets &E0 and &E1 to point to the revised table.

I believe MOS 3.2 doesn't use a multiplication table so it might not be possible on the M128. Although you could presumably just adjust the print coordinates yourself?

[tricky]

It should be no problem to make it full screen and probably mode 5 only as that required only half the frames for horizontal movement.
I've got the afternoon off, so will give this a bit of love, probably including adding some sort of print for single and multiple characters.
I was also thinking of having a swap modes without clearing the screen, but that would probably confuse basic.

[tricky]

I've been having a bit more of a think and think that I need to do a bit more thinking

Most of this is how it is now!

I want there to be enough to use without eating all the memory!
How does 8 sprites that can be any height, but are between 9 and 12 mode 5 pixels wide sound?
8 is just a nice number, 9 pixels if they move horizontally, but 12 if they only move vertically.
If they are too big, there will certainly be tearing/flicker. (too big is yet to be calculated)
Sprites are EORed on and off to avoid ordering and clearing issues.
Sprite positions are specified from top left of screen in pixels, but bottom left of sprite, Height=0 is off.
If PAGE is at &5400 instead of MOIDE 5's usual &5800 (-1KB) then that gives a grid of:
256 pixels high and four columns of 12 pixels wide, where the column is chosen using the bottom two bits of X.
This column indexing means that you have the four pixel offsets in the four columns.
I was also thinking of making the update user requested, but actually happen on vsync.
The timing would be: REP., app updates positions etc, ?flag=1 (start updating), update game, REP.WHILE?flag, UN.0.
Sprites sets ?flag to 0 when complete - so can also be used like a *FX 19 for throttling game.

It should probably have print/draw routines and a CLS too. I'm not sure about the MODE 7 bit, but as someone pointed out, change the X,Y and the usual PRINT should work.

[sydney]

I've been thinking about this a lot too.
I think 8 sprites is plenty. 8x16 mode 5 pixels is good, bigger would be useful but not necessary.
I'm quite happy with the current 128x256 screen size but if you think otherwise just go with what you think.

One problem that may hinder the use of this is the reliance on beebasm. Would it be possible to produce a self contained file, like *DISPLAY on your DEMO ssd, which would supply all the functions, have a small loader program to setup the screenmode, load sprite data, run *DISPLAY and set up and any needed variables.
Something like this:

Code: Select all

1 REM - LOADER FOR TRICKY'S SPRITE LIBRARY
10 H%=&0000
20 X%=&FF0380
30 Y%=&FF0390
40 Z%=&FF03A0
50 V%=&FF09DB
60 U%=&FF09E0
70 DATA 63, 32, 45, &24, 38, 0, 32, 34, &C0, 7, &C0, 8, &60/8, &00/8
75 MODE 5  
80 FOR x%=0TO13
90    READ y%
100    VDU 23;x%,y%,0;0;0;
110 NEXT
120 *LOAD SPRITES
130 *DISPLAY
140 CHAIN"GAME"
 

The users program would go into the GAME file and no setup would be needed. All that would be needed then is to create the sprite file which could be done by adapting your tga2equb program then using a utility or beebem to move it to the ssd.
I'd be interested in writing a beeb based sprite editor (already halfway there in my head!).

If 8 sprites have 8 frames that is 64 frames. Would it be possible for any sprite to display any frame? At the moment Z%?x points to the frame where x is between 0 and 7, could that become between 0 and 63?

If there are print and cls routines I'm not too fussed on mode 7 or any other mode change being supported.

Another possibility I was thinking about was utilising sideways ram. Would it be possible to produce a ROM designed to be loaded into sideways ram which could then use the remaining space to load the sprite data into. This would leave plenty of memory for the BASIC program.

[nicolagiacobbe]

since we spoke about AGD, what about WinAGD? Could it be used with tricky's routines?

[oss003]

Tricky,

AGD erases one horizontal line of the old sprite and then draws a horizontal line of the new sprite until all lines are done. This reduces flickering to max 1 hor. line which is barely visable.

Greetings
Kees

[tricky]

But you still get treating.
It would be fairly easy to do the same but as extra code for hiding and showing the sprite. It may also have changed size, which would complicate things.
I can't remember how many of the sprites fit into the vertical blank, but it should be most of them.

128x256 saves quite a bit of code.
You shouldn't need beebasm, but I'll check.
The sprite format will be vertical stripes of 256 bytes, column order to be decided.