Sprites that can be used from BASIC

developing/porting a new game or gaming framework? post in here!
User avatar
tricky
Posts: 4779
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Sprites that can be used from BASIC

Post by tricky » Sun Feb 12, 2017 2:10 pm

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).
Last edited by tricky on Thu Oct 08, 2020 9:57 pm, edited 1 time in total.

User avatar
FourthStone
Posts: 1045
Joined: Thu Nov 17, 2016 2:29 am
Location: Brisbane, Australia
Contact:

Re: any interest in a character display with sprites?

Post by FourthStone » Sun Feb 12, 2017 9:47 pm

If you build it, they will come :o

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.

User avatar
daveejhitchins
Posts: 5998
Joined: Wed Jun 13, 2012 6:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: any interest in a character display with sprites?

Post by daveejhitchins » Mon Feb 13, 2017 10:09 am

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 :D


User avatar
SimonSideburns
Posts: 576
Joined: Mon Aug 26, 2013 9:09 pm
Location: Purbrook, Hampshire
Contact:

Re: any interest in a character display with sprites?

Post by SimonSideburns » Mon Feb 13, 2017 10:41 pm

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.
Just remember kids, Beeb spelled backwards is Beeb!

User avatar
lurkio
Posts: 3026
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: any interest in a character display with sprites?

Post by lurkio » Mon Feb 13, 2017 11:27 pm

SimonSideburns wrote: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:

WhatsApp Image 2017-02-10 at 22.29.48.jpeg
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!
Last edited by lurkio on Wed Oct 28, 2020 1:28 pm, edited 1 time in total.

User avatar
tricky
Posts: 4779
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: any interest in a character display with sprites?

Post by tricky » Tue Feb 14, 2017 9:54 am

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.

User avatar
tricky
Posts: 4779
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: any interest in a character display with sprites?

Post by tricky » Thu Feb 16, 2017 8:34 pm

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.
Attachments
sprite_demo.zip
(4.98 KiB) Downloaded 99 times

User avatar
FourthStone
Posts: 1045
Joined: Thu Nov 17, 2016 2:29 am
Location: Brisbane, Australia
Contact:

Re: any interest in a character display with sprites?

Post by FourthStone » Sun Feb 19, 2017 10:22 pm

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 :oops:

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 :D

User avatar
tricky
Posts: 4779
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: any interest in a character display with sprites?

Post by tricky » Sun Feb 19, 2017 11:13 pm

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.

User avatar
Dethmunk
Posts: 220
Joined: Fri Jul 01, 2016 1:29 pm
Location: Guildford
Contact:

Re: any interest in a character display with sprites?

Post by Dethmunk » Thu Feb 23, 2017 1:51 pm

Yes there would be interest.... definitely. :D

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
Image

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. :D
Image

User avatar
Dethmunk
Posts: 220
Joined: Fri Jul 01, 2016 1:29 pm
Location: Guildford
Contact:

Re: any interest in a character display with sprites?

Post by Dethmunk » Thu Feb 23, 2017 2:11 pm

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. :D
Image

User avatar
tricky
Posts: 4779
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: any interest in a character display with sprites?

Post by tricky » Thu Feb 23, 2017 8:52 pm

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 :D
Attachments
Graphics.zip
The two TGAs used to make the sprites
(2.36 KiB) Downloaded 60 times
Demo.zip
Source for demo + prebuilt .ssd
(7.17 KiB) Downloaded 66 times
Converter.zip
All the source, project and solution file for tga2equb
(8.93 KiB) Downloaded 52 times
tga2equb.exe.zip
Prebuilt TGA converter in .EXE format
(50.61 KiB) Downloaded 44 times

User avatar
tricky
Posts: 4779
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: any interest in a character display with sprites?

