Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - bigsofty

Pages: [1] 2 3 ... 170
GLBasic - en / Re: Playmusic freeze
« on: Yesterday at 10:02 pm »
I remember that I had a lot of problems with the playmusic function (especially on mobile) and finally, I used the playsound function.

Moreover, at the time of launching this function, everything slows down (as in my demo with the music of 2001, when the music stops and restarts, the demo slows down).
Nevertheless, it is a bit normal because the music is not loaded in memory, unlike the playsound function.

Erico, you should convert all yours musics to be compatible with the playsound function. Personally, I think this is the best solution at the moment.

Playmusic slows your code down, wow. This is a bit of a concern TBH. Have you tried this recently Snoopy?

GLBasic - en / Re: Scaling 3D models to relative size
« on: Yesterday at 09:53 pm »
As long as you don't have tonnes of models, it's usually easier to load the models into your model editor and scale it there.

Just a word to the wise, the Steam "Updates History" and the "Recent Updates" for Godot need updating. I think Android support could be an important addition for possible buyers. Also keeping "Updates History" updated should be a priority as it’s the first place buyers look when buying software to see if the app is dead or not.

I don’t mind lending a hand if need be.

BTW there are a few English grammar mistakes in the current Steam ad too.

GLBasic - en / Re: How to compile "Fluids" ?
« on: 2019-Jul-11 »
No problem Qedo, its actually a very insightful example on how to manipulate GLB arrays via inline C. I just wish I knew why the first part behaves as it did.  :blink:

GLBasic - en / Re: How to compile "Fluids" ?
« on: 2019-Jul-09 »
This fixes it, although I have no idea why...  :D

I was writing a bit of test code to see have a look at how GLB uses 2D arrays in C and it seemed to make ALL the code compile?!? It seems like this code needs to have an existing GLB 2D array already defined?

Maybe Gernot could clear up this little mystery?


Code: GLBasic [Select]
// --------------------------------- //
// Project: Fluids
// Start: Saturday, March 24, 2007
// IDE Version: 4.136

TYPE poo

GLOBAL screenx, screeny, tst[] AS poo

LOCAL gridsize, mx, my, b1, b2
        DIM tst[10][10]

        GETSCREENSIZE screenx, screeny
        SetGrid(screenx/gridsize, screeny/gridsize)

        LOCAL x,y
        WHILE TRUE
                MOUSESTATE mx, my, b1, b2

                IF b1
                        SetColor(mx/gridsize, my/gridsize, 255,0,0)
                        SetColor((screenx-mx)/gridsize, my/gridsize, 0,255,0)
                        SetColor(mx/gridsize, (screeny-my)/gridsize, 0,0,255)
                        SetColor((screenx-mx)/gridsize, (screeny-my)/gridsize, 255,200,64)

                DRAWRECT 0,0,640,480,RGB(255,255,255)
                PRINT "X", mx, my


// ----------------------------------
// This is so I'm out of MAIN rountine - I need global stuff before
// ----------------------------------
FUNCTION endmainfoo:

