My bad - update pltloop to this :

I've noticed that to convert the screen address calculation you've realised it's 320 bytes per character row and to get this value you are dividing the 640 times table result by 2. I know you've done this to save you time initially in generating the 320 table but of course I know you realise this costs you some time in your code. So I've done the work for you and created a Wiki page for calculating the screen address for 10K screens. This includes the 320 x table. It's here;

http://www.retrosoftware.co.uk/wiki/ind ... ess10KMode

Thanks, Thats working nicely now.... Cool

Quick question....

In Swift.... I'm loading some sprites as a binary file.. this seems to work ok... (but I'm getting the odd glitch - prolly due to crossing a boundary)

at the end of the code, I'm doing.....

Sprite: ; sprite is in 'native' c64 format data
.incbin "asprites"

this is fine, but as I say , I'm getting a glitch in some of the frames (prolly due to the data being at a random start place., and crossing boundarys.. or my data is somehow corrupt - unlikely as I just tried an alternate sprite set and thats giving jip too)

Anyway.... as a sanity check.....I'd like to force my sprite data to start at $2000.... SO... if I force an Org....

.org $2000
Sprite: ; sprite is in 'native' c64 format data
.incbin "asprites" ; This is an 8k file (well 8193 bytes - extra naughty byte at the end !!)

This seems to make things worse.... it seems to throw the data out by a few bytes.... Am I missing something obvious with Swift ?

Cheers, Colin

##edit## looking at the sprite data file binary in swift... and the beebem debugger.... at memory $2000 > ... it seems my binary is loading from $575 upwards..... into $2000 ?? Strange !! as from there on.. the bytes are identical....

SO... it appears to me.... that the .incbin is ignoring the org.... ??? and just loading it into memory at the code end.... (and then assigning the sprite label to $2000, even though the data has loaded below it)...

So... how do I force it to load the .bin into $2000.....

You need a P65 facility not Swift. See the P65 docs here and in particular the section for Memory Model. This explains what you need to do, although I've not used any of these commands.

http://hkn.eecs.berkeley.edu/~mcmartin/ ... s-ref.html

I don't have any problem going across page boundary's with my sprites though, is this something to do with the type of sprite plotter you using ? My sprites re all sorts of sizes so some at some point would cross a boundary.

Try using .advance $2000. That seems to work for me on White Light.

Steve.. thanks for the link to the document...

Tom... Works spot on with the .advance instead now...

Cheers Guys.. Have a couple of Strongbows on me, lol... (check the avitar)
Regards, Colin

ta very much

Right.....

I'm now experimenting with Sprite Masks.... Yes this is very fisher price basic stuff for you guys, but its pretty essential that I learn all the basics first of all.....

Now... I thought it was pretty speed inefficent, to work out the mask while plotting (please please correct me if there is a fast on the fly bbc mask trick - maybe using a table of 256 bytes ????), ... SO basically I've just got my sprite data, and manipulated it to build me a negative mask.... So essentially there are now two sprites... one normal and one mask.... (all pre calculated but uses twice the memory so halves my sprite count)

Ok... While plotting, I get the mask byte, AND it with the Screen memory, OR it with the sprite byte, and then plot it back to screen memory....and repeat for all sprite bytes in the image...

Its working.... Not pretty code or whatever, but I'm learning the techniques now....

Heres a quick screen shot to show progress....

So.. what do I need to suss out next them ?? - I guess I should snapshot the screen background for all 8 sprites, before plotting, so afterwards I can then restore the screen background, before moving the sprites and replotting them somewhere else..... does this make sense ? -Is it the right approach I'm taking ?

I also need to work out a better sprite storage format for speed.... as its still a bit of a hybrid c64/bbc model... (with the bits shuffled around as the order is different on the bbc) - At the moment I can only plot the horizonal position in coarse steps..... SO a long way to go/learn yet !!

Cheers, Colin

Ps.. heres the mask code.....that runs at the start (similar to the sprite conversion code, but tweaked to combine the colour nybles and invert for mask) - I've edited in some comments since first posting...

(Pretty simple brute force bit shifting code eh ??)

makemask:

lda #<sprite
sta $70
lda #>sprite
sta $71

lda #<smasks
sta $80
lda #>smasks
sta $80

ldy #$3f
lda #$00
sta ($70),y ; clear 'unused' 63rd byte !! - just incase image has corrupt data in for sanity

ldy #$00
mmloop1:
lda ($70),y ;get sprite 'byte'
sta working
lda #$00
sta Working+1 ; clear our working nybles (in separate bytes before re-combining)
sta working+2

ldx #$04
mmLooprol:
asl working ; shuffle the c64 bits around to bbc hi/lo nybles style in two separate bytes
rol working+1
asl working
rol working+2
dex
bne mmlooprol

lda working+1 ; or both nyble pairs together so aways use 11 (if any of the bits are set)
ora working+2 ; if nyble pairs are 00 then they stay at 00

