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

[abu_the_monkey]

@pipper
I have raised a PR for the changes made to try and fix the double buffer sync issue, feel free to reject it if you have ideas for a better (more correct) solution

[grond]

When did this double buffer sync problem start or has it been there all the time?

[abu_the_monkey]

I think (and could be wrong) it started when the double buffering method was changed from using ScrollVPort to ChangeScreenBuffer. or at least that is when the issue became obvious visually. pipper could answer this better.

[Angus]

(Disclaimer: I don't know nuffink.)

It couldn't have any relationship with the hardcoded mouse/keyboard controls?

P.S. I will try to run the latest exe later today. (1200 060)

[Angus]

Originally Posted by Angus

P.S. I will try to run the latest exe later today. (1200 060)

I'm probably doing something daft (again) but I just get an iconx shell opening which says, EXECUTE invalid directive. I basically just put the new exe into the drawer which has a working exe, copied the working exe's icon and renamed it to the new executable's name. hiresBUFF.info The older exe still works very well.

[pipper]

Originally Posted by grond

When did this double buffer sync problem start or has it been there all the time?

It started with me trying to switch from ScrollVPort to ChangeScreenbuffer as method to switch the bitmap pointers. This was to solve two problems 1) prevent occasional visible glitches when switching the bitmap mid frame 2) sync the switch to Vsync an thereby limit the frame rate on extremely fast setups like WinUAE JIT

I had reverted the patch in meantime in the master branch. Something about ChangeScreenbuffer doesn’t work right in our context and it’s documentation is not helping.

[grond]

Does the code have more than one task running in parallel? I wonder how the screen computation / display routine could get out of sync if not. The screen computation (or c2p / fastmem-to-videomem-copy routine) should load the pointers much in the same way it gets loaded for the ChanceScreenBuffer() call. If all of this happens sequentially, I don't see how it could get out of sync.

[pipper]

Some parts of the engine run in the vblank interrupt. I have not yet determined which parts those are. One could say this is effectively running two threads…

[abu_the_monkey]

Maybe the screenbufferindex flip should be moved to after the call to changescreenbuffer?

                                move.w	ScreenBufferIndex,d0
				lea	ScreenBuffers,a1
				;eor.w	#1,d0					; flip screen index
				;move.w	d0,ScreenBufferIndex
				move.l	(a1,d0.w*4),a1			; grab ScreenBuffer pointer
				move.l	MainScreen,a0
				CALLINT	ChangeScreenBuffer		; DisplayMsgPort will be notified if this image had been fully scanned out
                                *****************************
                                move.w	ScreenBufferIndex,d0
				eor.w	#1,d0					; flip screen index
				move.w	d0,ScreenBufferIndex
                                *****************************

edit: missed a line out

[abu_the_monkey]

Originally Posted by Angus

I'm probably doing something daft (again) but I just get an iconx shell opening which says, EXECUTE invalid directive. I basically just put the new exe into the drawer which has a working exe, copied the working exe's icon and renamed it to the new executable's name. hiresBUFF.info The older exe still works very well.

check your PM's and the zone

[abu_the_monkey]

did anyone get a chance to test the exe I posted with a 'hack' to try and keep the double buffering in sync? Angus said he had not seen issues but it felt slightly slower, would be nice to know of any other experiences good or bad.

[abu_the_monkey]

clearing the DisplayMsgPort and setting ScreenBufferIndex to 0 (so the start conditions are always the same) before entring the main game loop seems to be a better solution to the stuttering double buffering.

pre main game loop

syncDblBuffer:
				move.l	a6,-(sp)

				;empty DisplayMsgPort and set ScreenBufferIndex to 0
				;so the starting point is the same every time
.clrMsgPort			move.l	DisplayMsgPort,a0
				CALLEXEC GetMsg
				tst.l	d0
				bne.s	.clrMsgPort
				move.l	#0,ScreenBufferIndex

				; Flip screen once, to initiate the message queue.
				; Otherwise we'd be stuck on the very first frame
				; waiting on DisplayMsgPort for a message that'll
				; never arrive.
.nok
				lea	ScreenBuffers,a1
				move.w	ScreenBufferIndex,d0
				move.l	(a1,d0.w*4),a1			; grab ScreenBuffer pointer
				move.l	MainScreen,a0
				CALLINT	ChangeScreenBuffer		; DisplayMsgPort will be notified if this image had been fully scanned out
				tst.l	d0
				beq.s	.nok

				move.w	ScreenBufferIndex,d0
				eor.w	#1,d0					; flip  screen index
				move.w	d0,ScreenBufferIndex

				move.l	(sp)+,a6
				rts