// ----------------------------------
// GLOBAL stuff
// ----------------------------------

        } // end namespace __GLBASIC__ - see manual for INLINE

        // some constants - for more see:
        extern "C"
                // some of the GL constants
                enum CONSTANTS{
                GL_VERTEX_ARRAY                 = 0x8074,
                GL_NORMAL_ARRAY                 = 0x8075,
                GL_COLOR_ARRAY                  = 0x8076,
                GL_INDEX_ARRAY                  = 0x8077,

                GL_FLOAT                                = 0x1406,
                GL_DOUBLE                               = 0x140A,
                GL_UNSIGNED_INT                 = 0x1405,

                GL_TRIANGLE_STRIP               = 0x0005,

                GL_COLOR_MATERIAL               = 0x0B57,
                GL_DITHER                               = 0x0BD0,
                GL_SMOOTH                               = 0x1D01,
                GL_FLAT                                 = 0x1D00,

                GL_CULL_FACE                    = 0x0B44
                // the functions are all >>extern "C" __stdcall<<
                extern void __stdcall glColorPointer(int size, int typ, int stride, const void *ptr );
                extern void __stdcall glVertexPointer(int size, int typ, int stride, const void *ptr );
                extern void __stdcall glDrawArrays( int mode, int first, int count );
                extern void __stdcall glDrawElements( int mode, int count, int typ, const void *indices );
                extern void __stdcall glEnable( int cap );
                extern void __stdcall glDisable( int cap );
                extern void __stdcall glShadeModel( int model );
                extern void __stdcall glEnableClientState( int cap );
                extern void __stdcall glDisableClientState( int cap );

        // restore the namespace
        namespace __GLBASIC__

        // this is a point. Color in 3float format is the fastest for
        // gfx card
        struct cPOD
                float x,y;
                float vx,vy;
                float col[3]; // rgb values
        // 2 arrays for the background mesh
        // a pointer to the current one
        DGArray<cPOD> gcPODs1, gcPODs2, *pCurPODs;
        // an array of mesh indices for faaaast drawing
        DGArray<unsigned int>  gIndices;


// ----------------------------------
// Set the grid size
// ----------------------------------
FUNCTION SetGrid: w,h
        DIM(gIndices, w*h*2);
        DIM(gcPODs1, w, h);

        int j=0;
        for (int y=0; y<h; ++y)
                for (int x=0; x<w; ++x)
                        gcPODs1(x,y).x = x*screenx/w;
                        gcPODs1(x,y).y = y*screeny/h;
                        gIndices(j++) =  y*w +x;
                        gIndices(j++) = (y+1)*w +x;
        gcPODs2 = gcPODs1;
        pCurPODs = &gcPODs1;


// ----------------------------------
// Draw the whole background grid
// ----------------------------------
        // Disable texturing
        X_SETTEXTURE -1, -1

        int width = BOUNDS(gcPODs1, 0);
        int height= BOUNDS(gcPODs1, 1);

        // change rendering context to what we need

        // vertex arrays & color array

        // set the data pointers
        glVertexPointer(2, GL_FLOAT, sizeof(cPOD), (void*)&(*pCurPODs)(0,0).x);
        glColorPointer (3, GL_FLOAT, sizeof(cPOD), (void*)&(*pCurPODs)(0,0).col[0]);

        // for each "line" of the mesh
        for(int i = 0; i < height - 1; ++i)
                // whee
                glDrawElements(GL_TRIANGLE_STRIP, width * 2, GL_UNSIGNED_INT, &gIndices(i * width * 2));

        // restore what GLBasic would not do automatically

// ----------------------------------
// Set the color of a grid point
// ----------------------------------
FUNCTION SetColor: x,y,r,g,b

// ----------------------------------
// Smooth the mesh
// ----------------------------------
        int width = BOUNDS(gcPODs1, 0);
        int height= BOUNDS(gcPODs1, 1);
        DGArray<cPOD>* pOther=&gcPODs1;
        if(pOther == pCurPODs)
                pOther = &gcPODs2;

        for (int x=0; x<width-1; ++x)
        for (int y=0; y<height-1;++y)
                cPOD& p1=(*pCurPODs)(x,y);
                cPOD& p2=(*pCurPODs)(MIN(width-1,x+1),y);
                cPOD& p3=(*pCurPODs)(MAX(0,x-1),y);
                cPOD& p4=(*pCurPODs)(x,MIN(height-1,y+1));
                cPOD& p5=(*pCurPODs)(x,MAX(0,y-1));

                cPOD& r= (*pOther)(x,y);

                r.col[0] = (p1.col[0]*1.05 + p2.col[0] + p3.col[0]+p4.col[0]+p5.col[0])/5.1;
                r.col[1] = (p1.col[1]*1.05 + p2.col[1] + p3.col[1]+p4.col[1]+p5.col[1])/5.1;
                r.col[2] = (p1.col[2]*1.05 + p2.col[2] + p3.col[2]+p4.col[2]+p5.col[2])/5.1;

// ----------------------------------
// Set border pixels to black
// ----------------------------------
FUNCTION SetBorders:
        int width = BOUNDS(gcPODs1, 0);
        int height= BOUNDS(gcPODs1, 1);
        for(int i=0; i<width; ++i)
        for(int i=0; i<height; ++i)


Small bug introduced...   :(

KEY() now returns a real (DGint), before this new version is always returned a, integer (DGNat). The manual states that it returns an integer but it now returns a float instead. This kinda messes up my code that uses bit manipulation with the KEY() function TBH.

I could cast it temporarily but KEY() really should return only integers IMHO.

Its on purpose, not a bug. Gamecontrollers is the issue. We do shall update the document.

The reason is the game controllers which some buttons returns a float, so you can support a game pad controller using KEY(). Game controllers is a hell to get right on Android and even the included joy() might mess up on some gamepads as they diddent propert support remapping. Even tilt is routed to KEY() as well.

So if you uses a one player that support gamepad, you should uses KEY() and do a remapping feature to make its would works in thier gamepad. Triggers and Right stick is often the issue which dont follow a standard and sometimes swapped.

But im do have in strings.xml make sure its does not return a float between 0-1, if you dont want that, but here you do require to set a deadzone throught.

But so if you want to support game controllers, dont do bit manipulation at all, if you want analoge support! But if you dont use the analoge feature, just disable it and its return either 0 or 1 as before, but just a float.

TBH this is not great news to me personally.

The KEY() integer problem was really for this bit of code...

Code: GLBasic [Select]
                        self.keys = KEY(200)|KEY(208)<<1)|(KEY(203)<<2)|(KEY(205)<<3)|(KEY(42)<<4)|(KEY(54)<<5)|(KEY(29)<<6)|(KEY(157)<<7);

Not a biggie, I just cast those but I mentioned it cause it looked like a bug.

But I do have a large and extensive library for GamePads using the traditional GETJOYBUTTON, GETJOYX, GETJOYRX, GETDIGIX, GETJOYZ etc. to name but a few. It already handles, multiple GamePads, types(XBox 1, PS4 ect.), deadzones, remapping of game pads, analogue + digital input and gampad emulation via a keyboard/mouse.

I am feeling that to go down a different input route for Android input should not be the way to go. The GLB input API should be universal and not platform dependant, as it is already now. If there are back-end differences, then they should be emulated under the current API or extended via new commands that complement the current API.

Maybe I have the wrong end of the stick? I hope so.  TBH it probably wouldn't kill me at the end of the day I could rewrite my input code for Android. :S

Yup, access to the Steam API in general would be very handy.

Nice bit of inlining there BTW Dreamerman!

Small bug introduced...   :(

KEY() now returns a real (DGint), before this new version is always returned a, integer (DGNat). The manual states that it returns an integer but it now returns a float instead. This kinda messes up my code that uses bit manipulation with the KEY() function TBH.

I could cast it temporarily but KEY() really should return only integers IMHO.

Live on Steam as an update now :)
Well done everyone involved with this, I know Google made it more of a pain than it needed to be.  :happy:

Always a good idea to keep your coding skills up to date, thanks Mentalthink!  :good:

Announcements / Re: Colour Asteroids
« on: 2019-Jun-11 »
Looks good!  :good:

Don’t have an Android device to have a go though.

Kinda solved the problem for myself by simply using a more powerful machine with more memory. Compilations still freeze that machine when the compiler is not using incredibuild but its much less intrusive, maybe 5-10 seconds, then full control returns, and the crashes are very infrequent now(once or twice a week at most).

Lesson learned, time to update my machine, I needed to anyways, GLB just kicked my butt a bit to remind me! :P

Well done guys, I know this wasn’t easy!  :good:

Bug Reports / Re: Profiler broken?
« on: 2019-May-24 »
I had a quick look at Tracy, yeah seems like a very good profiler. Not sure it would work out of the box with GLBasic though, as it needs OpenGL 3. I did a quick tutorial on installing OpenGL 3 support but that was on a per project basis.

Bug Reports / Re: Profiler broken?
« on: 2019-May-24 »
Still no luck for me I'm afraid, I'm pretty sure I tried this earlier but I went though the steps again here just in case and still no "gmon.out". Hmm...

BTW there are a couple of Windows utils that will produce a profile graph based on gmon.out... and

You'll need to make sure python is install first though.

EDIT: OK, I got it working. The main problem was the project command line options. I chose Win64 as my target, so I added "-pg" to the linker and GCC for that platform(Each platform has its own set of command line options). BUT there seems to be a bug with the project options even if you choose Win64 the GLB compiler ONLY uses Win32 projects command line options. Changing the Win32 ones(even though I'm not compiling Win32) seemed to add the "-pg" to the compile process.

Thanks for your help Dreamerman.  :booze:

Pages: [1] 2 3 ... 170