Sticky: PowerBASIC OpenGL Off-Site Community

[Brice Manuel]

I'm very confused by your posts.

Missed this earlier.  Perhaps you could ask Steve to let you read the PM I sent him a few days ago?

DirectX? Forget it. Many people asked during years how to use it with PB. As soon as I made it possible, first writing wrapper functions for PB8 and later interface definitions for PB9, the interest vanished.

Do you know how hard it is for an indie developer to find a publisher willing to touch a game made using DX9?  The reasons are two-fold.

1.  DX9 does not work well on Intel graphics cards which is sadly used on a large percentage of systems sold.
2.  DX9 has major compatibility issues with itself as new versions are released every three months and although it is backwards compatible, it is not forwards compatible.  If somebody buys a DX9 game, there is a good chance it will not work on their system without redownloading DX9 (which gets outdated every three months).

There are actually reasons why indie publishers are still carrying so many DX7 titles.  There has to be a demand for something before you can actually sell it.  It is only within the past 18 months that you have seen indie publishers increasing the number of DX8 titles they carry.  DX9 games are definitely in the minority for most indie publishers.

The major gaming companies deal with the same thing with AAA titles.  DX10 was released with Vista (fall of 2006).  Here is the list of AAA titles using DX10 that have been released since DX10 hit.  Considering a few hundred AAA titles get released every year, the DX10 titles comprise a laughable minority when you consider DDX10 is almost four years old.

When it comes to DirectX, newest is not always better.  Again, it is the right tool for the right job.

Direct2D? The next update of my headers will allow to use it with PB. But as it requires Windows 7 and the use of low-level COM

Direct2D also works on Vista SP2 as long as the platform update is installed.  Windows Update has the platform update flagged as a "Recommended" download.  

I haven't read much on Direct2D since MS first presented it at PDC '08, however not much has changed since then.  Unless you are content with it running via software rendering you are going to need a DX 10.1 capable graphics card to take advantage of Direct2D which leaves out the majority of users who have Intel graphics chips or grossly outdated Nvidia/ATI MOBO vchips.  Heck most Windows 7 systems being sold now are still chugging along with 10-level-9 rendering for Windows 7 itself, because of lousy graphics cards.

There have been OpenGL examples (SDK) available for years, but in the PB forum only attract attention if you post them using DDT.

It would seem the actual interest in SDK code is not the same as the perceived interest in SDK code

[Patrice Terrier]

Bob,

Patrice wants us to remove DDT just because he prefers something different

For me DDT would have been a perfect addon candidate, like PBform.

Historicaly the first PowerBASIC Windows compiler was PB/DLL and it was exactly what i was looking for, because it could compete with C with a syntax i was familiar with. Then you started to put your resources on DDT stuff, leaving the gap between C and PB become larger and larger, and making PB/Win something different, hence my frustration because i felt abandoned.

...

[Edwin Knoppert]

Well, Edwin, at PowerBASIC we don't depend upon the "arguments" of others.  We welcome the suggestions of our friends and customers.  We really want to know what features would help you in your day-to-day use of PowerBASIC.  If you share that information with us, it's far more likely you'll see it than if you simply sit back and wish for it.  You don't need a huge document.  You don't need fancy semantics.  You simply enter a few sentences to describe your idea.

Best regards,

Bob Zale
PowerBASIC Inc.

Thank you for your kind reply, i'll consider it to do that more often.
I already did sometimes but for these kind of things i had the feeling a thorough explaination may be required.

Thanks,

[Brice Manuel]

Historicaly the first PowerBASIC Windows compiler was PB/DLL and it was exactly what i was looking for, because it could compete with C with a syntax i was familiar with. Then you started to put your resources on DDT stuff, leaving the gap between C and PB become larger and larger, and making PB/Win something different, hence my frustation because i felt abandoned.

Why do you feel that way?  What is keeping you from solely using SDK only with PB now?  Why do you feel others should be forced to follow your methods when you are not being forced to use DDT?  I am not asking to be instigative, I am just trying to understand your reasoning.

