V104 beta now up

Blitz3D SDK V104 beta is now available here:

http://blitzbasic.com:81/svn/blitz3dsdk/packages/Blitz3DSDK_V104beta4.zip

[edit]***** Note: beta version 4! Yes 4! *****[/edit]

(use your bb.com user/pass when prompted...)

From README.TXT:

Awesome! bbBeginBlitz3DEx() is exactly what I have been wanting since the SDK was released. Thank you!

Please, any chance of ever letting us try it before we buy it?

Hallo ...

the declaration from PureBasic ist Wrong at this

Global bbPaint.bbPaintProc

bbPaintProc not exist.

by TFT

Cheers for this Mark.

many thanks mark, great update

Oops...

Big bug in there that means it probably wont work *unless* you use bbBeginBlitz3DEx!

Currently uploading beta2, also with PB fix...

[edit]
Okay, done - beta2 now up, see initial post.
[/edit]

*lol* and I was sweating over the Freebasic wrapper yesterday and couldn't get it to work. Now it works exactly as i expected.

hi....

the Z Order from Objects ist binding with Pivot are wrong. Lock my tutorial
hire, http://www.purebasic.fr/german/viewtopic.php?t=18797&start=34 , ist under 102 OK . You load the BetaUpdate2 and run this. You can see
the problem.

by TFT

Another (possible) bug in V104b:

In PureBasic demos the function bbGfxDriverName is used.

With the V104b dll I get a trashed stack after calling this function.

I tested the same demos with V103 and is all worked as it was supposed to.

I cannot open the Blitz 3D SDK file B3D.DLL using:

Global b3ddll = OpenLibrary(#PB_Any, "C:\Windows\system32\b3d.dll")
If b3ddll = 0
  MessageRequester ("Fatal error!", "Failed to open b3d.dll")
  End
EndIf

The OpenLibrary() statement always returns 0.
Redownloading the SDK package made no difference.

I am using version 104 beta 2 of the SDK package under Windows ME and PureBasic 4.30.

Can anyone else with Windows ME/98 and PureBasic get the DLL file to open?

Hi,


Can't try your code as this link appears to be dead:

http://www.optima-code.ch/PB/capter10.zip

Object not found!

I really just need: Dat\kosmos.3ds I guess. Feel free to email it to me.


I tried the 'countgfxdrivers.pb' sample and had no problems. Does this sample crash for you? If not, can you post one that does crash?

I'm not actually sure how PB strings work: b3dsdk returns a C style 'const char *' which really needs to be copied by the client language.

BlitzMax and C# do this automatically, but I'm not sure about PB - I suspect not.

Perhaps a ""+PeekS( bbGfxDriverName(gfx) ) is enough to copy it? I'll ask on the PB forums (weirdly interesting when I post there!) but if anyone can clarify this...

Hallo.....

the link was wrong.

http://www.optima-code.ch/PB/capter-010.zip

its OK . I am tested :-)

the Kosmos.3ds is in the Zip Package at Dat\

By TFT

Hi,

I'm still getting a 404 error with that URL.

Can you please email the kosmos.3ds file to me?

Yes, this sample crashes for me when i use the .DLL that was in the "104 beta 2"-pack. As soon as i replace this DLL in the working folder with DLL version 103 everything works.

Note: The first call is successful and returns a string. But I got two graphics drivers and on the second call to the bbGfxDriverName(gfx)-function i get this error:

[ERROR] Invalid memory access. (read error at address 16806673)


The "stack trashing" thing was just an assumption on my part. The problem is that the first call actually works. But it seems that the calls after that crash the program. Even if i just read the first driver name with one call to bbGfxDriverName(gfx) my program still crashes on the bbEndBlitz3D()-call afterwards.

That lead me to think the something happens on that first bbGfxDriverName(gfx) call that makes the process angry in some way afterwards. So I just guessed it might be stack related, but it might also be something else.

I'm using Purebasic v4.30(x86) btw.

The PB stuff is working fine here with PB 4.30 and SDK beta 2.

I'm pretty sure PeekS (bbGfxDriverName (gfx)) is legit, and of course it's working without error here. (The sample named stringreturn.pb also covers this.)

Just saw Mahan's post, but the code looks correct here, so not sure what's wrong. I can't check further as I've only got the one graphics driver installed, sorry.

