PowerBASIC

[chrisc]

Welcome back Chris Boss

Glad to see you online again at O2,  betcha many PB users will be flocking here if you can SELL
to us your EzGui for O2.  We really need some code generator for graphics and dialogs which Ezgui did for PB
Start small and built your Ezgui for O2 step by step and grow with O2 -- start with visual designer first
don't need OpenGL graphics etc as for now

disinllusioned  pb users like myself and my boss, we definitely will buy from you if you can provide Ezgui for O2 64bits
just generate the O2 code and that's all we need.  Don't have to sell to us at $39 but sell to us at your normal price

[chrisc]

thanxx Aurel
for your 32bit awinh.inc you are still moving in the right direction, pls keep up the efforts to upgrade O2

[Aurel]

pls keep up the efforts to upgrade O2

ok chrisc ..i will try 

[Chris Boss]

I chose OpenGL rather than DirectX for EZGUI for the following reasons:

Direct-X is Object based (COM), while early OpenGL (1.0/2.0) is procedural based, which I prefer.

Direct-X can only display either full screen or if Windowed in only one Window. It is not suited for using in a Graphic Control.

OpenGL can be used in multiple child windows, so it is better suited for a Graphic control.

Most 3D is used for gaming today, so full screen (or one window only) is sufficient for that and so Direct-X is the better choice.

EZGUI was not designed as a gaming engine, but instead as a business app framework. Having a real custom control which does OpenGL 3D makes it perfect for a real custom control, which can have multiple instances on the same parent form. EZGUI's use of OpenGL also makes it work better on Linux with WINE too.

So, Direct-X would not suffice for the needs of a real custom Graphic control capable of multiple instances.

With that explained, EZGUI supports the STL 3D model file format and it loads/displays STL models which contain millions of polygons in just a few seconds on a typical mass market PC (aka. from Walmart). It displays STL models faster than most STL model viewers I have tried.

Gaming engines (aka. Direct-X) often cater to low polygon count models using texture maps for realism.

EZGUI, using OpenGL and STL format, caters to extremely high polygon count models with no texture maps needed for realism (except for color though). The details of such high polygon count models is amazing. I have tried it with some STL models with 2 million polygons and it loads/display them in a few seconds on a low end PC.

EZGUI also has a unique hook command which allows one to define objects and draw them with other 3D drawing engines or even pure OpenGL. Petr Schreiber's MD2 3D model engine works great with EZGUI's 3D Canvas control using this hook feature. His engine displays the kind of realistic texture mapped models one may often sees in games.

[Mike Lobanovsky]

Thanks for the input Chris,

Please have a look here for what multi-million polygon count, multi-texturing, multi-lighting, and modern 3D in general are all about.

[Chris Boss]

Mike, not so fast.

Follow the links for the 3D model (Biped Robot) on SketchFab and it says"

Less than 17k tris

Less than 17,000 triangles (polygons).

I have loaded STL files with over 2,000,000 (117 times more triangles than robot model).

Like I said, most gaming style 3D models use low polygon counts (in the thousands at most) but gain realism from texture mapping and shading. To get the kind performance most 3D games require, polygon count is crucial. A few thousand polygons (triangles) is not a lot for a 3D model.

[chrisc]

yeah,  if your Ezgui can work in 64bits then you probably can compile programs to multi-million polygon count

hence it is best to convert your Ezgui visual designer to generate O2 64bits codes
best to use O2

the problem with alternative basic languages can be summarized as follows

Freebasic is now similar to PB -- dead in the water and no further development, probably many folks will
be abandoning it

Purebasic does not have basic language syntax, making it difficult to covert powebasic code to it

Xojo is a glorified basic interpreter, it is slow and its executables are huge as it needs
Xojo distributable to execute its embeded pcodes. it does not support dll and inline assembly

GlBasic is also dead

[Mike Lobanovsky]

Mike, not so fast.

Of course Chris,

I'll hold my horses. Indeed it takes time to register on the forum and download the actual models ObjReader deals with.

In the meantime, here's the exact mesh data as seen in my dev version of ObjReader for the Event Horizon model my link takes you to:

[attachment deleted by admin]

[Chris Boss]

Mike you can download the Event Horizon model here:  http://www.digitawn.co.uk/3d-downloads.html

The site is the models authors site.

Download it and see if you can see how many polygons in the model.

[Charles Pegge]

Hi Chris,

We don't have static libraries yet. But one possibility, I am investigating, is to generate mapping files when dlls are created. These can be used for statically embedding code from the dlls.

[Mike Lobanovsky]

Chris,

Sorry for a delayed response (more on the reason why a little further on below).

I don't really need to download the model again. It was done years ago. And BTW ObjReader was prototyped on this very site. There must still be some remnants of that effort here somewhere... Oh, those were the times! My personal message count used to be almost twice higher than it reads now, and the site daily unique visitor count was probably ten times higher than it is today.

... see if you can see how many polygons in the model

Actually I can. Can you?

Seriously, no. The LightWave modeller doesn't yield the model file statistics that easily. "Something is rotten in the state of Denmark..."* and every bloody "pro" vendor on the market are falling over themselves to obscure their proprietary model file format as much as possible -- well, almost as much as e.g. .SLL files are in PowerBASIC.

But using the LW "official" OBJ file exporter (see picture 1 below) we can obtain a 455 MB large (!) event_horizon_007_v001.obj version and a "matching" event_horizon_007_v001.mtl material library of the original .LWO model to try and import them in a 3rd party viewer to verify my ability to put two and two together in OpenGL and count the number of model polygons correctly (see picture 2 below). Needless to say that most "pro" OBJ viewers and "editors" would merely choke and crash with insufficient memory at an attempt to do just that.