*edit*  I do get the feeling that DDT users are not welcome on this forum, so I should probably skedaddle.  I only joined the forum so I could download SED.  The SDK elitism besides being juvenile, is also amateurish.  It is counter-productive and needlessly divisive to the community.  We are supposed to all be playing the the same team.  Unfortunately, some rather play for team ego than team pb

[Patrice Terrier]

Brice

What is keeping you from solely using SDK only with PB now?

You totaly miss my point.

However you are correct when you speak of elitism, because as a third party addon provider, my competitors are C++ programmers not DDT rookies, and i am learning direct from the low level API, because that's the foundation of Windows programming. Thus i would like PB to help me to stay in the race with my competitors, and i have no problem to assume this.

I have expressed my choice here for long.

...

[Brice Manuel]

my competitors are C++ programmers not DDT rookies,

Rookies, huh?  What is sad is you actually believe what you say.  To be honest, the rookie mistakes you continually make in posts (especially about SDK)  on the official forums and this forum show your inexperience and that you still have a lot to learn, especially if you plan to only use SDK.  Unfortunately your arrogance is the greatest obstacle to your competency as a programmer.  Somebody who thinks they know it all can never learn anything.

It would appear the purpose of this forum is for a select few to sit around and tell each other how great they are and put down PB and put down other demographics of PB users in every other post.


However, this thread has convinced me there is a need for a gaming related forum for PB where all PB users can have open and unfettered discussion about gaming related topics regardless of the methods they choose to use. 

No option is provided for "unjoining" this forum, so hopefully the admin can handle that for me.

[Bob Zale]

Patrice-

I've tried very hard to explain this in a polite and businesslike fashion.  All C++ programmers are not "Pros".  All PowerBASIC DDT programmers are not "rookies".  These are good people.  Please treat them with normal business respect.

Best regards,

Bob Zale
PowerBASIC Inc.

[Patrice Terrier]

Unfortunately your arrogance is the greatest obstacle to your competency as a programmer.

If i could make some good friends using a specific compiler that's fine, but my first motivation to select a compiler is business, just business, everything else is the cherry on the cake.

Amen.

[Edwin Knoppert]

Unfortunately your arrogance is the greatest obstacle to your competency as a programmer.

If i could make some good friends using a specific compiler that's fine, but my first motivation to select a compiler is business, just business, everything else is the cherry on the cake.

Amen.

You don't always have to express what you feel.
A needless statement leading no-where..
Oh well, i have been there myself

[Chris Boss]

I don't find the DDT command set limiting to using SDK style coding with it.

The PB Graphic command implimentation was ingenious!

All the PB Graphic control is, is a STATIC class OwnerDraw control. It works exactly like a STATIC class ownerdraw window except DDT is doing the drawing in the WM_DRAWITEM message.

DDT simply has its own internal dialog procedure and it then forwards messages to the apps dialog procedures. No problem here!

This allows it to handle mundane messages like the colors and ownerdraw so it can handle colors and the PB Graphic control so the programmer need not have to.

This is perfectly in harmony with SDK programming (they are using a built in window class, dialogs, and not a black box).

It would be wrong to think that one can't integrate SDK style coding with DDT's Graphic control. I did it!

A good example is my EZSprite library.

It can take control of the PB Graphic control and integrate 2D sprites on top of the controls image and it does not conflict with it at all.

It was easy to accomplish this because I assumed that PowerBasic followed the rules with the PB Graphic control and likely implimented the proper way for ownerdraw.

So it was proper to assume the control still supported WM_PRINT and it does.

Integration was easy. I simply subclass the control, take control of WM_PAINT, send WM_PRINT to the control to get the current image so I could use it to merge with my sprite engine images. Because Powerbasic didn't do anything strange, it was no problem.

If they had implimented a black box graphic control, I may not have be so fortunate.

