Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 01:28 30 Mar 2024 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : Sprite demo artefacts

Author Message
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 3423
Posted: 12:52pm 01 Jan 2020
Copy link to clipboard 
Print this post

Hi geoff,

While I was looking through the maximites capabilities for games, i stumbled upon then sprite demo.
It is the SPRTDEMO.BAS in the program pack.
If I run this on V4.5C mmbasic on the maximite it stops after a while.
I found the reason behind it, and it is in the BOUNCE routine that changes direction. But it is fixed in changing from direction 1 to direction 2 and reverse. There are instances where this results in an endless loop. I fixed it by simply going to the next direction, so endless loops are avoided.

But now the demo runs longer, and artefacts show. Especially when 2 sprites move adjacent in the same direction. The underlying bitmap is corrupted. I can make a picture, but assume it is easily visible if you simple start the demo, even without my proposed change.within minutes, black and red stripes can be observed (the sprites are black and red) at ayers rock...

Somewhere the bitblitter routine makes an error, after a move taking pixels of the other sprite to repair the background image. This typically points to a cache update problem,

Geoff, is this something you could fix for the new mmbasic for maximite ?

Regards,

Volhout
PicomiteVGA PETSCII ROBOTS
 
Turbo46

Guru

Joined: 24/12/2017
Location: Australia
Posts: 1584
Posted: 01:34pm 01 Jan 2020
Copy link to clipboard 
Print this post

I have seen this when the background is changed before a sprite is moved. The previous background (before the sprite is moved) is restored when the sprite is moved leaving an artefact of the previous background.

I suspect that the other sprite was part of the background that was saved and that part of the other sprite was 'restored' when the first sprite was moved.

Hope that makes sense.  

Bill

PS Nothing went right today. I turned left and it didn't help.
Keep safe. Live long and prosper.
 
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 3423
Posted: 01:53pm 01 Jan 2020
Copy link to clipboard 
Print this post

Hi Turbo46,

If you change the background to solid white is is very clear that corruptions occur.

Replace
LoadBMP"backdrop"

With
Line (1,1)-(MM.Hres,MM.Vres),7,B


Screen corruptions are multiple and obvious.

I think the damage is done in the sprite move funtion. It may be in the order in which the sprites are moved. But it is impossible to change the order in which the sprites move depending on the position of the other sprites on the screen.

Maybe the only way to solvhe this is double buffering the background BMP. But that costs serious memory.

Volhout
PicomiteVGA PETSCII ROBOTS
 
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 3423
Posted: 02:37pm 01 Jan 2020
Copy link to clipboard 
Print this post

Hi Turbo46, Geoff,

I have played with the demo program, and when sprites actually overlap in non-transparent colors, moving them shows the artefacts.
Normally you could avoid overlapping sprites by doing a collision detect before you move the sprite. But it looks like the collission is only detected after the sprite move command.

As result of the collision detect the demo program moves the sprites away, but if they accidntally move in the same direction, the collision leaves an artefact.

Volhout

It is also related to the sprite number. Which sprite moves first, shows different artefacts.
Edited 2020-01-02 00:50 by Volhout
PicomiteVGA PETSCII ROBOTS
 
Turbo46

Guru

Joined: 24/12/2017
Location: Australia
Posts: 1584
Posted: 11:28pm 01 Jan 2020
Copy link to clipboard 
Print this post

I made a similar comment here regarding sprites on a scrolling background. MauroXavier said that he had that covered by using "SPRITE PASTE" I still haven't played the game and didn't pursue the subject any further.

Bill
Keep safe. Live long and prosper.
 
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 3423
Posted: 09:39am 02 Jan 2020
Copy link to clipboard 
Print this post

Hi Turbo46,

I see the workaround MauroXavier proposes. It has a drawback that is slows down the speed, and forces to bigger movements (he uses 8 pixels) But there may be an even simpler solution, if an update of MMBasic is possible (or a CFunction)?

Typically a collision detect would take place, avoiding sprite overlap.
But the collision detect in MMBasic, in combination with sprite move does not work well, as the demo shows.

Maybe 90% of this problem can be fixed by doing a collision prediction.
Let's assume the sprites move pixel by pixel. That means that 2 sprites can move towards eachother maximum 2 pixels per refresh. Current collision detect works when the sprites actually overlap. But for the gameplay it could just as well be "just before they overlap". A brute force way could be to detect if there are any sprites within 17x17 pixels (only check origin), before doing the actual move.
But in that case transparent area's would indicate a false collision.
This could be done in basic, but is much faster (you have to check all sprites at every move of every sprite) if there was a collision prediction command or CFunction.

What I guess that happens now is that the sprite is pasted in the video memory, and the 16x16 area is compared to the original. Whenever a collision occurs the pasted version is different from the original.

The collision with edge could be based on origin only.

Volhout
Edited 2020-01-02 19:41 by Volhout
PicomiteVGA PETSCII ROBOTS
 
Turbo46

Guru

Joined: 24/12/2017
Location: Australia
Posts: 1584
Posted: 10:27pm 02 Jan 2020
Copy link to clipboard 
Print this post

Yes, that may help the programmer manage artefacts caused by sprite collisions but the screen background can change by other means. I am not a games programmer so I have only had to deal with the problem in a minor way where the background was changed because of another action when the sprite was in a certain area of the screen.

I think that the only way to make it easier for a programmer is to NOT paste the sprites into the screen memory. Having to restore the previous background is the cause of the artefacts.

If a second copy of the screen could be kept where the sprites are copied into could be kept - this would need to be updated every time the main background screen was changed or when a sprite was moved. A lot of memory and processing time though.

Or perhaps a second screen memory containing only the sprites on a transparent background which is then combined into the video stream when sent to the monitor. Anything in the sprite 'screen' would take precedence over that in the main screen memory.

Another option is to keep the sprites out of screen memory completely and add them into the video stream as it is sent to the monitor.

I don't know if any of that is feasible but it would be good to fix the sprite artefact problem. Maybe in the next Maximite?

Bill
Keep safe. Live long and prosper.
 
Print this page


To reply to this topic, you need to log in.

© JAQ Software 2024