Messages

All sounds good to me Gernot.  I don't know what dent GLBasic would make in the application market, but having those tools will be a very good thing.  You've got a lot of solid competition out there, Jamagic (now RIP) excelled in its support for application development as well as games but it was unfortunately not enough to save it in its case.

I'd still like to see music in the PocketPC runtime and support for tracker music built in for multiple platforms but those are my priorities.  I'd also love to see the language get more support for some OOP principles which I personally think would attract more programming types to GLBasic, but I know that is a sensitive subject.  If this new direction will energise you to take GLB on then go for it

Wooo!

Ah, it's that MinGW bug again.  If I rename the mingw folder, GLBasic works again. 

No.

I installed v 5.235 from the CD and all my programs worked.  I then did the internet update to the latest version and nothing will compile.  Did you say you upgraded the GCC compiler recently ... could that be something to do with this?

BTW, it does this with anything I try to compile, even just a simple test program...

SETSCREEN 640,480,0
SHOWSCREEN
MOUSEWAIT

I'd missed a couple of patches and I everything was running ok previously.

Hmmm... I have got that file:

C:\Program Files\GLBasic\Compiler\platform\Win32\Bin\ld.exe

I've recently installed VS2008 but I think that's all.

Hi Gernot,

Any idea what's causing this error (I have the latest patch).

There's no indication if it's in my source and as it happens on linking could it be something in GLB?

*** Configuration: WIN32 ***
precompiling:
GPC - GLBasic Precompiler V.2008.179 - 3D, NET
Wordcount:3328 commands

compiling:

