Since dual-playfields are supported now, vAmiga is nearly feature complete. Woohoo 馃嵑!
(Of course, there are trillions of bugs and compatibility issues to be worked on.)
The only missing feature (If I don't miss anything) is sprite collision detection.
Does somebody know a decent test-case for this? Professional games are not well suited for testing, because only a few of them use collision detection at all.
Could you relase a beta of vAmiga to try it ?
Archon and gravityforce are using sprite to playfield collision detection.
Rotor is the only game out there which uses playfield to playfield collision detection.
Most of emulators for android do not proper implement this. Three years ago I backported the code into the iAmiga project because I wanted to play Archon against a friend on an iPhone.
Emufreak/iAmiga#19
The current version can be downloaded here:
http://www.dirkwhoffmann.de/vAmiga/vAmiga_0.26.zip
Don't be confused that the mouse pointer is now visible outside the main screen. Making shift register handling more accurate has broken the old border drawing code.
Archon and gravityforce
That's good to know! Unfortunately, both games do not run yet. 馃檨
Best would be some kind of a demo program (maybe on some Fish disk) that allows the user to move some simple sprites and to inspect the detection register.
Sprite collision detection is up and running.
Current scores (tests collision1, ..., collision7 from vAmigaTS repo):
vAmiga: 7/7 馃槑
UAE: 6/7 馃き
OK, I have to admit that UAE's better than vAmiga in every other respect 馃槈.
Because collision detection is both expensive and rarely used, I added three user-options to the compatibility preferences letting the user enable or disable sprite-sprite, sprite-playfield, and
playfield-playfield collision detection individually. UAE and SAE have similar options.

Seems as sprite to playfield test in Archon II fails ? The guy in the fire is supposed to loose all his energy. But he is invincible .... Although simple shooting collision works (sprite to sprite) playfield to sprite seems not.
@dirkwhoffmann I tested this with the latest changes from vAmiga/master this morning. Will do some cross check tests in SAE this evening...
Wasn't Archon the game that didn't load in previous releases?
BTW, I am working on the ExtRom branch most of the time and only merge back into the master branch occasionally. Therefore, the master branch is not always up-to-date.
I'll give Archon a try and report back...
I'm really thrilled that both Archon and Archon II do run in vAmiga now 馃榾.


Sprite-to-sprite collisions seems to work correctly. In Archon I, if I let my Orc knock his stick over the knight's skull, I can see the following debug message in the console (if CLX_DEBUG is set to 1):
[5644] (122,226) 037E3C BCBSDA 602C 0440 Denise: Collision between 01 and 67
Also, the knight dies when I do that. (Poor guy, but it's all in the sake of science 馃檮.)
I didn't check sprite / playfield collisions, because I don't know how the real game behaves. I would be surprised if sprite / playfield collision don't work, because test cases collision1 to collision7 all pass in vAmiga now. There might well be a bug of course, because my collision tests do not cover all possible combinations though (there are just too many).
The master branch is up-to-date now. I've just merged in the ExRom branch.
In Archon II you have the four playgrounds to fight in: earth water air and fire. In each you have a wizard who can spell casts for example summon an orc. Each playground has its specific battle-background-elements: earth has some rocks, fire some fire fields.. When you let your character on a earth battleground run against a rock then it can not walk through. It is stopped before the rock. When you let your character run into the fire on a fire battleground then it burns and its energy is depleted continuosly.
But in vAmiga there is no burning in da fire. So what I suspect is, that these background graphics is sprite to playfield collision and that it maybe does not work already.
When you let your character run into the fire on a fire battleground then it burns and its energy is depleted continuosly.
Indeed, I can run into the fire without loosing energy. I'll investigate what's happening there...
What I found out so far:
Left player is sprite 6
Right player is sprite 7
When I run into the fire (with sprite 7), Denise detects a collision with PF2:
[7301] (102,226) 02C298 BCBSDA 602C 01C0 Denise: S6 collides with PF2
[7302] ( 99,226) 02C292 BCBSDA 602C 01C0 Denise: S6 collides with PF2
The debug message is misleading (S6 is sprite 7, because counting starts at 0 internally).
Time to check how the game behaves on a real machine 馃槑. Stay tuned...
More findings:
When I walk into the fire, the following happens internally:
[8005] ( 99,226) 02C298 BCBSD- 602C 0040 Denise: <6> b[769] = 2A e1 = 10 e2 = 2A, c1 = 10 c2 = 2A
[8005] ( 99,226) 02C298 BCBSD- 602C 0040 Denise: S6 collides with PF2
[8005] ( 99,226) 02C298 BCBSD- 602C 0040 Denise: <6> b[755] = 2A e1 = 10 e2 = 2A, c1 = 10 c2 = 2A
[8005] (100,226) 02C28E BCBSD- 602C 0040 Denise: S6 collides with PF2
[8005] (100,226) 02C28E BCBSD- 602C 0040 Denise: <6> b[769] = 2A e1 = 10 e2 = 2A, c1 = 10 c2 = 2A
[8005] (100,226) 02C28E BCBSD- 602C 0040 Denise: S6 collides with PF2
[8005] (100,226) 02C28E BCBSD- 602C 0040 Denise: <6> b[755] = 2A e1 = 10 e2 = 2A, c1 = 10 c2 = 2A
[8005] (101,226) 02C298 BCBSD- 602C 0040 Denise: S6 collides with PF2
[8005] (101,226) 02C298 BCBSD- 602C 0040 Denise: <6> b[769] = 2A e1 = 10 e2 = 2A, c1 = 10 c2 = 2A
[8006] ( 99,226) 02C298 BCBSD- 602C 0040 Denise: S6 collides with PF2
Assuming that the bitplane data is correct, Denise is doing the right thing. It detects a collision with PF2, but not with PF1.
I also observed the following in vAmiga:
When I just hit a few pixels of the fire, no energy is lost (I guess these pixels are drawn in PF1):

But when I do this, energy does get lost:

This means that you do loose energy in the fire (in vAmiga), but you have to walk in the middle of it. My hypothesis is that it is a game feature. Hitting just a few fire pixels are not supposed to hurt.
To reproduce, play human vs. human to have enough time for experiments.
I need to doublecheck on my A500...
Just doublechecked...
There is indeed an issue. In vAmiga, it seems like a collision is detected only if you walk through the bottom part of the fire. If there are three fires in a row, you can just walk through the upper and middle fire without getting hurt.
On the A500, you can do the following without being hurt, but you can never walk through a fire as it is possible in vAmiga:

Bottom line: vAmiga misses some collisions.
Nailed it. Now fire hurts in vAmiga, too 馃く.
The bug was hidden in function Denise::drawSprites():
The culprit is this code portion:
if (col) {
if (z > zBuffer[pos]) {
iBuffer[pos] = baseCol | col;
zBuffer[pos] |= z;
}
if (z > zBuffer[pos-1]) {
iBuffer[pos-1] = baseCol | col;
zBuffer[pos-1] |= z;
}
}
Background: vAmiga utilizes a z buffer to implement the display hierarchy. The depth value is chosen in a way that it codes some meta-information besides the depth of the pixel. I.e., there is a dedicated bit for each sprite indicating if the sprite is solid at this pixel position. In the old code, the sprite flag was only set when the sprite was in front which is wrong (the flag has to be set whenever the sprite pixel is solid).
Here is the (easy) fix:
if (col) {
if (z > zBuffer[pos]) iBuffer[pos] = baseCol | col;
if (z > zBuffer[pos-1]) iBuffer[pos-1] = baseCol | col;
zBuffer[pos] |= z;
zBuffer[pos-1] |= z;
}
The fix has already been checked in and merged into the main branch.
Just tested the firewalk. It works as expected now I would say ! I can run from the screen top into an fire and the energy starts immedialty to deplete. Very cool.
I wanted to test more sprite2playfield collisions in games... One nice candidate for sprite to playfield collisions is gravityforce, but the disk does not start at all yet. We can test this somewhen later when vAmiga has gotten more refined over the time....
Since Archon is a very nice test candidate for both sprite2pf and sprite2sprite collision. And it runs so well in vAmiga. Dirk thats really awesome.
Rotor is the only game I know out there which uses playfield to playfield collision detection. I will give it a try in the evening...
tried to check rotor for playfield2playfield ... but it get stuck while loading.... shortly before it enters what seems to be an endless loop ... there we can spot these debug output lines ...
[634] (281,211) 00F014 BCB-D- 606C 1780 [0245E0] Copper: ***** BFD FLAG NOT IMPLEMENTED YET
[634] (288, 46) 00F13A BCB-D- 606C 1780 [0245E4] Copper: ***** BFD FLAG NOT IMPLEMENTED YET
[634] (288, 47) 00F13A BCB-D- 606C 1780 [0245E4] Copper: ***** BFD FLAG NOT IMPLEMENTED YET
[634] (288, 48) 00F13C BCB-D- 606C 1780 [0245E4] Copper: ***** BFD FLAG NOT IMPLEMENTED YET
[634] (302, 6) 00F0E0 BCB-D- 606C 1780 [0245E8] Copper: ***** BFD FLAG NOT IMPLEMENTED YET
[634] (303, 30) 00F0B8 BCB-D- 606C 1780 [0245EC] Copper: ***** BFD FLAG NOT IMPLEMENTED YET
maybe it is also too early for that game test ... we have to come back here somewhen later I guess... 聽馃
The "infinite loop" seems to be created simply by the huge amount of warning messages of type
Copper: ***** BFD FLAG NOT IMPLEMENTED YET
It's generated in Copper.cpp
case COP_WAIT1:
if (verbose) debug("COP_WAIT1\n");
if (getBFD() == 0) {
debug("***** BFD FLAG NOT IMPLEMENTED YET\n");
}
// Wait for the next free cycle
if (!agnus->copperCanRun()) { reschedule(); break; }
If the debug message is disabled, the game seems to run just fine 馃槑.


However, I'm not sure if PF/PF collision works, because this game is damn difficult 馃槚. I've broken 5 space ships in less than a minute 馃き. On the positive side, this means that the game does detect collisions between the ship and the wall.
I've just uploaded a new pre-release (0.32).
It should be compatible with Archon, Archon II, Sword of Sodan, and Rotor.
This time, I've uploaded it directly on Github:

It also comes with a brand new reset button 馃槑:

For implementing the reset, I had to shift a lot of stuff from functions _powerOn() to functions _reset(). When moving large portions of code, there is always the risk of breaking something. So you better fasten your seat-belts before pushing the button.
Playfield2Playfield Collision detection is working -> Confirmed
When you only disable pf/pf collision detection in the compatibility preferences of vAmiga then the spaceship flies through the walls (and the rotor game goes totally crazy ... ) Your ship can even fly beyond the boundary which the programmer has expected to be normal it seems. If you fly always in one direction then you fly into the outerspace of the chipram (Kuiper belt ?). Inevitably the game crashes then with a completely distorted random pixelated screen. I guess the game/blitter draws the spaceship everywhere in the memory ... maybe even in programm code which leads to a crash ... no MMU here ?
In contrast when pf/pf collision is enabled in vAmiga prefs, everything works as expected. Spaceship can not fly through walls then. So denise plays a sort of the role of MMU protection in this game. 馃
Conclusion: vAmiga is fully capable and compatible with all types of amiga hardware collision detection ! And that is soooo nice !!!
Your ship can even fly beyond the boundary which the programmer has expected to be normal it seems.
I suppose the spaceship first thought: "Oh cool, the walls are gone, I can escape". And then seconds later it fell over the Chip Ram cliff. That's a really sad fate. My own spaceships didn't do better. None of them reached level 2. 馃槩
Conclusion: vAmiga is fully capable and compatible with all types of amiga hardware collision detection !
馃コ Woohoo. I'll close this issue then and hope that we'll never have to reopen it again.
Most helpful comment
I've just uploaded a new pre-release (0.32).
It should be compatible with Archon, Archon II, Sword of Sodan, and Rotor.
This time, I've uploaded it directly on Github:
It also comes with a brand new reset button 馃槑:
For implementing the reset, I had to shift a lot of stuff from functions _powerOn() to functions _reset(). When moving large portions of code, there is always the risk of breaking something. So you better fasten your seat-belts before pushing the button.