Screen doesn't update on netbook after FILEREQUEST$

Previous topic - Next topic

Cliff3D

As per the subject line, if I use FILEREQUEST$ then my current pet project (which I get to grips with GBLBasic) never updates the screen. The same project compiled on my desktop PC updates just fine.

As  workaround I can either avoid FILEREQUEST$ and assign the filename to a string in code (giving no runtime choice) or I can use an extra SHOWSCREEN directly after the FILEREQUEST$ to reinstate a window afterwards. I've no idea why the latter works. Here's the code to ReadOBJ.bas:

// --------------------------------- //
// Project: ReadOBJ
// Start: Monday, August 30, 2010
// IDE Version: 8.085

// IMMEDIATE OBJECTIVES:
// Evaluation of GLBasic ("getting to know GLBasic")
// Produce Basic import/read routine for 3D .OBJ files
// Must support at least quads and very large .OBJ files
// Store .OBJ data in custom type in verbose manner - I want to be able to write out the model
//  with zero math/rounding errors as-is, and also be able to negate every number and have no
//  math/ rounding errors

// LONGER TERM OBJECTIVES:
// ability to show .OBJ 3d model in 3D and rotate around, zoom, or view in orthogonal mode
// Ability to show coloured, textured, or wireframe without appearance of extra lines
// Head towards various possible utilities for tweaking .OBJ files
// Will eventually need to be able to read, modify, and write JPEG, BMP and PNG files
// at least up TO 4096 * 4096 (ideally higher)
// May at some stage need to be able to select parts of the model by group and/or material

// FREE-VERSION:
// Need Premium for Features:
// 3D Graphics
// Network Commands
// INLINE C/C+++ code

SETCURRENTDIR("Media") // seperate media and binaries?

GLOBAL intLineHeight=8,intLineVPos=0 // variables to control where on screen to put file text
GLOBAL bFileOpened // did we successfully open a file?
LOCAL strFileName$,strLine$,strCommand$
GLOBAL lngVerts=0, lngUVs=0, lngNormals=0, intGroups=0, lngFaces=0, intUSEMTLs=0, intMTLLIBs=0

strFileName$=FILEREQUEST$(TRUE, "Alias Wavefront OBJ|*.obj|All|*.*")
SHOWSCREEN // NETBOOK WORKAROUND LINE 1

//strFileName$="blMilWom_v4b.obj" // NETBOOK WORKAROUND LINE 2

bFileOpened = OPENFILE(1, strFileName$, TRUE)

