Using CPC+ hardware sprites from BASIC?

[mr_lou]

Been feeling like looking into a BASIC game recently, but too lazy to do all the sprite routines.
Then I thought maybe I can use the hardware sprites of the plus models from BASIC?
Can anyone confirm or reject that? Easy? Difficult?

Alternatively, can someone point me to a very simple RSX sprite routine that works in MODE 1?

[Morri]

I can't help on the PLUS side but for the standard CPC's I have also had the interest of writing BASIC games using RSX sprite routines to spruce them up.
I decided to write different games using different routines so hopefully my experiences can help you out.

Sprites Alive Basic (used to write Eternal Light) - Extends BASIC with over 70 RSX commands to help deal with sprites, collision and movement. I found SA very easy to use with a very simple, easy to follow manual. Biggest problems I encountered were space issues, I think I started running out of memory after 6kb of BASIC and the sprite collision could be a bit hit and miss. The sprite editor is excellent and very easy to use. I think you have to compile the sprites once you're ready to use them but it wasn't that big of a deal. Overall, a very good starting point.

Sprites Alive Compiler (used to write Eternal Light 2) - This one was a little more complicated to use then I initially thought going in. SAC changes alot of BASIC to make it machine code compilable. You still have access to most of the original SA's commands (with only a few tweaks) but again the manual for it is very well written and easy to follow. You have alot of rules to follow that you would normally get away with in standard BASIC but they are workable (i.e. the use of labels instead of numbers for GOTO and GOSUB, GOTO label instead of GOTO 10). Big issue is having to compile your BASIC program (which must be saved as an ASCII file) every time you want to test it. Big advantage is the speed difference of having compiled your BASIC program into machine code. Also has a pretty good error checking routine for mistakes or syntax errors while compiling. I would recommend getting used to SA BASIC before tackling this.

Easy Sprite Driver / Sprite Definer - Written by Sean McManus, I am currently in the process of making a game using sean's sprite definer and driver. Simply draw your sprites with Sprite Definer (not as good as Sprite Alive's editor but it does the trick), load into memory and call with a simple RSX command. Very simple and easy to use. You have to do all the work with your BASIC skills and ESD simply places the sprite onto screen. Repeat the command in the same place to erase the sprite. EASY. Refer to Sean's webpage for instructions. Personally, this is where I would start from.

[CraigsBar]

Been feeling like looking into a BASIC game recently, but too lazy to do all the sprite routines.
Then I thought maybe I can use the hardware sprites of the plus models from BASIC?
Can anyone confirm or reject that? Easy? Difficult?

Alternatively, can someone point me to a very simple RSX sprite routine that works in MODE 1?

B-asic provides an RSX suite for the plus features including sprites.
http://www.cpcwiki.eu/index.php/B-ASIC

[mr_lou]

B-asic provides an RSX suite for the plus features including sprites.
B-ASIC - CPCWiki

Thanks! Looks like this offers what I'm looking for, and a lot more.
I'll take a closer look at this. 

[mr_lou]

Ok

I always prefer that my creations works on as many devices as possible, which is why I also looked at standard CPC sprite options.
BUT... this idea I have is a 4-player game.
And it seems that people generally agree that the standard CPC isn't suitable for multiplayer games. We can connect 2 joysticks, and if the adapter is using diodes there shouldn't be any clash here, right?
But I'll need 2 additional control inputs, also preferably with joystick, and that doesn't seem to be possible. Or what?
Can someone tell me, if it's definitely possible without a hassle to get 4-player input on a standard CPC464 while avoiding keyboard/joystick clash?

Anyway, the clash issue is currently the main reason I'm looking at B-asic. I'm sad that B-asic seems to acquire 128kb though, since that rules out the GX4000 (if I manage to create this idea).
But maybe it's possible to compile a smaller version of B-asic without the functionality that I end up not using, and thus make my game runnable on 64kb machines?

I'm also spotting something else: As far as I can see, B-asic doesn't give me some way of accessing analog joystick input. Can anyone give some input here? Am I missing something? Is there another way of getting analog joystick input?

Arnoldemu said in an older thread that theoretically, the analog joystick port should be split-able too, resulting in actual 4 joysticks connected to the CPC+. Can anyone confirm or reject that?