linking:
collect2: cannot find `ld'
*** FATAL ERROR - Please post this output in the forum
_______________________________________
*** Finished ***
Elapsed: 19.4 sec. Time: 19:36
Build: 0 succeeded.
*** 1 FAILED ***

It's funny, I had seen it happen before but not really noticed it as it seems so infrequent.

I would agree, it needs to be fixed, but on the grand scale of things I would not rank it as a high priority.  Hopefully Gernot will be able to fix it at some point.  I don't know any of the history behind the previous flicker issues but as Ian suggests it may not be a simple thing to track down so it could take some time and I'd agree that there are other things that are probably a higher priority right now.

For example, there was a problem on the PocketPC where after an amount of time the display would just lock up.  Now that is a serious problem and it took some time to track it down and fix it.

Gernot has done a fantastic job to date with GLBasic, but I also understand the amount of time he can spend on it is limited being something he does mostly in his spare time.  I think it's fantastic that GLB compiles for so many platforms, with very little (if any) modification of code as long as you design with a broad scope of support in mind.

Personally I'd like for the PocketPC music support to be completed and for the bug with Music / Media shoeboxes on the GP2X to be fixed first, but that aligns to my priorities   I'd also like to see built in support for MOD/IT music on ALL platforms and would rank this a higher priority too.

I'm sure an improvement to this bug will come at some point ... just maybe not today

GLBasic runs only on Windows, but can compile to many different platforms (linux included).

There is not a command line version, you have to use the IDE but it is pretty good.

When you buy GLBasic, you get a licence to distribute, sell or what ever, the executables you produce with it royalty free.

Very nice!

OOo that looks v.nice.

The GP2X and other goodies arrived today, having fun already... many thanks!

That's really good gg_tk!

There is a BOXCOLL command which may be better (you could use masks in sprites rather than anim's).  I'd avoid the pixel perfect collision tests unless you absolutely need it.

Another way you could look at this is perhaps start from a simple application to display bombs and do nothing else.  Work out how many you can get on screen moving (in a simple way) before you notice the slow down.  I haven't got a GP2X (yet) but when I was testing on the PPC which I believe is similar performance wise, I was able to get over 100 32x32 sprites before any noticeable slow down.  Hopefully this will be a lot more than 18 bombs.  You could then work backwards through your code disabling parts to see what helps or measure how quick certain sections take to run using GETTIMERALL().

Just taken a look at your bombs-20px.png - this is using an alpha channel, while nicer is going to be slower due to rendering in software mode.  If you put this to use a solid colour for transparency instead (RGB(255,0,128)) you may find an improvement.  As your background is prominintly light coloured, you could antialias your bomb edges to a mid-grey/white background and you'll probably not notice the lack of blended edges at the speed they generally move?

There are bugs in the following (some bombs get stuck because of the co-ordinates I've hastily put together and the size of bombs are not taken into account) but how many bombs can you display before it slows down?

Code (glbasic) Select Expand

// --------------------------------- //
// Project: Bomb Sorting2
// Start: Sunday, April 20, 2008
// IDE Version: 5.235


TYPE tBomb
x;y
dx;dy
ENDTYPE

GLOBAL bombList[] AS tBomb

SETSCREEN 320,240,0
LIMITFPS 60

// start
LOADBMP "resources/background.png"

LOADANIM "resources/bombs-20px.png", 0, 20, 20

GLOBAL gRunning = TRUE
GLOBAL gCounter = 0

WHILE gRunning

ProcessBombs()

INC gCounter,1
IF gCounter > 60
CreateBomb(RND(280)+19, RND(200)+19)
gCounter = 0
ENDIF

PRINT LEN(bombList[]), 0,0

SHOWSCREEN

// put in something to set gRunning = false when you want to quit out
WEND



FUNCTION ProcessBombs:
LOCAL b AS tBomb

// nb 20 modifier for size of bomb sprite
FOREACH b IN bombList[]
INC b.x, b.dx
INC b.y, b.dy
IF b.x > 300-20 OR b.x < 19 THEN b.dx=-b.dx
IF b.y > 220-20 OR b.y < 19 THEN b.dy=-b.dy

// check for boxed areas
IF b.y > 68 AND (b.x < 102 OR b.x > 219) AND b.dy > 0 THEN b.dy = -b.dy
IF b.y < 170 AND (b.x < 102 OR b.x > 219) AND b.dy < 0 THEN b.dy = -b.dy

IF b.x < 102 AND b.y > 68 AND b.y < 170 AND b.dx < 0 THEN b.dx = -b.dx
IF b.x > 219 AND b.y > 68 AND b.y < 170 AND b.dx > 0 THEN b.dx = -b.dx

DRAWANIM 0,0, b.x, b.y
NEXT

ENDFUNCTION




FUNCTION CreateBomb: x, y
LOCAL b AS tBomb

b.x = x
b.y = y
b.dx = (RND(40)/10)-2
b.dy = (RND(40)/10)-2

DIMPUSH bombList[], b

ENDFUNCTION

you don't have to use LOADBMP within the game loop, just load the picture one time e.g. at start of sub Play()

Yes, that is what I was meaning, but important to state in case it is used in a loop.

On the subject of arrays, I also find that DIMDEL and DIMPUSH work really well for moderately sized arrays when you just want to manage a list where some elements die after a time (eg: particles) and others need to be introduced.  The next best thing to linked lists, they seem pretty fast (at least for me on Windows + PocketPC).

Not sure if these things will help a great deal, but worth looking into if you're still having problems finding ways to keep the speed.

If you look in the samples folder that comes with GLBasic, you'll find a QSIN and QCOS function that does faster calculations than the normal COS/SIN.

You could also ensure you redraw as little as possible, eg: use LOADBMP to load in the game screen and then only add in your bombs on top.

Not sure if you are using your sin tables all the time to calculate the movement or not, but if you are then try working out the DX and DY offset at the start only and when you want to change direction, then just INC x,dx and INC y,dy... you could always do if X>320 or X<0 then dx=-dx to change direction (do the same for DY).

You could work out your average FPS while the game is running and use a multiplier factor to adjust the game speed eg:  INC x, dx * fpsfactor --- so that X moves in larger steps to keep the impression of the speed, with the trade off of not moving as smoothly.

Sure others will post some suggestions too