AKJ: Can you try adding this to the top of the include file, and call Debug ShowError () directly after the OpenLibrary call, ie. on the next line? It should hopefully give some clue as to what's wrong, eg. DLL not being found.

Procedure.s ShowError ()
  error = GetLastError_ () 
  If error
    mem = AllocateMemory (255)
    length = FormatMessage_ (#FORMAT_MESSAGE_FROM_SYSTEM | #FORMAT_MESSAGE_IGNORE_INSERTS, #Null, error, 0, mem, 255, #Null)
    If length > 1 ; Some error messages are "" + Chr (13) + Chr (10)... stoopid M$... :(
        e$ = PeekS (mem, length - 2)
    Else
        e$ = "Unknown error!"
    EndIf
    FreeMemory (mem)
    ProcedureReturn e$
  Else
    ProcedureReturn "No error has occurred!"
  EndIf 
EndProcedure 

(Just noticed you mentioned "Windows ME/98", which could of course be relevant.)

Also, Mark, you might want to take a look at this, a conversion of the Blitz3D demos for PB, which appears to have been overlooked. They still work with a little path-fixing and would be well worth adding.

Correct link: http://www.optima-code.ch/PB/capter-010.zip

ABBKlaus suggested in your thread on the PB forums that it may be a problem with the VC runtime library.

You could try installing this VC6 runtime update, but please note that I don't know how this might affect your current VC setup, system, etc, so run at your own risk.

It might have to be considered a B3D SDK requirement if this is the problem.

EDIT: Disregard this answer in the first place and go check out my comment #20 first (think I might have found it)
I made some more tests and I've got a little more info now:

The v104b2 DLL works with the countgfxdrivers.pb example on my other (eee) laptop. It runs WinXP sp2.

The first computer I ran my tests on (in replies #10 and #15) is a Thinkpad T61 with WinXP sp3.

When I wrote a test-program in FreePascal on the T61 (WinXP sp3) to extract the graphics driver names, it seems as extracting the first name went well i.e. bbGfxDriverName(1) but it crashed on bbGfxDriverName(2), but as a difference to PureBasic the FreePascal program did not crash on other arbitrary B3D-calls after a single call to bbGfxDriverName(1). In PureBasic i can do one call to bbGfxDriverName(1) and after that any subsequent call to B3D.dll crashes the process with "Invalid memory access" as described before.


So WinXP sp2 versus sp3 is a major difference between between these computers and might maybe also be a clue to this problem.



Reading that page, it looked as those where updates for Win 9X, ME and NT4. I've got WinXP so I didn't download these updates as they didn't seem relevant to my computer systems.

Does anyone reading this conversation tried v104 in conjuction with WinXP sp3?

And especially calls to the B3D dll returning CStrings? Both error-reports and success-confirmations are very welcome to help identify/deduct sources of this problem.

Skip this part and go to Edit4 directly below

I'm no C-expert in any way so what I bring up now might be completely wrong but bare with me (and just disregard me if I'm talking trash):

const char *c_str( string t ){
	static char *buf,buf_sz;
	int sz=t.size()+1;
	if( sz>buf_sz ){
		free( buf );
		buf=(char*)malloc( buf_sz );
	}
	strcpy( buf,t.c_str() );
	return buf;
}

This is if I understand things right this C-function from the B3D.dll is used to return strings to external users of the DLL by making sure the buffer is large enough first and then copy the string in question to this area.

I see two problems:


1) What happens when the line "free( buf );" is run the first time?

If the pointer is set to NULL and you run Free(NULL)? Is this ok?

2) static char *buf,buf_sz;

These two variables (pointer, var) are not initialized to zero. This might however be an missunderstanding on my part if C guarantees that "statics" are zero'ed.


Please disregard from this message if it's complete nonsence, I just wanted to ask since you said (in the release-note) that you've been fixing something about the strings, so I went inside to peek about a bit. =)

EDIT: (Foot-in-mouth). After some googling i learned that Free(NULL) is a no-op and that statics are indeed zeroed in C. Well maybe I'll remember this :)

EDIT2: Ah maybe now then:

The line that reads:

buf=(char*)malloc( buf_sz );

should possibly be

buf=(char*)malloc( sz );

instead?


EDIT3:

And right after the replaced line:

buf=(char*)malloc( sz );

we maybe should put this line:

buf_sz=sz;

EDIT4:
So my suggested function (in stdutil.cpp) now looks like this:

