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

[abu_the_monkey]

@pipper

I can get the stuttering to stop on the a4000 by adding the section between the Asterix

				; 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

				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
****************************************************************
				tst.l	d0
				beq	.ok
				move.w	ScreenBufferIndex,d0
				lea		ScreenBuffers,a1
				eor.w	#1,d0					; flip  screen index
				move.w	d0,ScreenBufferIndex
.ok
****************************************************************

how ever it is hit and miss as to if the next level will start (get background sound/music and the border but no 3d rendered image) . Best guess is it gets proper out of sync at this point. performance does seem slower but not tested the previous version to confirm this.

@Grond
any views on this? the code you posted for the fps counter contained a double buffer routine that makes sense in my head, but, implementing such stuff is beyond me at this point in time.

[grond]

Originally Posted by abu_the_monkey

@Grond
any views on this? the code you posted for the fps counter contained a double buffer routine that makes sense in my head, but, implementing such stuff is beyond me at this point in time.

The code I posted was written over 25 years ago, I never had any problems with it but it wasn't tested on many different hardware configurations, especially not on configurations with so different CPU speeds. <old man voice>All we had back in the day were 030s and perhaps the occasional 040</old man voice>

The double-buffering mechanism in the code you posted seems to be to flip a bit in a variable to indicate which screen is going to be the next to get displayed. This variable really only switches between 0 and 1 from what I see. I then gets used as an index to a table comprising a whopping two entries, the first buffer and the second buffer. In short, before the function gets called, the index will be flipped, the index will then be used to load the right pointer and the function will be called with the new screen buffer.

The way I remember it my code is pretty similar, I think I called my buffers "odd" and "even" (referring to the numbers of the screen the code renders) and just swap the variables around each time rendering of a buffer finishes. It probably is a few instructions shorter than this one because I don't use this index-loading approach but it shouldn't matter.

Now this ChangeScreenBuffer() function apparently fails (the fact that it could was new to me). From a quick search it seems that one reason for it to fail is that some system function or library (gadgets were mentioned) is drawing something on the screen or such. I wonder whether we should check how we set up the screen and the window because we shouldn't have any gadgets and also no right mouse-button action which IIRC calls a hook into intuition so that a menu bar can be drawn (do you see any flickering at the top of the screen when the right mouse button is pressed?). Anyway, after the call fails, you flip the bit again and thus try to change the buffer to be displayed to the one that is already being displayed. I guess the system will not mind replacing the screen buffer by itself but I suspect that the "synchronisation" between the buffer to render to and the buffer to display may be affected. If the call succeeds, perhaps rendering happens in the same buffer as the one that is being displayed? This is just a wild guess, I don't know the code well enough.

[abu_the_monkey]

@grond
thanks for your input, gives us more avenues to explore for a fix

[Karlos]

I managed to test the latest version and can definitely reproduce the frame flipping bug. In C, when calling the change screen buffer it's normal to have to check for failure, IIRC. Revisiting some very old code of mine...

https://github.com/0xABADCAFE/ancien...native.cpp#374

I remember having all kinds of annoying problems flipping the buffer properly (this was under CGX/RTG) and just after the commented out TODO block you can see that in the end I resorted to busy polling the ChangeScreenBuffer. I remember recording loop counts in there and it almost always worked first time back then.

[grond]

Originally Posted by Karlos

I resorted to busy polling the ChangeScreenBuffer. I remember recording loop counts in there and it almost always worked first time back then.

That's exactly what I propose here (I probably wasn't clear enough). The code would then look like this:

.nok:
				CALLINT	ChangeScreenBuffer		; DisplayMsgPort will be notified if this image had been fully scanned out
****************************************************************
				tst.l	d0
				bne	.nok
.ok
****************************************************************

After this we might want to find the root cause but this, at least, is a way of dealing with the failed call. Of course, we could also count the failed attempts and abort e.g. after a second or so of failed attempts to get a clean exit from the program if something is really wrong.

I still wonder whether the problem has anything to do with the right mouse button or some sort of messaging for the window. When did the problem first arise?

[Karlos]

@grond

Very clear, thanks. I never was able to find out why the call failed back in the RTG days but it was also quite infrequent as I recall. This seems to be much more frequent, multiple times a second.

[grond]

