TBGL 0.2.2, first public preview version

[Petr Schreiber]

Hi,

as you probably noticed, last thinBASIC preview contains first public version of TBGL 0.2.2.
This version is most probably the last for Windows98, so I dedicated some time to tune some older skeletons in wardrobe :)

What is new, what has changed, what was wrong? :)

Window handling
After long long time, there is an update on window handling functions!

You can setup start position for window, define standard buttons ( maximize, minimize, close ), and set custom icon to it.
Maximalization can work in 2 modes - one is the classic Windows one, second preserves the aspect ratio and centers position.
This should be compatible with Abraxas proposal, just with some minor name changes.

Other new thing is possibility to retrieve supported video modes, and switch to fullscreen and windowed mode during script execution.
This was finally quite easy, so Eros, please take my apologies it took so long :-[

Fonts
One world is not enough, James Bond knows it. Does it apply to fonts too? According to Mike yes, so I added feature allowing to specify 4 custom Windows fonts and 4 custom bitmap fonts.
So in very crazy situation you can plot 8 types of fonts on screen at the same time :D.
Sounds mad? It can allow some "functionality hijacks" too. Imagine one bitmap font as for menus, second for in-game texts and third bitmap can contain graphical symbols for creating GUI for example ( like in DOS times, but here you could use bitmap editor to create something really nice ).
Also the character position precision in case of BMP fonts was improved.

Bones
Bones bring just mini update in this preview - TBGL_m15DefBoneEmpty, TBGL_m15GetBoneChild, TBGL_m15GetBoneChildCount.
Limit of 32 bones was raised from 32 to 64 too.
It will take some time to facelift bone engine internals, but stay tuned ;)

Entities
You can now give them name, as well as custom data. Very useful in both games and "serious applications".
Thanks to thinBASIC perfect commands for UDT assignments it is pretty easy to use.

Kent, TBGL_EntityGetFreeID is here :) Hope you will like it - it can return index of first free entity from beginning or starting from user defined ID.


Tweaks of old stuff
Both display lists and textures have limits raised from 255 to 1024, which will make life a bit easier.

Noticeable improvement should affect entity rendering, TBGL 0.2.1 used MAT functions provided by compiler, which are very nice to work with.
But TBGL 0.2.2 comes with hand optimized matrix internals, which positively affects all scripts. Speed gain depends on situation, but for more complex scenes it can be as much as 30%, sometimes even better. And that still without using inline assembly.

Improved was garbage collection too, and TBGLized Windows fonts are not needed to kill manually anymore, all is done automatically ( even when creating new font to already used slot ).

Help file corrects typos and adds fulltext search, so I hope it will serve better than before.

So that is all for now, you can try the sample scripts ( nothing beautiful, just simple examples of use ).
To start coding, just use templates from thinAir TBGL template directory.


Thanks again for the support and suggestions to all!
Petr


P.S. If some artists from here ;) have a some free time, I would appreciate 3 lowpoly models of fish. Small, bigger and biggest, in size range [0.1, 1.0] meters... Not in hurry, but got an idea for more juicy demoscript than you can find in SampleScripts/TBGL/TBGL_0220_Samples :)

[Michael Hartlef]

Thanks man for all the additions. :)

[kryton9]

Thanks Petr, I was pleasantly surprised to see the update out today. Lots of improvements and additions, thanks so much!!

[Petr Schreiber]

Thanks guys :),

did the fullscreen mode changing script run ok?


Bye,
Petr

[matthew]

Hi Petr, nice TBGL update. :)

I tried using the 'fullscreen mode changing script' but it wouldn't work.

Apparently my new graphics card doesn't support a fullscreen resolution of '640 x 480'. :P

It only supports fullscreen at '800 x 600', '1024 x 768' & '1280 x 800'.

[Petr Schreiber]

Hi Matthew,

thanks a lot for reporting it!
That is odd ( both it was detected as supported, and that is not). Will investigate on this!

What is your graphic card model?
In case of unsupported resolution, RunTimeError dialog should pop up, with description of problem.
This works when you try to set for example 2048x4096. Do you get error message for 640x480 too?


Petr

P.S. Don't you have a Vista Matthew? I think there 640x480 is prohibied in general ( but not sure ) - then why WinAPI functions still return it as viable ???

[matthew]

What is your graphic card model?


Mobile Intel 965 Express Chipset

I'm using the new driver that was released a few weeks ago.

Update

Yes, I'm running Vista, I've attached the error message.

[Petr Schreiber]

Hi Matthew,

thanks! It seems resolution change on Intel 965 can be problematic according to what I have read on net and Intel website.
I will try to get workaround.

The screen says problem is "640x400", not "640x480" ( or this really fails too ?).
On my PC I get this resolution listed as well, a bit odd one, but works.

I will try to find the problem reason.

Thanks,
Petr

[Michael Hartlef]

Hi Petr,

there is something wrong in your new function about getting the resolution.

