To all PowerBasic OpenGL User..!
One of the Reason`s to start this Thread is that i have an increasing incomming of eMail`s
with Questions about using the OpenGL (Open Graphics Library).
To have a much better assistance under Legal Advice Scheme and to share this knowlege with the PB Community,
i will create this Thread as a Collection of good Links those giving answers to OpenGL.
The Goal of this Tread is an enlargement of the PB Community and enlargement of knowlege with the PB Community!
This Thread will be accessible also from other Sides...
First ongoing development is created also here:
http://www.powerbasic.com/support/pbforums/showthread.php?t=43874 (http://www.powerbasic.com/support/pbforums/showthread.php?t=43874) <-- Start
All current Threads to OpenGL at powerbasic support Forum:
http://www.powerbasic.com/support/pbforums/forumdisplay.php?s=&daysprune=&f=44 (http://www.powerbasic.com/support/pbforums/forumdisplay.php?s=&daysprune=&f=44)
PowerBasic at Google here:
http://tab.search.sweetim.com/search.asp?q=http%3A%2F%2Fwww.powerbasic.com%2Fsupport%2Fpbforums%2Fmember.php%3Fu%3D17&ln=de&src=36&lcr=0 (http://tab.search.sweetim.com/search.asp?q=http%3A%2F%2Fwww.powerbasic.com%2Fsupport%2Fpbforums%2Fmember.php%3Fu%3D17&ln=de&src=36&lcr=0)
I requesting you to give your Question in a short Form and or post an unknown Link for Reply! Also good Links without having a Question.
EG.:
-------------------------------------------------
OpenGLincluding COM objects?
-------------------------------------------------
http://www.xxx
-------------------------------------------------
OR "No OpenGL doesn't including COM objects!"
if you know that..
...
Jürgen
I think there have been too much thread about OpenGL lately.
Most of them focusing on basic things that have been explained for years all over the InterNET.
There is nothing new under the sun, except on this forum of course ;)
José Roca's being toward to advanced SDK programming, i will keep posting here, and nowhere else.
One thing that could be a useful project is something like my GDImage 3Dchart demo that could be turned into a full 3D business graphic, like in WinDev.
Also there are plainty of visual effects that could be added to BassBox, like the amazing magnetosphere that could be a good candidate ;D
...
I am happy to see the recent interest in OpenGL on the PB forums.
I have considered starting up a game programming forum for PB, but there really doesn't seem to be a lot of people interested in game development. Perhaps with the recent OpenGL interest, The Times They Are a-Changin' ;)
Brice
If you have some expertise in game programming, you are welcomed to post your OpenGL code here.
There are also several peoples interrested in on the Eros's ThinBASIC web site about game programming, and most of them are also members of this forum, thus that could be the start of a new team.
...
Quote
José Roca's being toward to advanced SDK programming, i will keep posting here, and nowhere else.
Since DDTer's have taken power in the PB Forum, communicating with them has become too difficult. SDKer's can't use the graphic control and statements, DDT fonts, etc. Therefore, the code looks so different that a casual reader could think that has been written using a different language.
Patrice: Most of my experience is actually in game development and I worked for some major (and minor) gaming companies. However, I am not overly fond of 3D, I prefer 2D. That said, I am actually working on a 3D related project in PB in my spare time. Since I have reached a roadblock (mentioned in other thread) with my other 2D projects done in PB, I have a bit more spare time :-\
It is important for my games to work on all systems and work well under WINE on Linux (why EZSprite is so great). As great as OpenGL is, a Windows OpenGL game will suffer under WINE. I am working on an alternative 3D engine that purely uses software rendering. I am trying to keep syntax close to OpenGL, yet use only native PB commands as much as possible and resort to ASM in a spot or two to improve performance. Originally this was written in Emergence and it was using DirectDraw for rendering, but there were speed issues with EB itself. I may be getting in over my head porting it to PB (as I am no longer using DirectDraw and that complicates things a bit), but if it works out as planned, it will allow me to finally make a 3D game I have been wanting to make for 15 years ;)
Welcome Brice,
and wellcome to all PowerBasic, PowerBasic OpenGL User..!
Important!
(PowerBasic, PowerBasic)
Here at the Forum is the one and only Place where you will find the "FULL MODES OF OPERATIONS" Support for programming an OpenGL Context.
It`s absolute recommended and since WinVista and now Windows7 much more, to be Conform with the WinApi32.
The usage of DDT and the Headerfiles for them doesn`t provide full operation on essential Funtion`s.
The implemented PB Graphic Control, for example is limited, only RGB and BGR Pixelformat maximum
24Bit = 3 * 8 BIT = 3 Bytes per Color no Alphachannel. RGBA Pixelformat is needed to render the real OpenGL Context.
Additional also only here on the Forum the best OpenGL Third Party addon Library`s
Freeglut 2.6.0 actually translated handy glFunction`s to PB by Jose Rocca:
http://www.jose.it-berater.org/smfforum/index.php?topic=3694.msg12068#msg1206te (http://www.jose.it-berater.org/smfforum/index.php?topic=3694.msg12068#msg1206te)
The last few Day`s i went through the PowerBasic Community outsite this Forum and i was really dismayed about
some Code Examples for OpemGL usage.. I will resarch the Link`s an post them here for Discussion next time.
That`s a next Reason for starting this Thread.
Normally i`m only here on the Forum to stay up to Date with my Code, Jose`s Header`s and other SDK related Topics.
Patrice and Jose, thank`s to you,
however you`re filling in the gaps with the suitable words!!
;)
Quote from: Patrice Terrier on June 28, 2010, 04:29:40 PM
Jürgen
I think there have been too much thread about OpenGL lately.
Most of them focusing on basic things that have been explained for years all over the InterNET.
There is nothing new under the sun, except on this forum of course ;)
Until last week i was thinking the same, but some Day`s outside this Forum, i was involved in some Discussion`s wich have changed
this Illusion.
Especially by talking about the BASICS, our daily routine for progamming, most of the DDT user are unsuspecting
what`s behind the Hood of DDT.
Behind the Hood is that what we do!! Nothing else as plain SDK, , our daily business.
I think the Hook hides the real Interfaces (WinApi`s), because the PB DDT Style is devoloped to provide very
simple Way`s for creating Dialogs, Controls and complete Userinterfaces by using just single Statements.
The control`s and Dialog`s are completly predefined.. Also included, defined and hidden the controlprocedures for these
Windows.
We know that, but to make this old Story short, i will post here some of my last Discussions outside this Forum!!
Also Brice is comming here to learn what`s behind the Hood:
QuoteI am trying to keep syntax close to OpenGL, yet use only native PB commands as much as possible and resort to ASM in a spot or two to improve performance.
It`s needed to have this Discussion...
;)
...
Brice,
Most of the people who have been working in the Borland's sphere (Delphi, C++ builder, etc.) have been biased with VCL, just like PB's guys using DDT.
OpenGL is the widest common denominator to be used with all languages, thus i think you should avoid using ezotics.
...
Hi Brice,
QuoteAs great as OpenGL is, a Windows OpenGL game will suffer under WINE
in my experience this has never been problem, if you use SDK Window in fullscreen or windowed mode.
All games in window, built on top of the TBGL module for ThinBASIC, were reported to run very good under Linux. Until I passed my Linux machine to grandpa, I did few tests on Ubuntu and there was no observable performance degradation. The PC had ancient GeForce 2 MX. If you have drivers installed (not the default ones, but directly from vendor), it runs great, the same applies to Windows.
TBGL is written in PB/Win 9 using Win32 and OpenGL 1.1+ (that means, it adapts to hardware it runs on, using more advanced features when available).
Only problem with WINE I observed was when you "hijack" some control in the window (like LABEL) as rendering surface. That works good on Windows, but never worked in WINE (it is caused by known, not solved bug in WINE).
Petr
Petr,
Your TBGL is a great library, and an excellent example of what can be done when mastering the low level programming!
...
One of the problems with using DDT with OpenGL is that OpenGL recommends using the CS_OWNDC class style for an OpenGL window and DDT does not provide this.
OpenGL does appear to work with DDT Dialogs though, so I am not sure whether the CS_OWNDC class style is critical or not, but it may have some downside not obvious at first.
When using DDT, I would think it better to create custom window class (custom control) so you can make sure it works perfectly with OpenGL.
I do not use DDT (pure API), so I am not limited by this.
Right now I am "fast tracking" my learning of OpenGL. I have never worked with it before, so I am trying to learn it quickly. Within a couple weeks I now have a working OpenGL custom control (hybrid actually which combines a GDI based custom Graphic control with OpenGL). The only thing the GDI part does is allow you to draw on a DIBsection buffer an image, which can then be used to draw on the background of the OpenGL window. Right now I am using glDrawPixels which is very slow on some systems, but I may convert that over to a 3D plane with a texture bitmap.
As far as the 3D objects, this is an area which requires some work since OpenGl does not directly support any 3D file format, so you have to either write your own or write code to import some standard 3D file format. What good is 3D without 3D models ?
Currently I am writing my own 3D model macro language, but I am also researching existing 3D model file formats to see if any would be good to write an import routine for.
Trying to learn OpenGL in just a couple weeks time has been a challenge.
One benefit of converting OpenGL headers to PB myself is it is a good learning experience about the syntax of OpenGL.
I have been using the spec sheets from the Opengl.org web site for all the constants and amazingly the Microsoft Windows SDK docs for the subroutine/function call syntax, since I haven't been using any commands outside the core OpenGL definition yet.
Extensions I research on opengl.org
Personally I find error trapping has been very helpful. I wrote some error trapping routines that call the OpenGL error command so I can see what errors I get after am OpenGL call.
That makes a big difference in solving problems.
I surely don't have the experience of Jose or Patrice with OpenGL, but I am fast tracking the learning experience.
The "OpenGL SuperBible" book I got has been very helpful. Amazingly I picked it up at a Goodwill store (second hand store) for just 25 cents. Best 25 cents I ever spent.
I don't though find OpenGL very intuitive though. I have to do a lot of experimenting before I appreciate what an OpenGl command is really doing.
I am finally starting to get the matrix stuff. Very important for transformations. One thing it at first which was confusing was how the matrix changes are often not absolute, but cumulative.
Also one can accomplish the same thing in more than one way in OpenGL.
I figured out how to make an object rotate on its own axis and it worked great, as an example. Turned out I was doing it the hard way with glOrtho and some calculations. Turned out when I checked some of the links on the PB forums for the NEHE examples, all I needed was glTranslate. Both worked, but one with a little less effort.
I do find the discussions on the PB forums about OpenGL valuable though. Even if it is "old hat" to some here, it does bring out interesting perspectives (and views) on OpenGL which are valuable. Just because those who post in those discussions may be "new" to OpenGL, does not mean they are "new" to programming. Gary Beenes" posts have been invaluable to me and in a short time I have been digging into OpenGl at a very fast rate. Gary writes some very clean code which is easy to read and learn from. His online tutorials have been very well written.
I'm neither expert in OpenGL nor in graphics programming in general. My apportation in this field has been providing headers and translating examples.
QuoteThe last few Day`s i went through the PowerBasic Community outsite this Forum and i was really dismayed about some Code Examples for OpemGL usage.. I will resarch the Link`s an post them here for Discussion next time.
I have read the posts over on the PB forum, unfortunately I can't access the examples attached to posts. Even though I can't participate in the discussions or try out the examples, I am glad to see the OpenGL discussions going on. There are some good folks over there (as there are here) working on it.
QuoteOpenGL is the widest common denominator to be used with all languages, thus i think you should avoid using ezotics.
Nothing exotic. Pretty simple actually as it is nothing more than "old school" 3D.
QuoteI did few tests on Ubuntu and there was no observable performance degradation. The PC had ancient GeForce 2 MX. If you have drivers installed (not the default ones, but directly from vendor), it runs great, the same applies to Windows.
Part of the problem with Linux is only Nvidia seems to care about releasing functional drivers. Proper ATI and Intel drivers are severely lacking in the Linux world.
I have not looked at TB in a couple of years, but the Windows OpenGL based software I was trying out under WINE was written in Blitz Plus, so it may be Mark Sibly's OpenGL implementation that is problematic under WINE.
QuoteAs far as the 3D objects, this is an area which requires some work since OpenGl does not directly support any 3D file format, so you have to either write your own or write code to import some standard 3D file format. What good is 3D without 3D models ?
3DS, MD2 and X formats are fairly easy to work with and there is a lot of documentation for them and support for them in most modeling programs.
The downside to creating your own format is you have no art pipeline and you will have to write converters to convert other formats into your format, or you will have to write exporters for some of the more common modeling programs so people can export the models they create into your format. This is not so bad for static models, but if you are going to create an animated model format, this can get troublesome very quickly.
I wrote a simple DX based 3D engine years back for a project and it allowed for user editable levels. I went with a custom model format (static only) and even wrote a simple model editor so EUs would not have to invest in any modeling programs which "can" be expensive. Hmm... I should dig this out and rewrite it in PB some day.
Chris,
From the people coming here:
Some use this forum as a super-market, grabing the code without even a "merci".
Some are always asking, without giving anything in return.
Some are sharing their tips and source codes with others.
Sometimes this takes over me, and then i am getting rough.
Ask yourself what a low level SDK programmer could learn from DDT contributors or proprietary code.
...
Quote from: Patrice Terrier on June 29, 2010, 05:10:15 PM
Ask yourself what a low level SDK programmer could learn from DDT contributors or proprietary code.
That's very impressive, Patrice. It's good to know you have nothing more to learn from them.
Best regards,
Bob Zale
Quote from: Brice Manuel on June 29, 2010, 05:05:42 PM
I have read the posts over on the PB forum, unfortunately I can't access the examples attached to posts. Even though I can't participate in the discussions or try out the examples...
Brice --
I'm very confused by your posts. Over and over, I've read that you "can't post on PowerBASIC Forums" or "can't try out the examples". You're giving folks the impression that you've been barred from using the PowerBASIC Forums, when we know that simply isn't correct.
Your problem started when you changed your password while retaining an invalid email address on file. Without email contact, you couldn't verify th password, so then you couldn't lof in. We fixed that problem for you, but then you rejoined the forums eight or ten more times using variations on your name, and using many different email addresses. It was impossible to approve them all, so we consolidated them, just as you later requested. PowerBASIC hasn't heard from you since then. If there's another email problem, or another password problem, please contact support@powerbasic.com and they'll help.
Best regards,
Bob Zale
PowerBASIC Inc.
I do not see the whole SDK vs DDT argument. I was happily using SDK via Firefly and I loved it. Unfortunately, I never backed up my reg info before reinstalling XP. Around that time a "friend" bought me PB Forms 1.x and I started using it and I got along with it, so my wife bought me the PBF 2 upgrade with some of her birthday or Christmas (forget which) money soon after it was released.
There are pros and cons to SDK and DDT. Certainly nothing worth arguing about or being elitist about. ;)
Bob,
QuoteThat's very impressive, Patrice. It's good to know you have nothing more to learn from them.
This is my opinion that i can't learn from a black box, but this doesn't mean that i do not appreciate the PowerBASIC compiler, however it is clear that PB has two kind of users.
Among the years you have pushed one group of user, but the other still exist, and they are well alive. :)
...
Patrice--
I think you you may have inferred a tiny bit of misinformation. I haven't "pushed" one group of users. Every user is important to us. If you'd take a few minutes away from this attitude and just look at the PowerBASIC Forums, you'd find thousands and thousands of posts about SDK programming.
There is a place for SDK coding and there is a place for DDT coding. We've always acknowledged that. DDT is simply a tool to get a straightforward GUI program running quickly and efficiently. It isn't perfect for everything, but it's wonderful for many things.
You say you "can't learn from a black box"? You're wrong. If that were true, you wouldn't bother using a compiler. You'd write everything in assembler. But, then again, an assembler is a tool, too. Maybe everyone should go back to entering machine code with toggle switches? What do you think?
Tools are an important part of programming. We use them (when they're appropriate) to build upon the work of others. A compiler is a tool. Jose's header files are tools. DDT is a tool. In fact, DDT code comprises only around 2% or 3% of PowerBASIC. Is that what you're so "worked up" about? Well, thousands of PowerBASIC programmers use it daily, and they do quite well with it. TCP is a tool, also. Should we remove it tomorrow just because you don't use it?
If you prefer SDK coding for your purposes, that's wonderful. Just ignore that 3% of PowerBASIC called DDT. But, as Brice mentioned, there's no point in being an elitist about it. That's just plain destructive. Most of the folks who use DDT are pretty nice, friendly folks. Just like you and I. You should get to know a few of them... {smile}
Best regards,
Bob Zale
PowerBASIC Inc.
Bob,
Back to OpenGL.
We all know here, that low level SDK is the way to go with it.
If you never try BassBox (OpenGL application), then you should, because the whole project is written with your compiler, and it is probably one of the most downloaded PB project :D
People have been told for years that the low level flat API is over complicated, but that is just untrue, and now most of the new programmers generation are totaly lost without dotNET, MFC, VCL, Clarion, WinDev, and the other API encapsulations.
...
Quote
I do not see the whole SDK vs DDT argument.
As I said, sharing code between SDKer's and DDTer's has become too difficult. SDKer's can't use DDT in their SDK programs and new users don't understand SDK code.
You, for example, posted in another forum:
Quote
I need to use a web gadget on a DDT form. Unfortunately, I can't figure out how to do this, as PB does not have native support for web gadgets/controls. I looked on Jose's forum, but could only find info for Windows created via SDK.
And you are an experienced programmer, not a novice.
There have been OpenGL examples (SDK) available for years, but in the PB forum only attract attention if you post them using DDT.
Users of SDK visual designers for PB can't use the graphic control, so they have to buy a third party one or use my freeware one.
Etc.
So there is a problem of communication and great difficulties to share code.
But this is a "fait accompli", so I'm only stating it, not whining. As long as the PB compiler will allow me to program as I wish...
Quote
TCP is a tool, also. Should we remove it tomorrow just because you don't use it?
It's not the same, Bob. TCP can be used by both SDKer's and DDTer's.
My background is mostly game programming where if you wanted a GUI system that had stuff like buttons, image buttons, canvas, image box, scrollbars, tabs, etc (all the standard Windows GUI controls) you wrote your own GUI system from scratch. You would never use Windows API for something like this. So, I really do not "get" the SDK elitism. SDK users just use a crutch made by another company. ;)
SDK and DDT are two sides of the same coin in my eyes. They are both tools and a real programmer will always use the right tool for the job. What tool may be right for one programmer doing a job, may not be right for another programmer doing the same job.
However, I do not think code posted should be expected to be in SDK & DDT formats. If somebody is nice enough to share code with you, you should be willing to put forth the required effort to make it work for your needs.
Quote from: José Roca on June 29, 2010, 08:33:28 PM
And you are an experienced programmer, not a novice.
To be accurate, I consider myself a PB newbie.
I really do not have an issue following SDK code, but applying it to DDT is an issue for me in some cases, but I chalk that up to being a PB newbie, not that DDT sucks. DDT or PB isn't the problem, me not knowing how to do it is the problem ;) Besides that request for help, the only other time I can
remember asking for help is regarding sizing a dialog by client size and that was a case I has simply overlooked/misread something in the manual. I think I have been floundering along pretty good on my own. ;)
However, I almost always learn something new and helpful every time I read the PB forums.
Sorry, Jose, but it's exactly the same. ARRAY SORT doesn't work with SafeArrays. Should we remove ARRAY SORT? MID$ doesn't work with unicode strings. Should we remove MID$? There are hundreds of sub-components in any good programming language which are dependent upon each other. Flight attendants need a pilot to fly the plane. Surgeons need an anesthesiologist. And more.
Patrice wants us to remove DDT just because he prefers something different. Patrice thinks DDT programmers are not very talented. They have nothing to offer him. In my opinion, he's just plain wrong. He's a nice fellow and a good programmer, but he's wrong. There are a lot of very talented programmers who use it. Including me.
DDT and its sub-components are best considered as a package. You can use SDK operations on almost all DDT dialogs and controls. A PB Graphic Control is an intrinsic part of DDT, yet you can still use hundreds of SDK operations on it. Should we remove it just because you can't place it on a Visual Basic Form? I think not. If we removed DDT, you wouldn't even have a Graphic Control to consider. And, if we made a Graphic Control for an SDK Window, Patrice would likely complain that it's a "black box", so he won't use it.
If you use DDT Dialogs, you get a Graphic Control, if you want it. If not, that's just great, too. It's entirely your choice.
Best regards,
Bob
DDT can't be removed because many people use it. It would be crazy. What I'm saying is that because DDTer's use the graphic control and SDKer's can't use it, sharing code related to graphics programming has become difficult.
Several years ago I compiled the first complete reference guide to all the GDI+ Flat API functions (more than 600), and four years ago I posted in this forum more than 300 examples (each one in 3 versions: using SDK, DDT and DDT's graphic control). The reference guide was a success... among PureBasic and ansi C programmers... It's not a joke: a PureBasic programmer used it to write one in French adapted to the syntax of PureBasic.
On July 2009, Gary was trying to use a ListView to load a JPG image with the purpose of then copy it to a graphic control. I tried once more to show how easy was using GDI+ and posted a clear and commented example: http://www.powerbasic.com/support/pbforums/showthread.php?t=41020&highlight=GDIP_DrawImage
On November 2009, I tried again, this time with a little more success: http://www.powerbasic.com/support/pbforums/showthread.php?t=41977
And all this because too many DDTer's are afraid of using anything that is not implemented in the PB language, as if his computer was going to explode if they use an API function.
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.
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, I guess that only Patrice, Petr and I will use it. So be prepared to receive requests about adding GRAPHIC2D statements to the language :)
Flawed form mechanisms are offered in many compilers.
DDT is no different.
And it could have been 100% flawless, PowerBASIC had the chance, believe me.
I really don't know why compiler builders implement these kind of things in such a way that in fact it is restrictive.
I tried to setup such a topic several months ago but had no response, it does not matter as it seems to most of the users, imo it says enough about the level of the programmer.
Somewhere i mentioned it that by pre-registering a simple formclass (instead of offering DDT) it would make life seriously easier already.
Only a few functions would be required to even make things more easier like a messagepump handler similar as offered now.
No one really needs Control Handle to .., they just need the info for GetDlgItem() since most users have to start somewhere and the SDK is to large to learn in a few days.
If the system was meant to be SDK one could implement a custom messagepump handler, for example to be used with a webcontrol or so, but with DDT it is never mentioned to be compatible with other calls or use.
The messagepump is such an example, there are two options here, dialog show modal or the dialog doevents but does not say you can use SDK to extend the program further, it's therefore a black box.
This is one example only.
Many people may be happy but with some clear thinking it could have been 100%.
For years i am really confused about certain steps PowerBASIC inc took like the way DDT got implemented and maybe a few other things.
Imo it's better not to implement things than half way.
But then.. that does not bring the bucks in, i understand of course.
QuoteSo be prepared to receive requests about adding GRAPHIC2D statements to the language
Are we going to make another wishlist thread?
I think anybody of us could sent a big wishlist to Bob. including me - just ask.
The Problem is the same like with a 64 bit compiler. The resources of PB.inc won't be large enough to fullfill all our wishes.
If we look at the alternatives, Microsoft has much more resources. And they develope the wheel somehow every two, three years new (even give it new names). Thats just the opposite from what we want.
I don't think so much in ideologies.
If i want to make a program, i use what i have at hand.
SDK, DDT ... at the end what i want is an dialog - as fast as possible.
And actually i do not need DirectX or 2D etc. I would be happy for structural improvements:
- Improvements in MACRO abilites
- Support for Parameters in Multithreading
- Support for Multithreading in Objects
- x64 Support
In the last days i have thought about better Library organiszation using Powerbasic.
It fails because PB does include all SUBs and FUNCTIONS into the resulting EXE.
With Objects if they are bloated, its even worse.
If I include my own libraries at all i will end up with a monster programm having 90% unused binaries inside.
I'd love a Button to switch that off.
Just tell the compiler "Please do no include unused SUBs or Functions (or Variables?) i nthe final Executable/DLL".
Thats something the user can't fix.
Maybe an preprocessing pass would fix it in the compiler.
Means, i rather take a look on the hardware market and on features that we as user can not easily implement for my wishlist.
So... what I'm hearing now is that we made DDT far too easy for our customers to use. If I just changed it some, and made it more difficult and unintuitive, folks would be much more likely to embrace SDK methodology. I guess I'll have to give that a bit more thought. {smile}
For a long time, I've considered adding a PowerBASIC Sub-Forum called "My Favorite API". We'd encourage folks to pick one API function, and show how powerful it might be, and even easy to use. Give newbies and DDT addicts the opportunity to try it out step-by-step and get comfortable. If you guys will help me by adding a post or two, I'll open the forum... Talk to me?
PowerBASIC has a fine mechanism for ideas and New Feature Suggestions. It's easy... Just GOTO http://www.powerbasic.com/support/request.html Your idea will get the attention it deserves, and it will be recorded appropriately for reference by our R&D staff. Discussing new ideas here (or anywhere) is excellent. However, posting PowerBASIC requests here, hoping PowerBASIC employees will read it and copy it elsewhere, just doesn't seem to have the same impact and staying power for next week, next month...
Best regards,
Bob Zale
It's not that i can not suggest feature enhancements but i do similar things at the office and usually takes hours to come up with a document.
I do not want that for 'externals', and that sometimes frustrates me, i mean my laziness and the obvious changes PowerBASIC inc could make to improve certain things.
This morning it came to my mind if a callback function was used it's a DDT class, if it's an ordinary function it will be SDK (which needs DefWindowProc() and such).
But then, i haven't thought it over + i am an end-user, think about your own stuff (better) and don't depend so much on other people's arguments (and time).
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.
QuoteI'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?
QuoteDirectX? 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 (http://en.wikipedia.org/wiki/List_of_games_with_DirectX_10_support) 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.
QuoteDirect2D? 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.
QuoteThere 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 ::)
Bob,
QuotePatrice 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.
...
Quote from: Bob Zale on June 30, 2010, 09:53:45 AM
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,
Quote from: Patrice Terrier on June 30, 2010, 10:44:36 AM
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 :(
Brice
QuoteWhat 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 (http://www.jose.it-berater.org/smfforum/index.php?topic=1129.0) for long.
...
Quote from: Patrice Terrier on June 30, 2010, 03:24:36 PMmy 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.
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.
QuoteUnfortunately 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.
Quote from: Patrice Terrier on June 30, 2010, 05:05:01 PM
QuoteUnfortunately 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 :)
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.
Chris,
You are a SDK programmer, aren't you? ;D
...
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.
...
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.
QuoteYou 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.
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.
QuoteI appreciate the need to be able to develop applications as fast as possible. The old saying "time is money" really applies to software
development.
Same for me, and this is the reason why in such a case i am using my "beloved WinDev", but i will never be able to write WinLIFT or GDImage with it.
It is also my credo that a "good" programmer must have several tools at his finger tips and choose the best one for a specific task.
...
Brice,
Here is a screen shot of a full fledged 2D interface (with alpha channel) drawn directly into an OpenGL control, and floating hover the 3D animation.
and here is a link that explain some very basic 2D drawing in OpenGL: http://basic4gl.wikispaces.com/2D+Drawing+in+OpenGL
Added:
See also the work of Ryan Cross here (http://www.jose.it-berater.org/smfforum/index.php?topic=2276.msg8401#msg8401)
...
Quote
SDK can be used with DDT, but it is more complicated to use DDT with SDK.
And this is why I did chose SDK. If it was a wrapper on top of CreateWindowEx and you could mix DDT and SDK seamlessly, I will have little to object. I also use wrappers: hundreds of them. I even wrote a class that simplifies GUI programming, but without the limitations inherent to the Windows Dialog Engine.
I started Windows programming using DDT. At that time I had little choice, not knowing anything about the Windows API. One day, I wanted to write an editor, and found that I needed to use SDK because DDT has not MDI support. Another day, I wanted to write a custom control, and found that I also needed to use SDK. I also disliked other things, not worth to mentioning now because they're no longer a problem, such having to use dialog units. And once I learned to use the Windows API, I didn't see any reason to came back.
Regarding new features, I'm above all interested in things like native unicode support, inline functions, calculated object references, compiler checking of intermediate null object references when using the compound syntax with COM, etc. I also would like to see SHIFT implemented as an operator instead of an statement (please).
Quote
I do get the feeling that DDT users are not welcome on this forum, so I should probably skedaddle.
DDT users are welcome. They won't get much help regarding DDT GUI and GRAPHIC statements, but they also use the Windows API and COM for other matters.
Quote
No option is provided for "unjoining" this forum, so hopefully the admin can handle that for me.
Certainly, if that is what you want. You have a long history of joining forums looking for a fight and then abandon them slamming the door.
Quote
For a long time, I've considered adding a PowerBASIC Sub-Forum called "My Favorite API".
My favorite one is SendMessage.
José,
I agree 100% with your list of new features, indeed i would like to have the best of C++ and the best of PB, altogether in one single language ;D
About SDK, the things have been a little {easier} for me, because i started Windows programming at the time of PBDK, and i had no other choice than to learn the core API. When PB/DLL came first onto the market, my friend Philippe Monteil and myself worked together to write DV32. It was one of the first addon written specifically for the new compiler. And since that time, with the exception of COM, i never had to learn something new about the flat API, this giving me the opportunity to learn new graphic technologies as they were coming out.
...
And my favorite one is CreateWindowEx, because everything in Windows is a window ;)
...