Btw, a0 should probably be reinitialised before calling ChangeScreenBuffer() again. I don't think we should rely on a0 being kept unchanged. However, the reinitialisation should not have the flipping stuff.

Edit: I accidentally wrote d0 when I meant a0.

[Karlos]

Originally Posted by grond

Btw, d0 should probably be reinitialised before calling ChangeScreenBuffer() again. I don't think we should rely on a0 being kept unchanged. However, the reinitialisation should not have the flipping stuff.

Yep, clobber list.

[abu_the_monkey]

ok, so after butchering everything looking for what caused the stuttering I found changing ScreenBufferIndex from
ScreenBufferIndex dc.w 0
to
ScreenBufferIndex dc.w 1
fixed it.

[abu_the_monkey]

I guess the first ScreenBufferIndex flip before the start of the main loop puts it out of sync?

[abu_the_monkey]

spoke too soon.
this puts it out of sync when you complete a level and starting a new one.

[abu_the_monkey]

adding a test for zero in the initial screen flip may be enough to know which buffer was last displayed I guess? and keep it in sync

XXX				move.w	ScreenBufferIndex,d0
				lea		ScreenBuffers,a1
****************************************************************
				tst.w	d0
				beq.s	.zero
****************************************************************
				eor.w	#1,d0					; flip  screen index
.zero
				move.w	d0,ScreenBufferIndex

				move.l	(a1,d0.w*4),a1			; grab ScreenBuffer pointer

				move.l	MainScreen,a0
				CALLINT	ChangeScreenBuffer

then again, it may not start the message queue and wait forever...

[grond]

Could you try this:

.nok
	move.w		ScreenBufferIndex,d0
	lea		ScreenBuffers,a1
	move.l		(a1,d0.w*4),a1			; grab ScreenBuffer pointer
	move.l		MainScreen,a0
	CALLINT		ChangeScreenBuffer
	tst.l		d0
	bne		.nok

[abu_the_monkey]

I am testing this horror at the moment

XXX				move.w	ScreenBufferIndex,d0
				lea		ScreenBuffers,a1
****************************************************************
				tst.w	d0
				beq.s	.zero
****************************************************************
				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
				bra	.done
.zero
				eor.w	#1,d0					; flip  screen index
				move.l	(a1,d0.w*4),a1			; grab ScreenBuffer pointer

				move.l	MainScreen,a0
				CALLINT	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
.done

not got out of sync yet, but, a bit of a mess

[abu_the_monkey]

think I am getting confused

[abu_the_monkey]

@grond

I will try your code later today, but, I think I have tried something similar and it crashed, hard. It is for the double buffer in the main game loop yes?

the code snippet I posted is setup code before entering the main game loop just to re-sync the screenbuffer to the screenbufferindex and start the message queue for DisplayMsgPort. hope this makes sense.

[abu_the_monkey]

@grond

sadly your code did not yield the desired result, the border graphic is displayed but that is as far as it goes, no sound and no input response. it didn't crash the system, just caught in an endless loop?

[robinsonb5]

Originally Posted by grond

Could you try this:

.nok
    move.w        ScreenBufferIndex,d0
    lea        ScreenBuffers,a1
    move.l        (a1,d0.w*4),a1            ; grab ScreenBuffer pointer
    move.l        MainScreen,a0
    CALLINT        ChangeScreenBuffer
    tst.l        d0
    bne        .nok

Shouldn't that last "bne" be "beq"? ChangeScreenBuffer returns non-zero on success, zero if the update couldn't be performed, I think?

[abu_the_monkey]

from the docs

RESULT
Returns non-zero if the operation succeeded. Returns zero
if the operation cannot be performed. This function will
fail if Intuition's state cannot permit it, for example the
user is playing with menus or gadgets.

what we speculated was that something was causing ChangeScreenBuffer to fail, so checking if it returned zero, and busy loop until non zero is returned.

so yes you are correct it should be beq .nok

however the stuttering is still there. (it is displaying the buffer it is rendering to and changing to a previously rendered buffer)

the reason for this I believe is when the buffers get flipped the first time (outside of the main game loop) it gets out of sync, this is what the snippet i posted above is meant to remedy.
and so far with limited testing it works.

[abu_the_monkey]

here is an executable if anyone wishes to try it and let us know of any issues.