IF bFileOpened=TRUE
// load a background in
//LOADBMP "back.bmp";
   WHILE NOT (ENDOFFILE(1)) // cycle through entire file a line at a time to count entries

      READLINE 1, strLine$ // read each line in
      IF LEN(strLine$) > 2 // is the line long enough to contain a command?

         strCommand$=LCASE$(LEFT$(strLine$,2))
         SELECT strCommand$
         CASE "f " // FACE
            lngFaces=lngFaces+1
         CASE "v " // VERTEX
            lngVerts=lngVerts+1
         CASE "vt" // TEXTURE (UV) VERTEX
            lngUVs=lngUVs+1
         CASE "vn"  // NORMAL
            lngNormals=lngNormals+1
         CASE "g " // GROUP
            intGroups=intGroups+1
         CASE "us" // Probable USE MATERIAL command. Do further checking?
            intUSEMTLs=intUSEMTLs+1
         CASE "mt" // Probable MATERIAL LIBRARY command. Do further checking?
            intMTLLIBs=intMTLLIBs+1
         DEFAULT // COMMENT or UNKNOWN/UNRECOGNISED
         ENDSELECT

      ENDIF

   WEND


   PRINT "Vertices : "+lngVerts ,0,intLineVPos
   intLineVPos = intLineVPos + intLineHeight
   IF intLineVPos >= 480
      intLineVPos = 0
      SHOWSCREEN
   ENDIF
   PRINT "UVs : "+lngUVs ,0,intLineVPos
   intLineVPos = intLineVPos + intLineHeight
   IF intLineVPos >= 480
      intLineVPos = 0
      SHOWSCREEN
   ENDIF
   PRINT "Normals : "+lngNormals ,0,intLineVPos
   intLineVPos = intLineVPos + intLineHeight
   IF intLineVPos >= 480
      intLineVPos = 0
      SHOWSCREEN
   ENDIF
   PRINT "Groups : "+intGroups ,0,intLineVPos
   intLineVPos = intLineVPos + intLineHeight
   IF intLineVPos >= 480
      intLineVPos = 0
      SHOWSCREEN
   ENDIF
   PRINT "Faces : "+lngFaces ,0,intLineVPos
   intLineVPos = intLineVPos + intLineHeight
   IF intLineVPos >= 480
      intLineVPos = 0
      SHOWSCREEN
   ENDIF
   PRINT "Materials : "+intUSEMTLs ,0,intLineVPos
   intLineVPos = intLineVPos + intLineHeight
   IF intLineVPos >= 480
      intLineVPos = 0
      SHOWSCREEN
   ENDIF
   PRINT "Material Libraries : "+intMTLLIBs ,0,intLineVPos
   intLineVPos = intLineVPos + intLineHeight
   IF intLineVPos >= 480
      intLineVPos = 0
      SHOWSCREEN
   ENDIF

   FILESEEK 1, 0, 0 // reset file position to start ready to ACTUALLY read the 3D model in
   WHILE NOT (ENDOFFILE(1)) // cycle through entire file a line at a time

      READLINE 1, strLine$ // read each line in
      IF LEN(strLine$) > 2 // is the line long enough to contain a command?

         strCommand$=LCASE$(LEFT$(strLine$,2))
         SELECT strCommand$
         CASE "f " // FACE

         CASE "v " // VERTEX

         CASE "vt" // TEXTURE (UV) VERTEX

         CASE "vn"  // NORMAL

         CASE "g " // GROUP

         CASE "us" // Probable USE MATERIAL command. Do further checking?

         CASE "mt" // Probable MATERIAL LIBRARY command. Do further checking?

         DEFAULT // COMMENT or UNKNOWN/UNRECOGNISED

            PRINT strLine$ ,0,intLineVPos
            intLineVPos = intLineVPos + intLineHeight
            IF intLineVPos >= 480
               intLineVPos = 0
            SHOWSCREEN
            ENDIF

         ENDSELECT

      ENDIF

   WEND
   SHOWSCREEN
   CLOSEFILE 1
   MOUSEWAIT
ENDIF


END


and you will also need a .OBJ file for it to read - how about Cube 03 (normals).obj:
# NumVerts/NumTVerts/NumVNormals/NumFacets   8/16/6/6
# NumGroups   1
# Original File Name "Cube 03 (normals).obj"

v -1.00000000 -1.00000000  1.00000000
v -1.00000000  1.00000000  1.00000000
v  1.00000000 -1.00000000  1.00000000
v  1.00000000  1.00000000  1.00000000
v  1.00000000 -1.00000000 -1.00000000
v  1.00000000  1.00000000 -1.00000000
v -1.00000000 -1.00000000 -1.00000000
v -1.00000000  1.00000000 -1.00000000

vt  0.50000000  0.66666669
vt  0.75000000  0.66666669
vt  1.00000000  0.66666669
vt  0.75000000  0.33333334
vt  1.00000000  0.33333334
vt  0.25000000  0.66666669
vt  0.00000000  0.66666669
vt  0.00000000  0.33333334
vt  0.50000000  1.00000000
vt  0.25000000  1.00000000
vt  0.50000000  0.33333334
vt  0.25000000  0.33333334
vt  0.25000000  0.00000000
vt  0.50000000  0.00000000

vn  0.00000000  0.00000000  1.00000000
vn  1.00000000  0.00000000  0.00000000
vn  0.00000000  0.00000000 -1.00000000
vn -1.00000000  0.00000000  0.00000000
vn  0.00000000  1.00000000  0.00000000
vn  0.00000000 -1.00000000  0.00000000

g Cube
f 4/1/1 2/6/1 1/12/1 3/11/1
f 6/2/2 4/1/2 3/11/2 5/4/2
f 8/3/3 6/2/3 5/4/3 7/5/3
f 2/6/4 8/7/4 7/8/4 1/12/4
f 6/9/5 8/10/5 2/6/5 4/1/5
f 3/11/6 1/12/6 7/13/6 5/14/6


if I comment out NETBOOK WORKAROUND LINE 1 then the screen never gets updated. If instead I comment out the FILEREQUEST and uncomment NETBOOK WORKAROUND LINE 2 then everything works fine (but I cannot choose a different file).


Help?

Cliff3D

Oh yes-Dell Mini 9 netbook with Windows XP Pro, 2GB of RAM, and Mobile Intel 945 Express Chipset graphics onboard (latest drivers). 32 GB SSD split between Windows and Ubuntu ;)

