jostein_aarbakk wrote:I am currently programming a simple game for OS4 (non-commercial, just for fun), and are now working on a screen with 2D scrolling.
I have no problems making a glitch-free scrolltext, as long as it's far down on the screen.
However, if I put my scrolltext on the upper part of the screen (especially at the upper position 0), it doesn't scroll smooth anymore (graphics glitches and occasional 1-frame freezes now and then).
jostein_aarbakk wrote:The program is made in C, and I use Intuition & Graphics library (no SDL, MiniGL or similar).
Scrolling is made by using the Graphics library "BltBitMapRastPort"/"BltBitMap"-procedures.
It's "single buffered", but the graphics are so light, that this shouldn't be a problem.
The graphics I "blit" is very small (672x32 pixels, 32 colours).
The screen resolution is 640x512 pixels, and of course fullscreen mode on a separate screen.
On my system, I have the following issues:
1) Graphics glitches when my program scrolls an object on the screen, using a loop with WaitTOF() in it:
=> See description of the issue above.
jostein_aarbakk wrote:2) The Graphics.library function "VBeamPos" increases by 1 position for each vertical blank (after each WaitTOF-call).
=> See the output I got below. It's consistently +1 compared to the previous VBL. This is strange, as I would expect the value to be approximately fixed.
This must either be a bug in the VBeamPos-function, or it indicates a VBL synchronization issue that leads to the issue described in 1) above and 3) below.
jostein_aarbakk wrote:3) Graphics glitches when my program scrolls an object upwards on the screen, using a VBL-interrupt containing a "BltBitMapRastPort"-call (through Exec's "AddIntServer"-function):
=> The glitches are different than for case 1). The scrolling runs smooth, except for a few fixed intervals (a horizontal stripe moving upwards on the screen).
Hans wrote:As a general rule, if you want smooth graphics without tearing, then you should use double-buffering. You can use true double-buffering via IIntuition->ChangeScreenBuffer(), or use vertical blanking interrupts and a blit from the back-buffer.
Hans wrote:AFAIK, Picasso96 doesn't support VBeamPos; that's a classic Amiga chipset thing.
Hans wrote:Are you sure that you are catching the VBL interrupt? I don't think that you even have access to the information required to know which interrupt to use. Plus, what if VBL interrupts are disabled? WaitTOF() and ChangeScreenBuffer() still work; your interrupt routine won't.
Hans wrote:P.S. This message board also has a forums for developer topics. You'll see down the bottom of theindex page.
So; I suspect WaitTOF() isn't precise enough.
jostein_aarbakk wrote:Hans wrote:Are you sure that you are catching the VBL interrupt? I don't think that you even have access to the information required to know which interrupt to use. Plus, what if VBL interrupts are disabled? WaitTOF() and ChangeScreenBuffer() still work; your interrupt routine won't.
I am sure I have done it right according to how the vertical blanking interrupts should be setuped on the Classic.
But if things have changed in OS4 compared to the classic, there might of course be something I have overlooked.
The interrupt part of my program is "ported" from a program I have made on my classic Amiga, and is programmed according to what the ROM Kernel Ref. manuals says.
It works perfect on my Classic, and it works on OS4 (but not perfect. Some "tearing" every 3 seconds or so. That is, a horizontal "stripe" moving slowly in the vertical direction.).
Technically, the "intNum"-parameter passed to the AddIntServer, is INTB_VERTB.
The Interrupt structure's "ln_Type" passed to AddIntServer, is set to NT_INTERRUPT.
jostein_aarbakk wrote:Hans wrote:P.S. This message board also has a forums for developer topics. You'll see down the bottom of theindex page.
Ok. I'll have that in mind for the future, even if they are like this one (to address possible bugs).
Just a status:
I am happy to announce that after "playing" some more with my code, I have gotten the program to scroll smoothly 95% of the time during a 10 sec period, and sometimes 100%.
Much better than before.
Solution: To synchronize the changeScreenBuffer()-call, I needed to make use of Exec's message ports as described in the autodocs for IGraphics->AllocDBufInfo.
jostein_aarbakk wrote:Avoiding use of the "Limpid clock" also helped (of some weird reason).
jostein_aarbakk wrote:If there are ways to reduce the risk for making the remaining minor "stalls" appear, I would be happy (I am kind of obsessed by perfect, smooth scrolling).
jostein_aarbakk wrote:The previous version of my program relied on WaitTOF() only, in order to synchronize the changeScreenBuffer()-call, and that just didn't do it (lead to random, clearly visible "stalls" in the scrolling now and then.).
The program code is ok.
jostein_aarbakk wrote:Regarding the monitor tooltype; Interrupts was on.
jostein_aarbakk wrote:PS: My post was written with the best intentions, and written with the details needed to use them sometime in the future to check if there is a bug somewhere (hardware-related? OS? ...).
I was not complaining in any way. I am an Amiga-enthusiast, and want the platform to be as good as possible.
Before I report bugs, asks for help etc., I always do proper research in advance. I don't want to cause unnecessary work for others.
Is LimpidClock showing seconds? Analog or digital clock (or even both)? Could be interesting to see if anything changes if you turn off seconds in LC.Hans wrote:Interesting. Maybe "Limpid clock" is running at a higher priority level, and/or hogging the CPU for large chunks of time. That could delay the completion of your program's rendering until after the next VBlank, resulting in a one frame stall.jostein_aarbakk wrote:Avoiding use of the "Limpid clock" also helped (of some weird reason).
thomasrapp wrote:LimpidClock refreshes every second, no matter if the seconds hand or even the entire clock is switched of.
Users browsing this forum: No registered users and 1 guest