My sprite engine works seamlessly with the PB Graphic control (actually with any static control which supports WM_PRINT).

So whats the big deal, saying the DDT somehow conflicts with SDK style coding ?

It doesn't.

I think that one of the reasons I found DDT so easy to grasp as far as how it works under the hood, is that I did the same thing in versions 1.0 and 2.0 of EZGUI. I used the built in dialog class. One can easily build upon the dialog class using SDK style code and still follow the rules as far as the API goes.

I have gone beyond that now, by using a custom dialog class, which is still part of the windows API, rather than the dialog class. IMO Powerbasic should drop the dialog class in the next version and move to a custom dialog class. Windows was actually designed in a way so it makes it easy to customize the dialog class and build classes on top of it. This technique has been around since Windows 3.1 surprisingly, but few seem to use it. A custom dialog class would give DDT more control over the window class for forms. Thats how I implimented MDI. I use a hybrid custom dialog class (actually multiple classes) which allow me to emulate dialogs, MDI parents and MDI children and it all follows the rules for the Windows API. Microsoft put such ability into Windows, simply by providing key API's for building custom dialog classes.

DDT may not be my "cup of tea" in its implimentation (too close to the API for me), but it works, works well, follows the rules of the API, is easy to integrate API code with and is reliable (not buggy). Because such a large number of PB'ers use it, it should be supported as much as possible by third party developers (meaning, make your tools work with it).

About the only thing I would suggest to Powerbasic for the future is make sure that you always give users access to any true API handles for any resource PB may create, even if PB doesn't use them in its own commands.

For example, with EZGUI I define Fonts using an index. Font #1, #2, etc. When a user creates a font they create it with an index (ie. EZ_DefFont SomeIndex&, "Arial", 10, "V" - which is a 10 point variable width Arial font). But so not to limit the programmer I provide a function to retrieve the actual operating system font handle (ie.  hFont& = EZ_FontHandle(SomeIndex&)  ) so it can be used with any Windows API.

The point is, even if PB uses its own internal way of tracking bitmaps, fonts, etc, provide functions to convert those values to actual API handles. Then no one can ever complain they can't integrate the Windows API, with PB resources created using DDT. As long as you do that, there shouldn't be any problem mixing the two (DDT and SDK).

Also, while you may not want to give away any secrets, Powerbasic should provide some background info about what DDT is doing under the hood so SDK style programmers can more easily integrate the API with DDT. I do that with EZGUI. Now that is a "black box", if there ever was one, yet my customers rarely have problems integrating the API with it. The reason is that I provide many mechanisms to get true API handles and create hooks to key procedures (ie. to the message loop, internal window procedure, etc.). If the user need to process a message before EZGUI does, they can simply create a hook into its internal window procedure and then process the messages using a standard dialog procedure using the API.

The point is, that if something as complex as EZGUI (" a really big black box") can easily allow users to integrate API code with it, surely DDT shouldn't be a problem to do the same.

[Patrice Terrier]

Chris,

You are a SDK programmer, aren't you? 

...

[Patrice Terrier]

Brice,

To come back to OpenGL, and show you that i can also be a good guy...

Take a look at the BassBox "Matrix" plugin, especialy the HUD section, it does 2D altogether with 3D animations and shows one way to create a specific user interface with OpenGL.

...

[Edwin Knoppert]

Chris, what a terrible single-minded perspective do you have today..
Because WM_PRINT works it is ok?

And what if i want that graphic thinghy in my SDK window?
I also mentioned visual activex support, what if that doesn't work on your ez-something-window?
Pfftt.

Anyway, my two points are that DDT is salvageable towards SDK mode and not keep it a black box but provide additional info in the helpfile what we can do with SDK syntax.
Like the messagepump example i gave.

[Chris Boss]

You are a SDK programmer, aren't you?

To answer, Yes and No!

Would I write an application simply using the Windows API ?

Absolutely not!

That would take too much time and is too low level. I prefer as "high level" of an programming environment as possible.