My graphic chip doesn't support 640x960x16 but TBGL thinks it does :D

Michael


Edit: Maybe it is just the script that screws up here as the first dialog doesn't list this resolution.

[Michael Hartlef]

Odd... more than odd. After adding some debugging stuff into the script... Everything works fine. Taking the debugging stuff out gives the same result. Now it runs fine. That leaves me a feeling that there are some memory problems with how thinBasic is storing datas at the moment.

[Petr Schreiber]

Wow,

that is silly. My apologies :(

What resolutions does report following script? ( better, worse, same ? ):


' Supported resolutions

' size of a device name string
%CCHDEVICENAME = 32

' size of a form name string
%CCHFORMNAME = 32
TYPE DEVMODE
dmDeviceName AS ASCIIZ * %CCHDEVICENAME
dmSpecVersion AS WORD
dmDriverVersion AS WORD
dmSize AS WORD
dmDriverExtra AS WORD
dmFields AS DWORD
dmOrientation AS INTEGER
dmPaperSize AS INTEGER
dmPaperLength AS INTEGER
dmPaperWidth AS INTEGER
dmScale AS INTEGER
dmCopies AS INTEGER
dmDefaultSource AS INTEGER
dmPrintQuality AS INTEGER
dmColor AS INTEGER
dmDuplex AS INTEGER
dmYResolution AS INTEGER
dmTTOption AS INTEGER
dmCollate AS INTEGER
dmFormName AS ASCIIZ * %CCHFORMNAME
dmLogPixels AS WORD
dmBitsPerPel AS DWORD
dmPelsWidth AS DWORD
dmPelsHeight AS DWORD
dmDisplayFlags AS DWORD
dmDisplayFrequency AS DWORD
dmICMMethod AS DWORD
dmICMIntent AS DWORD
dmMediaType AS DWORD
dmDitherType AS DWORD
dmICCManufacturer AS DWORD
dmICCModel AS DWORD
dmPanningWidth AS DWORD
dmPanningHeight AS DWORD
END TYPE

DECLARE FUNCTION EnumDisplaySettings LIB "USER32.DLL" ALIAS "EnumDisplaySettingsA" (lpszDeviceName AS ASCIIZ, BYVAL iModeNum AS DWORD, lpDevMode AS DEVMODE) AS LONG

dim Device AS LONG, Result AS STRING
dim i, r AS LONG
dim ScrnModeID, ValidScrnModeID AS LONG
dim ScrnMode AS DEVMODE
dim mode, modes AS STRING
DIM DModes(128) AS STRING

FOR Device = 1 TO 3
DO
INCR ScrnModeID
i = EnumDisplaySettings( "\\.\Display"+FORMAT$(Device), ScrnModeID, ScrnMode)

IF i = 0 THEN EXIT DO ' -- No more

IF ScrnMode.dmBitsPerPel >= 16 AND ScrnMode.dmPelsWidth >= 640 THEN

mode = FORMAT$( ScrnMode.dmPelsWidth)+"x"+FORMAT$( ScrnMode.dmPelsHeight)+"x"+FORMAT$( ScrnMode.dmBitsPerPel)

r = ARRAY SCAN DModes() FOR ValidScrnModeID, = mode

IF r = 0 THEN
INCR ValidScrnModeID
IF ValidScrnModeID > UBOUND(DModes) THEN REDIM PRESERVE DModes( 1 TO ValidScrnModeID+8 )
DModes(ValidScrnModeID) = mode
END IF

END IF
LOOP

modes = JOIN$(DModes(), $CRLF)
modes = RTRIM$(modes, $CRLF)

Result = Result +$CRLF+ "DEVICE: #"+FORMAT$(Device)+" ("+STR$(ValidScrnModeID)+" modes)"+$CRLF+ modes +$CRLF+ REPEAT$(20, "-")
REDIM DModes(128)
ScrnModeID = 0
ValidScrnModeID = 0

NEXT

MSGBOX 0, Result




Thanks,
Petr

[matthew]

I've attached the image which is shown when the above script is run.

[Petr Schreiber]

Thanks Matthew and Mike,

this is very interesting situation.
I think the code is correct but returned resolutions are not


Petr

[catventure]

Hi psch,

Here are results on my Vista using above code.

[Petr Schreiber]

Thanks!,

does your PC really allow 2048x1536?


Thanks for the help,
Petr

[Michael Hartlef]

Hi Petr,

here are the results of the german jury. Odd, device 2 shows the strange resolution 640x960x16 :o

[Michael Hartlef]

Ok, I have 4 devices, here are the results more detailed:

[Petr Schreiber]

Hi Mike,

you have 4 monitor setup ?!

I wonder if 640x960 is not mentioned as when using two monitors, one above other, each having 640x480 but in total making 640x480*2 = 640x960.


Thanks,
Petr

[Petr Schreiber]

Here is an experimental version for volunteers,

with slightly different setting of fullscreen mode and modes retrieving.
Let me know if it is working better of worse.

During tomorrow I wont be on PC all the day, but starting from ~6 PM CET.
So do not get scared I am not responding sooner, I did not escaped :)

