PureBasic Forums - English

Hi,

i used the current sourcecode from infratec and reworked it a bit:

- The enter-key now switches between real fullscreen and standard windowed mode (presentation restarts from beginning)
- The screenfull switch in XML file is reactivated and works as expected (this is now kind of "initial" value)
- I found some way to improve performance (3D calculations are only done for objects that are moving)

The current source V1.03 is included in the link from the first page of this thread:
http://www.x-beliebig.info/Download/Pre ... source.zip

Kukulkan

Hi Kukulkan,

I'm just testing Pres3D with Linux and it is not working

First I had tofor the MessageRequester()
Than I had to use opengl as subsystem (Sprite3D needs opengl)
Than I was able to start the program, but it hangs.
After some debugging I found the point:
In ImageToSprite() you used always 4 byte as pixelsize (SizeOf(Long)).
But in my case this was wrong. So I addedand replaced SizeOf(Long) with PixelSize.
Now the program starts, but does not work as expected.
The first image is totally corrupted and it is not in the middle.
I can not go forward.
But I can stop it by closing the window.
It needs more investigations.

Have you ever tested it with Linux?

Bernd

Hi Infratec,

Im sorry to hear that porting to linux will not be as easy as I thought.

Have you ever tested it with Linux?

No, I never tested it on Linux. I used only PureBasic commands that are supported by Linux (PB Help) and try'd to avoid any OS specific parts (exept of the DirectX part). I thought about porting with as less problems as possible. But I have not expected that there are no problems. So, this will need some more investigations. For me, I definitely will not try to port to Linux as I do not have the time to.

In ImageToSprite() you used always 4 byte as pixelsize (SizeOf(Long)).

Isn't PureBasic using 32 bit internally at all the time? I thought I have read such statement in the earlier past... Ah, I found: The PureBasic Team Blog stated for 4.50:

Image Library changes: We decided to abandon the support for images with depths below 24bit. Support for images with a palette was Windows-only anyway and had quite a number of bugs as well. The library now stores images internally only in 24bit or 32bit format which makes things a lot simpler. Images can still be loaded (and now also saved) at lower bit depth, so you can still work with them if you need to.

So, we do not need to care about lower bit-depth, or do we? Maybe the image has had 24 bit instead of 32? Could'nt you use DrawingBufferPixelFormat() to gather the needed size?

Kukulkan

Hi,

here is V1.04
http://www.infratec-ag.de/PureBASIC/Pres3D_V1.04.zip

What's new:
Added a statusbar in windows mode.
Shows the page number and if the current page is active or not.

I'm not a xml guy. Maybe it is simple to go through the tree and count the pages before.
So it would be possible to show 'Page 1 of X'

I also implemented my discovered Linux stuff.
But still, it is at the same state: not working But it does not crash anymore

Bernd

Hello,

oh well - everytime I come to post, a new version is up and I have to trash all remarks

still - thanks for improving Pres3D so far and I'll be on your heels

'til later ~ Vera

~~~~~~~~~~~~~~~~~~~~

