Sorry for appearing to be the thickest person on the planet.

OK, so I can plot bytes to the screen. I can see that if I've got sprite data, I can read the values of that data into A and write it at the appropriate location in screen memory.

I've also designed a sprite in the Swift sprite editor (the Commander Stryker sprite from Codename:Droid (when is there going to be a PC conversion of this)).

The step I can't quite see is in my plotting routine how I tell the program where the sprite is stored in data. I don't even know where this is going to be, so how do I either

a) Decide where it is going to go in memory (any suggestions?)
b) Have a local reference to the data

Once I can do this I can stick my sprite on screen.

Thanks

One way would be to initialise a memory block for data like this:



You can then refer to this in your assembly code using something like:



Kind regards,

Francis.

If your not using BeebASM (does BeebASM support DIM ?) then in P65 you can just embed it as part of your code.

In Swift if your sprite project item is called "Droid" then just do this;

DroidSprite:
.incbin "Droid"

Then to refer to this you can use

lda DroidSprite

to get the first byte from the "Droid" data.

Just bang the include at the end of your code.

You can do this with BeebASM as your assembler to but the syntax of labels and directives is slightly different

Pity you can't see the tutorials, there's a bit about including raw data with includes in there.

Sorry, I was forgetting rival was doing the development in Swift and not in BeebEm or similar.

Kind regards,

Francis.

In BeebAsm,

.droidsprite
INCBIN "DroidSpriteFile"

Ooops

My exmple should have been incbin not include I've edited my original post.

Hi Guys,

well first post ... Hmmm I'm hoping most of you will of seen my introduction post on STH - if not yell and I'll bore you silly with my life!

Anyway, oh it's been a long while since I did a 8bit assembler, I've been spolit with many many many regs etc since my Z80 days... Anyway, I noticed this topic title and thought I'd come over and at least tell you that I'm slowly getting up to speed with 6502 using Steve's GREAT Swift dev env. It doesn't help with the fact I've got my house now on the market and have been sneaking in snippets of time at work - when no one's looking!

I've had a quick scan through the general chat in this topic, and notice one very important point - that should be stamped on my forehead, FLAGS, FLAGS, FLAGS! I think there was some optimizing points suggested by Steve concerning BMI over the load and cmp, that made a very old bell ring in my head, haha as I said it's been 18yrs since Z80!

From my end of the field, I currently working on my sprite controller, it's in very very early stages, but this is helping me build up my knowledge and macro set. Once I get it into a working state, I'll throw it to the wolfs and see what improvements etc are advised!
One final note from me, I'm using P65 with of course Swift, I haven't been able to find any one document that just gives a good reference for the syntax ... example being;
lda #<lovelyExample, lda #>lovelyExample
for the hi/low byte. I found it really by accident. So, has anyone got ideas on if there's a document that might help? I must say that the tutorals with Swift are great, and got me coding on Beebem after watching a couple of them! Very impressed!

Right, better get back to work, sigh - its a hard life,
thanks - Neil

Thanks for your compliments, glad it's proving useful;

You may have seen these documents, so apologies if you have but just in case;

http://hkn.berkeley.edu/~mcmartin/P65/ophis-ref.html

http://hkn.berkeley.edu/~mcmartin/P65/docs.html

I've added these links to the Swift Wiki page.

Aww thanks Steve!

I did look at those in passing, however actually reading them does HELP!

Should help me no end, erm right, better finish off my current chore, then onto the window's machine for SWIFT development!

- thanks - Neil

Hi there all,

QUESTION TIME!

little old me again ... working on my sprite drawer... SIGH!

I now see what's meant by the 'horrid' layout of the screen, in characters and moving eight bytes to get two pixels across ( mode 2 )... it has certainly made me stop and have a good think!

With regards sprite drawers, what seems to be the best approach for drawing good quick movement etc... specially when it could move diag across the screen?

My first thoughts is to produce various sprite frames, for example 16 pixels by 8,(lets say the splot is 8x8 size) and have say 4 frames of the sprite in the various positions, allowing for what appears to be smooth movement left-right - and quickly drawn. Extending the size of the sprite to 16 pixels by 16 - this allows for larger sprite draws but vertical movement! However this does increase the size of the sprite data - BIG TIME!

Having a play with drawing my splot ( best word for programmer art! ), I can only see this approach for drawing inbetween the 8 pixel vertical character spacing, please tell me if I'm just being a DUM DUM and not seeing the whole picture!

thanks guys, Neil ( with a slight headache! )

The way it's generally done is to code your sprite plotter to handle the odd screen and having just the one sprite definition. Plotting your sprite in columns. If your desperate for some example code I can root you out some from one of the demos. (I would have done this now but the one I looked at wasn't working as I must have been messing at some point), so I'll have to debug that one !

I posted some example sprite routines here on the STH forums a little while back - might be some help, though it's a bit sparse on comments I'm afraid

I've debugged that code, I'd really been messing with it when writing the sprite plotter that allows for masks, so been jiggling with it quite a bit to get it back to a working simple version. It's probably not optimum but it did the job for my tutorial.