const char *c_str( string t ){
	static char *buf,buf_sz;
	int sz=t.size()+1;
	if( sz>buf_sz ){
		free( buf );
		buf=(char*)malloc( sz );
		buf_sz=sz;
	}
	strcpy( buf,t.c_str() );
	return buf;
}

Still ranting and guessing around wildly :)

Hi,

Well found - definitely a bug! Weird, because it was copied from *working* code - one line just went missing.

[edit]Will post a new beta tomorrow - holiday today![/edit]

Hi Mark,

In the last Blitz3D update, you added some fixes to enable apps to survive 'loss of graphics' - such as when UAC kicks in. Has this been implemented in the SDK? I ask because my application (using bbBeginBlitz3DEx) always loses graphics in these cases. Is it possible to detect this? The SDK doesn't seem to have the GraphicsLost() command.

Thanks!

Actually it's 1 line missing and another 1 changed:

		buf=(char*)malloc( sz ); /* buf_sz changed to sz */
		buf_sz=sz; /* missing before. */

It's not that I'm nagging on purpose but I just wanted you to not miss this when you recompile the DLL.



likewise!

edit: spelling

Yes, that code's in there, although I'm not sure where GraphicsLost() has got to. In any case, with bbBeginBlitz3DEx, bbValidateGraphics() is really all you need.

Note that (with bbBeginBlitz3DEx) you *must* call bbValidateGraphics() yourself - since it's your HWND, Blitz3D's WndProc never gets called so it's up to you to handle this. If you don't, graphics will never get restored. See new render_to_hwnd.bmx for one way to use ValidateGraphics. If it's still not working, please post some demo code to bug reports.


Just one line missing: 'buf_sz=sz' before the malloc - and don't worry, I wont be forgetting about this one!

Hi,


This looks like it could be quite hard to fix.

Some changes were made to the SDK to improve the alpha blending quality. I suspect your demo was (indirectly) taking advantage of some of these changes.

Unfortunately, these changes have proven to have some seriously undesirable side effects so with V104 I attempted to 'reset' this stuff to the way Blitz3D works.

What exactly is the demo meant to show?

Do you have a plain Blitz3D version of this demo?

I can run the EXE OK, but how can I compile the demo 'from scratch' - ie: where's main? Where's makecube?

Hi,

Ok, beta3 now up - see link at top of topic.

This will hopefully take care of the PB string related crashes.

@marksibly: A quick test shows that my previous string issues are now fixed, and the included demo-apps work on my computer! Thanks a lot!

I'm on my way to work now, but I'll be playing around with the DLL 104b3 later this evening.

Thanks again both for helping out and BRL for all this great software in general. I have such a great time toying with your B3D scenegraph and compilers. You do a fabulous job bringing 3D to us that just have spare hours to spend on it.

Hallo ....

the Blitz3D works fine.......

The Main Code are in Dir FW, this ist the FrameWork. At PureBasic the Include Codes are configure. Call the Main automaticly. Shit...... my english is so little bit. MakeCube was the Procedure from FrameWork. Wat you see ist not a standat qube. 6 Qube scaling so on. That locks like the cube. Its binding wite a pivot point. I can create 2 Exe. 1.02 and 1.04. ore make the screenshut.

by TFT

I've just noticed that in Si's fps demo, the gargoyle consistently gets stuck when he reaches the first corner directly beneath the very top/end part of the blue path, which doesn't happen in the original Blitz3D version.

Also, emailed PB examples converted by ozak, with relative path-fixes for SDK.

Hi,

Beta 4 now up! Link at top of topic...

> the Z Order from Objects ist binding with Pivot are wrong

This was very easy to fix - just incredibly hard to find!

Turns out the default 'flags' param value for CreateTexture was wrong in the PB and C include files. So my attempts at reproducing the problem in Max were doomed. Oh well, fixed now.

This isn't the first time default params have bitten us in the bum - I'm starting to think they're as evil as overloaded functions. I've had a thorough scan through everything now though, so hopefully that's it!

> I've just noticed that in Si's fps demo, the gargoyle consistently gets stuck > when he reaches the first corner directly beneath the very top/end part of > the blue path, which doesn't happen in the original Blitz3D version.

This is unrelated to the b3dsdk, it's due to the fact that b3d and bmx do their float->int conversions differently. I think. Anyway, I've hacked around it so the gargoyle now goes on his merry, slidey way...