Compileable version of Alien Breed 3D II - The Killing Grounds

[Karlos]

@pipper - confirmed. The regular c2p for fullscreen uses a literal #232 still on around line 39 of chunky.s. This is why the HUD is working, except in the teleport version where it used FS_HEIGHT.

[Karlos]

How do we feel about using the 240 hack as an interim measure until we get to the very bottom of it?

I've updated the PR accordingly and included annotation specific to the hack.

[pipper]

Originally Posted by grond

Does this mean a good c2p function that converts from 160xHEIGHT to 320xHEIGHT would be useful?

We have a routine that does this. The more challenging part is making the renderer render to only 160 pixels wide while keeping the aspect ratio of the objects in the world unaffected. There's a "doublewidth_test" branch that does this, but sacrifices the "normal" rendering on the way
It was meant as a test to see how many parts of the code are affected and if there's a way to unify the rendering of the various sizes.

[abu_the_monkey]

I know I am probably being thick but, where does the 232 height come from?
by that I mean why was it set to 232 and not 240? 256 screen height -16 pixels for the boarder = 240

[Karlos]

Originally Posted by abu_the_monkey

I know I am probably being thick but, where does the 232 height come from?
by that I mean why was it set to 232 and not 240? 256 screen height -16 pixels for the boarder = 240

240 is the height it should have been based on multiplying the original 192*160 view by 1.5. presumably this didn't leave enough space for the HUD so it got truncated a bit.

[abu_the_monkey]

no it is me being thick. I forgot that there is text at the bottom of the screen and so accounts for the extra 8 lines required. the text is just not output to the screen on the new builds.

[Karlos]

Originally Posted by abu_the_monkey

no it is me being thick. I forgot that there is text at the bottom of the screen and so accounts for the extra 8 lines required. the text is just not output to the screen on the new builds.

I think the original used a separate view for that, it was 640 wide.

[Karlos]

Damn. I have to say, I'm developing a certain sympathy for the original level designers. It's easy to criticise the original levels but damn it's difficult to avoid corrupting the PVS solution. I'm have been working a simple storage area. You know, big space, lots of stacked crates and such. Even following the rules to the letter you get the hall of mirrors issue even in areas nowhere near the bit you are working on.

[Karlos]

@pipper - raised an unrelated PR to eliminate old dead code (stuff commented out since first commit and stuff identified as unused and commented out in recent changes).

[abu_the_monkey]

current build of main for ZyberSE to test on Pimiga 3 regarding issue #42

[abu_the_monkey]

a couple of clips of issues flagged by ZyberSE

"Shaking" with JIT enabled Pimiga 3
[ Show youtube player ]
this may be an emulator issue.

"look behind key" in mouse control
[ Show youtube player ]
this is present in winuae, not tested on real hardware

"look behind key" in mouse control
[ Show youtube player ]
this is present in winuae, not tested on real hardware

[abu_the_monkey]

@Angus

can you confirm that these issues are or are not present on a real amiga setup?

[Angus]

Will do. Is this using the earlier build I've got or the one in post 1170?

[abu_the_monkey]

either I guess as I had noticed the 'look behind key' issue before the latest build but I think the '(' and ')' keys for pixel resolution are also affected in the same way.

[Karlos]

Originally Posted by abu_the_monkey

either I guess as I had noticed the 'look behind key' issue before the latest build but I think the '(' and ')' keys for pixel resolution are also affected in the same way.

I've yet to test those because they aren't sensibly mapped in my UAE configuration.

[abu_the_monkey]

yeah they are not mapped by default which was confusing to me early on.
WHY WILL IT NOT CHANGE RESOLUTION!

[Karlos]

Those PRs are now merged.

[Angus]

Originally Posted by abu_the_monkey

@Angus

can you confirm that these issues are or are not present on a real amiga setup?

It all seems pretty stable visually with none of that dancing about shown in the youtube video.


The rear view feature however does do the same strobe effect between both views, though.



I noticed that if you "jab" the key briefly you can use it quite effectively as it goes to rear view and back in a controllable manner.



My recollection is that in the original game t was just a "quick glance" feature that would not stick to rear view - but I may have mis-remembered....

[abu_the_monkey]

cheers Angus,

the 'strobe effect' when using the 'look behind key' only happens in mouse control, with joystick/keyboard control holding down the 'look behind key' locks you to rear view until you release it.
this bug is present in the original Team17 release also.

[abu_the_monkey]

@Karlos

could you also apply the 'hack' (replace FS_HEIGHT with FS_C2P_HEIGHT) for screen positioning in the 2x1 1x2 and 2x2 modes? they suffer the same hud overdraw in the current 'main' branch