sta working+1 ; store combined nyble bytes back into both nyble bytes
;sta working+2 ; dont need to store it !!

asl working+1 ;rotate them all back into place - eg combine the nyble bytes into one byte - hi/lo bbc format
asl working+1 ; we only have to do this for the high nyble as its 'out of place'
asl working+1
asl working+1

;lda working+2 ; get the low nyble (we already got this in accumulator)
ora Working+1 ; combine with high nyble

eor #$FF ; invert the mask

sta ($80),y ; store fixed sprite mask value
iny
cpy #64
bne mmloop1 ; repeat for all sprite bytes in the image

rts

I wouldn't try and snapshot the background, would take up too much processor time and you'd have to find the memory to temporarily store this snapshot. Usual method on the beeb would be to use your background graphic plot routine to re-plot the required area to perform the erase. This is the routine that you would call repeatedly to plot the blocks for your background when your level starts

Thanks for that Steve.... I've now put my mode 2 hat on and am thinking about things.....(not fast - got a LOT of stuff on my mind at the moment).

Looking at your sprite plotter, you can only move 2 pixels at a time left/right... is that assumption correct ? (saves bit shifing the data to give 1 pixel increments which would slow things down somewhat !!)

OK....I've written some code to get the c64 sprite (64 bytes) and convert it to a mode 2 usable format (144 bytes - its gross, excuse the pun !! - Ideally 128 byes if I optimise it) ... I've even impressed myself that my bit shuffling works perfectly !!! (its quite short too !!)

Basically, I get the sprite, split up pixels to get one of the 4 colours (3 and background), use a pallet lookup table to select the new 4 colours to use...(c64 uses 2 fixed definable colours for all 8 sprites and a 3rd selectable colour for each sprite - in multi colour mode) and then I finally convert to bbc graphics format..... It works - and is even more flexible than the c64 because I can select the 3 different colours for each spite now individually !! (but obviously it will have to be run 'off line' as it will be pretty slow).

I'm now trying to work out some 'fast cheats'.... but will probably fall back to your sprite plotter eventually...as you seem to have done the homework

Probably will KEEP the c64 sprite format (more memory efficient) and pull the sprites out as required (say at a level start) - If I get as far as putting a demo together that is.... Could always use some kind of cruncher as DaveF suggests - way over my head for the time being - or load up each levels data/graphics from disk I guess - but both are LONG way off...

I'm also considering using a 'smallish block' of memory to pre-process stuff prior to plotting or to generate masks, to try to speed things up and/or avoid flicker.... (and I don't like flickering graphics one little bit)

Long way to go yet... Just throwing some ideas in.... I'm coming in from a totaly different angle.... might be bad or might be good..... lets see....

Cheers, Colin

Really glad to hear your still coding away

Bang on, 2 pixel movement is generally ok on the beeb, I tend to call them byte positions (to avoid confusion with pixels), but that's just me, not sure if there's proper name for referring to the byte that holds the pixel data.

as hinted about on the Wiki page, there is still some improvements that could be made But the code gets more complex and long as you try to squeeze more sprites out without flicker/ shear. Also you can gear your improvements to the game style/engine that you are developing. So there isn't a total one solution fits all thing when you really want to optimise fully.

Thanks for the kind comments...

I edited my above post a little to explain things a little more..... I'm pleased with my progress, but WILL hit some brick walls with regard to using the 'full' memory map and such like....

Yes... theres no perfect fit all solution...its all compromises...

Say I stick with my sprites current sizes and mask them 'off line' then I'm looking at 256 bytes per sprite, which is kind of scarry for me animation wise !! - So obviously I want to cheat as much as I can, lol !!!

So....I'm looking at 128 bytes per sprite, plus a 256 byte mask table (128 bytes maybe ???, ignoring the high 'flashy colour' bit) to cheat while plotting on the fly (If I decide to allow overlapping graphics of course !!).... not quite got my head around it yet... plus 6502 adressing modes for zero page are limited, grrrr !!!

Certainly cant see me running at 50 FPS.... like I could on the c64...

Mode 5 is more 'native' to c64 graphic storage (just using 4 colours), but mode 2 is more 'true to c64' to give more colours which is what I desire... but snatches vital memory.... .... BUT mode 5 is more cpu intensive if I want to plot fine positions horizontally (less than 4 pixels), Mode 2 allows 2 pixel plots more easily, and more colours too... I've seen the light, but it's all Hard work, lol !!!

Maybe I'll drop my c64 hat, and go for more of an 'unexpanded' Vic-20 style fashion (plenty of good games made in 3.5k, lo) - or CERTAINLY a bit of a hybrid.... The thing with the commodore machines is that the backround graphics were all 'tile' based... so you need to plot 16 bytes on the beeb (mode2), as opposed to 1 byte on a commy...

Cheers, Col

The advanced user guide has a very good description of what's used for what in memory. You can claw back quite a bit from the OS of required. Just recently I've used 40 bytes from the printer buffer (itself only 64 bytes long) as a memory block for some pointer lists I need. Seemed silly to nick some from my main program area when there was a small amount going just right for the job.

