PureGDK Open Beta - DarkBasic for PureBasic

Mistrel · Post by **Mistrel** » Wed Mar 26, 2008 3:51 pm

Would you confirm that the same examples run when compiled in DBP? These are the same examples from your DarkBasic Professional installation Help\examples folder. Also, are you running my pre-compiled examples or are you compiling from the source?

I've only been able to test DBP on my desktop (8800 GTS) and my notebook (7400 Go). I'm surprised no one else has mentioned these problems throughout the beta. If it is video card related I may buy have to buy a pci 5200 to test this.

Has anyone else here run PureGDK on a 5200?

BTW, particles-1.exe extracts "dbpdata" and "dbpdata0" in the temp dir, contains the PureGDK and DBP DLLs, I think it's one reason I don't use DBP, there's no need to extract all DLLs before run unless Lee Bamber don't know how to handle APIs(not our problem with PB tho).

The dlls are extracted because they are only merged with the exe to eliminate the need of a runtime library. Because the DBP engine and TPC plugins are a set of dlls and not libs it has to be this way.

I don't think you can load a dll from memory without some form of dll injection. To load from memory would be the same as loading an exe which DEP would prevent.

Most engines are in source or lib form. DarkBasic Professional is kind of unique in that it's build around a plugin framework. I agree that it's not the cleanest method but there isn't anything functionally wrong with it.

yoxola · Post by **yoxola** » Wed Mar 26, 2008 7:02 pm

All my 3 PCs has same config/hardware except Video Card.

All PC are running in Administator mode.

And yes, I tried more possible examples looks like in PureGDK and DBPro, the PGDK ones got problems or no start at all while all DBP ones work very well.

There's something in my observation:

If the program failed to start or crash, it still left the temp files(DLLs etc) in folder "dbpdataXX", growing from dbpdata0 to XXX and they're not cleaned.

And, if you want to find some way to load DLL from a EXE/Memory chunk and avoid DEP, there're some in this forum, and you can just left the TPC dlls as is and laying on the executable directory and no extraction required, but it's not something most important.

I just suffer from the "usability" problem on this and I decided to wait and see if it got improved. I have a boxed DBPro and upgraded to 6.7 so I can test these and see what going wrong.

Mistrel · Post by **Mistrel** » Wed Mar 26, 2008 11:37 pm

If the dbpdata folders are building up in the temp directory that means that there is a runtime error somewhere. PureGDK will normally clean up after itself on termination.

I went out and bought an ATI VisionTek X1300 PCI card to test with and see if I can reproduce the problem.

Edit:

I cannot reproduce these errors except for a special case.

My test systems (all XP Pro SP2) are:
Core 2 Duo E4300
GeForce 8800 GTS (640mb)
4GB DDR 2

Core 2 Duo E4300
ATI X1300
4GB DDR 2

Pentium Dual-Core (Core Duo)
GeForce 7400 Go
2GB DDR2

Pentium M 1.6Ghz
Intel Extreme Graphics 2 (examples which are compatible with DBP run fine)
1.25GB DDR 1

The special case where most of the programs failed to load was were my Pentium M system only had 512MB of memory and had the swap space disabled. I had other things in memory and there wasn't enough room for the program to load and it crashed silently.

yoxola · Post by **yoxola** » Thu Mar 27, 2008 6:03 am

My 3 PCs have P4 2.4GHz and 1GB DDR RAM Each, the difference seems come with video cards.

I'm glad to help with this, however I have not much time on this due to daily job and my family, so I'll wait and see if it's gettign better etc.

Mistrel · Post by **Mistrel** » Thu Mar 27, 2008 6:33 am

Please keep me posted with each new release.

Morty · Post by **Morty** » Thu Mar 27, 2008 8:50 pm

Hi.

I've found a "little" bug in the current release.
If I'm doing that with Debuger, all is fine

Code: Select all

