Just fudging some more colours into the thing... Man background is now cyan (nearest to origonal c64 light blue)... Sprites now have a black outline (as god intended) too.

Now heres the cool thing that the beeb can do that the c64 cannot....

I can have multiple 'multicolours' as well as the main colour, plus I can change the background colour too if I like !!! - So I've bodged the pearls to use totally different pallets than the rest of the background graphics ( on the c64 they would have to have 2 common colours - just being able to change the 3rd one only !!) - For the graphics slab plot at the top, it looked poor on the cyan background, black was better, so I just changes the pallet again before plotting, so I get black... !!! - This is really quite ace - Colin is pleased !!

I will leave the 'Aquarius' slab graphics at $3000 throught the game, and will maybe format it so it loads at $3000 without having to drop it down in memory and replot it (uses 1.5k of valuable game memory ) - Another cool thing, is that the BBC have more rows than the c64 (c64 only has 25) - I used 20 for the game graphics, and the other 5 for borders and stuff.... Game screen 'could' be made taller, but would mean redesigning all the levsls..... All this testing has givem me a lot of new ideas and stuff !!

Probably will end up looking something like this paint mockup.... I do a LOT of stuff like this recently (mainly been editor screens on my c64 music player - saves a LOT of time !!)



Will be a challenge squeezing in say 10 levels or so - 256 bytes each including ALL the sprite positions, colours to use and enemy types - plain level takes 190 bytes ( I have about 20 GOOD ones, 20 reasonable ones and 10 not finished)... plus the graphics (1k for tiles) - Plus Sprite Graphics on top of that (which will need thinning out a LOT) - plus game code of course too !!

#edit# Each Graphic Tile uses 32 bytes of memory - and is in a 4 colour format... my plotter can plot any tile graphic with a definable pallet... Once plotted it uses 64 bytes of screen memory to allow for the extra colours / bbc colour space....

On the origonal design, the sprites looked at the character graphics around them, either to the sides (for the fishes) , below (for the crab so he follows the platform), or above and below for the Jellyfish/Octopus..... The border allows for them to collide with something.. (hence 19 tiles wide instead of 20) and saved me a few valuable bytes to squeeze in the the types and stuff to keep it in 256 bytes.... Don't know if it will be possible for the sprites to look ahead and react (lets see) - You could have stuff 'trapped' in the graphics, and release them once you picked up the objects.... Will have to see how far I get.... Sprite Storage is going to me the main problem - as they will have to be 128 bytes big, instead of 64 bytes to speed up plotting..... Might have to limit the types of enemy to each level.... and 'convert the required graphics' at the start of the level... The diver will will mostly stay the same though, and I will convert him on the fly (which takes about 1/3 of 1 frame of display time !!! - but the rest will have to be done at the start like I say maybe - unless I can really optimise stuff for speed - which would be a nice to have !!) - This is totally different from what I can gather from traditional BBC graphics programming/storage, so obvioulsy takes a good speed hit....

##edit2## Why am I doing all this - well - because I already have all the graphiccs and level designs done on the c64, so why not try to reuse all this - also I think a nice side effect of all this is that It may look a little different than a stock BBC game

Cheers, Colin

Just thrown some more levels into the display engine.... Ran out of room for any sprites whatsoever now, lol...

Load this disk in for a sneak preview of the first few levsls from the c64 beta...

Cheers, Colin

Colin, your an absolute coding whirlwind, wish I had just a small amount of your energy and enthusiasm. Great job

Maybe you can join our "Team Beeb" for the next pub quiz, your c64 guys pipped us to first place at the Lass Were you in the C64 Team ?

Absolutely fantastic.

Yeah, fantastic work Colin Looking forward to seeing how this one develops!

Don't forget the last screen shot is a 'mock up', I haven't got that far yet - but pretty achievable - Then I have to start on the game engine itself... as its non existant.

Thanks for the kind comments. Cheers, Colin

Hi Colin

Sorry I've been away for a few weeks, moving house and work has been very busy. I've actually played this at Console Combat and it's nice, great to see a BBC version in the works

