Feedback --- FB.11 and GFX

[rayjohn01]

I got this working on a graphics programme just maneuvering some pset points.
I found that the image was upside down cf QB and that the 'window' took no notice of signs . I was using
screen 20,8,1,1
window (-x,-y)-(x,y) changing to (-x,y)-( x-y) had zero effect

In the FB0.1 sdl format there was no problem.

The mouse pointer is invisible and seemed to have the same up/down problems.

The nice thing about the sdl color format is that it deals with standard rgb color values which you can check and see in other draw programs without using hex.

A minor gripe -- in sdl I can choose any screen size -- it happens that for me with a 17" monitor the 'best' screen is 1152x864 -- but there is no 'mode' to support this. If I had a 19" monitor then I would use mode 21
( but this means I have to set my monitor to this and the text becomes too small on a 17 " ).

One plus noted cf sdl was that the gfx mode was faster when moving objects under keybd control (and seeing them as they move ) so long as
the keybd buffer is emptied. ( while wend etc. ) It appeared on my machine about 1.4 x faster.

Comment --- It appears currently that I cannot get back to the sdl mode under FB.11 , If I had a faster machine ( someday) I would not see any point in using gfx .
My only complaint about sdl is that if you draw one point and want to see it you have to flip the whole screen -- which appears very wastefull -- but I do not know what that implies from a soft ware hardware viewpoint .

Will any body ever give us control of the keybd buffer ??????

Anyway they are only minor gripes , this is all good stuff
Ray.

[Z!re]

You only flip once you've drawn all the gfx for that frame.

Flipping after only a single dot is being drawn is extremely wasteful, and will result in your program being slower than it would normally be.

Also, if you use SDL_Flip, make sure to implement a delay, or only flip a certain amount of times per second. Ptherwise your program will suck up 100% CPU, and will slowdown to a crawl.
Use SDL_GetTicks, to get a very highresolution timer (much better than TIMER)
I use SDL_GetTicks, and only flip once every 25th tick (millisecond which gives a nice smooth 40FPS


To get keypresses in SDL:

Code:

dim shared key as ubyte ptr
key = SDL_GetKeystate(0)
Do
SDL_PumpEvents 'enables the user to press keys, and move the window etc.
'Always pump events, especially if you want mouse or keyboard to work properly


If Peek(key + SDLK_ESCAPE) Then
  'Escape was pressed
   Exit Do
End If
Loop

[lillo]

Thanks for the feedback rayjohn01.

WINDOW SCREEN did indeed have a bug in 0.11; I just fixed it in CVS.

Mouse cursor coordinates however are not supposed to be affected by WINDOW SCREEN, are they? Maybe. Suggestions? I can easily make them to be affected for next release.

About custom screen modes; what if I add a PROPOSEMODE instrinsic function with which you can specify custom dimensions for screen mode 22? Mode 22 would be the "custom mode":

Code:

PROPOSEMODE 1280, 800 ' widescreen
SCREEN 22

About keyboard control, new gfxlib depends on the Win32 keyboard repeat rate settings for rapidity with which the keyboard buffer is refilled with new chars. Anyway I suppose you'd better use the MULTIKEY function if dealing with an object to move on the screen; this allows multiple keypresses and returns the state of any key at any time (pressed or not). See the gfxlib.txt docs, MULTIKEY example.

[rayjohn01]

To restate in case of any missunderstanding
a) I found that just window (-x,-y)-(x,y) ignored the signs and oriented from top left to bottom right adding 'screen' did nothing.
b) Totally agree with a custom screen mode ( I know I'm a bit picky but I need as much resolution as I can get ) but I cannot go to mode 21
because if I have to set my monitor that way the text in other applications becomes very difficult to read.
c) I notice mode 20 mentions 2 text sizes -- how do you switch ?
d) I have two programs nominally the same the first using FB0.1 and sdl , the second FB0.11 and GFX . In the second the getmouse funtion had to have the 'y' value negated to get the correct direction.
e)Yes I will look at the multikey function
f) The first program will not compile to full screen with FB.11 so I cannot examine what's going on there is sdl allowable in FB.11 ???
The reason is that I much prefer the sdl color format because it uses common rgb numbers -- which if you do a lot of graphics in other applications you get used to.

[lillo]

ok, here are replies to each of your points:

a) as I previously stated, I recognized FB 0.11 has a bug in the WINDOW statement handling, for which using SCREEN with it does not affect y axis invertion; I already fixed it and the fix is in CVS. Either get a fresh new CVS snapshot and rebuild the lib, or wait for next official release.

b) Adding availability of a mode "22" does not mean you cannot use it if your monitor does't support mode 21. Mode 22 would be a different thing: a custom mode for which you set the size using an additional PROPOSEMODE function.

c) Using the WIDTH statement. Mode 20 supports (as reported in the SCREEN function documentation) 128x48 and 128x96; to set one of them, use either

Code:

WIDTH 128, 48

or

Code:

WIDTH 128, 96

d) Probably the old SDL-based gfxlib reported the mouse coordinates as affected by the WINDOW statement settings. New gfxlib always report mouse coordinates as screen (physical) coordinates... This seems more logical to me, but I'm open to discussing it for the next release.

e) ok

f) Sure there is SDL for 0.11. But it's not mixed up with gfxlib anymore, so if you need SDL, just go with it and not with QB-like gfx functions; SDL has its very own functions to set video mode and other gfx stuff. Have a look at the examples shipped with FB 0.11, under the examples/SDL directory.
As for color format, FB 0.11 gfxlib (the new standalone one) offers the same method of FB 0.10 gfxlib (the old SDL-based one) to specify colors: the RGB function:

Code:

PSET (x, y), RGB(255, 0, 0) ' red

The only difference is in 0.11 you can also, if you prefer, use the hexadecimal notation to specify color:

Code:

PSET (x, y), &hFF0000 ' red

The RGB function is still there though, so if you prefer it, just use it.

[Sterling Christensen]

d) Probably the old SDL-based gfxlib reported the mouse coordinates as affected by the WINDOW statement settings.

Nope, the old one had no mouse support at all. Using the old gfxlib, you'd have to intercept SDL mouse events using SDL functions before calling inkey$.

[rayjohn01]

Fb 0.11 will still not open a full window with
'$inlude: "sdl\sdl.bi"
screen 1024, 768,8,1
it does in Fb 0.1
If I am missing some code to correct this them I'm listening
Ray.

[v3cz0r]

RTFM applies perfectly here. It's at docs/gfxlib.txt, if you can't find it, here is the SCREEN description:

Code:

+--------+--------------------------------------------------------------------
| SCREEN |
+--------+

Statement to set current gfx mode.


Syntax:
    SCREEN mode[,[depth][,[num_pages][,fullscreen]]]


Argument:    Description:

mode        Gfx mode number, see below.

depth        Color depth in bits per pixel. If you omit this argument, the
        default depth for given mode is set.

num_pages    Number of pages, see below. Default if omitted is 1.

fullscreen    Set this argument to 0 to request a windowed mode, 1 to
        request a fullscreen mode. Default if omitted is 0.

If you can't understand simple instructions like Angelo wrote in gfxlib.txt, forget about programming, open up MS-Paint and your problems are over.

[lillo]

The SCREEN statement now has a different meaning for the parameters in 0.11; including sdl.bi before calling it will not make it magically behave like it did in 0.10...
If you want to use SDL, don't use SCREEN, but use SDL_Init and SDL_SetVideoMode instead (refer to SDL documentation, the SDL homepage is at www.libsdl.org) to set up the video mode.

[Sterling Christensen]

[...] it does in Fb 0.1

Mathmatically yes, 0.10 is equal to 0.1, but version numbers on open source projects usually aren't like a decimal number. Depending on the project (it varies a little), a version number like "0.1" would probably mean "release #1 of version 0". So you see, "0.10" cannot be abbreviated to "0.1" because the two have different meanings ("0.10" would mean "the 10th release of version 0"). It's best to think of the dot(s) in version numbers as separators instead of decimal points.

There is a very good, very simple reason for this. Suppose 0.1, 0.2, then 0.3... all the way to 0.9 are released. Then what? Do they have to call the next release "1.0" even if it doesn't deserve it? Or resort to "0.91", "0.95", "0.9999", etc? It's more flexable to just continue on to "0.10", "0.11", ... "0.1000". That way there's room in the version number for there to be a thousand releases before it gets to 1.0.

I imagine anyone who thought it was a decimal number would be wondering why the version number went down from 0.9 to 0.1 (0.10). The 9 was simply incremented to a 10. I hope this clears up any confusion.