dbLoadAnimation(GetCurrentDirectory()+"myvideo.avi",#AnimNumber)
dbPlayAnimationToImage(#AnimNumber,#img_from_video,0,0,800,600)
dbLoopAnimation(#AnimNumber)

Without the debuger, I get the error that the file could not be loaded.
But if I create an executable all runs fine again, only from the ide seems to be the problem with GetCurrentDirectory()

Morty

Mistrel · Post by **Mistrel** » Thu Mar 27, 2008 9:27 pm

Morty, the current directory is not always the exe directory. It is simply the last working directory.

You can use dbGetDir() which is set to the exe directory by default.

There are also some API examples here:
http://www.purebasic.fr/english/viewtop ... hlight=exe

Mistrel · Post by **Mistrel** » Fri Mar 28, 2008 9:27 am

New beta.

0.4.12b - Mar. 28, 2008 Changelog:

* Fixed several compiler bugs that were created by the 0.4.9b compiler rewrite.
* Fixed a minor bug that would caused a problem if the DarkBasic render window was embedded inside of an MDI window.

Mistrel · Post by **Mistrel** » Tue Apr 01, 2008 11:42 pm

PureGDK was featured in this month's issue of The Game Creators Newsletter. Check it out.

http://www.thegamecreators.com/data/new ... _63.html#3

The fire demo from the newsletter showcases several features of PureBasic including:

Threads
Window callbacks
Linked lists
Enumeration
MDI windows
Gadgets
Windows API

The demo also demonstrates how to embed the DarkBasic render window into another and how to catch mouse input from the parent window using an API callback.

The demo is compiled without threadsafe and it not stable when compiling with the debugger. The next release includes a new threadsafe subsystem which addresses this issue and will allow PureGDK to compile completely thread safe applications.

Mistrel · Post by **Mistrel** » Wed Apr 02, 2008 7:56 pm

New beta:

0.4.13b - April. 2, 2008 Changelog:

* PureGDK can now compile to a threadsafe executable using the new PureGDKThreadSafe subsystem. Add this subsystem to your project under Compiler -> Compiler Options when compiling with threadsafe to use it. Only the core command can be used when compiling to threadsafe in this version. Plugins are not supported.

I'm looking to finalize things and start preparing PureGDK for its official release. Please keep those bugs coming, if you can still find one!

Kelebrindae · Post by **Kelebrindae** » Thu Apr 03, 2008 3:59 pm

I've compiled the same source (except for the 3D commands) in the 3 following configurations:

- PureBasic alone => http://keleb.free.fr/pb/abstractDance_pb.zip
- PureBasic + DreamMotion3D => http://keleb.free.fr/pb/abstractDance_dreammotion.zip
- PureBasic + PureGDK => http://keleb.free.fr/pb/abstractDance_puregdk.zip
(Each archive contains the .exe and the dlls needed to execute it)

Result:
The PureGDK version is very fast.

It's not very significative, because I've tapped only in the basic 3D commands (it's just a bunch of transparent cubes; no complicated mapping, no shaders...), but still...

NB: vSync is disabled in the 3 programs, so they run as fast as possible.

@Mistrel:
I have noticed that 2 DB commands were missing:
- disable object zwrite(obj) => useful with ghosted objects
- statistics(1) => to know how many polys are rendered

Except for that, all I can say is : "Wow!"

Mistrel · Post by **Mistrel** » Thu Apr 03, 2008 8:34 pm

Thank you for making those demos. They really do show the difference.

I can confirm that dbDisableObjectZWrite() does exists and the other command is dbStatistic not "Statistics".

Would you be willing to post your source too for later benchmarks?

Poshu · Post by **Poshu** » Thu Apr 03, 2008 11:20 pm

Actually, yeah, they show the difference, here is what you can find on the French forum:

Poshu wrote: On my comp, windowed with 2048 objects a quite a lot of programs runnings, I've got:
_Dreammotion = 75 fps
_PB = 13 fps ( =_=; )
_PureGDK = 23 fps.

With 256 objets:
_Dreammotion = 700~900 fps
_PB = 60 fps
_PureGDK = 400~1100

Cpl.Bator wrote: 2048 objects in fullscreen, I've got:
_Dreammotion = 85/90 fps, with a program size of 534 ko ( dll + exe )
_PureGDK = 25 fps, with a size of 4,82 mo

So, here is our advice: use Dreammotion or wait for PB 4.30 to choose.

Mistrel · Post by **Mistrel** » Thu Apr 03, 2008 11:58 pm

I would like to look at the source to see if there are further optimizations that can be made to the PureGDK example. This is an excellent test but it's not definitive as a straight binary.

Poshu wrote:So, here is our advice: use Dreammotion or wait for PB 4.30 to choose.

Dreammotion has suspended development. PureGDK (DarkBasic Professional) will continue to be updated as long as it remains TGC's flagship product.

TGC is also working on DBP X10 (DirectX10) which PureGDK will endeavor to support as well.

File size cannot be directly compared between PureGDK and Dreammotion executables. The Dreammotion engine is a single DLL while the DBP engine is plugin-based. Even if a command from a particular library is not used it is still included as a dependency. This can be easily avoided by using compiler exclusions.

Poshu · Post by **Poshu** » Fri Apr 04, 2008 7:31 am

Dreammotion has suspended development

True

PureGDK (DarkBasic Professional) will continue to be updated as long as it remains TGC's flagship product.

True too... and then? PureGDk (even thought it looked interesting at first sight) is far too slow, fat and unelegant to be used right now. Hopefully you'll work on it and we'll see some improvement.

TGC is also working on DBP X10 (DirectX10) which PureGDK will endeavor to support as well.

I've quite a good PC ans I'm not using Vista. I'm proud of that, and I think nonprofessional (and even professional) games don't need Dx10 right now. It's just that kind of shiny feature telling us "yeah, we're next gen so we're better!"...

File size cannot be directly compared between PureGDK and Dreammotion executables. The Dreammotion engine is a single DLL while the DBP engine is plugin-based. Even if a command from a particular library is not used it is still included as a dependency. This can be easily avoided by using compiler exclusions.

Actually, I don't care about size and I think that should not be considered: when it come with media, your product will be fat anyway.... It's just a quick translation from Cpl.Bator's post... Size matters for him ^^;

Don't mistake me, I do like your idea and program, and I've already bought lib. But, right now PureGDK is not a good product since free product overrun it. I still hope that you'll be able to do something great with it, but I thing DB was a bad bad idea to start with.