&H3DA And Other bits running in the background of programs.

[Clyde]

I've seen this used in a few programs, and would like to know a little more about it please, if anyone does.
It's a Hex address that some how controls Syncing, that is all I know about it used in the following way.

Code: [Select]

wait &H3DA,8

And also, I wondered if any of you dudes knew if there's any other checks / libs that are hidden and are running in the background of FB creations.
As I've been doing a bit of stuff dealing with mostly Bitmap scrollers and notice a heck of alot of slow down here and there. Or is it, to do with Windows tasks / processes interfering.

Cheers and many thanks for any info,
Clyde.

[relsoft]

wait &h3da, 8 technically should not work in windows.  It's there because of old QB compatibility.  FB does not actually use port 3dah when you call wait but instead calls an internal GFX funk called screensync. :*)

[Rattrapmax6]

lol, when I see it I'm like  -"They still use that?!?!"

I much rather double buffer, and in OpenGL use Flip....

Double Buffer:

Code: [Select]

SCREENRES Width, Hight, 32, 2
DIM AS BYTE P1, P2 = 1

DO
     SCREENSET P1, P2
     SWAP P1, P2
     CLS
     'Draw Stuff
LOOP UNTIL (Whatever)
Works a heck of a lot better than ScreenSync or WAIT &h3da, 8.... Least for me anyway..  ..

WAIT &h3da, 8 does look geekier though.... 

[relsoft]

A double buffer won't limit your FPS.

[Clyde]

Ive seen 3DA used in TinyPtc programs. And thanks for clearing that up.

Cheers Clyde.

[Rattrapmax6]

I've seen it used in QB, FB, OpenGL, etc.... and I've actualy used it back in my old QB days, and a lil when I started FB.... 

A double buffer won't limit your FPS.

I normaly use time-based-movement....  .... Dialing in my position advancments judging on how fast the computer can wind up.. So far it's stable on any computer fast enough to run it in the first place.. Thus, what ever speed it's running on my computer, I can trust that's how it's going to look on someone elses computer.... =)

http://www.freebasic.net/forum/viewtopic.php?t=1340
^ I called it PPS (Pixel Per Second or Positions Per Second), when it's actualy called Time Based Movement (Which I didn't find out until finding my trusty formula a month later in a Pro-game design book, under the title "Time Based Movement" )

[relsoft]

He was asking what exactly is wait &h3da,8.

[Rbz]

Yep, the &H3DA,8  command is used for wait for vertical retrace for DOS/VGA gfx mode, so it's useless for TinyPTC, below an example for ASM code.

Code: [Select]

;---------- Wait for vertical retrace
 mov dx,03DAh
.wait_for_retrace:
 in al,dx
 test al,8
 jz .wait_for_retrace
;------------------------------------

[relsoft]

The call to that is "emulated".  It actually would work with TPTC to limit the fps in win32 programs. But why would we use t when we could just use screensync?

[Rbz]

Hmm, very strange, relsoft dude, when I use ScreenSync for tinyPTC, I can't see any difference.  In the FB manual the autor say that this command is used for GFXlib.  Â

Syntax

SCREENSYNC

Description

This GfxLib statement stops the execution of the program until the graphics card signals it has ended tracing a frame and is going to start the new one. If the program uses the small interval of time between frames to redraw the image, the flickering is greatly reduced.
The use of the QB-compatible form WAIT &H3DA,8 is deprecated.

[Optimus]

I wish we had some good screensync function in windows without screen refresh bugs ;P

The nicest use I made with it is WAIT &H3DA, 1, 1: WAIT &H3DA, 1
This one would wait for the end of one raster line. Used to synchronize with the screen refresh per line and at the end of each line you could change rapidly the VGA pallete for the next line to produce oldschool raster effects with minimal CPU usage (copper bars and stuff) seen in Amiga, CPC, Atari, C64 and actually every 8bit/16bit demo. PC could do that too. I used this one in the secret part of Deedlines Sax (deedlines -copper), though the colors flicker under Windows (you have to boot in pure DOS to enjoy and don't try dosbox, it's incompatible with such hardware fx) because it looses synchronization. Ahhh,. I didn't knew I could do that in quickbasic back then! Also, my 256b intros kefrens256 and raster64 use it too.

