what should i write next?

[Beebson]

Thank you for the tip about timing bars in B-Type demo. If those bars will go near the bottom, does that mean really heavy use of cpu time?

Could you please explain, how that MODE 2 version that uses the 3 foreground, 4 background colour palette trick was done? I can see 4 colour
on the background and 3 for the sprites. As MODE 2 has 8 colours + flashing ones, it doesn´t need any tricks to get 7 colours. So it looks like MODE 5 tricked to draw the background, then to switch different palette and draw the sprites and then switch back to background colour on the next frame, etc..

40 years ago.... it was autumn ´82 back then. And you did that trick even before that.... the BBC was only just gone for sale few months earlier back then...!

In your latest demo, Jacks are looking great, as they have a nice contrast against background, btw..

[Beebson]

Of course, it could be MODE 1, have sprites that you could tell what they were, still mode 2 pixels per frame, but may flicker occasionally on later levels!

Anybody please, if you could post a demo or a link to a game video showing an example how that flicker will look like, thank you. Some sprite flicker will not scare me easily.

[RobC]

Could you please explain, how that MODE 2 version that uses the 3 foreground, 4 background colour palette trick was done? I can see 4 colour
on the background and 3 for the sprites. As MODE 2 has 8 colours + flashing ones, it doesn´t need any tricks to get 7 colours. So it looks like MODE 5 tricked to draw the background, then to switch different palette and draw the sprites and then switch back to background colour on the next frame, etc..

One way to think about this idea is to consider exclusive-OR (EOR) plotting and un-plotting. This would usually create "artefacts" where the foreground sprites overlap different background colours. However, if you partition the 16 logical colours in mode 2 into four blocks of four and then set up the palette so that plotting sprites generate the same colours irrespective of the background colour you are plotting over. This scheme gives you four background colours and 3 foreground/sprite colours (plus one "mask" colour).

One way to do this would be to set the palette up as follows:

Code: Select all

Logical colour		Physical colour
0			Background 1
1			Background 2
2			Background 3
3			Background 4
4			Foreground 1
5			Foreground 1
6			Foreground 1
7			Foreground 1
8			Foreground 2
9			Foreground 2
10			Foreground 2
11			Foreground 2
12			Foreground 3
13			Foreground 3
14			Foreground 3
15			Foreground 3

There are other better/more sophisticated ways of doing this but it explains the basic idea.

[paulb]

Could you please explain, how that MODE 2 version that uses the 3 foreground, 4 background colour palette trick was done? I can see 4 colour
on the background and 3 for the sprites. As MODE 2 has 8 colours + flashing ones, it doesn´t need any tricks to get 7 colours. So it looks like MODE 5 tricked to draw the background, then to switch different palette and draw the sprites and then switch back to background colour on the next frame, etc..

One way to think about this idea is to consider exclusive-OR (EOR) plotting and un-plotting. This would usually create "artefacts" where the foreground sprites overlap different background colours. However, if you partition the 16 logical colours in mode 2 into four blocks of four and then set up the palette so that plotting sprites generate the same colours irrespective of the background colour you are plotting over. This scheme gives you four background colours and 3 foreground/sprite colours (plus one "mask" colour).

What RobC is saying is that you have the colour encoded as follows for each pixel:

Code: Select all

Bits:    3210
Purpose: FFBB

Where bits marked F are used to indicate foreground colours and B for background colours. If F is zero, it is effectively transparent, yielding the background. Otherwise, F yields a foreground colour. So...

Code: Select all

Bits:    3210
Value:   0011 -> yields 11 (3) for background
Value:   0111 -> yields 01 (1) for foreground

Now, your background tiles or graphics will be written to the screen with the F bits set to zero. For example:

Code: Select all

Bits:    3210
Value:   0011 -> yields 11 (3) for background
Value:   0000 -> yields 00 (0) for background

Meanwhile, sprites will have their B bits set to zero. For example:

Code: Select all

Bits:    3210
Value:   1100 -> yields 11 (3) for foreground
Value:   1000 -> yields 10 (2) for foreground

If you use EOR to plot sprite data, combining it with the existing screen data, the result will be to combine the two different sets of bits:

Code: Select all

Bits:    3210
B:       0011 -> background 11 (3)
F:       1000 -> foreground 10 (2)
B EOR F: 1011 -> yields 10 (2) for foreground

Of course, that is the plan, but to turn it into reality, you need to assign palette entries implementing this scheme. That means going through each of the sixteen pixel values (logical colours) and assigning an actual colour (physical colour) to it.