Isn't it about time the CPC has some 4-player party games? 

[CraigsBar]

Yes indeed. 4 player games are fun lol. I wish you every success in this project.

[dthrone]

Via the 4 ports (2 x digital, 1 x analogue, 1 x aux) you've got access to 12 digital inputs and 4 analogue inputs.  So you could share these between multiple joysticks, or even make something like a dual-stick flight-sim cockpit controller, or whatever your imagination can come up with    I don't know if what clashes, if any, has been resolved yet.

[arnoldemu]

It's a little complicated.

On the PLUS:

You have two digital joysticks. They don't clash with each other so can be used together. They don't clash with keyboard.
BUT, the digital joysticks and analogue joysticks share the fire buttons!

So in reality you can do this (if you need fire):
2 digitial joysticks + keyboard
1 digital joystick + 1 analogue joystick + keyboard

if you don't need fire:

2 digital joysticks + 2 analogue  joysticks + keyboard.

Now the ASIC documents state that more than 1 analogue joystick is supported AND my emulator does support that. But I think you need a splitter to use two.
I never made one so I never tested it.


On the CPC:

You can have two digital joysticks using a splitter. But you need to add diodes to stop them clashing. Normally joysticks will clash with each other and the keyboard.

if you want to use 1 digital joystick, your choice of keys is severly limited to avoid clashing with keyboard.

EDIT: My WIP of Arnold emulates 2 digital joysticks and 2 analogue joysticks. In CPC mode, it emulates the clash too.

[mr_lou]

You have two digital joysticks. They don't clash with each other so can be used together. They don't clash with keyboard.
BUT, the digital joysticks and analogue joysticks share the fire buttons!

Thanks. Good answer. I guess that means I can forget about using the analog port in regards of getting multiple joysticks connected.

Another idea is to have a 4-player adapter built, similar to what the C64 users have.
The joystick talk can continue in this thread.

Back to B-ASIC.
If I manage to create a game using B-ASIC, is it possible to slim it down stripping the functionality I'm not using, in order to make my game run on 64kb machines?

[arnoldemu]

Thanks. Good answer. I guess that means I can forget about using the analog port in regards of getting multiple joysticks connected.

Another idea is to have a 4-player adapter built, similar to what the C64 users have.
The joystick talk can continue in this thread.

Back to B-ASIC.
If I manage to create a game using B-ASIC, is it possible to slim it down stripping the functionality I'm not using, in order to make my game run on 64kb machines?

Looking at B-ASIC, later versions are specifically written for 128KB, there are earlier versions which are made for 64KB machines.
Stripping it down would be more trouble without the source, or a dissassembly converted into source.

Could you use an earlier version?

EDIT: I think it's pre 3.2, but I can't be sure.

[mr_lou]

Could you use an earlier version?

Possibly. Thanks, I'll see if an earlier version is sufficient for my need.

[CraigsBar]

Possibly. Thanks, I'll see if an earlier version is sufficient for my need.

When adding plus palette pictures etc to my cart loaders I found that only 1.x would work reliably in 64k and they severely limit the available ram. In the end I reverted to CPC modes and colours for those. I am sure someone with more coding ability could make better use of the 64k than me. I was using half of it for 2 screens, a large chunk more for 2 soundtrakker tunes leaving not much for my basic code.

Craig

[mr_lou]

Should probably be asked in a new thread, but trying here first:

I've read that you can use 15 colours + transparent for the sprites on top of the 16 colours used for the other graphics.

Does anyone know whether hardware sprites offers 15 colours in MODE 1 resolution too?
I'm assuming of course, that I still only have 4 colours available for other graphics, but does the hardware sprites give me 15 colours in MODE 1, or just 3+transparent?

[andycadley]

Should probably be asked in a new thread, but trying here first:

I've read that you can use 15 colours + transparent for the sprites on top of the 16 colours used for the other graphics.

Does anyone know whether hardware sprites offers 15 colours in MODE 1 resolution too?
I'm assuming of course, that I still only have 4 colours available for other graphics, but does the hardware sprites give me 15 colours in MODE 1, or just 3+transparent?