Yet, part of the answer is Yes.

The core EZGUI runtimes are 100% pure API code and couldn't be written any other way.
So yes, I am an SDK style programmer.

The EZGUI Visual Designer (and version 5.0 will be far superior to the 4.0 one) is not only not an SDK application, but it is a 100%
EZGUI application (written only using core PB commands (no DDT) plus EZGUI runtime calls). Not a single Windows API is called in
the Visual Designer, not one. All of the calls are made to the EZGUI runtime and only the runtime calls the API.

I am a firm believer in using "high level" tools for programming. I did a lot of custom programming for local companies years ago, so
I appreciate the need to be able to develop applications as fast as possible. The old saying "time is money" really applies to software
development.

The need for high level tools is one of the primary goals of the next version of EZGUI. I have exhausted much of what I need to do with the Windows API
when it comes to normal controls (standard and common). The majority what one may need for writing a windows application is already in EZGUI 4.0
and most of my customers only use a small portion of its command set. The next generation instead is built upon the concept of "Code Reusability", rather
than just more API stuff.

What I mean is that, EZGUI already provides so many "low level mechanism" for handling API tasks (ie. ownerdraw, custom draw, subclassing, drawing directly on controls
backgrounds, etc.) that in the right hands one could do amazing things with it. The problem I have found though is that while the low level features are there, the average
programmer finds it too time consuming to work at that low level. If they do work at a low level, they want to be able to "code once" and reuse over and over again.

So the mechanisms I have added to the next version of EZGUI deal more with component design, code reusability, "high level functionality" (like the new auto sizing engine for controls)
, plus a few new more current features like OpenGL.

In that sense, I want to steer users further away from the API and let them just use (or build) components which they can just plug into their applications with minimal amount of code. Those who are experienced API programmers though can still use all the low level stuff and likely will build their own components.

Because of my slightly different approach to programming (albeit different than most), I can appreciate the views of both "camps", those who prefer the SDK style of programming
and those who prefer DDT (a slightly more high level approach). When I see people comment about DDT as a "black box", I have to laugh. If DDT is a "black box", then EZGUI is a "black universe". The point is that it doesn't matter. In the end, what matters is making PB'ers productive in whatever their fields are, so they can develop software as quick as possible, which works and works reliably. The end user doesn't care whether the app was written using the pure API, DDT, EZGUI and PB. The end user doesn't care whether the app
is a single EXE, uses multiple DLL's, etc. All they care about is whether the software can easily be installed and serves the purpose for what it was designed for.

I do subsribe to the "keep it as small as possible and as fast as possible" tradition found in Powerbasic itself. Thats why I wrote EZGUI 4.0 (and 5.0) in PB 6.1, rather than 9.0, since I count bytes too! But in the end, because it was all written using some powerbasic compiler (EZGUI in 6.1, my customers EZGUI apps likely in PB 9.0), the entire application will still be
extremely small in comparison to what the latest generation of dot.net compilers are putting out.

[Chris Boss]

Edwin,

The concept of DDT is not meant to be used in both directions.

SDK can be used with DDT, but it is more complicated to use DDT with SDK.

But anyone who prefers to work with the SDK so much, isn't loosing out on much, since I would think they should be
able to most of what DDT does with the SDK, so the DDT command set is not so critical to them.

When I said that the PB Graphic control handles WM_PRINT, that is a big deal, since one of the requirements of custom
controls in Windows is that it should support WM_PRINT and fortunately the PB Graphic control did not break this (they
implimented proper owner draw code, so as to leave intack the static controls ability to handle WM_PRINT).

Because of this it made it easy to integrate my EZSprite engine with it.

Actually EZSprite could be used in any SDK style app, with an Static control which supports WM_PRINT (all built in windows
controls support WM_PRINT, but a custom made static control may not).

Working purely with the SDK is not the panacea it is made out to be. Me personally when I write API code, I try to always
wrap that code into reusable routines and then afterwards I don't call the API any more, but call my own routines.