Since the background colours only show through when the F bits are zero, we define them as the palette for the first four values: 0000, 0001, 0010, 0011.

For the foreground colours, we then go through the remaining twelve pixel values (0100, 0101, ..., 1111), considering only the F bits and defining the appropriate colours for the four distinct values of those F bits. If you look through RobC's table, that is what he is doing.

Hope this was somewhat clear!

[RobC]

Thanks paulb - that explains the concept.

On the number of colours, although you have fewer colours available (7 rather than 16), 8 of the 16 colours available in mode 2 are flashing and are often not used [unless you've got a NuLA ]. By sacrificing these colours, you can use quick plotting and un-plotting (using EOR or other logic instructions) and not have any artefacts on screen.

Many mode 2 Beeb games used this trick or ones like it. Firetrack is an example of a game that used the four background/3 foreground scheme. I think Killer Gorilla and Match Day used a two background/7 foreground scheme (to prevent artefacts when moving over ladders or pitch markings).

[Grasshopper]

Many many years ago, when I used to experiment with writing simple games on my BBC B, I got good results by combining XOR plotting with saving the sprite's background image before drawing the sprite.

What I'd essentially do is the following:

• Define the square on the screen where the sprite is to be drawn. I'll call this area A.

• Copy the contents of A to a temporary buffer, which I'll call B.

• Draw the sprite's image to area A on the screen, using a shadow mask if necessary.

• Now we need to work out what image would need to be applied to area A (using the XOR operator) to get back to what was in area A before the sprite was drawn. We'll store this image in another temporary buffer called C.
  
  So, essentially you're using the following equation to find C:
  
  A XOR C = B
  
  This can be rewritten as:
  
  C = B XOR A
  
  The buffer B can now be discarded. However, buffer C needs to be retained until the sprite is ready to be redrawn.

• When it's time to redraw the sprite, the old sprite image can be erased by updating area A as follows:
  
  A := A XOR C

Obviously, the above operations are applied on a per pixel (or byte) basis. However, I find it conceptually easier to consider everything in terms of complete images.

Despite saving a modified version of the background image in a temporary buffer, you are still essentially applying two identical XOR operations (one to draw the sprite, and one to erase it). So everything eventually comes out in the wash. This means the above approach still gives you two of the main advantages of traditional XOR plotting, which are as follows:

• The sprites can be redrawn in any order.

• Not every sprite necessarily needs to be redrawn every frame.

However, unlike traditional XOR plotting, you don't see XOR artifacts when sprites move over background objects.

Unfortunately, you can still potentially end up with XOR artifacts when sprites move over one another. This will depend upon the order in which the sprites are redrawn. However, in my experience, this is far less intrusive than the artifacts created by moving sprites over background objects.

[Beebson]

Thank you Rob C and paulb for great explanation! I understand it well, how clever and easy! I didn´t know one could use flashing colours for EORing, too, but yes, you can turn the flashing off. Thank you, Grasshopper, too! I will have to read your´s again later!

[paulb]

Thank you Rob C and paulb for great explanation! I understand it well, how clever and easy! I didn´t know one could use flashing colours for EORing, too, but yes, you can turn the flashing off. Thank you, Grasshopper, too! I will have to read your´s again later!

Technically, you just assign non-flashing colours to the colours that are normally flashing. So, instead of colour 8 appearing as flashing black/white, you define colour 8 to be one of the static colours.

You can also adjust the flashing colour timings and turn the flashing off as well, but all we are describing here is straightforward palette redefinition for the colours that normally flash. The Beeb and Electron user guides describe this in much more detail, but VDU 19 is the way into that topic, along with the notions of logical and physical colours, these respectively being the value of the colour in memory (logical colour) and the static or flashing colour in the palette that gets shown (physical colour).

[tricky]

Grasshopper, I might have missed your explanation, but it seems to me that when sprites do overlap you would be left with a permanent artifact, not a temporary one.

In White Light, Sarah took the 4+3 colours to a new height by storing the sprites in the same memory as the background and adding an and #&0F or and #&F0 to the drawing routines.

See her ABUG video for details and some of the other great tricks she used.

These sprites are quicker to erase than EORed ones as you can lda (),y: and #:sta (),y making them I think the second fastest to erase after just copying the background back.

The flickering that I was talking about is visible as bits missing in a sprite at 50fps and the same bits swapping between background and sprite at 50fps.

We can chat on next Thursday's dev ABUG of any one wants to.

[BigEd]

(Sarah's ABUG talk video) (I think!) (Also gets a mention in the Sprite Masking thread)

[Grasshopper]

Grasshopper, I might have missed your explanation, but it seems to me that when sprites do overlap you would be left with a permanent artifact, not a temporary one.

That shouldn't happen because ultimately, for each sprite, you're still XORing the same image to the same position on the screen twice - once to draw the sprite, and once to erase it.

The only difference with my technique, is that I'm essentially creating a custom sprite image on the fly that won't produce XOR artifacts when XORed to a particular position on the screen. The same customised image is used to erase the sprite, so ultimately there are no permanent artifacts left, even when two sprites overlap.

[tricky]

Sorry, yes, I see it now, nice trick, seems like I've seen it in a game somewhere, but not one of mine

[tricky]

Here is a demo with 16 sprites being ORed on and ANDed off whilst being flipped and mirrored on the fly.
The three on the right flicker from about halfway down for a bit - sorry, forgot who was asking to see some flicker!
This is after it has auto dropped the display to 25fps, although the game logic is still 50Hz.
If less were flipped or mirrored, it wouldn't flicker and if some were turned off, it would automatically go back to 50fps.

[tricky]

Had a bit more of a play with this.
In the end, I had to tile the graphics and compress the tile maps and gfx to fit it into the SWRAM/ROM (to make the gfx available to restore if something is changed. e.g. a bomb is removed in BombJack).
The .ssd just runs through the five levels decompressing the maps (the corruption at the tp of the screen, then draws the tiles, and tidies up before going on to the next and finally smearing some corrupt sprites down the screen!

[Beebson]

Great XOR´ing, Grasshopper, great explanation, too! Thank you, paulb, too, now I understand better.

It was I who asked for the flickering demo, thank you for showing that, tricky! This looks like the usual TI´s TMS-9929 flicker, I don´t mind that at all.

[tricky]

Great XOR´ing, Grasshopper, great explanation, too! Thank you, paulb, too, now I understand better.

It was I who asked for the flickering demo, thank you for showing that, tricky! This looks like the usual TI´s TMS-9929 flicker, I don´t mind that at all.

But I do

[Beebson]

Sure, if you can get rid of that flicker, I don´t mind that either.

[tricky]

There are a list of games that I keep coming back to, but don't think I can do them justice or am not really that enthusiastic about:

; Circus Charlie
; Kung-Fu Master
; Marble Madness
; Pole Position
; Q*Bert
; Robotron
; Spy Hunter
; Zoo Keeper
; Rampage
; Commando
; 194x
; Puzzle Bobble series (bust-a-move) etc
; Out Run
; SMB
; Track & Field / Hyper Sports
; Mario Bros.
; Pac-Land
; Dragon Buster
; Paper Boy
; Ghosts'N Goblins
; Gauntlet

I know someone was looking at Circus Charlie, but what about Track & Field?
I played this (on joystick in the arcades) until I injured my neck and still suffer the spasms to prove it!
I have done a mock up and think I could use the parallax scrolling code from Moon Patrol to make it smooth.
Arcade

arcade.png (7.99 KiB) Viewed 2613 times

Mockup which as it needs lots of interrupts and 6845 trickery to do the parallax, I might as well do some palette swapping.

mockup.png (7.64 KiB) Viewed 2613 times

As usual, my programmer art is very poor, but hopefully it shows what could be done although, the event name might have to go on the scoreboard at the top.
The colours could be made more palatable with NuLA support.

As usual, no promises, something else shiny may come along tomorrow! Tonight, I sat down to do some more B-Type (R-Type demo)!

[Rob_hawk]

Track and Field a big tick for me. Hours of fun playing this in the arcades of Southend on Sea when I was a kid and just about every holiday away with my parents. Fingers crossed nothing too shiny comes up soon

[tricky]

Sorry, I should have done some more maths first!

It looks like it would need to be Master or multi-load and I currently have a self imposed condition of having to run on the B, with one SWRAM bank and be a single load.
I may still do the first even as proof of concept, but it is suddenly looking less shiny and I'm remembering why it is still on the "not yet" pile!

Without the textured grass and track and keeping the man where he is, you could get probably a couple of events on a B, but then it wouldn't really look right as it is the parallax and moving grass and track that make it a challenge on the beeb.

Maybe I should just go finish Moon Patrol or work on B-type, but there are no "tricky" bits left on them
This is why I have been doing more ports lately as they are all tricky bits and then the game is finished!

[tricky]

I'm not sure about commando as we do have one.
Does dithering work?

The white lines demark a screen.
The palette would change where the top of the bridge is to swap yellow for green.
The grass is just a 2x2 pattern fill and would need some noise like the dirt to look less "programmery"!
This would also need to slow to 25fps when things get busy, or even not busy, as the sprites are really quite big!
I seem to have been lured in by the dithertron (although I didn't use it for this).
Maybe a VideoNuLA MODE 2 would work better, but after looking again at BombJack, I don't think I can do MODE 2, but maybe one day I will find a game that it works for me - maybe if I ever go back to Pac Land, but walking is 25fps judder (to me).

OOPS! I have just noticed that I have yellow in the same place as RGBand black, quick bodge to the image!

[tricky]

Promise, last dither for a while!
NES version.

[Cybershark]

what about Track & Field?

The Beeb was pretty well catered for in that regard, with both Hypersports and International Megasports available.
Also, would that not be like coding several games at once - what with all the different events?

Dithering looks fantastic on that Commando mock-up. The version we have is certainly on the bland-looking side!

Personally I'd much rather see something something fresh debut here, such as 194x or Puzzle Bobble. Have you considered working collaboratively? That would allow you to focus solely on the "Tricky" bits and then allow someone else to tie up the loose ends and apply polish

[tricky]

I didn't play much Beeb when I was younger, I mostly coded.
I would happily collaborate if there was anyone who liked polishing other people's code

[kieranhj]

Personally I'd much rather see something something fresh debut here, such as 194x or Puzzle Bobble.

I second these suggestions!!

[Beebson]

Tricky & Field, the track itself doesn´t have to move. If you erase all those dots from the tracks, you will have to scroll just the distance numbers 10.......20.......30.......40.......etc....... plus the audience. The looks of the tracks is not the exactly same without the dots but you can go no wrong by using just plain red tracks with white lines.

Your commando mock ups are looking just great, but please check them on real television and monitor. I am not sure if that amount of dithering will hurt the eyes or not, haven´t tested, though. Please do not get me wrong, I appreciate a lot to see such good dithering! But many people should check all those screenshots on real Beeb on real television and monitor first before programming them in, just in case to check they are eye-friendly enough. To make sure, please program a vertical smooth scrolling routine for those screenshots, as moving screenful of dithering should look at least a bit different than immobile dithered screen. At least, if the scrolling is not really smooth all the time. Possible occasional jerkyness in extra-dithered screen scrolling may give a headache.

[grobda]

Curious, what's holding up b-type?

I keep wanting to redraw the graphics for BBC modes/colours, as I seem to have an obsession with collecting versions of r-type and always been cheesed off the BBC micro didnt get one.

MSX...Spectrum...Gameboy....C64.... surely the beeb is capable?

[Ronin47]

You could port Doom from the VIC-20 version

[tricky]

Curious, what's holding up b-type?
...

Enthusiasm and too many distractions!

...
MSX...Spectrum...Gameboy....C64.... surely the beeb is capable?

I wouldn't want to do one where the graphics moved in character squares as I would want something like the arcade.
It is relatively easy to do that sort of thing on the C64 with hardware pixel scrolling and hardware sprites, but we don't have either.

The demo that I have started shows that it is capable of something similar and actually on the master, it would be possible, but my min-spec is always the B with SWRAM if it can't be done satisfactorily another way - multi-load is not satisfactory to me The bit a B can't do is 1/2 pixel scrolling (1 every other frame) as that requires 2X more buffers with the technique that I am using and only masters have the required HW (I don't know of another method).

[tricky]

Thank you for the tip about timing bars in B-Type demo. If those bars will go near the bottom, does that mean really heavy use of cpu time?
...
40 years ago.... it was autumn ´82 back then. And you did that trick even before that.... the BBC was only just gone for sale few months earlier back then...!
...

Yes, the lower the bars, the more time it is spending drawing the screen and if it goes too far off the bottom, the timing will be wrong and things will start to flicker.

I got a very early Beeb. Every magazine I would search the ads for anyone saying they had beebs coming and in the end one person we rang said that they had part of a container coming but it was first come, first served. Dad took me from Devon to Wales and we joined the queue that was about 100 yards along the pavement, down someone's path and into their front door. I was panicking that there wouldn't be any left when we got to the front. When we got into the house, you went into the lounge, paid your money and were offered the opportunity to have a resistor fitted to the serial cable. I took them up on the offer, so we went via the kitchen before exiting through the side door, along with all the other excited kids and for the most part bewildered parents - some dads seemed even more excited than the kids in the queue. On the journey home I pawed over the user guide for all the hardware bits I could find and practically memorised the 6502 instruction set (or was that the aug trip?), but some secrets had to wait for a magazine until I got the AUG and then never bought a magazine again, although family still bought me a few.