There were quite a lot more hardware VGA tricks someone could do in older PCs running DOS. Amazing stuff! I only tried 1% of them ;P
There were hardware scrolling, split screen (hardware scrolling diferrent pieces of screen or per line to make parallax scrolles, sine distort or stretch of an image with minimal CPU), bitplanes for transparent scrolling of diferrent layers and other tricks(Yeah, like Amiga! It was on 640*480 modes of VGA iirc), special ModeX modes where you write one word and you see 16 bytes outputted (great for fast flat polygon fillers on the 386), some OUT to have the screen scaled on Y (I used it in Into the Fight to have an 320*100 resolution (which now fits well in one integer array with 32000 bytes, ah those qbasic lims ;P) in some parts), also you can even hardware scroll on text mode (plasma's demo Digital Reality does it) and do other tricks. There are much more to try if I ever want to go retro and start coding on my old 386 again..

But now you can do it in pure software

[Shockwave]

I've been trying to see what difference the Screensync command makes in tinyptc programs and to be honest I can't see any noticeable difference in refresh rate or anything.
Wait &H3DA,8 definately does something and All I'd say is use it with extreme care, especially if you are developing on a fast PC.
Point in case is the DBF oldschool cracktro, it wasn't doing much, just a simple vector object and a starfield and some text. It ran fine here, I used the wait command and got a really nice refresh rate. Released it and there were people saying that the intro was running slow.
I'm sure it's because of that wait command.
I don't see any use for it except to do dos demos or raster effects in dos like Optimus said.
Maybe a compatible version of your asm wait vbl routine would be a good idea rbraz? something that could be put between asm and end asm quotes and compiled.

[cha0s]

Greetz boyz. Thought you might like to see this:

Code: [Select]

int fb_GfxIn(unsigned short port)
{
int value = -1;

if (!fb_mode)
return -1;

switch (port) {

case 0x3C9:
if (fb_mode->depth > 8)
break;
value = (fb_mode->device_palette[idx] >> shift) & 0x3F;
shift += 8;
if (shift > 18) {
shift = 2;
idx++;
idx &= (fb_mode->default_palette->colors - 1);
}
break;

case 0x3DA:
if (fb_mode->driver->wait_vsync)
[b]fb_mode->driver->wait_vsync()[/b];
value = 8;
break;
}

return value;
}
That is an excerpt from the FBgfx c source code.

Code: [Select]

'' fb_GfxWaitVSync ( void ) as integer
data @"screensync", "fb_GfxWaitVSync", _
FB_DATATYPE_INTEGER,FB_FUNCMODE_STDCALL, _
@hGfxlib_cb, TRUE, FALSE, _
0
Theres the compiler bind for the keyword "screensync", so let's check the fb_GfxWaitVSync function...

Code: [Select]

FBCALL int fb_GfxWaitVSync(void)
{
if (!fb_mode)
return fb_ErrorSetNum( FB_RTERROR_ILLEGALFUNCTIONCALL );
if (fb_mode->driver->wait_vsync)
[b]fb_mode->driver->wait_vsync()[/b];

return FB_RTERROR_OK;
}
same call. =)

[edit, sorry Cha0s, I changed the tags for you because there were smileys creeping into the listings! ~ SW]

[Shockwave]

So basically it makes no difference then. 
Thanks very much Cha0s and welcome along to the DBF/GVY board. 

[relsoft]

Chaos: Still hounted by the ghey smileys?   Welcome!

[thrawn89]

Nice set of smiles here indeed...lol

Umm...I dont use Screensync cause...its falable...so I came up with a simple algo, you might want it for future reference if you just hate those flickers...not kidding works so much better than Screensync...even included a target FPS support...you can take that out easily if you wish:

Code: [Select]

'Needs at least 2 Virtual Screen pages
'Set Screen here

'FPS
Const FPS = 30

'Timei is TIMER var
Dim As Double Timei, SecondsPerFrame

