SCREEN

General FreeBASIC programming questions.
Zippy
Posts: 1293
Joined: Feb 10, 2006 18:05

Postby Zippy » Apr 29, 2008 22:22

mark bower wrote:after Zippy's comments, had to play some more. yes, .02 appears to eliminate the problem! however, i went to .00002, and there due to effective slow motion, one can see the bar expanding in the vertical as the arc builds towards its outside diameter.

You are noting that this appears to be a time problem? That the loop with .002 takes longer than a screen refresh (a better term escapes me at the moment). So doing this (using your last bug-code example):

Code: Select all

  screenlock

    Line (20,20)-(540,400),200, BF

    For j = 26 To 28 Step .002
        Circle (200,200),j,1,6.05,5
    Next
  screenunlock

should eliminate the problem. Which is what phishguy said earlier:

http://www.freebasic.net/forum/viewtopic.php?p=98892

and takes this out of bug-realm. Unless there were other probs, and there could be if you are drawing while the screen is trying to refresh.

ETA: Edited, the Line() with fill needs to be inside the screenlock/unlock pair, it's pretty slow in fullscreen.
phishguy
Posts: 1200
Joined: May 05, 2006 16:12
Location: West Richland, Wa

Postby phishguy » Apr 29, 2008 23:22

The screen lock and unlock does solve the given example. However, if I add a sleep statement after the second screenres and before the drawing commands, then the arc draws and nothing else. I don't quite understand this behavior.

Code: Select all

Dim As Double j

ScreenRes 800,600,8,1,1             
ScreenRes 640,480,8,1,1

sleep 50

screenlock

Line (20,20)-(540,400),200, BF

    For j = 26 To 28 Step .002
        Circle (200,200),j,1,6.05,5
    Next

screenunlock

Sleep
mark bower
Posts: 330
Joined: Dec 28, 2005 6:12
Location: arcadia, CA USA

Postby mark bower » Apr 29, 2008 23:35

@ Zippy - yes, i had tried Screenlock after 1st suggested and failed to report; it works just fine. so looks like 2 solutions for maybe not quite right code: Screenlock or use of .02 (which also does not interfere with my intended display).
@phishguy - tried your last code on my computer and confirm same response that you report. i am not deep into understanding, but agree that this also seems to indicate a code imperfection?
DOS386
Posts: 798
Joined: Jul 02, 2005 20:55

bugshot

Postby DOS386 » Apr 29, 2008 23:59

counting_pine wrote:If someone can post PNG screenshots of this, I think it would be helpful.


Oops I suck ... it's OGV, not PNG :-(

And YES, Screenlock prevents the bug from occurring ... but shouldn't PUT work without screenlock ? Regrettably my other SCREENLOCK thread didn't generate any useful answers :-(

EDIT (5 years later) : deleted dead links, see post below
Last edited by DOS386 on Jun 15, 2013 6:42, edited 2 times in total.
counting_pine
Site Admin
Posts: 5826
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Postby counting_pine » Apr 30, 2008 1:37

Note for other forum users: OGV is a video format, and it demonstrates the banding effect caused, in the case of the video, by Putting a sprite multiple times in random places all over the screen. As for what to load it in, I don't know. I just cheated and went into Ubuntu.

As far as I know, all the graphics commands *should* work needing the screen to be locked. So I'd say this is a bug. But it might need someone with more intimate knowldege of gfxlib.
For the moment it looks like it can be worked aroud by manually forcing a complete screen update using ScreenUnlock. The screen doesn't need to be locked beforehand.

@DOS386, it looks like your demo is Win32. Is that right? Or are the banding issues occuring in gfxlib on other platforms too?


@axipher, Is there still an issue with colors, as you mentioned in your second post? If so, I'd still like to see a screenshot of that if possible.
DOS386
Posts: 798
Joined: Jul 02, 2005 20:55

my bugshot

Postby DOS386 » Apr 30, 2008 1:46

counting_pine wrote:Note for other forum users: OGV is a video format


YES, a GOOD one :-)

As for what to load it in, I don't know.


Any reasonable video player, like MPLAYER ;-)

As far as I know, all the graphics commands *should* work needing the screen to be locked. So I'd say this is a bug.


Maybe *without* needing to lock ?

> forcing a complete screen update using ScreenUnlock. The screen doesn't need to be locked beforehand.

Screenunlock must not be called without a previous call to Screenlock.


http://www.freebasic.net/wiki/wikka.php ... reenunlock