Now is later:
v1.01:
- in the new windowed mode ZOOM isn't available anymore (not reverted 'til 1.04)
(you could change the zoom in fullscreen and it'll be ported to windowed mode as well)
- re-toggling to windowed mode doesn't return to the original or starting position

v1.02:
- commandline support also enables drag&drop

v.1.03 / v.1.04
- fullscreen-toggle crashes Pres3D*
- the statusbar transfers the mouse clicks
- on drag&drop the images won't be processed

* while 1.03 simply crashes (ends) there's a very strange effect with 1.04:
toggling to fullscreen freezes the compilation (still the window vanishes) and the desktop area where the windowed screen has been seen before also freezes. At first glance you won't notice but there is no more mouse and you can't grab what you see in this area. Only the leftover parts of the screen stay active (luckily including the taskbar )

(that's why I don't know yet, how re-toggling behaves in the meantime)
[WIN XP SP2]

----------------
@ Kukulkan
ups - forgot to note: the current Pres3D-download (1.03) misses the Effects.pbi

Hi,

Version 1.05 is online
http://www.infratec-ag.de/PureBASIC/Pres3D_V1.05.zip

What's new:

I removed some procedures and replaced them by
GotoXMLPage()

So it was possible to jump to a direct page.

Have fun,

Bernd

Oh... Vera
So I have new work todo.
Changing the window switch mode was done by Kukulkan. He wanted to avoid 'autostretch'.
Hm, with my new GotoXMLPage() it should be easy to jump to the same page.
So....
stay tuned.

Hi Vera,

http://www.infratec-ag.de/PureBASIC/Pres3D_V1.06.zip

I fixed a few points of your list:

The zoom function was not working anymore in window mode for 2 reasons.
I released the mouse to have a cursor for the menu,
Kukulkan optimized the drawing.
Now it is workig again.

When you switch now between window and fullscreen the same page should be active.
(But the transforming is started again. Should I avoid this ?)

I use Windows XP SP3 and I have no crashes here when I'm switching between the modes.
I also can not reproduce what you mean with

the statusbar transfers the mouse clicks

I have also nothing done for drag & drop

But I noticed the missing 2 rows of the images now.

Bernd

Good night oh.... or better good morning! (why is the time flying so fast ?)

Hello infratec,

I can give you a further hint about that crash-effect (it's still the same in 1.06 as described for 1.04).
As I don't like large windows much I lowered the presetted values in the XML to s.th. like 900x600. Now I found out that the size of the frozen desktop area exactly corresponds with these values. But toggling to fullscreen shouldn't read /depend on those values - or?
Although I might call the taskmanager I can't operate it because everything will stay hidden behind this area. That's why I'm a bit ancious to test what happens if I supply the fullscreen values not wanting to force a reboot via main power. Maybe the effect occures with you too if you change the presetted values as well.

Besides - pagecounting and switching to another page works fine

infratec wrote:When you switch now between window and fullscreen the same page should be active.
(But the transforming is started again. Should I avoid this ?)

I would suggest yes, but I also think this is a minor issue, as on presentating I wouldn't expect a high frequency of interruptions by toggling the mode.

infratec wrote:I also can not reproduce what you mean with
Quote:
the statusbar transfers the mouse clicks

normally a taskbar is 'deaf' and I can click it to refocus a window that's in the background without provoking any further command. But the Pres3D statusbar will also grab the click as shuffle-command and process the next/previous page.

I have also nothing done for drag & drop

I think it's a 'natural' sideeffect of expecting a file command parameter. That the pictures won't be read is because the filepath is unknown on draging. (I'll have a look what I can do about that)

greetings ~ Vera

Hi Vera,

I already reduced the size in the slide.xml to 800 by 600 since I have only 1024 by 768 as monitor resolution.

Do you own an other software which can switch between window and fullscreen?
Maybe a game like 'Florensia' (which my son is playing).
Because it could be your graphic card driver.

Bernd

Vera wrote:the pictures won't be read is because the filepath is unknown on draging. (I'll have a look what I can do about that)

What do you mean?
If you're talking about adding pictures to an WYSIWYG-Editor via Drag&Drop or about loading an xml-file via Drag&Drop, you can retrieve the filename of the dropped file with EventDropFiles().

If you're talking about moving pictures and textblocks in an editor, what do you need the filename of the picture for? If you really need it, use an array and save the filename accordingly to the ImageID.

@infratec
same monitor resolution here as well

Yes I have some applications that switch to fullscreen mode and they never failed. Also Pres3D did until v1.03 (so I'll have a closer look at the changes - maybe I find something).
As for the grafic card - well it isn't healthy anymore still I had no trouble with toggling before.

@TomS
Thanks for the tip with EventDropFiles() so I know already what to look for. Pres3D is fine to read the xml-file as whole but can't allocate the (relativ) links (pictures) inside without knowing the current path.

greeting ~ Vera

Hi,

here is V1.07:
http://www.infratec-ag.de/PureBASIC/Pres3D_V1.07.zip

I only removed the statusbar from the 'clickable' area.
And removed the reload of the xml file. It was not neccessary, a ClearObjects() was enough.

I also checked version 1.03 against 1.04:
The main differences were, that I changed .l against * for the pointer variables.
But I have no explanation why the switching between window and fullscreen is not working on
Vera's PC.
Here it works still without any problems. ( I use PB 4.51 X86)

So I have no chance to find the 'fault'.

Bernd

Hello infratec,

Thanks for hunting as well, but the major difference must have happened between 1.02 and 1.03 and I couldn't find anything yet by chance

Still I accidently found today that the fullscreen toggling will work if I preset one of these classic monitor dimensions: 1024x768 / 800x600 / 640x480
It doesn't work with any other value, even if they preserve the proportions.

Also, only because testing a small dimension I saw for the first time that there was a debugger output (had been hidden before by the frozen screen):

[Debugger Error] invalid memory access (read error at address 0)
[Debugger Error] File: Pres3D7.pb (Line:229)

in: Procedure ImageToSprite(Sprite.i, Image.i, Mode.i = #False)
line: CreateSprite(Sprite, ImageWidth, ImageHeight, Mode)

---------------
I also get a <DebuggerError: can't open screen.. > when cancelling the messagerequester,
for line 200: ReleaseMouse(1)

~~~~~~~~~~~~~~

Statusbar:
- thanks for making it 'deaf'
- is not displayed when I use 1024x768 , funny - only the [active]-part is shown while the rest is covered by the backgroundcolor
(maybe it's because <768+title+menu+taskbar> will never fit on 768)

~~~~~~~~~~~~~~

Opening other XMLs:
- a different presetted dimension doesn't change the windowsize
- BUT after toggling to fullscreen & back the new dimension will be used
-> BUT the displayed contents will then be deranged (not centered anymore but moved sideways, depending what XML one chooses first)

I tested it with two XMLs one with 800x600 and the other 640x480.
A reactivation of <reload current xml file> didn't solve this.

~~~~~~~~~~~~~~

btw: forgot to mention that the zoom is working fine again

Last but not least: the GoTo request wouldn't allow jumping to the last page until I added +1 :
in: Case #GotoWindow
line: If Help > 0 And Help < ArraySize(PageNo())+1

~ Vera

Vera wrote:Still I accidently found today that the fullscreen toggling will work if I preset one of these classic monitor dimensions: 1024x768 / 800x600 / 640x480
It doesn't work with any other value, even if they preserve the proportions.

That's what ExamineScreenModes() is for. If your Graphiccard doesn't support the resolution it goes bonkers (either crashes or looks totally deformed). It has nothing to do with the aspect ratio. A 400x300 simply can't be opened, even though it's the same aspect ratio as 800x600.

And that's why I advised against letting the creator of a presentation setting the screen resolution in the german board.
You should stick to 800x600 or 1024x768. Better 800x600 for netbook support.