'How long each frame should take to be rendered
SecondsPerFrame = 1 / FPS

'Set up virtual vars
Dim As Integer Viewpage = 0, Workpage = 1

Screenset Workpage, Viewpage
Do
     Timei = Timer
     
     DrawScene

     ProcessInput

     UpdateScene

     Flip Workpage, Viewpage
     Do: Sleep 1: Loop While Timer - Timei <= SecondsPerFrame

     EraseScene

Loop Until SomeCondition
If you dont want the target FPS support then just take out the "Do: Sleep 1: Loop while Timer - Timei <= SecondsPerFrame" line

You can see it in action here with a small demo I made, just unREM the lines in the main loop if you wish to have it targetting the FPS again:

Code: [Select]

'Needs at least 2 Virtual Screen pages
Screen 19, 32, 2

DefInt A-Z
Option Explicit
Randomize Timer

'FPS
Const FPS = 30
Const SCRX = 800
Const SCRY = 600

Type Col_Type
    RR As Integer
    GG As Integer
    BB As Integer
End Type

Type _2DVector_Type
   x As Integer
   y As Integer
End Type

   Type Ball_Type
       x As Integer
       y As Integer
       OldX As Integer
       OldY As Integer
       R As Integer
       Col As Col_Type
       Vector As _2DVector_Type
   End Type

Declare Function RandomInt(High As Integer, Low As Integer)

'Note this is a basic example, I was gonna do stuff more complex, but decided not, so please dont pick at my inefficencys ;-)
ReDim Shared As Ball_Type Balls(0)

'Set Up First Ball
Balls(0).R = RandomInt(50,10)
Balls(0).x = RandomInt((SCRX - Balls(0).R), Balls(0).R)
Balls(0).y = RandomInt((SCRY - Balls(0).R), Balls(0).R)
Balls(0).Col.RR = RandomInt(255,30)
Balls(0).Col.GG = RandomInt(255,30)
Balls(0).Col.BB = RandomInt(255,30)
Balls(0).Vector.x = RandomInt(3, -3)
Balls(0).Vector.y = RandomInt(3, -3)
If Balls(0).Vector.x = 0 And Balls(0).Vector.y = 0 Then Balls(0).Vector.x = 2: Balls(0).Vector.y = RandomInt(3, -3)

'Timei is TIMER var
Dim As Double Timei, SecondsPerFrame

'How long each frame should take to be rendered
SecondsPerFrame = 1 / FPS

'Set up virtual vars
Dim As Integer Viewpage = 0, Workpage = 1

Declare Function DrawScene()
Declare Function ProcessInput()
Declare Function UpdateScene()
Declare Function EraseScene()

Declare Function AddBall()

'Calc FPS
Dim FrameCount As Integer
Dim FPSTimei As Double
FrameCount = 0

Screenset Workpage, Viewpage
FPSTimei = Timer
Do
     'Timei = Timer
     
     DrawScene

     ProcessInput

     UpdateScene

     Flip Workpage, Viewpage
     'Do: Sleep 1: Loop While Timer - Timei <= SecondsPerFrame

     EraseScene

     'FrameCount += 1
     'If Timer - FPSTimei >= 1 Then FPSTimei = Timer: WindowTitle "FPS: " & FrameCount: FrameCount = 1
Loop While Not Multikey(&h1)

Function ProcessInput()
    Dim As Integer MX, MY, MB
    GetMouse MX, MY, ,MB
   
    If MB And 1 Then AddBall()
   
End Function

Function UpdateScene()
    Dim AS Integer i
   
    For i = LBound(Balls) To UBound(Balls)
        Balls(i).x += Balls(i).Vector.x
        Balls(i).y += Balls(i).Vector.y
       
        If Balls(i).x + Balls(i).R >= SCRX Then Balls(i).x = SCRX - Balls(i).R: Balls(i).Vector.x *= -1
        If Balls(i).y + Balls(i).R >= SCRY Then Balls(i).y = SCRY - Balls(i).R: Balls(i).Vector.y *= -1
   
        If Balls(i).x - Balls(i).R <= 0 Then Balls(i).x = Balls(i).R: Balls(i).Vector.x *= -1
        If Balls(i).y - Balls(i).R <= 0 Then Balls(i).y = Balls(i).R: Balls(i).Vector.y *= -1
    Next i
   