Post by tricky » Fri Feb 24, 2017 9:17 pm

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.
ImageImage
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!
Attachments
sprites.png
sprites.png (1.06 KiB) Viewed 3182 times
pacmania.png
pacmania.png (1.55 KiB) Viewed 3182 times
Sprites4.zip
mode 4 sprites TGA with .equ
(2.84 KiB) Downloaded 57 times
Sprites.zip
updated source and demo .ssd
(7.36 KiB) Downloaded 85 times
tga2equb.exe.zip
new version of the converter EXE
(50.62 KiB) Downloaded 57 times

User avatar
JonathanC
Posts: 4
Joined: Sun Feb 26, 2017 6:12 pm
Location: Nottingham
Contact:

Re: any interest in a character display with sprites?

Post by JonathanC » Mon Mar 06, 2017 11:14 pm

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.

User avatar
tricky
Posts: 4779
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: any interest in a character display with sprites?

Post by tricky » Tue Mar 07, 2017 7:13 am

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

User avatar
sydney
Posts: 2732
Joined: Wed May 18, 2005 10:09 am
Location: Newcastle upon Tyne
Contact:

Re: any interest in a character display with sprites?

Post by sydney » Tue Mar 07, 2017 9:55 am

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.

User avatar
BigEd
Posts: 3530
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

Re: any interest in a character display with sprites?

Post by BigEd » Tue Sep 29, 2020 8:43 pm

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

User avatar
tricky
Posts: 4779
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: any interest in a character display with sprites?

Post by tricky » Wed Sep 30, 2020 9:09 am

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.

User avatar
sydney
Posts: 2732
Joined: Wed May 18, 2005 10:09 am
Location: Newcastle upon Tyne
Contact:

Re: any interest in a character display with sprites?

Post by sydney » Wed Sep 30, 2020 9:39 am

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.

User avatar
sydney
Posts: 2732
Joined: Wed May 18, 2005 10:09 am
Location: Newcastle upon Tyne
Contact:

Re: any interest in a character display with sprites?

Post by sydney » Wed Sep 30, 2020 5:09 pm

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!
Attachments
game.ssd
(12.5 KiB) Downloaded 18 times

User avatar
tricky
Posts: 4779
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: any interest in a character display with sprites?

Post by tricky » Wed Sep 30, 2020 5:43 pm

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.

User avatar
sydney
Posts: 2732
Joined: Wed May 18, 2005 10:09 am
Location: Newcastle upon Tyne
Contact:

Re: any interest in a character display with sprites?

Post by sydney » Wed Sep 30, 2020 9:14 pm

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
Posts: 3009
Joined: Sat Sep 01, 2007 10:41 pm
Contact:

Re: any interest in a character display with sprites?

Post by RobC » Wed Sep 30, 2020 11:18 pm

Great stuff - would be good to have a run through of this on one of the Dev nights if possible.
tricky wrote:
Wed Sep 30, 2020 5:43 pm
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?

User avatar
tricky
Posts: 4779
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: any interest in a character display with sprites?

Post by tricky » Thu Oct 01, 2020 12:36 pm

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.

User avatar
tricky
Posts: 4779
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: any interest in a character display with sprites?

Post by tricky » Thu Oct 01, 2020 2:13 pm

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.

User avatar
sydney
Posts: 2732
Joined: Wed May 18, 2005 10:09 am
Location: Newcastle upon Tyne
Contact:

Re: any interest in a character display with sprites?

Post by sydney » Thu Oct 01, 2020 3:17 pm

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
Posts: 14
Joined: Tue Jul 03, 2007 10:40 am
Location: italy
Contact:

Re: any interest in a character display with sprites?

Post by nicolagiacobbe » Thu Oct 01, 2020 3:36 pm

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

User avatar
oss003
Posts: 3399
Joined: Tue Jul 14, 2009 12:57 pm
Location: Netherlands
Contact:

Re: any interest in a character display with sprites?

Post by oss003 » Thu Oct 01, 2020 5:50 pm

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

User avatar
tricky
Posts: 4779
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: any interest in a character display with sprites?

Post by tricky » Fri Oct 02, 2020 9:02 am

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.

Post Reply

Return to “new projects in development: games”