MrTAToad

You need to do a SHOWSCREEN after all the prints if you want them displayed for a split second, or you can do all the prints within the loop - dont forget for each render loop, you have to re-displayed everything...

Cliff3D

Quote from: MrTAToad on 2010-Aug-31
You need to do a SHOWSCREEN after all the prints if you want them displayed for a split second, or you can do all the prints within the loop - dont forget for each render loop, you have to re-displayed everything...

I am gewtting different behaviour on a virtual PC on a desktop PC and the netbook. I originaly wrote the above code using the virtual PC, which worked fine - everything was as expected. Then I copied it to the notebook and on the first pass nothing I PRINTed showed up in the application's window. It was black. On second and subsequent tries the black background didn't even show up - just the Windows title bar and border around the client area - but the client area itself was transparent. Didn't draw.

Removing the FILEREQUEST and using a predefined string works correctly every time on both PCs.

Using SHOWSCREEN after FILEREQUEST - producing a blank window - makes the program behave as it does on my virtual PC.

The behaviour is not consistent between PCs running Windows XP SP3 with current video drivers - which is why I call "bug" :)

Slydog

Could you be running out of memory on the one device?
Try loading the task manager and view the 'Performance' tab.
My current project (WIP) :: TwistedMaze <<  [Updated: 2015-11-25]

MrTAToad

You will see differences between a virtual machine and a proper one.  As a VM is a lot slower, you'll see artifacts from a previous page flip; everything slower; screen display can be controlled and handled differently.

Run the same program together and you'll have a nice fun time :)

You will sometimes get just the window bar, as your first command is to call FILEREQUEST.  It also has problems (with a x64 machine) in debug mode.

Everything is displayed fine on my machine.

Cliff3D

Quote from: Slydog on 2010-Aug-31
Could you be running out of memory on the one device?
Try loading the task manager and view the 'Performance' tab.

That does not seem to be the problem :(


Cliff3D

Thanks to everyone for attitude so far - I can come across as snippy, especially when (as lately) I'm in a bunch of pain. So apologies if I seem snippy, (it's unintentional) and thanks for not responding in the same way :D


Quote from: MrTAToad on 2010-Aug-31
You will see differences between a virtual machine and a proper one.  As a VM is a lot slower, you'll see artifacts from a previous page flip; everything slower; screen display can be controlled and handled differently.

So far, my desktop Virtual Machine is much faster than the real netbook in every way (compiling, screen updates, reading in a .OBJ file etc.)

Quote from: MrTAToad on 2010-Aug-31You will sometimes get just the window bar, as your first command is to call FILEREQUEST.  It also has problems (with a x64 machine) in debug mode.

My netbook has the display problem running the program from the IDE or from Windows Explorer - certainlt not just in debug mode. To show exactly what is happening, I have trimmed down the code and made a little animation. Here's the minimalist version of the code:

// --------------------------------- //
// Project: filerequestbugreport
// Start: Thursday, September 02, 2010
// IDE Version: 8.085


// FREE-VERSION:

LOCAL strFileName$

strFileName$=FILEREQUEST$(TRUE, "All|*.*")
//SHOWSCREEN // NETBOOK WORKAROUND LINE 1 TO ENSURE SCREEN UPDATE

PRINT "This does not show up on my netbook without a SHOWSCREEN *BEFORE* it :(" ,25,150
SHOWSCREEN
MOUSEWAIT

END


No support files are required now and everything is very clear :)

Here is a tiny version of the animation showing what happens:-



and you can see a larger, cleaer copy at:

http://tinypic.com/r/3148hhi/7

Quote from: MrTAToad on 2010-Aug-31Everything is displayed fine on my machine.