Atypic 640x400 will appear again, on my PC it worked ( and looked bit ugly ), so I thought problem might be with wrong fullscreen setup, we will see...


Petr

UPDATED for second time at 21:36 CET, good night and see you tomorrow!
Removed, obsolete version. You can find latest TBGL with your ThinBasic installation

[Michael Hartlef]

No, I just have 1 monitor. And the Xpress 200 is the onboard chip.

[Michael Hartlef]

Ok now I know where the problem is. tbgl_GetFullscreenModes doesn't have an indicator for the device you want to check.
I don't know if it allways checks the active one. Because when it reported 640x960x16 it reported a resolution from the second device I have.
But somehow we also need a function to count the devices and tbgl_GetFullscreenModes needs an index to tell TBGL which device you want the modes collected from. Or make sure that you only get the modes form the active device.

But then, what if someone has a 2 monitor setup?

EDIT: The script reports a resolution of 640x400x16. But I'm not able to select this resolution in the display settings.

[Michael Clease]

EDIT: The script reports a resolution of 640x400x16. But I'm not able to select this resolution in the display settings.


This maybe the adapters resolutions and not the DDC data from the monitor so the monitor may not support that resolution.

[Michael Hartlef]

EDIT: The script reports a resolution of 640x400x16. But I'm not able to select this resolution in the display settings.


This maybe the adapters resolutions and not the DDC data from the monitor so the monitor may not support that resolution.


Oh, that makes sence. Thanks.

[Petr Schreiber]

Hi Mike,

I was thinking of some filters for TBGL_GetFullscreenModes, like only specified aspect ratio, bit depth ... this are things we can tune up in these previews.

The old version, returning 640x960, had not specified device, and from MS docs I got feeling it will return resolutions for now active device. The "fix" TBGL edition above forces Device1 and also while retrieves the mode it tests them with CDS_TEST flag to see if there is some problem.

I think Abraxas is right with the possible monitor problem, so I will have to incorporate it into this too.

Fact is I did not found API to give me same results as Win display settings, but will make some more search.

I will try to work on device enumeration too, good suggestion. Maybe it could be passed to CreateWindowEx too.


Thanks,
Petr

[ISAWHIM]

I suggest the API calls for user32.
There is also a neat command to LOCK TOPMOST, when you go to full-screen... stops pop-ups from knocking you out of full screen mode.

http://msdn.microsoft.com/en-us/library/ms534611(VS.85).aspx

Those GL modes are only the "Ability" of the software/hardware as a transform/display. (You can display 640*400 in a 1280*800 mode. That is my wide-screen "default-pixel-native" resolution. But for FPS, GL would lower to 640*400, which is not a windows setting. "Full-Screen" has no real values, only a ratio. Hardware transform has the limitations.)

EG...
1. Find the number of screens.
2. Find the screens actual resolutions. (That is what you stretch the screen to fit. Keeping ratio in mind.)
3. Find available GL modes for full screen.
4. Allow the user to select any agreeable setting. (If you have issues with them selecting 640*400, because your GUI needs 640*480 minimum, you don't allow that, you move one-up, in a ratio that they can handle.)
5. Match the selection to the best-fit "Larger" screen. (You don't want to cram a 1024*768 into a 640*480 resolution, but you will freely up-size a 640*480 to fit into a 1024*768, if it is desired.)
6. Maximize the screen. Test for actual display size to see if it needs a change.
7. Reduce or enlarge the screen to an available screen resolution at the desired ratio.
8. Stretch the selected resolution to fit the area. This may require a 0,0 to 1024,768 stretch. Use ((1024-640)/2*-1), ((768-480)/2*-1) to ((1024-640)/2+640), ((768-480)/2+768) and that should push the black-borders off the screen, so the screen now has the full drawing area displayed in the full view. (Otherwise, you have a black-border around a smaller image in the full screen that is larger than the drawn-view.)

The result should be, the speed gain of the smaller resolution, in a compatible view, filled to the full view. (That should not present any drop in performance, as the resize is one that is not of importance. Only the RECT where changes are drawn reduce performance. Windows and the monitor doesn't care if it is shrunk to the size of an icon, or stretched to 10x the resolution. It all draws the same, it just looks odd. An icon scale will take as much to process as a 10x scale. GL draws the pixel grid at the specified resolution.)

The "Special" sizes also come in handy for "Mobile" and "Kiosk" units, where the connected display actually has those resolutions selectable.

This monitor actually goes down to 320*200 when I install new drivers. You would think I was blind... The login icon is nearly the size of a cup of coffee!

Any-who... Here is my results... (I was looking for the TBGL_Benchmark and stumbled upon this cool posting. keeping the code, and I am also suggesting that it be added to one of the main topics here, and included in the demo files for TBGL.)