I can't quite remember but I think BASIC is allocated 1 or 2K from main ram that you can pinch as well.


I really hope you keep with it, without doubt the c64 hardware sprites were an excellent feature and more than compensated for the 1Mhz processor.

Yes... indeed.... (also edited my above post) - you keep beating me to it, lol....

So... Hybrid C64/Vic-20 style of game to BBC convertion I think is the way to go.... Limited animations/graphics... But I'd hope to try to squeeze some stuff out, but limited by a slowish (not too slow though) frame rate.... As I say.. I'm coming in from an different angle....(and am stuck with real life time eating issues ).. Lets see....

Also.. thinking about it... I can probably live with not masking sprites on mode 2, allowing a little flicker horizontally (depends on what I decide to program or whether things overlap at all !!)

Cheers, Col

I haven't really been following this thread so closely, but just thought I'd add a little something.

As always on the Beeb, you're forever trying to balance memory requirements versus frame rate versus resolution/colour - it's pretty tough! I guess you need to determine which of these is most important, and then make the decision on the screen mode based on that.

If you really need the colour, then Mode 2 is your only option. This also allows you to quickly move sprites by 2 pixel amounts horizontally, and you can also get relatively cheap (speed- and memory-wise) masking by nominating logical colour 0 as your 'transparent' colour, and using a simple lookup table to do the appropriate ANDing. Here the compromise is with the memory requirements - a full unshrunk screen is 20k, and a 16x32 sprite is 256 bytes! This, in turn, will take longer to render, and so your frame rate also potentially suffers! On the Beeb, it's possible to define screens of custom sizes, so you can at least reduce your memory requirements for the screen.

If it's more important to be able to blat around a lot of sprites, whilst maintaining a reasonable frame rate, you might have to go with Mode 5. Here the sprites will require half the memory, and therefore render twice as quickly If you're prepared to sacrifice logical colour 0 as a transparent colour (leaving 3 colours for the actual sprite, which I think is the same as a C64 anyway), then you needn't store a separate mask, and can use a table-based solution, as with Mode 2. If you require smooth horizontal movement, then one option is to store two copies of the sprite, one offset two pixels horizontally from the other. This will give you the same freedom of movement as Mode 2 (with identical memory requirements for storing the sprite), but will render very quickly. Don't try to do on-the-fly bit shifting of sprite data for pixel-by-pixel horizontal movement, it's just too horrible to think about. The only problem then is that you only have 4 colours, but if they're chosen carefully, you can 'make' new colours by dithering, and you can also use interrupts to change the palette midway through the screen raster to allow a few more simultaneous colours.

Finally, Mode 1 - only recommended if you need the high resolution. Otherwise it suffers the same problems as Mode 2 with the same drawbacks of Mode 5! Also, movement by 4 pixels horizontally might not really be acceptable.

So, in summary then:

Mode 2 - low resolution, colourful, memory intensive, slow to render
Mode 5 - low resolution, not so colourful, half the memory requirements of Mode 2, twice as fast to render.
Mode 1 - high resolution, memory intensive, meh.

Thanks.... Yes.. I've 'really really' weighed up the various options (and covered a lot of the issues you mention in my head, like pre-shifted sprite positions), so will stick with Mode 2 for the time being.... Best compromise.. for what I'd like to achieve.. For instance, I'd happily trade off half the speed for more colours...(4 colours is NOT for me) - Mode 1 is certainly not on the cards... (maybe for a spectrum programmer though ??)

Cheers, Colin

Here's a little demo to show progress to date......Just to test for speed of code....

Now.... for every loop....

Its getting a C64 sprite (63 bytes) - Converting to a 'middle format' (126 bytes) - applying a user definable colour table and storing as BBC Native mode 2 format (126 bytes) - then plotting/copying the resulting 'kludged' data on the screen in an xy plot place.... and then looping back to the start..... (I'm using the 256 bytes just below the screen memory for the sprite 'pre plot' calculations - can probably get this workspace down to 126 bytes - not thought about it yet !!)

So basically its doing a LOT of stuff thats not really needed - I only really need to just plot (and convert off line) - But like I say , testing for speed...

I'm sure I can even speed up the convertion code (but not sure yet - might get messy !!)....

If I just pre convert 'off line' and plot (using a modified version of Tom's code above), its blisteringly fast !! - so at the moment - I'm trading speed against graphics memory used (plotter is fast, but conversion and especially the colour tables slow things down)

Disk file attatched.... Cheers, Colin

Nice demo

Thanks Steve.....

Heres how fast it runs IF I convert the sprite 'off line'.... (but I loose the ability of changing the colours on the fly) - You can see.. it speeds up somewhat, lol !!!

btw.... The sine table was done on the c64 emulator in basic, and I saved the 256 byte block off using the monitor.... lol....

edited my post above to explain things a little more too !!

Cheers, Colin