My version of PureBasic's future

[J. Baker]

of course its everywhere, it has been around for almost 25 years now.

I understand your reasoning but OpenGL is not 25 years old. It's just been around since then. It has been upgraded throughout the years. So I wouldn't say it's dated. That would be like saying lets get rid of ASM because it's old. The age of something doesn't always mean it's time is almost over. It's been around for a reason and I think OpenGL will be around for a long time from now.

OpenGL is quite nice really. All you need is a driver for your graphics card. No third party plugins, software, etc., to download. That's one of the reasons I like it anyway. I can run the latest OpenGL on an XP machine as long as my graphics card supports it. No need to update your OS like you have to do with DirectX.

I don't know enough about Vulkan. So I can not say whether you need to download extra software or not, or need an updated OS, etc.

[nco2k]

of course. i dont dislike opengl, its just that it didnt improve as much as it should have, while directx quickly got better by a lot.

as far as i can tell, you only need a gpu driver that supports vulkan to run it.

c ya,
nco2k

[J. Baker]

as far as i can tell, you only need a gpu driver that supports vulkan to run it.

Well, that's a plus.

[wilbert]

as far as i can tell, you only need a gpu driver that supports vulkan to run it.

The problem with Vulkan is that it's not available on OSX.

[J. Baker]

The problem with Vulkan is that it's not available on OSX.

Yeah, that doesn't make it a good solution for something like PureBasic. I can not see Apple wanting to support it either since they now have Metal. Which is another one I haven't read up on.

[Samuel]

LOL! I'm not stuck in the past. I'm all for new tech and optimizations.

Except for the fact that you'd prefer a 3D engine based off of an OpenGL version from 15 years ago.

But if one is not using its full effect, why even use it? Why cut yourself off from distributing to customers who don't have the latest hardware or OS?

You'll lose more customers by not keeping up with the times.
Everyone needs to keep up including customers. I'm not saying the best hardware out there, but reasonable requirements. Like I said earlier a lot of cheap graphic cards support OpenGL 3.3+.

Take a look at this link from steam http://store.steampowered.com/hwsurvey/videocard/
It shows the overall distribution of graphic cards for active steam users (which is why some months fluctuate). Less than 5% of users have cards that only support DirectX 9 or lower and more than 95% of users have cards that support DirectX 10+. With the majority of the 95% having cards that support the newest DirectX 12.
So I have a question for you. Would you be willing to cut yourself off from the customers who want your software to keep up with the times?

Just because it's new doesn't make it better.

You're right, the reason modern OpenGL is better than legacy is because modern is shader based which is many times faster and has much nicer results. If you'd like me to go into details like explaining why object buffers are faster than the fixed pipeline then let me know.

Have you never had to revert to older code, app, PureBasic, etc. just because the newer version either didn't work, wasn't as fast, or compatible?

Once when I wanted to see Purebasic's water demo, but it wasn't working with the current version of PB I had.
You know what though the PB team fixed that issue. If developers do their job then these issues won't pop up often and when they do appear the developers will fix them.

That's like saying Windows 7 or better is more secure than XP. LOL! Everything can be hacked and nothing is secure. Treat it as so.

Well, maybe they are more secure. For example let's say both systems have an equal amount of hackers break into them, but it took the hackers twice as long to break into the Windows 7 systems. Wouldn't that mean that Windows 7 is more secure than Windows XP?

The problem with Vulkan is that it's not available on OSX.