main game loop

doDblBuffer:
				move.l	a6,-(sp)
				; Flip screens

				; Wait on prior frame to be displayed.
				; FIXME: this could waste time synchrously waiting on the scanout to happen if we manage
				; to fully produce the next frame before the last frame has been scanned out.
				; We could move the screen flipping into its own thread that flips asynchronously.
				; It does not seem very practical, though as this scenario

				move.l	DisplayMsgPort,a0
				move.l	a0,a3
				CALLEXEC WaitPort
.clrMsgPort			move.l	a3,a0
				CALLEXEC GetMsg
				tst.l	d0
				bne.s	.clrMsgPort
.nok
				lea	ScreenBuffers,a1
				move.w	ScreenBufferIndex,d0
				
				move.l	(a1,d0.w*4),a1			; grab ScreenBuffer pointer
				move.l	MainScreen,a0
				CALLINT	ChangeScreenBuffer		; DisplayMsgPort will be notified if this image had been fully scanned out
				tst.l	d0
				beq.s	.nok

				move.w	ScreenBufferIndex,d0
				eor.w	#1,d0					; flip  screen index
				move.w	d0,ScreenBufferIndex

				move.l	(sp)+,a6
				rts

[Karlos]

@Abu

I'll add your fork as a remote and test tomorrow. I've been totally unable to make time for it. You have two open pull requests against the main repo. Which branch would you like me test our first? Pipper granted me collaborator access so Incan merge approved work. We are quite a few hours apart timezone wise.

[abu_the_monkey]

@Karlos
see what you make of the double buffer 'hack' first as I could be beating a dead donkey and miss understanding all of it, but, the last changes (in the post above) made sense to me in my tiny little mind .

The other branch was for pipper to cherry pick any useful ideas from, not necessarily the way I (with help from others) implemented them, like the fps counter and timed lighting etc. most of which I felt would be made redundant soon with the rate of progress you two are making.

[grond]

@Abu: didn't see where you are setting the framebuffer index to zero and I'm not sure it's a good idea. But it is a very good idea to empty the message queue! The code you posted looks good.

One thing that has been lurking in my brain for some time now is the fact that the swapping of the index (the instructions around the EOR) isn't protected against an VBL interrupt happening right in the middle of it. Perhaps this seems academic but if frame computation time is nearly 1/50 seconds or an integer multiple of it this could become a factor. Perhaps even the whole framebuffer swapping thing needs to be protected. I haven't really spent much thought on the whole thing yet.

[abu_the_monkey]

odd but I thought interesting, ab3d2 (with the original game levels) only requires 512kb of chip ram + 4mb of fast to run (the first levels at least and in winuae), Karlos' mod (and maybe others) require 1mb chip ram + 4mb fast.
I may have to test this on real hardware using TUDE (a Degrader) at some point.

I guess it is just using the chip ram as a frame buffer and to hold sound for paula?

[abu_the_monkey]

@Angus

here is a rebuild of the double buffer version I posted before but with the fps counter which can be enabled/disabled by pressing 'F8' if you feel like comparing it to previous builds

[sokolovic]

Just tested the 2 versions (AB3D2 optimized and Karlos mod) on an A1200 with Blizzard 030/50Mhz and this is amazing. The game is now perfectly playable with this configuration, even in full screen with details lowered.

What a shame they didn't release it as such, it is really a nice old school FPS.

Thanks everyone here for the great work (now waiting an WHD version to properly put it in my WHD games repertory )

[Karlos]

I made the mistake of downloading project Osiris to remind myself of some of the great AB3D levels. And suddenly the time id set aside to actually test the latest build disappeared. The two may be connected.

[Karlos]

Originally Posted by abu_the_monkey

odd but I thought interesting, ab3d2 (with the original game levels) only requires 512kb of chip ram + 4mb of fast to run (the first levels at least and in winuae), Karlos' mod (and maybe others) require 1mb chip ram + 4mb fast.
I may have to test this on real hardware using TUDE (a Degrader) at some point.

I guess it is just using the chip ram as a frame buffer and to hold sound for paula?

The latest version of the mod takes advantage of pipper removing the restriction on the music .mod file. It has probably gone unnoticed that the original bass pulse transforms into the weird breaks I had before and then back. It was all done in OctaMED SS, rendered to disk, chopped back to samples that could be sequenced and then converted back to a mod. It's bigger than it was

You can hear it here after I go through the teleporter. Though the audio capture is a bit screwed up... [ Show youtube player ]