Author Topic: Bug in AGI Object Collision Check function  (Read 2459 times)

0 Members and 1 Guest are viewing this topic.

Offline AGKorson

Bug in AGI Object Collision Check function
« on: August 16, 2022, 03:18:30 PM »
While working on my latest AGI project, I came across a bug in AGI that I don't think anyone has ever mentioned before. I wanted to place a series of views in a line, directly adjacent to each other with no gaps between them. But when I first added them, AGI moved them around, using the 'shuffle' function that gets applied when screen objects are found to be overlapping.

Which made no sense to me; the objects were all exactly 16 pixels wide, and I positioned them exactly 16 pixels apart; that should align them all right next to each other. So why did AGI shuffle them? 

I took a look at the code in the shuffle function and found that there is a bug in there that checks how objects overlap. When calculating the pixel value of the right edge of an object's baseline, the function adds the object's width to its position, which is actually one pixel PAST the right edge. It should decrement that value by one to get the actual position of the right edge. But it doesn't.

Because of this, AGI thinks objects overlap when they are placed adjacent to each other with the same Y value. And this bug exists in every MSDOS version of AGI, including all known v2 and all v3 interpreters.

Here is a graphical explanation to clarify:
Code: [Select]
Object A is 4 pixels wide with an X value of 4:
0         1
0123456789012345         
....AAAA........

Add new object B, also width of 4, and position it with an X value of 9, with same Y value as object A. It will look like this:
0         1
0123456789012345
....AAAA.BBBB...

Then try to position object B right next to object A, by using X value of 8. You would expect to get this:
0         1
0123456789012345
....AAAABBBB....
but the shuffle function thinks this is an overlap, and will shuffle object B, which (because of how the shuffle function works) will actually give you this:
0         1
0123456789012345
....AAAA........
.......BBBB.....

The shuffle function is used to check object movement as well, so if two objects are at the same Y value, they can never be moved so they touch each other; AGI forces a one pixel gap between them because of this bug.

If either object is set to ignore objects, then overlapping is allowed, and placement/movement is not affected. But that doesn't help if you can't use the ignore.objs command for other reasons.

I checked around, and I haven't seen any mention of this anywhere. I haven't seen any posts asking about this behavior, and there's nothing in any AGI documentation (Specs, help files, etc.)

It's surprising to me that after all these years, there are still new things to discover within the AGI code.
« Last Edit: August 17, 2022, 04:56:25 PM by AGKorson »



Offline Kawa

Re: Bug in AGI Object Collision Check function
« Reply #1 on: August 16, 2022, 04:09:31 PM »
Woah. Do NAGI and ScummVM do this too?

Offline doomlazer

Re: Bug in AGI Object Collision Check function
« Reply #2 on: August 16, 2022, 05:31:54 PM »
This is in ScummVM's checks.cpp AgiEngine::checkCollision

Code: [Select]
// No horizontal overlap, check next
if (screenObj->xPos + screenObj->xSize < checkObj->xPos || screenObj->xPos > checkObj->xPos + checkObj->xSize)
continue;

https://github.com/scummvm/scummvm/blob/master/engines/agi/checks.cpp

Offline Kawa

Re: Bug in AGI Object Collision Check function
« Reply #3 on: August 16, 2022, 06:14:25 PM »
From this I understand it does in fact have the same bug. Neat.

Offline troflip

Re: Bug in AGI Object Collision Check function
« Reply #4 on: August 16, 2022, 07:00:53 PM »
That's a cool find!
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline OmerMor

Re: Bug in AGI Object Collision Check function
« Reply #5 on: August 17, 2022, 05:54:52 AM »
Nice!

I wonder whether any game would break if this was fixed...


SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.503 seconds with 23 queries.