MiniB3d for FreeBasic

[D.J.Peters]

Hello angros47
is your lib ready for FreeBASIC on Windows 64 and Linux86_64 (ARM)?

I ported TrueAxis to 64bit and ARM CPU's.

For 64 bit it was easy I must changed only the param of the C++ new operator from new[](unsigned int) to new[](size_t) thats was all so far.

Joshy

[angros47]

Currently I work with Ubuntu linux at 32 bit and Wine at 32 bit, so I never made experiments at 64 bit. You'd have to try to compile, and tell me what happen.

About ARM 32, it should works well(after all, the original code of iMiniB3D was for iphone' that is arm-based). So the same fixes needed for x86 64 should work on arm64.

[D.J.Peters]

Hello angros47,
same situation here I have only 32 workstations at home.
Slackware x86 and Windows XP 32 bit.
But you can use qemu-system-x86-64 on your Ubuntu box to run Ubuntu_x86_64 and qemu-system-arm also.

Emulating a 64 bit guest OS on a 32 bit host OS is natural slow but good for porting and testing of libs.

I need a Win7 64 bit ISO image now.

Joshy

Here are qemu on win32 XP running Slackware Linux_86_64 and FreeBASIC_x86_64 click to enlarge:

[angros47]

I can run Ubuntu 64 under VirtualBox (my processor can do 64 bit, but I use Ubuntu 32 because I have 4 Gb of ram, so I don't need 64 bit features).

So, 64 bit is a low priority (after all, you, too, use a 32 bit system, so you don't actually need a 64 bit port). Anyway, on BlitzBasic forum, I read that some users compiled OpenB3D successfully on Mac OSX (that, as far as I know, should be 64 bit)

[Coolman]

for information.

tests for both 64-bit linux (or some distribution) is much faster than 32-bit. debian and ubuntu increasingly possible to use the 32-bit libraries and programs ...

[justfree]

Hello Angros47,

To test openB3D, I converted one of the Blitz3D manual examples, it worked very well.

Are all of those examples already converted to openB3D?

How about samples?

Is it legal to provide freeBasic version of Blitz3D samples using the codes and the assets that those samples have?

[angros47]

No, not all examples are converted. OpenB3D is similar to Blitz3d, but not exactly identical.

Examples that are published on Blitz3d forum should be public domain, and examples included with Blitz3d... well, now Blitz3D is open source, and released under zlib license: since examples are included on github, I'd suppose they have the same license, so it should be legal to redistribute them (or programs derived from them)

[justfree]

Thanks!

[justfree]

Angros47,

all hardware accelerated by the GPU through opengl (BlitzBasic and FreeBasic gfx don't use the GPU for accelerare 2d mode, they just use fast blitting and mmx instructions); OpenB2D, instead, can use hardware acceleration even for collision detection, if available

So, there is no hardware accelerated openGL access using freeBasic, we should always use a wrapper. Am I correct?

[angros47]

No, you are definitely not correct.

Freebasic normally does not use OpenGl, it uses its own library, called fbgfx (that provides commands like CIRCLE, PAINT, LINE, PSET...), and is not hardware accelerated. It provides a set of command that are easy to learn, and enough powerful for many applications.

OpenGL, on the other end, is hardware accelerated: but FreeBasic does not use OpenGL internally: anyway, you can load it like any other external library, and use it, just as you could do in C. A program written in C that uses openGL can be easily ported in FreeBasic.

Anyway, native FreeBasic command does not work in opengl, so old programs (ported from QBASIC and gwbasic) need a rewrite to be able to use OpenGl.

Anyway, FB provides at least one tool for OpenGl: it can create a context (i.e. a window, or a full screen mode configured to display openGL graphic), so you don't need the GLUT library.

Since OpenGL is more powerful, but even more difficult to use than fbgfx (to use it, you have to know how to use transformation matrices, even for the simplest task) I ported a sprite library to make things easier, and called it OpenB2D (to state that the phylosophy is the same of OpenB3D).

Of course, if you want to just use OpenGL with no "helper" libraries, you can do, and FB is just as good as C or C++ to support that.

[justfree]

Thanks for detailed explanation.

Let me see if I am getting it right.

the NeHe examples in freeBasic are not hardware accelerated because of:

Code: Select all

#include once "fbgfx.bi" 

But in this example: "glext_test.bas", we have hardware acceleration:

Code: Select all

#include once "GL/gl.bi"
#include once "GL/glu.bi"
#include once "GL/glext.bi"
#include once "GL/glfw.bi"

because of glfw.bi that gives us a context and that opens our way to use openGL API in freebasic.

In fact, it is like BlitzMax without high level graphics functions.

Correct?

If Correct:

1 - which version? 2.1, 3.x, 4.x.?
2 - why not coding a complete accelerated 2D/3D graphic engine with freeBasic?

[angros47]

Thanks for detailed explanation.

Let me see if I am getting it right.

the NeHe examples in freeBasic are not hardware accelerated because of:

Code: Select all

#include once "fbgfx.bi" 

Wrong: they are hardware accelerated, because they use openGL:

Code: Select all

#include once "GL/gl.bi"
#include once "GL/glu.bi"

fbgfx is just used to create context (the window), then it passes control to openGL; the header fbgfx.bi contains some constants, that can be used with SCREENRES command to tell you want to use openGL (but you can also give the literal value)

But in this example: "glext_test.bas", we have hardware acceleration:

Code: Select all

#include once "GL/gl.bi"
#include once "GL/glu.bi"
#include once "GL/glext.bi"
#include once "GL/glfw.bi"

because of glfw.bi that gives us a context and that opens our way to use openGL API in freebasic.

"glfw.bi" is just the header of glfw library, a small library that creates openGL context (in FreeBasic, you don't need it, but you can still use it if you want; in C, that doesn't have the SCREENRES command, it can be very useful; likely the example has been ported from C)

You could also create your context "by hand": the way to do is different in windows and in linux (i.e., in linux you might have to use GTK), that's why there are libraries like glut, glfw, and fbgfx: to provide a single way to create the openGL window in many platforms; but, by creating the context by hand, you can use it as any window widget, and mix it with other controls (i.e., you can create a window that has buttons, scrollbars, menus, and a frame of that window contain the openGL scene): since the commands to create a window with GUI widgets are different on different platform, there is no standard way to do that.

In fact, it is like BlitzMax without high level graphics functions.

BlitzMax has its own graphic library, that can create openGL context just like fbgfx, or can provide some drawing features.

1 - which version? 2.1, 3.x, 4.x.?

You can use any version of OpenGL you have installed, as long as you have the headers; the context you use is the same, it doesn't matter if you use openGL 1.1, 2.0, 3.x, 4.x ...

2 - why not coding a complete accelerated 2D/3D graphic engine with freeBasic?

What do you think I'm doing with OpenB3D and OpenB2D?

They are built to work with FreeBasic; I didn't use FreeBasic itself to code them because, when I started working on OpenB3D (in 2009), I needed inheritance, and it wasn't supported in FB at time (now it is); also, it's not a big difference, because using openGL is virtually identical in C++ and FreeBasic, so if you can read a code written in FreeBasic that uses openGL you should be able to read the equivalent C++ code, too. And don't forget that fbgfx, too, is written in C, not in FB.

[justfree]

I am now a lot more encouraged to work more with freebasic. Thanks!

[bluatigro]

so if i understand corectly

i can use the blitz3d exaples in FB ? exactly ?

or what is different / extended ?

[bluatigro]

where do i do the .dll and .bi ?

in the same dir as the using programme ?

i think i have to do

Code: Select all

#include "MiniB3D.bi"

corect ?