English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General > Coders. Releases

 
 
Thread Tools
Old Yesterday, 01:24   #621
abu_the_monkey
Registered User

 
Join Date: Oct 2020
Location: Bicester
Posts: 258
@pipper

I can get the stuttering to stop on the a4000 by adding the section between the Asterix
Code:
				; 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.
abu_the_monkey is offline  
Old Yesterday, 10:00   #622
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 1,337
Quote:
Originally Posted by abu_the_monkey View Post
@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.
grond is offline  
Old Yesterday, 23:06   #623
abu_the_monkey
Registered User

 
Join Date: Oct 2020
Location: Bicester
Posts: 258
@grond
thanks for your input, gives us more avenues to explore for a fix
abu_the_monkey is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Alien Breed 3D II The Killing Grounds RTG patch Angus Retrogaming General Discussion 62 06 July 2021 23:30
Alien Breed & Alien Breed '92: SE - delay when picking up items / opening doors Ian support.WinUAE 16 23 December 2016 15:50
Alien Breed 3D II : The Killing Grounds code booklet alexh support.Games 19 10 October 2012 22:17
Alien Breed 3D 2 - The Killing Grounds Ironclaw support.Games 12 13 September 2005 13:07
HD Version of Alien Breed I ? Kintaro request.Old Rare Games 20 31 July 2003 10:48

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 03:34.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.
Page generated in 0.08041 seconds with 15 queries