Hi Neil,

OK I'm gonna dive in now - but the water's a bit unclear

It's a little hard to see quite what's going on from the small amount of code you've posted. So, I'm going to try and clarify what you've got so far, and make some assumptions too - tell me if I'm way off track:

• spriteX is being used as the x position for all 3 sprites (even though your comment says it's 'not used' )
• SpriteController.SpriteInit initialises 3 sprites' x positions to spriteX, their y positions to some arbitrary values, and also calculates and caches the corresponding screen address.
• SpriteController.SpritesWipeActive plots black sprite-sized blocks at the cached screen address for each sprite.
• SpriteController.SpritesDrawActive recalculates the screen address corresponding to the sprite x, y position, and plots the sprite with a standard sprite routine.

Am I anywhere near close there? The code as you've posted looks strange, because as Paras says, it looks like you're doing:

LOOP START
- wait for vsync
- erase at (x,y)
- plot at (x,y)
- increment x
RELOOP

which would leave a trail behind it.

How simple are the erase and plot subroutines? Is there no chance that they are doing more work than simply erasing or plotting 3 sprites - e.g. is it looking through a bigger pool for active sprites, and attempting to update more than 3 due to some error?

It does seem that perhaps your erase is perhaps taking longer than expected (as the tearing goes away when the y position is sufficiently far down the screen).

I don't know how practical it is, but you can often improve your results by sorting your sprites by y position, topmost ones first, and plotting them in that order. Another huge advantage is set a timer to interrupt every frame at the bottom scanline of your game window, which sets a flag. Then instead of waiting for VSync, wait for this flag to change, and you can win yourself a considerable amount of extra dead screen time to start doing your rendering.

Another point: it's best to leave as little time possible between erasing and redrawing - so ideally, your recalculating of the screen address should happen as a separate subroutine altogether, ideally after you've altered the (x,y) positions, i.e. in your code, just before you check for the keypress.

(edit)
....which means you'll need to cache two versions of the screen addresses - old and new.

Thanks Rich for replying...

Firstly the wipe function - has the screenaddress and x and y and xoffset already calculated and stored, from the drawsprite - so it's straight in there and clearing the screen. There isn't any trail left.

Ok, here's the full nitty gritty, posting snippets of code doesn't really help you guys.

Right - lets leave it at one sprite...

*SpriteController.SpriteInit - activates one sprite slot, setting up the X,Y, frame number and anim info.
* SpriteController.SpritesDrawActive - works throught a small list, and will draw the active sprite, masking it onto the screen. [This list is set to 6, only one being active]
*SpriteController.SpritesWipeActive - searches the same list, then with it's pre-calculated screen address, width, height and x offset ( within the character ) it then just clears the block with colour 0.

Sorry for the confusion of SpriteX, its not used for drawing - from my sample I posted ( which is still just a test loop ) I was writing directly into the sx positoin in the SprArray for sprite 0 (the first one).

I'm not sure at the worth of positing the sprite draw and sprite wipe functions here - it's easlier to read it in a source editor. I'll be more then happy to post what ever on here thou, or mail a zip off ... I am too old to be worried about people viewing my code!

Right - again thanks guys, I'm sure to get to the bottom of this sooner or later!

Neil

...and with only one sprite you still have flicker?

maybe we should see your erase subroutine...? I can't really imagine why.

you can see the relative time per frame taken by the rendering. Replace this bit of your main loop with:



This will show a blue band of colour, showing you which part of the screen is being rasterised while your rendering subroutines are called.

Ideally, you wouldn't see a coloured band, because all the rendering would happen during flyback and the top border rasterising - but unfortunately, in this imperfect world, you'll probably see it. Note that if a sprite overlaps with this band, you'll see the flickering you mention, and if it is outside of the band, it will render smoothly (try it!).

The aim of course is to make the band end as high up as possible - either by starting it earlier (i.e. before VSync on the previous frame, after all moving screen areas have been rasterised), or by optimising the rendering code.

Roughly at which pixel row of the screen do you see the band finish at, on average? Anything more than a couple of character rows (16 scanlines) and I would say something strange is happening, if you're just erasing and plotting one 16x18 sprite...

Coming in a little late here, but noticed you said your code was based on some of mine. I think back a few months but it was just something knocked up that did the job, it was never pushed much to the limit, when I came to do the real plotting routines for my project the original code changed somewhat to improve speed (with many suggestions for improvement coming from Rich and others).

Unrolling loops etc. and other optimisations improved speed, Rich's coloured band really helps to see if your changes improve the performance.

Thanks Steve and Rich!

The colour bands help no end. It did point to the sprite draw function. As you pointed out Steve, the sprite plot function that I worked with as a reference for mine - plus the additional code to mask the sprite onto the screen made the sprite draw function slow - came down to around 60 scanlines.
I've stripped out the pixel masking, just doing the [blank 2 pixel skip] technique . The masking was unneeded and was the first thing to go.
I'm in the process of rewriting the system so that the screen address and other nitty gritty is stored and precalculated only when needed. This was done for the SpriteWipe. Also I'll fixed the sprites to a set sizes to allow for easy unrolling.
At present the two are hovering at around 32 scan-lines so still room for improvement. The erase needs very little work, just unrolling as there is naught to it - however the spritedraw is getting alot smaller.

Now, realizing what the problem is and being able to see it - has put my mind at ease. Speeding routines up once you have a frame work - i.e. the coloured bar, or bars in my case(!) helps no end!! Oh it's been a long long time since I've used coloured bars for speed improvements.

Right - thanks again for your help - I'll have to read the forum to get a few hints on speeding things up, so any ideas - please throw them or the refererence my way... It's a pleasure doing this development as I'm learning and relearning stuff ... Shame there isn't 48 hours in one day!

Neil

A few snippets here. Most useful I found was using a timer instead of a proper vsync.

Saying that, I haven't eliminated my flicker problem completely but that will come in time

Thanks Dave!

I've consulted the AUG and STH in the end, and introduced an int timer, which is called just at the bottom of the screen - and restarted by the VBlank int. This is basically using Rich Talbot-Watkins split-screen example from STH, allowing a flag to be set once the bottom of the screen has been reached. This has given another 20 odd lines of processing over the original VertBlank timings - which is good.

I like the idea of Y sorted sprites - ( I wont be implementing quick-sort ), working ahead of the raster line with drawing, I can understand that!

I'm really glad of all your help, as understanding a problem really helps with the coding the solution! Jezz, I know that's stating the obvious, but I've got that excited feeling! Haha you know what I'm trying to say! Sigh!!

I still need to re-go through my draw function, but it's getting there.

Once I'm happy with the code, I'll drop it in the sample code section, to help the newbies amoung us ( that includes me! ),

- Neil

Good stuff! Glad it's all coming together nicely. I think that starting the render earlier using a timer interrupt is the most valuable little trick there is. You waste so many off-screen lines waiting until VSync

Just to make the point again, another way you can minimise the flicker/disappearing portions is by plotting the new sprite as soon as possible after erasing it - because otherwise, of course, there's a bigger chance that all of the sprite will still be erased when its part of the screen is being rasterised.

Since you're erasing everything then plotting everything, you might find that calculating the new screen addresses is best done in a less frantic moment! e.g. after the character movement, so that your sprite routines themselves don't have to waste time doing it when speed is of the essence!

Oh, and by the way...
Which one was that? I don't remember...

It'll be good to see the final results

Hi Rich!

Hmm RichTW and 'Rich Talbot-Watkins' - there's a slight link here, but I can't quite put my finger on it! LOL!!!

I'll take a big assumption that both are you, so to speak - so - many thanks for your help Rich! Let's see - the article is in "General > Software: Games > Screen Split" (STH) - explaining the mode change tech used in games - for example - Elite.

Once I've got my code together, I'll post it on here and let you all review it - then if it helps I'll put it in sample-code. It would be best reviewing the source code, file by file - so timers, sprites etc ... but that's a while off yet.

I have been thinking of allowing full access to the project and source as well as the 'game' once it's more finished as in a phrase for review, so people can build and change ( via the Swift IDE)... It passes on the knowledge in a 'come and play' example, allowing new coders to get stuck in straight away! What do you guys think of that?

thanks - Neil

The easier it is to get started the better, sounds like a great idea

Right, just to keep you all updated...

With help from Rich, implemented his fast keyboard handling - ( very impressed ). I found I had to do this, as with the custom interrupt handler ( used for V-blank syncing ) it was playing mary-hell with the OS calls.

So, at present I have basic sprite handling (any size, crude masking), keyboard handling, timers and .... as I said to Rich, best way to optimise it is to add it in a quick and easy to implement game, so invaders it is! LOL Should be good to optimise but also to allow me to think about implementing the screen drawing stuff in a full on game!

I've been reading the forum and like the idea of a 256byte maskable table for sprites, if anyone has already done the table (mode 2) then please SHARE! If I get time after this phrase of optimising, then I put it on the site when I've done it!
Hmm, was reading the thread where Steve was discussing speed up of game ideas with the rest, various options were thrown in the pot... Sigh, better get back to it - if I can find it!

Many thanks all, Neil having another senoir moment!

Hey hey, that's on my list of things to do, due to a lot of RL getting in the way my Beeb codings been none existent for some time and will unfortunatly remain so until after christmas. So look forwar to having a lend of your code