Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[adrazar]

Here is a new version of amos.library. It features an improvment of the Bob Clear instruction.

What was wrong with the original?

Good question! Imagine we have a bob that we want to move around the screen. First we decide its location using the Bob instruction, next we reveal it using Bob Draw. Bob Draw basically does two things: first it saves a copy of the area right underneath where the bob is going, then it draws the image. When we later move the bob to a new location, we must first erase it from its previos location using Bob Clear. This instruction does what one would expect it to do; it redraws the previously stored background.

So far there is no problem, and that is because the problem only occurs when the bob moves entirely off screen. What happens when calling Bob Draw in this case is firstly that no new background is saved, and secondly that nothing is being drawn. In this situation it would be fair to assume that Bob Clear also didn't redraw any background either, but surprisingly it does. The background that is redrawn is the last stored from when the bob was on-screen, and it keeps redrawing this until the bob is moved back into the screen. The consequence is that graphics operations in the affected areas will get corrupted. The improved version stops the redrawing while the bob is off the screen.

Nice! However, is this really useful?

Maybe? Certainly I will make good use of it in the tilemap-scrolling platformer I'm making. Bobs regularly move off the screen, and tiles in the background needs redrawing when the screen scrolls. This combination causes corrupted background graphics and a lot of grief finding ways to compensate. Undoubtly the most efficient solution was to fix AMOS, and now that has been done.

The new version of amos.library also contains a minor change in the Limit Bob instruction such that it works as intended. This fix has been done before by others, but not in the latest unofficial version on this forum. The other fixes that were already present includes the must-have Dual Playfield fix and a couple of less significant ones that I'm unfamiliar with.


HOW TO "INSTALL":
First install and upgrade AMOS Pro to verison 2.0. Then download the attachment which consists two files: amos.library and +w.s. Move "amos.library" into the directory "System:Libs/" and installation is complete.

The file +w.s is the modified source code. I had to make changes at several places because I redefined three existing variables to hold additional data. The section at the top describing latest added features has not been updated.

[BooBoo]

Reading your other post on EAB about Bob clipping must this patch be used if we go outside the screen size after using the fix you found of Doke Screen Base+76,NEW_SCREEN_WIDTH ?

[adrazar]

I think the answer is no. The patch is really only useful in situations where one actually allows the automatic bob-clipping to kick in. I don't know how safe it is to send bobs through the top and bottom of the screen after increasing the screen width, so if this is out of question only the left and right edges of the map remains possible as candidates. If a bob can return into the screen after passing either of these the patch could become necessary. Otherwise, if it can't return, the bob might just as well be turned off to prevent the problems from not using the patch.

[adrazar]

Reading your other post on EAB about Bob clipping must this patch be used if we go outside the screen size after using the fix you found of Doke Screen Base+76,NEW_SCREEN_WIDTH ?

After a bit more thinking yesterday night, I suddenly realised Limit Bob maybe could be used as a key part to make bob handling easy also in a corkscrew scroller. Increasing the screen width alone doesn't solve all problems, because one still has to find a way to manage bobs coming in and out of the visible screen (failing to do so would result in revealing every bob on the map because of the wrapover).

Well the idea I got was to use Limit Bob the same way as Screen Offset for managing the bobs. That is, only increase the x-coordinates of Limit Bob (keep the y-coordinates fixed). Today I made a program to see if this would work, and it did! I have attached a small demonstration to show how it works.

As long as the screen is high enough it should with this method be perfectly safe to send bobs out of the screen in any direction. Both things I put into the patch are necessary to make this method work.