Chris, if you're not sure who I am or what Freestyle BASIC Script Language is then just ask and I'll answer, and my crown isn't going to fall off my head. I am just another one of very rare, almost defunct species of indie BASIC developers pretty much like Bob Zale was or Charles Pegge or Eros Olmi or James Fuller or Richard Russel or ... uhm ... Zlatko "Aurel" Vidlanović are (I hope I spelled the name correctly, pal).

I am proficient in ANSI C and several modern BASIC dialects, pretty good at C++, and good at 32 bit assembly. Apart from my real life duties irrelevant here, I have a ca. 15 years experience in developing BASIC translators and interpreters, C compilers, and 32 bit assemblers. My long-term pet project used to be Freestyle BASIC Script Language (FBSL, now infinitely suspended in favor of more visually pleasing and satisfying hobbies). I am familiar with the Borland products -- Turbo C, Turbo Pascal, Turbo Assembler and Turbo Basic -- that used to be very popular on my side of the infamous Iron Curtain since the days when Intel and IBM compatibles were still very scarce here due to the COCOM restrictions. And yes, our Sputnik and Laika and Youri Gagarin all went into outer space mounted on top of raw intercontinental ballistic missiles. I am retired now and actually I am exactly 62 years old as of today.

Seriously again, if you really wonder why Patrice Terrier's OBJ models are so special and good looking compared to their crude and raw prototypes, you are welcome to register on the objreader dot com site and address all your questions directly to him. Once registered and still wondering how come huge, HUGE, HUGE Wavefront OBJ model files that take minutes and hours to load (if at all) and render, respectively, in a single frame in "professional" 3D modellers can be loaded, re-triangulated and re-normalized in seconds, and rendered at 30 (typically 60) frames per second (a.k.a. FPS) at superior quality settings (see picture 3 below), you will be able to not only load the models proper but also get a full set of ObjReader sources and resources (my contribution included) -- open and free.

Now, can we expect, just as a matter of reciprocal courtesy, a heads up on why exactly should Oxygen Basic (or its PB oriented clone) be tailored especially to commercial Ezgui (I gather that must be some sort of PB-dependent windowing framework) rather than any other well developed and free, 64-bit OOTB capable and multi-platform GUI library such as e.g. IUP, wxWidgets, libui and the like?

_______________________________________
* William Shakespeare, "The Tragedy Of Hamlet Prince Of Denmark"

[attachment deleted by admin]

[Charles Pegge]

Mike delivers robust critique 

[JRS]

We don't have static libraries yet. But one possibility, I am investigating, is to generate mapping files when dlls are created. These can be used for statically embedding code from the dlls.

Charles has dynamic DLL creation working in DLLC. Having O2 as a Script BASIC extension module is the best of both worlds.

[Aurel]

by the way PAL...
FBSL have very good FORM DESIGNER.... right?

[Chris Boss]

My EZGUI engine does return back the number of triangles in a model, so I can always tell. Sadly it only works with STL 3D models.

My comments about BASIC and the need for a better GUI are simple. Having been a BASIC programmer for close to 30 years, I have lived the transition from CPM, to DOS, to Windows 3.1 and finally WIN32 Windows. I wrote customer software business in the beginning and it was more than just a hobby for me. My EZGUI was designed not for the hobby programmer, but for the professional writing commercial quality software. The problem with BASIC has been that it straddled the hobby world and the commercial world. Commercial developers have much great needs and being able to produce a high end GUI is vital. This is where Bob Zale lacked. He was probably one of the best compiler developers around, but he came late into the GUI world. For example for years, when PB should have been a standalone development tool, he catered to the Visual Basic world as an addon to VB. I remember the ads in the magazines. He couldn't get past the DLL stuff into building full blow GUI apps. Only an advanced WIN32 programmer would have been able to write a GUI app using early PB DLL versions. Bob had enough on his plate just writing the compiler. He really needed to have some inhouse WIN32 experts in the early years to help with the GUI stuff. I only developed the predecessor to EZGUI because of shear need when I was using PB 5.0, since there was no easy way to write a GUI app back then. My inhouse work eventually became a product which I began selling. Even with EZGUI being far more advanced than Bob's later early DDT, my work was still only rudimentary. I was still learning. There was so much to learn it seemed like it would take a life time. There is a good reason Microsoft got away from WIN32 development. It just was too hard and too time consuming. They developed MFC and ATL, but that was only a bandaid on the problem. Microsoft wasn't expecting the success with classic Visual Basic they eventually had. GUI development became easy and now programmers could write apps at lightning speeds. In time MS moved to dot.net, but still the idea of drag and drop development was obvious.

This is why the best thing that ever happened to Powerbasic was those third party developers who started creating drag and drop visual designers. Bob had no choice but to play catch up and create PB Forms, but it paled in comparison to what third party developers were doing. The most successful was like Paul Squires Firefly, because it emulated classic Visual Basic. I chose a different route concentrating on the GUI framework and less on the designer experience because I felt that the front end depended ultimately on the back end. I had less users, but I likely had more users writing higher end commercial software with better GUIs.

The GUI framework makes or breaks a compiler today. Windows is all about a graphic experience. In the old DOS days this did not matter so much (except for games). Most apps were simpler UI's which were only text based. Todays demands are much greater.