End Function

Function DrawScene()
    Dim As Integer i
   
    For i = LBound(Balls) To UBound(Balls)
        Circle(Balls(i).x, Balls(i).y), Balls(i).R, RGB(Balls(i).Col.RR, Balls(i).Col.GG, Balls(i).Col.BB),,,,F
       
        Balls(i).OldX = Balls(i).X
        Balls(i).OldY = Balls(i).Y
    Next i
End Function

Function EraseScene()
    Dim As Integer i
   
    For i = LBound(Balls) To UBound(Balls)
        Circle(Balls(i).OldX, Balls(i).OldY), Balls(i).R, RGB(0,0,0),,,,F
    Next i
End Function

Function AddBall()
    Dim As Integer i
   
    'Preserve
    ReDim Temp_Balls(LBound(Balls) To UBound(Balls)) As Ball_Type
    For i = LBound(Balls) To Ubound(Balls)
        Temp_Balls(i) = Balls(i)
    Next i
    ReDim Balls(LBound(Temp_Balls) To (Ubound(Temp_Balls) + 1)) As Ball_Type
    For i = LBound(Temp_Balls) To UBound(Temp_Balls)
        Balls(i) = Temp_Balls(i)
    Next i

    Balls(UBound(Balls)).R = RandomInt(50,10)
    Balls(UBound(Balls)).x = RandomInt((SCRX - Balls(UBound(Balls)).R), Balls(UBound(Balls)).R)
    Balls(UBound(Balls)).y = RandomInt((SCRY - Balls(UBound(Balls)).R), Balls(UBound(Balls)).R)
    Balls(UBound(Balls)).Col.RR = RandomInt(255,30)
    Balls(UBound(Balls)).Col.GG = RandomInt(255,30)
    Balls(UBound(Balls)).Col.BB = RandomInt(255,30)
    Balls(UBound(Balls)).Vector.x = RandomInt(3, -3)
    Balls(UBound(Balls)).Vector.y = RandomInt(3, -3)
    If Balls(UBound(Balls)).Vector.x = 0 And Balls(UBound(Balls)).Vector.y = 0 Then Balls(UBound(Balls)).Vector.x = 2: Balls(UBound(Balls)).Vector.y = RandomInt(3, -3)
End Function

Function RandomInt(High As Integer, Low As Integer)
     RandomInt = Int(Rnd * (High - Low + 1) + Low)   
End Function
Well, thats all, Happy coding,
Matt

[Shockwave]

I hadn't thought of doing it that way Thrawn, thanks very much for sharing your algo I'll definately be looking to see how it works in combination with tinyptc.

[Jim]

fb_mode->driver->wait_vsync()

Just to add to Chaos' post.  The actual code down at wait_vsync() is

Code: [Select]

Sleep(1000/refresh_rate?refresh_rate:60)
So it's not actually checking the vsync at all, it's just waiting for 16ms.  If your code takes 15ms, then instead of this waiting for the remaining 1.6ms of the 60fps, it will still wait 16ms, taking your frame time to 31ms and your refresh down to about 30fps.

So, don't use the 'wait &h3da' command!  Either implement your own sleep code to sync to 60 or use Shockwave's delta timing method to deal with the varying frame rates (highly recommended!)

Jim

[Shockwave]

That settles that issue once and for all then.
Cheers Jim. Maybe it would be a good idea to pester V1ctor to impliment a proper wait vbl command into freebasic.

[Jim]

Under GDI there's nothing you can do.  There isn't a vblank interrupt.  The best you could do is monitor the time between calls to flip and subtract it away from the next multiple of 1000/refresh_rate and Sleep the remaining amount.  It would be really jerky though - Windows' timers aren't that accurate.

With OpenGL you can make it work, but for some reason, as nino is finding out, the default seems to be not to wait.  That's the reason I was digging around in the freebasic libs in the first place.

It can be made to work with DirectDraw and Direct3D as well.

Jim