You can thank Apple for that one, and the way they're pushing Metal I wouldn't be surprised if they get rid of OpenGL support (if they haven't already).

[J. Baker]

Except for the fact that you'd prefer a 3D engine based off of an OpenGL version from 15 years ago.

Fair enough.

New tech is cool but I prefer to target everyone.

[Dude]

Why bother with two versions, if the 32 bit Windows® version's executables will run just fine on all systems?

I agree with this. My OS is Windows 7 64-bit, but I use 32-bit PureBasic all the way. This guarantees my apps run on any PC and I don't get support questions from my customers. Plus potential customers don't have to decide which version of my apps to download from my site: there's a single download only. No confusion!

[oakvalley]

For me, OGRE mesh objects for use with PB has always been a headache. Trying to convert an OBJ, LWO, VRML and finding tools for such "easy" conversion, we learn that either the softwarelink is dead, or simply goes back to ogre website or needs a very specific version of especially Lightwave.

Why can't they just at least have some kind of OBJ to MESH converter handy (as VRML is kind of dead, replaced by its successor, and LWO is a cranky format)?

http://www.ogre3d.org/tikiwiki/tiki-ind ... +Converter = DEAD
http://www.ogre3d.org/tikiwiki/tiki-ind ... ture=Tools = Need specific LW version

Then, we have the option of choosing (to install one of their export plugins):
1: 3DSMAX
2: MAYA
3: BLENDER
4: MILKSHAPE
5: SOFTIMAGE
+ some others

Where 1,2,4,5 are expensive and buyware, and 3 is way to wierd to work with. Blender has a illogical mouse control and "for no reason" ghosted exportmenu for OGRE mesh while the plugin is really enabled. Trying to install some wierd PY scripts from OGRE website and getting it to work is a headache. For me, entire Blender is total crap made by some very confused people in how mouse control should be implemented. Lightwave I've used since V4.0 on the Amiga back in the early 90's, still do

Wierd that OGRE is free, but the software to convert xxx model to OGRE objects/mesh costs a lot of money.

Looking at the people who have fled from OGRE the past years: http://www.ogre3d.org/about/team versus those currently on the team makes you wonder too. More people through the door than those staying. No wonder why 90% of their conversion tools is broken or a sign that OGRE is obsolete/uninterresting/slow development.

I would wish that OGRE was removed from PureBasic and something else would replace it, what I do not know. So, I guess that part of PureBasic will never be used by me that deals with meshes and skeletons.

For now, those in favour for OGRE in PB can enjoy robot.mesh, some balls, boxes and a bridge demo. I'm not.

[Keya]

Why bother with two versions, if the 32 bit Windows® version's executables will run just fine on all systems?

I agree with this. My OS is Windows 7 64-bit, but I use 32-bit PureBasic all the way. This guarantees my apps run on any PC and I don't get support questions from my customers. Plus potential customers don't have to decide which version of my apps to download from my site: there's a single download only. No confusion!

I completely disagree! Simple reason - 32-bit apps can't do everything that 64-bit apps can do on x64. Consider for example a lot of the process/module WinAPIs - your 32bit app can only enumerate/open/etc 32bit modules, while it's effectively blind to 64-bit modules - your 32bit process cannot access the process memory space (ReadProcessMemory etc) of a 64bit module, so you must create a 64-bit version of your executable in this case, and I would argue that your suggestion of "PB should only compile to 32bit because 64bit OS can run it" is equivalent to saying "32-bit compilers should only create 16bit COM executables because 32bit Windows can still run them" ... and 16bit processes of course can't access 32-bit processes, same deal

[bosker]

Well, I also deliver 32 bit applications to my clients because some of them (about 30%) are still using 32-bit. If I ever need to enumerate 64-bit modules or read their process memory then of course I would compile in 64-bit (but I don't need to do that and probably never will).

Right now, the applications work fine in 32-bit, are smaller and faster than 64-bit ones and I only have to support one set. When my market goes entirely 64-bit or actually asks for 64-bit, I'll start delivering them (everything builds and runs in 64-bit).

I'm happy that Purebasic provides a 64-bit compiler because it makes the transition easy when it becomes necessary, but I'm not going 64-bit just because it's there.

[Keya]

Well, I also deliver 32 bit applications to my clients because some of them (about 30%) are still using 32-bit.

70% of users using a 64-bit OS i guess would be another reason in favor of not ditching the 64bit compiler... (seriously though i can't even believe we're having this conversation lol)

If I ever need to enumerate 64-bit modules or read their process memory then of course I would compile in 64-bit (but I don't need to do that and probably never will).

It was just 1 simple example of 32-bit inability on x64 - not the only one!

Right now, the applications work fine in 32-bit, are smaller and faster than 64-bit ones

how are they faster, if i may ask? I hope i dont sound rude in asking that because I don't know and am wondering! I was just under the impression that 64bit apps run faster on 64bit OS than 32bit as there's no thunking etc so although I thought most 32bit apps could run pretty much on par with 64bit i didn't think they could actually run faster? or can they?

[djes]

For me, OGRE mesh objects for use with PB has always been a headache. Trying to convert an OBJ, LWO, VRML and finding tools for such "easy" conversion, we learn that either the softwarelink is dead, or simply goes back to ogre website or needs a very specific version of especially Lightwave.

Why can't they just at least have some kind of OBJ to MESH converter handy (as VRML is kind of dead, replaced by its successor, and LWO is a cranky format)?

http://www.ogre3d.org/tikiwiki/tiki-ind ... +Converter = DEAD
http://www.ogre3d.org/tikiwiki/tiki-ind ... ture=Tools = Need specific LW version

Then, we have the option of choosing (to install one of their export plugins):
1: 3DSMAX
2: MAYA
3: BLENDER
4: MILKSHAPE
5: SOFTIMAGE
+ some others

Where 1,2,4,5 are expensive and buyware, and 3 is way to wierd to work with. Blender has a illogical mouse control and "for no reason" ghosted exportmenu for OGRE mesh while the plugin is really enabled. Trying to install some wierd PY scripts from OGRE website and getting it to work is a headache. For me, entire Blender is total crap made by some very confused people in how mouse control should be implemented. Lightwave I've used since V4.0 on the Amiga back in the early 90's, still do

Wierd that OGRE is free, but the software to convert xxx model to OGRE objects/mesh costs a lot of money.

Looking at the people who have fled from OGRE the past years: http://www.ogre3d.org/about/team versus those currently on the team makes you wonder too. More people through the door than those staying. No wonder why 90% of their conversion tools is broken or a sign that OGRE is obsolete/uninterresting/slow development.

I would wish that OGRE was removed from PureBasic and something else would replace it, what I do not know. So, I guess that part of PureBasic will never be used by me that deals with meshes and skeletons.

For now, those in favour for OGRE in PB can enjoy robot.mesh, some balls, boxes and a bridge demo. I'm not.

Hey, a lightwave fan !
A loooong time ago, I needed a converter and found this one. So far, I've not used it for years and I don't know if it works with the new lw version (I found it OK with 11.5 if I remember). The source code was included. I'm still hosting the last working version, take a look there : http://www.purebasic.fr/english/viewtop ... 97#p292697
and there : http://www.purebasic.fr/english/viewtop ... 33#p401733
And... I've done a lot of objects with it, happily sharing some, and even used morph functions and bones

[bosker]

@Keya

The speed of 32 vs 64 bit depends on what you are doing.
The stuff that I provide manipulates a lot of scientific data - there's a lot of maths and shovelling lumps of data around. The vast majority of time is spent executing code in my applications - there's not much reliance on Windows system functions, so thunking isn't an issue.

I've found that some of the CPU math instructions in 64-bit are much slower than the 32 bit ones. Division and modulo in particular seem very sluggish. I guess it's because more bits are being moved around in 64-bit.

The difference between 32 and 64-bit math operations was so marked that I wrote a set of benchmarks to check what I was seeing. They confirmed that some things are definitely slower with more bits but the numbers vary from one machine to the next.

The biggest difference I currently have is that in one particular application, the 32-bit version takes only 21% of the time the 64-bit takes. I have a redesign / rewrite planned for that one.

[acreis]

Drop 32 bit support!

But let me first discover how run a 64 bit app in a x86 hardware!!

Thanks in advance!