You are wrong or the Wiki is wrong :-(

it looks like your demo is Win32. Is that right?


YES.

are the banding issues occuring in gfxlib on other platforms too?


NO. But there are other issues ... see DOS subforum.
counting_pine
Site Admin
Posts: 5826
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Postby counting_pine » Apr 30, 2008 2:19

Thank you DOS386. Your video was illustrative, thanks in no small part to the format you chose.
I'm not an expert in GfxLib. I also don't know who wrote the wiki. I suspect if you delve into the source code, you'll find your answer there.
If the DOS bugs are not in the tracker on SourceForge, it would be helpful if you could add each of them. They are likely to get lost in this forum.

If you could stop typing "Yes" and "No" in all caps, that would also be appreciated, thank you.
DOS386
Posts: 798
Joined: Jul 02, 2005 20:55

Postby DOS386 » Sep 09, 2008 0:06

0.20 is out ... and the question arises, whether the bugs are fixed. "banding" is no longer - Page Fault instead:

Code: Select all

; Dissasembler dump of 'putw20.exe'
; File position = $9900 | RVA = $0040A500
; Written by Binary Viewer v 5.6.4-ia32.DOS Build: Apr 16 2007
; Format : PE (Portable Executable)

.0040A500: push      ebp                        ; 55
.0040A501: mov       ebp,esp                    ; 89E5
.0040A503: sub       esp,+000000A8              ; 81ECA8000000
.0040A509: test (b)  [+004251D4],01             ; F605D451420001
.0040A510: je        .0040A632                  ; 0F841C010000
.0040A516: mov       edx,[+0041FD30]            ; 8B1530FD4100
.0040A51C: test      edx,edx                    ; 85D2
.0040A51E: je        .0040A539                  ; 7419
.0040A520: mov       ecx,[+0041FD40]            ; 8B0D40FD4100
.0040A526: test      ecx,ecx                    ; 85C9
.0040A528: jne       .0040A687                  ; 0F8559010000
.0040A52E: mov       eax,[edx]                  ; 8B02
.0040A530: mov       [esp],edx                  ; 891424
.0040A533: call (d)  [eax+08]                   ; FF5008 !!! HERE !!!
.0040A536: sub (d)   esp,+04                    ; 83EC04
.0040A539: mov       ecx,[+0041ECB0]            ; 8B0DB0EC4100
.0040A53F: test      ecx,ecx                    ; 85C9
.0040A541: je        .0040A595                  ; 7452
.0040A543: test (b)  [+004251D4],01             ; F605D451420001
.0040A54A: jne       .0040A5D0                  ; 0F8580000000
.0040A550: mov       ecx,[+0041FD00]            ; 8B0D00FD4100
.0040A556: test      ecx,ecx                    ; 85C9
.0040A558: jne       .0040A712                  ; 0F85B4010000
.0040A55E: mov       eax,[+004251D4]            ; A1D4514200
.0040A563: test      al,01                      ; A801
.0040A565: jne       .0040A575                  ; 750E
.0040A567: mov       edx,[+0041FD10]            ; 8B1510FD4100
.0040A56D: test      edx,edx                    ; 85D2
.0040A56F: jne       .0040A6B8                  ; 0F8543010000
.0040A575: test      al,01                      ; A801
.0040A577: jne       .0040A6F8                  ; 0F857B010000
.0040A57D: test      al,01                      ; A801
.0040A57F: jne       .0040A6D0                  ; 0F854B010000
.0040A585: mov       eax,[+0041ECB0]            ; A1B0EC4100
.0040A58A: mov       edx,[eax]                  ; 8B10
.0040A58C: mov       [esp],eax                  ; 890424
.0040A58F: call (d)  [edx+08]                   ; FF5208
.0040A592: sub (d)   esp,+04                    ; 83EC04
.0040A595: mov       eax,[+00424DB0]            ; A1B04D4200
.0040A59A: test      eax,eax                    ; 85C0
.0040A59C: jne       .0040A677                  ; 0F85D5000000
.0040A5A2: mov       eax,[+0041FCE0]            ; A1E0FC4100
.0040A5A7: test      eax,eax                    ; 85C0
.0040A5A9: jne       .0040A667                  ; 0F85B8000000
.0040A5AF: mov       eax,[+0041FCF0]            ; A1F0FC4100
.0040A5B4: test      eax,eax                    ; 85C0
.0040A5B6: jne       .0040A625                  ; 756D
.0040A5B8: mov       eax,[+0041ECD0]            ; A1D0EC4100
.0040A5BD: test      eax,eax                    ; 85C0
.0040A5BF: jne       .0040A5C3                  ; 7502
.0040A5C1: leave                                ; C9
.0040A5C2: retn                                 ; C3

Page fault at $0040A533

EAX=7DD115E4 (evil)
EBX=00418120
ECX=00000000
EDX=005404C8
ESI=00000000
EDI=00000002
EIP=0040A533 EFLGS=00210246
ESP=0066FC88 EBP=0066FD30


EDIT (5 years later) : deleted dead links, see viewtopic.php?t=21146 ( 0.90rc2 ) and http://www.freebasic.net/wiki/wikka.php?wakka=GfxLib
Last edited by DOS386 on Jun 15, 2013 6:40, edited 3 times in total.
DOS386
Posts: 798
Joined: Jul 02, 2005 20:55

Postby DOS386 » Sep 09, 2008 0:56

EDIT (5 years later) : deleted dead links, see post above
Last edited by DOS386 on Jun 15, 2013 6:40, edited 2 times in total.
mark bower
Posts: 330
Joined: Dec 28, 2005 6:12
Location: arcadia, CA USA

Postby mark bower » Sep 10, 2008 21:25

just for the record, FB .20 appears to have fixed the problem presented in the very 1st post. the following code works just fine with no black band across the arc. no need for SCREENLOCK or changing .002 to .02.

Code: Select all

dim as single j

ScreenRes 1280,1024,8,1,1             

'screenlock
Line (20,20)-(540,400),200, BF
For j = 26 To 28 Step .002
    Circle (200,200),j,1,6.05,5
Next
'screenunlock
sleep

Return to “General”

Who is online

Users browsing this forum: Google [Bot] and 0 guests