Nope... I was in the 'Box Eaters' team... Me, Vinny, Psyco Rob and a Scott's lad, who all seemed to be eating the Curry around the Phoenix Table top at the time, so we teamed up for a laught !! - I was pretty hopeless anyway... Took all my brain cogs whirring to remeber the Space Wars - PDP-11 question !!! (Took me a few minutes to recall that too, and eventually I spat out the punched tape answer, folowed by a microwave style 'ding' !!) - I'd not eaten all day, had a few drinks (not too many mind you - I'd took it easy) - and was about to pass out ( due to the curry delay and not eating !!) - After the curry I 'woke up' and managed to get the Pub High Score on Phoenix (maybe a UK record ??) while trying to do the first couple of rounds of the quiz at the same time, lol !!! I was on a roll !!!

Me and DaveF ended up politely declining the 'Lets to to China Town and get pissed invite' and had a couple of drinks in the hotel bar, talking shop and bullhooks !! (and we got lost in the hotel warren of corridors and lifts !! - Hey Dave I was kind of right - but we'd walked right past the lift, lol, and doubled back missing it again !!) - I went to the UK Pinball Show on the Sunday afternoon (otherwise I probably wouldn't have woken up for Breakfast !! - I'm an old timer, lol !! )

There is a nice write up of console combat in the current issue of Retro Gamer Magazine...

I've had a bash at some really nasty code tonight.... This is built on some experimental code that I've been buggering about with..... I'm not pround of the speed, and its a messy implementation, but I thought I'd still have a bash at it anyway.....

What I'm doing is copying the approximate screen memory to a buffer (this is the only memory overhead) ..... prior to plotting a 'real 64 byte c64 sprite' (no tricks), Erasing the old plot (by restoring the memory back from whence it came) - This is in CYAN..... (Memory copied is bigger than the sprite as I cant get my head around all the fine plot lines in realtime for speed)

I'm then plotting a c64 sprite to screen (purple), complete with on the fly masks..... !!!

It takes quite a lot of cpu time.... as you can see from the raster colours....

It was moving across the screen pretty fast, so I've done a vsync to every 4th frame to slow things down...... Hence the raster colour flickers...

Thought it was worth sharing though..... I may be able to live with this in a game scenario, but for just 1 sprite (eg the player)

All the 'JUNK' at the bottom of the screen is the source memory for all the graphics.... I'm using only 64 bytes per sprite, a BBC equiv with masks would take 256 bytes..... (but would be considerably quicker to plot - in the Purple Bit - about 8 or so times quicker !! - You could just stick with 128 bytes per sprite 'in beeb format' and a 256 byte 'mask table' overall if you wanted to make things about 'as quick and memory efficient' at the same time as possible - I'll be looking at this maybe next !!!)

Cheers, Colin

Stunning stuff Colin, I'm out of breath trying to keep up - I don't know how you find the energy

Don't forget though - when the dust has settled you will be obliged to publish all these techniques in a Wiki so that us learners can benefit from your obviously twisted mind

Martin

At the moment... It's basically an easy escape from real life when I get home from work if I've not got any other comittments on (for the time being - and I need to really get on top of things !!!) - I'm also powered by Strong Bow and Regal Ciggies....!!!

Won't be able to keep this up however.... This is all brute force test work.... and things will slow shortly !!!

Tonight, Matthew.... I'm counting sprites.... (to minimalise things as much as I can) - and working out (in therory) a way to store the level data, so that each level is 'drawn up' from a 'display list'. I need to get a Level down to at least 128 bytes - (half the c64 binary format !!) - This is going to be real grunt work.... so expect me to be pretty quiet for a while !!! - I want 'at least' 10 levels with a fair few sprites and varied graphics (in one single load).

Glad you like the tech demo.... its working nice eh...
Cheers, Colin

Nice work col, your demos are always treat

Right... Yes... I've been quiet....

What have I been up to ???

Half Term Holiday with Kids in Fleetwood....
Won a Working Atari Roadblasters Cockpit Game on Ebay for £102....
Started trying to smoke E-Cigarettes (on and off) - in an effort to give up !! (I smoke a LOT while programming)
Caught a Cold.... been off work in bed with no motivation..and Just Getting over it....

Did a bit more BBC coding tonight... after a couple of weeks break.....

OK.... Spent most of the time this afternoon starting a new project.. and copying/modifying code over and coaxing it to work again.....

Just before I went on Holiday, I had a sprite 'cull' and selcted 32 nice sprites to use (2k).. They all face one way (or the other)... Thats no good....

So... I made a copy of the NEW C64 sprite code, and modified it to display a flipped (L/r) image..... and modified the wrapper code a little, So I enter with X = X position , Y = Y Position, and A = Sprite Frame to display.... If I use 0>31 I get Normal Sprites, If I use 32 to 63 I get flipped sprites !!!

To test this.... I've just written a simple program, it looks ahead of the sprite, sees if there is any graphics data there (copied to the top left of the screen as a test), if there is, it changes direction.... Thats about it for now..... Heres what it looks like..... Next is to try some animations...

Cheers, Colin

Looking good Col, are you at 50fps there ? How are you doing the masked plot, is it copying the background or re-printing it ?

Its using 3 frames at the moment....To change to 1 frame (50fps) go into BeebEm debugger and type "poke 1981 01" That will speed it up.....

Its copying the background at the moment... but it makes it messy for more sprites, as it uses up memory !!! - Background replot could be the key, but thats kind of hard to get my head around, especially as I'm still under the weather = The way the backgrounds works, it could work out more time intensive even to replot ?? - This is where I struggle !!!

However... Good level design should negate the need for a lot of masked sprites anyway as most of the stuff can float in space (or underwater !!).

Cheers, Col

Felling better this evening (My Cold is nearly gone)....... So I've started coding some enemy sprite routines..... and thrown them at the sprite displayer (disabled the background copy)... I've got it synced to 4 frames at the moment, which is about the right speed to replicate the c64 version (trust me !!)....

Check this out.....

Bit Flickery and stuff but its working..... Each Enemy only uses 2 sprites of data (128 bytes total for both) - and uses flipping to make into 4 frames where required... (for the fish - look at him turn !! )

If I de-sync... it runs a bit quicker ( I'm still doing masked plots on the fly which is not really required).

Cheers, Colin

Your right the fish turn is very nicely animated

Looking good as ever Col

( ...and great to see some flicker, Colin's human after all )

Martin

Thanks.... I'm "Human'ish", but maybe not quite, lol - (those that have met me will probably agree !!).. I'm also a left hander (which makes me think a bit differently aparently !!)

This is pretty well the proof of the pudding now.... Its messy code though if you are picky.... It was a quick 'knock up' ...But it was to prove to myself that the thing can run on the bbc, with slimmed down graphics and a slower frame update rate....(the c64 version ran at 50hz with a lot more sprites 'in between' animation frames)

I now have to 'rewind' a lot..... and start a lot of the code again..... (or modify)

Why ?

1) Well the sprites look at the bitmap for colisions... this is no good... as they will 'avoid' the player sprite.... So.... I will have to have a 'virtual' level in memory, so that things will work properly... And it uses the vitual level for the collisions.... On the C64 the sprites are seperate from the screen memory, so it was easy to look at the data on the screen and react.... (Yes I could just define set paths for the enemies.. but I'd like them to react to the background 'ideally') - Lets see about this.... Easy opt out is to define start position and end position..(or length of travel). On the C64, you could have sprites trapped inside the stuff you collect, so the level evolves a little... and can get out of hand if you were not strategic.... !!! (Thats partly why the game plays a 'little different' )

2) The Sprite Displayer I'm using is quite slow.... It's bound to be though because its using C64 Style Sprite Data (Very memory efficient on the beeb !!!, but slow) - as discussed above, its doing LOADS of bitshifting, coloring, and masking..... I need to trim out the masking (will speed up a little) and tidy it up ( Most sprites will NOT be overlapping other sprites or level graphics - If I'm carefull with Level Design) - Exceptions will be the Player and the Crab.... However - I will still convert most of the graphics on the fly, as this method is very memory efficient to store LOTS of sprites (but slow to display)

3) Each enemy type NOW uses a chunk of 'very similar' code...(eg I have 3 enemies that move left, so 3 lots of code, 3 enemys move right, 3 lots of code, etc) so not memory efficient....(was quick to knock up though !!)... I think I used a 256 byte table on the c64... and each enemy and enemy state used 8 bytes (cant quite recall - it was 20 odd years ago) - and just had an enemy program that ran through the tables..... eg 1st 8 bytes... fish swimming to left... next 8 bytes fish turning ltor .. next 8 fish right... next 8 fish turning rtol.... each state included collision offsets, colision type, x and y speeds, animation tables to use and the next state to jump to (32 different states overall)... so say by mucking with the tables, you could make the fish swim to the right, turn, then turn into a crab, go left, pause, then turn into a fish swimming right again..... make sense ??? (not that you would want to do that of course) but thats how it worked.

I also need to work out an efficient way of storing the levels... Friend suggested looking at the "boulderdash common file format" BDCFF.... He has done a lot of work with the Rocks and Diamonds graphics and levels "Alan Bond"...and he is the guy who drew all these graphics for Aquarius too... however I think this may be a bum lead... (level would maybe be bigger ?)

http://www.elmerproductions.com/sp/pete ... index.html

Looking at it in detail.... its similar to how my levels are stored anyway....(mine is simpler)

But I think I can make things pretty simple myself doing my own thing.......

Can't promise I'll get this finished... as I say its a proof...... But will try to work on it as time allows....

Cheers, Colin

PS....

Here is my proposed memory map..... (for a single load game if I stick to this)

So.. I've got 11K for all Game Code, Levels and Graphics.... Fair Enough....

Any comments appreciated please......

;########### MEMORY MAP #########
; 0400 > 07FF = Tile Graphics (1K) - C64 Format - Used for the Level Graphics Tiles
; 0800 > 0FFF = sprites (2K) - C64 Format -culled from 8k worth !!
; 1000 > 17FF = Level Data (2K) - ONLY 8 Levels in Native c64 format !!!
; 1800 > 2dFF = GAME CODE ( 5.5k )
; 2E00 > 2EFF = 'unpacked' Level to display (and we will use for colisions maybe ?? !!)
; 2F00 > 2FFF = WORKSPACE for SPRITEs ?? (Copy of old screen memory)
; 3000 > 7FFF = Screen Data (and 'Initial Data' Load Space prior to being copied/formatted etc)