Sprites are independent of mode. They always have 15 colours + transparent (and a separate 15 colour palette from the main display). The pixels in a sprite are Mode 2 sized, but you can use x2 horizontal magnification to get Mode 1 size or x4 for Mode 0 sized. You can also use x2 and x4 magnification vertically to get even larger pixels.

[mr_lou]

Sprites are independent of mode. They always have 15 colours + transparent (and a separate 15 colour palette from the main display). The pixels in a sprite are Mode 2 sized, but you can use x2 horizontal magnification to get Mode 1 size or x4 for Mode 0 sized. You can also use x2 and x4 magnification vertically to get even larger pixels.

Wow.... 15 colours in MODE 2 resolution??? That's freakin' awesome!
That sounds very intriguing. 
Thanks. Will soon need to make up my mind whether to do this game with old-skool software sprites, or CPC+ hardware sprites. I suspect I will go with the hardware sprites though, due to speed. 
But might be trying with software sprites first...

[CraigsBar]

I am really looking forward to this. Hardware sprites and 64k so it works on the gx4000 would be awesome.

[mr_lou]

I am really looking forward to this. Hardware sprites and 64k so it works on the gx4000 would be awesome.

Yes, that would be awesome.
But if I use B-ASIC, it may not run on 64kb machines, since B-ASIC requires 128kb.
Earlier versions of B-ASIC only requires 64kb. I have to figure out if I can settle for an earlier version.
Otherwise, maybe one of the other coders could help me by creating another set of limited RSX commands. I don't think I need all of what B-ASIC is offering.

But I think we will start out trying software sprites targeting the standard CPC range. If that turns out to be too slow, then we'll go with hardware sprites and thus targeting the plus machines of course.
(Then, if the game should become popular, someone else much more hardcore than me could probably port it for the standard CPC range, in that we'd already have the graphics ready).

[TFM]

Forget 64KB - Welcome in 128 KB world! 

[andycadley]

Yes, that would be awesome.
But if I use B-ASIC, it may not run on 64kb machines, since B-ASIC requires 128kb.
Earlier versions of B-ASIC only requires 64kb. I have to figure out if I can settle for an earlier version.
Otherwise, maybe one of the other coders could help me by creating another set of limited RSX commands. I don't think I need all of what B-ASIC is offering.

It does seem to have gained a lot of functionality over and above what I remember (and even back in the day had rather more than seemed necessary).

I'm sure it wouldn't take much to do a "bare minimum" set of RSXs. Though I'd have to remind myself of the tricks to stop the firmware getting in the way.

[CraigsBar]

Forget 64KB - Welcome in 128 KB world! 

Boooo... If you are using Hardware sprites, now that the C4CPC exists, targetting only the 6128+ seems harsh. I am sure a well written card release can be quite spectacular using the ROM for storage of sprites, backdrops etc, so the 64k is not as much of a limit as it would otherwise be, or have I completely misunderstood the cart concept?


Craig

[andycadley]

Boooo... If you are using Hardware sprites, now that the C4CPC exists, targetting only the 6128+ seems harsh. I am sure a well written card release can be quite spectacular using the ROM for storage of sprites, backdrops etc, so the 64k is not as much of a limit as it would otherwise be, or have I completely misunderstood the cart concept?

It should easily be possible to do as good, if not better, than 128K games using cartridges. Probably not if you're writing them in BASIC and using a disk rom hack to access the cartridge, but then that's hardly surprising. And, as I've said many time before, the Plus hardware doesn't actually play well with the way banking works on the 128 machines. When you program for it, it's very obviously been geared around the way the cartridge ROM paging works, with very little consideration for 6128+ only software (presumably because that was never really meant to be a thing)

[TFM]

Boooo... If you are using Hardware sprites, now that the C4CPC exists, targetting only the 6128+ seems harsh. I am sure a well written card release can be quite spectacular using the ROM for storage of sprites, backdrops etc, so the 64k is not as much of a limit as it would otherwise be, or have I completely misunderstood the cart concept?
Craig

Depends... when using overscan and two screens, then 64 KB is not much.


However my comment targeted at the B-ASIC Software, which needs 128 KB.