However just showing it in abstract may not be that helpful as there's loads of support code needed (i.e. calculating a screen start address, 640 x look up table) and it's just too much to list here. Would people like the full tutorial source code attaching with all the graphics etc. which could then be loaded into Swift and just ran ? You'll then have an actual full sprite plotter that can plot any sprite at any X,Y ord, but not with a mask. Or is that giving too much and would you prefer the learning curve of writing your own ? Although the routines were written hastily and there'll be room for improvement I would have thought (I've not reviewed them).

Aww thanks guys ...

Steve: Hmm would be nice to have the sample source, however - I'll would be writing my own - as this, for me is the best way to learn.. as you have said.

Hmmm however it's still good to see a working example as this would save no end of time!

Sigh - I'm so busy here at work, the cheek of the guys, LOL - so will catch up more tonight - thanks again for your replies,

Neil

Yes please. I'll try to get some more time together to update my code.

OK, here's the source for one of the tutorials (forget which) that can plot a sprite from codename droid anywhere on a mode 2 screen. The code should work with any mode that has character row data length of 640 bytes (the 20K screens) and with a very slight mod would work with the other screen modes too.

There's about a dozen sprites from that game included in the sprites file and you can select which to plot in the project item "DroidConstants". There's some reasonable comments included but probably not enough to cover every thing I'm doing !

One essential thing covered in these that's not really cropped up in this thread yet is the calculation of where your sprite starts on the screen given a set of X,Y ords. So that's a freebie bonus !

I probably abuse zero page addresses somewhat and as I've mentioned it's not optimised code but it's a good place to start.

To use it right away, just extract and load the project file using Swift and click run. It uses P65 so this assembler must be set up in your Swift installation.

Enjoy

I should point out that it does need work to make this ok for a game. For a start you cannot plot the Sprite partially off screen as it makes no checks for screen boundaries. So you'd be filling up other bits of program memory if at the top of the screen (ok at bottom as it'd try to write to ROM), or at the sides it' appear on the other side of the screen.

It really isn't rocket science to implement though and I'll leave that as an exercise for those interested.

Also if you want to move the sprite then there's no erase routine for the previous plotted sprite. Now this can be implemented fairly simply or quite cleverly to ensure you only 'rub out' the bits required to keep the speed of the sprite plotter up to scratch.

And of course avoiding screen flicker can be simple if not plotting too much on screen at once or require more thought if your pushing the limits ! See some of Rich TW's brilliant posts for ideas here. (might be on STH forums).

Steve, matey - what can I say!

Looking at your screen position code for the sprite, hmmm it all clicked - haha sometimes I think I read code better then the text books. I have to admit with plopping my hat in my hand and lowered head, I am a bit of a DUNCE! How I didn't work out the Y position by the screen address with the visual position and breakup of the splot , plus only drawing a column at a time - it's beyond me!! I'm normally pretty good at seeing patterns and relationships.

To help others and myself ...
(Note: Please Edit if I have understood incorrectly)

------------------------------------------------------------------------------------------------------------------------------------------

THE SCREEN ADDRESS, explained
=====================================================
| Yc | Yc | Yc | Yc | Yc | Yc | Yc | X6 | X5 | X4 | X3 | X2 | X1 | Y3 | Y2 | Y1 |
=====================================================

Key:
Y3-Y1 = the Yposition (0-7) from top of character line
X6-X1 = X position multiplied by 8
Yc-Yc = Y character position ( div 8 ) * 640

ScreenPosition = ScreenStartAddress + ((Ypos div 8)*640) + (Xpos mul 8) + ( Ypos AND 0x07 )

------------------------------------------------------------------------------------------------------------------------------------------
Damn- ran out of time, LOL, thanks again Steve for your example, Neil

Spot on

I've noticed a couple of errors in the comments, but I'm sure you'll spot them, all part of the challenge ! ! !

Also did anyone think about these lines;



This is the main bit that reads a sprite pixel byte and plots to screen. It uses self modifying code, code that literally writes in values into itself. It makes it harder to follow but that above type of addressing (absolute indexed) is faster than using indirect indexed addressing (by about 1 - 2 cycles per instruction - IIRC) which might not sound much but on the inner loop of a sprite plot routine every single cycle counts. Your saving at least 2 cycles there on 1 byte, and there might be a 100 bytes in your sprite and 8 sprites on screen, that's at least 1600 cycles ! With an average-ish 3 cycles per instruction you've gained over 500 instructions worth of cycles just by saving that tiny amount there. Worth doing !

But.... if you do use this method your code would never work if you blew it into ROM as it wouldn't be able to overwrite itself. But your probably never going to release a game with some code on ROM !

This kind of technique can actually be used to not just write addresses but change actual machine code instructions on the fly and can be a handy thing to consider but can make code debugging a pain in the ass if your not careful. As a tip if you feel adventurous why not print out all the 6502 op codes with they're binary number representations. The 6502 is a RISC like processor (rather than having lots of Macro code like the Z80) and as such certain bit patterns can turn on certain functions in the chip .You will find if you print it out that you can spot certain patterns emerging and sometimes just flipping a single bit in an instruction can be very useful. But I'll admit I haven't looked at this kind of coding in many many years (circa 87, when I pored over the binary representations of the opcodes working stuff out !), so it usefulness on the 6502 may be clouded by my aging memory