I am really trying to evaluate GLBasic for my coding purposes, which would ideally include cross-platform. I'm going to struggle with this ideal if the programs don 't work consistently even between 2 Windows XP PCs :(

I do not need to uncomment that SHOWSCREEN command to see the message printed on my Virtual Machine which is running Windows XP Pro with less RAM than the netbook has.

MrTAToad

The only thing I can suggest is make sure the graphics drivers are updated - preferably with the non-manufacturer drivers.  Unfortunately as I dont have a laptop, its the only thing I can suggest.  Does your laptop use an Intel graphics processor ?

Both Windows XP in VirtualBox and Windows 7 desktop do the same thing here.

Might be worth seeing if someone with a laptop can test.

According to this its also  known problem : http://forums.libsdl.org/viewtopic.php?p=25310&sid=e95561e9e6b298838a59543ff93432e8




Cliff3D

Quote from: MrTAToad on 2010-Sep-02
The only thing I can suggest is make sure the graphics drivers are updated - preferably with the non-manufacturer drivers.  Unfortunately as I dont have a laptop, its the only thing I can suggest.  Does your laptop use an Intel graphics processor ?

Yup!:

Quote from: Cliff3D on 2010-Aug-31
... Mobile Intel 945 Express Chipset graphics onboard (latest drivers).

I checked Intel's web site for updated drivers before posting it as a problem here :)

Quote from: MrTAToad on 2010-Sep-02Might be worth seeing if someone with a laptop can test.

Probably the more people tha test, the better. the code snippet isn't long, shouldn't take much to test and pass back any reports of where it fails?

Quote from: MrTAToad on 2010-Sep-02According to this its also  known problem : http://forums.libsdl.org/viewtopic.php?p=25310&sid=e95561e9e6b298838a59543ff93432e8

I hate "known problems". One of (several) reasons that I haven't even downloaded a recent VisualBasic to try (along with platform dependance) is that I grew to loathe the list of "Known Problems" with VB that didn't get addressed until the next paid-for upgrade. Perhaps I should use this and JPEG handling issues as a barometer of how well GLBasic gets fixed? I realise that SDL is a seperate entity, but if GLBasic relieas on SDL then either GLBasic owners should be pushing for SDL fixes or should be providing workarounds in GLBasic (IMHO) rather than each individual APP author finding the problems and working around them. I think? Don't forget, I don't relaly know how the community round here works yet :)

MrTAToad

SDL 1.2 has no chance of being updated, aside from Gernot getting the source code (and a mess it is too) and fixed any and all problems himself, for each platform...

There is supposed to be a 1.3 in development (and has been for years now - http://www.galaxygameworks.com/), which if/when its finished and released would be the ideal thing to move straight onto - especially with the features its supposed to have.

I've just sent them an email to see how far it is to being released - it will be interesting to see if I get a reply :)

On the whole though 1.2 does a pretty good job, although its getting to be pretty badly out-of-date.

GLBasic doesn't really support JPEG's at the moment, and thus shouldn't be used.

It sounds like the graphics processor cant handle a change from GDI back to the SDL.  Theoretically a call to UpdateWindow in C would do it (or keep the SHOWSCREEN command in).

Hatonastick

Well mine uses the Intel GMA 3150 and running your test program I don't get the same issue -- it runs fine.  What makes it interesting is I've been experiencing other issues with regards to things that use OpenGL.
Mat. 5: 14 - 16

Android: Toshiba Thrive Tablet (3.2), Samsung Galaxy Tab 2 (4.1.2).
Netbook: Samsung N150+ Netbook (Win 7 32-bit + Ubuntu 11.10).
Desktop: Intel i5 Desktop with NVIDIA GeForce GTX 460 (Win 8.1 64-bit).

MrTAToad

I've managed to got hold of a computer with an Intel 945 Mobile Graphics Processor - and the good news is that the graphical problem also happens here too.

Cliff3D

LOL. Good news come sin strange packages ;)

But yes - as long as it's not a Dell, that would indicate that it's probably a chipset issue (technically) so should hopefully affect a very very small percentage of PCs out there :)

Thanks!

Quote from: Hatonastick on 2010-Sep-03
Well mine uses the Intel GMA 3150 and running your test program I don't get the same issue -- it runs fine.  What makes it interesting is I've been experiencing other issues with regards to things that use OpenGL.

The problem with any system that isn't compeltely locked out is that you get different interpretations of "standards" and also "acceptability". When there are too many sources behind the software you use, accountability is a problem.

you use an application, utility or game and it fails. Surely the guy that wrote the game is to blame? the guy that wrote the game blames the development tools, as they have a problem. The guy that wrote the development tools blames the middleware. The guy that wrote the middleware blames the device drivers. The guy that wrote the device drivers blames the OS or the hardware. The guys that wrote the OS and developed the hardware both blame the end user for wanting stuff so cheaply.

Who, at the end of the day, picks up responsibility for anything nowadays? :( And why is it nearly always ME that's supposed to "fix it"?  =D

MrTAToad

It sounds likely to be a chipset issue.  As for why you should solve it :  Its cheaper that way  =D

Although if it just affects 945, I don't think you can fix it...