Topics

MUSICVOLUME causes this compiler error:


*** Configuration: WINCE ***
precompiling:
GPC - GLBasic Precompiler V.2007.363 - 3D, NET
Wordcount:189 commands

compile+link:
/cygdrive/c/Users/User/AppData/Local/Temp/ccpgQHgt.o(.text+0x2a4):gpc_temp0.cpp: undefined reference to `ZN11__GLBASIC__11MUSICVOLUMEEf'
*** FATAL ERROR - Please post this output in the forum

As you may now, I'm testing my GP2X entry on my Pocket PC as that's the nearest thing I have to a real GP2X.

I have an MP3 I want to play (if my PPC is fast enough to do this) in game and also one for the title page.  On Windows it plays OK.  On the PocketPC, nothing plays.  The game runs as normal.  I noticed this in Ian's game too.

I can play the MP3 via Media Player on the Pocket PC.  Can you fix this issue so GLB can play MP3's on the PPC?  Does this issue arise on the GP2X too?

Hi, SPRCOLL does not work on Pocket PC.  Not been able to test with any other platform (eg: Mac, GP2X, Linux etc) but the following code works in Windows, but not on the Pocket PC:

Code (glbasic) Select Expand

SETSCREEN 320,240,0
LIMITFPS 60

GLOBAL mx,my,ma,mb

BLACKSCREEN
DRAWRECT 0,0,16,16, RGB(255,255,255)

GRABSPRITE 0,0,0,16,16
GRABSPRITE 1,0,0,8,8

WHILE TRUE

MOUSESTATE mx,my,ma,mb

DRAWSPRITE 0, 160,120
DRAWSPRITE 1, mx,my

IF SPRCOLL( 0,160,120, 1,mx,my )
PRINT "COLLISION!!!",0,0
ELSE
PRINT "OK",0,0
ENDIF

SHOWSCREEN
WENDMove the mouse to position the smaller square (used squares just for this example, in my code I have also tried LOADSPRITE with same results).  On Windows when any part of a pixel in sprite 1 and 2 overlap, the COLLISSION!!! message appears, otherwise OK.  On the Pocket PC COLLISION!!! will never appear.

Hi Gernot

Will we be able to get a SPRCOLL command for the new LOADANIM and DRAWANIM functionality.

I'm using an anim strip for my player and an anim strip to hold scenery tiles.  I need to be able to test if animation number 3 of sprite 0 is colliding with animation number 10 of sprite 1 (for example).

It's not possible to detect such a collision at present.  I don't want to have to go down the route of making masks in individual sprites, as that defeats the point of using the tilesets.

Could we see some enhancements to the way GLB handles full screen modes please?  A bit of background to why I'm asking first

I'd like to run my pocket PC / GP2X games on my PC too (without having to make separate versions of the code).  Some graphics cards, one in my laptop included, doesn't support full screen at 320x240.  When I try to set a full screen mode that is not supported by my graphics card, I get a beep then it opens in a window instead which isn't nice for certain types of games.  Full screen, and blocky, is nice!

So my laptop (which has a hideously large desktop of 1920x1200) has a tiny window with my game in it, where as my desktop which supports full screen at this res will look excellent with it filling the screen.

My laptop supports standard resolutions with 640x480 as the smallest.  I've figured out some work a-rounds to the problem.  For example I can use the PLATFORMINFO$ command to detect if I'm on a DESKTOP or hand held device and change the way the program works.  If a desktop I could go for one of the options below:


1) A nice option, but would take a lot of work, could be to create both 320x240 and 640x480 graphic sets which I could SHOEBOX up and load the appropriate shoebox, making adjustments to my code for how I display and move things about on screen.  Would be a lot of work though!

2) A slightly less nice, but quicker and simpler option, would be to set the screenmode to the next best screen mode that is available for full screen.  EG: 640x480, and use VIEWPORT 160,120, 320,240, then my game area would appear central in the 640x480 screen.  There's some workarounds to do for LOADBMP, USESCREEN etc but all manageable.

3) A third option would be to use CREATESCREEN and USESCREEN to draw everything to a virtual screen then use one of the sprite scaling routines to draw that virtual screen at the full 640x480 window size.   EG:     STRETCHSPRITE 1,0,0,640,480 or ZOOMSPRITE 1,160,120,2,2.


Both options #2 and #3 are relatively easy to implement if I know the next best resolution available should the native resolution of the game not be available.

Option #3 should see the OpenGL acceleration handling the graphics fast enough, a danger though could be if there are any graphics cards that don't support the CREATESCREEN commands too well (eg: if ^2 sized textures or max size textures are an issue).


So here comes the requests bit again  Could you provide any of the following in GLB that would work on any platform...

1) A command to return if a screen mode is available or not (ideally a command to return a list of modes available).

2) The ZOOMSPRITE and STRETCHSPRITE (option 3) will not work correctly for my scenario at present when there are transparent areas ( RGB(255,0,128) ), as GLB / OPENGL scales the graphic data and smooths the image, so where there is a transparent coloured pixel next to a real pixel, you'll get a purple edge.  Effectively you end up with a purple halo around every graphic (I can post an example if required).  I have a work a-round to this work a-round by not having any transparent areas in the virtual screen (can draw with transparent on to it though) but then I can't use LOADBMP and have to put everything into the one virtual screen.  Is it possible to add a command to tell GLB to not use smoothing when scaling and rotating sprites - we could then choose the method to use.

I think both of these requests would be useful for other scenarios, so they'd be a benefit to have.


Maybe there is a better work a-round, if so please let me know.  BTW, have seen the code that can detect screen modes in Windows, but this doesn't work for other platforms so it's limited.

Hi

having a wee problem with shoebox on the PocketPC.

I have a folder structure:

GAME.EXE
GAME_CE.EXE
DATA\IMG\  (load of PNG's in here - notice IMG is a subfolder to DATA)


I shoebox DATA to get DATA.sbx and it looks the right size.

I add the following line to my code at the top:

SETSHOEBOX "DATA.sbx", ""

And then rename my DATA folder just to make sure I know it's loading the sprites from my shoebox and not the original folder.


Run on Windows and it works, LOADSPRITE and LOADBMP get the required images from my shoebox.

Compile and run on the pocket PC and no graphics are loaded.  The game runs, (I can see my default text) but no sprites or background is displayed.  The DATA.sbx sits in the same folder as the GAME_CE.exe (on my Pocket PC's SD card in a sub-folder).

Here's an example load command:

LOADANIM "DATA/IMG/bgtile01.png", 0, 16,16

have tried LOADANIM "./DATA/IMG/bgtile01.png", 0, 16,16 and LOADANIM "\\DATA\\IMG\\bgtile01.png", 0, 16,16 as well.  All of these work on the PC but not on the Pocket PC.

If I copy my DATA folder on to the Pocket PC the game works, so it's something to do with the shoebox as this shows my code is working with out it.



Doing anything wrong or is there a bug?  BTW, what is the best method to use for folders considering the code can be compiled to PPC, PC, Linux, Mac etc?  Is it / or \ ("\\" in the string) ?

When you run a game in debug mode, then click the pause button you are returned to the editor to debug at the current line.  F10 executes the line and moves to the next.  However F5 to continue does not appear to work as it breaks on the next line.  Anyway, F5 currently has the same effect as pressing F10.  The play button in the toolbar does the same.

If you place breakpoints in your code, you do not get this problem, F5 will continue running the game.  Because of this I would make a guess that GLB must use a flag of some kind to tell the running code to pause when the PAUSE key is pressed but perhaps this is not being cleared after so F5 continues but immediately pauses on the next command, where as when you hit a breakpoint you have not set the pause flag so this problem does not exist in this case.

[GLB number data type]

Hi

How would I best go about storing level data for a scrolling tile map in memory with GLB?

I tried DIM tiles[100][100] but there are currently two things that concern me about this.

1) Having an array this large makes debugging unusably slow.  I've posted a bug about this in the bug forum.  Every press of F10 to trace the next line refreshes the Variables panel in the editor, and it takes a long time to do it when you have large arrays.  Hopefully this can be optimised though in a future build of GLB?

2) Storing an array of tiles using the GLB number data type is going to be wasteful on memory - I think each number is going to be either 64 bits or 32 bits on Windows/ PPC/ GP2X, meaning between 4 and 8 bytes per number required to store it.  If so I'd need 40,000 bytes to store a 100x100 tilemap (which isn't very big in game map terms).

All I need is bytes which for the same example requires only 10,000 bytes in total.  This will all add up.  

I see there is a OPENFILE - READBYTE  (BTW there's no mention of these commands in the contents under Commands by Category -> Input-Output) for reading bytes from a file, but I think we need to have a CREATEBANK( memory_size ) command with a POKEBYTE, POKEWORD, POKELONG and PEEKBYTE, PEEKWORD, PEEKLONG commands to read and write to this memory bank.   Unless there is a better way built in.

I'm finding that when using arrays the debugger becomes unusable because it is so slow.

For exaggeration purposes, here is a large array:

DIM t[160][160]

Was thinking of using it to store a level 160 tiles across, 160 down - a lot of array elements.  The debugger upon pressing F10 to go to the next line will refresh the Variables panel in the editor each time and I guess is having to update each element in this array.  It can take a few seconds.

Can you optimise this?

Maybe only update the parts of the arrays that are expanded so you don't have to rebuild such large structures?  When the user clicks the + to expand a node in the array you could fetch the part required for that to help speed things up?

Jamagic's debugger (a long dead programming language) allowed an option in the project settings to force the debugger to show NO variables unless you placed some special debugger commands in your source to tell it to add a specific variable to the debugger watch list.  Maybe you could do something similar?

[Nachstes]

Under the edit menu, the bookmarks sub-menu contains:

Toggle
Nachstes
Previous
Remove all


Nachstes should be Next in English version.

I have a new project, created since todays GLB update that contains three separate source files (including the main).

Set it to debug mode and press F9 - a break point can be set at the cursor.  Run the project and then quit out.  Press F9 to set a breakpoint now and the STOP icon appears in the margin temporarily and then disappears again.  I can no longer set breakpoints.  Although if I press F9 to set a breakpoint and quickly press F5 to run the project before the breakpoint has had chance to disappear again, the program will stop at the breakpoint.

In all cases (including after first load of a project) all breakpoints are cleared when the program ends and returns to the editor.

Looks like something is clearing the breakpoint markers?

Hi

Taking a look around the GLBasic program files directory, there is a plug in folder and in there is one for GP2X.  The readme says:

This is the mmu-hack from Squidge. It allows GLBasic to access upper 32MB of memory for faster graphics.

Usage:
put this side-by-side with your executable (.gpe) file


What's this all about.  Do/should we copy this with our executables for the GP2X or does GLB pick this up when compiling?  Got any more info on it?

Also in the Samples-Xtra's folder there are some nice examples.  A starfield (lol thread in code forum) and many interesting snippets.  One file is a text Scroller.  I noticed it used a different font to what GLB normally uses but has no LOADFONT/SETFONT commands.  After further inspection  I see there is a file in the same directory as the gbas called "smalfont.bmp" which GLB is automatically picking up and using.  I didn't find any reference to this in the help, are there any other gems you can tell us about GLB that might be useful

In another thread, I was testing a game on a Pocket PC and it was behaving differently to the same game compiled for Windows due to the mouse input.

It seemed like mouse clicks were always one behind in the game, and on dialogue screens pressing buttons required a long firm press on the screen but only for the PPC version.

I've not got the source to the game to test more thoroughly so I've been trying to replicate the possible behaviour and here's what I found.

Code (glbasic) Select Expand

SETSCREEN 320, 240,1
LIMITFPS 60

GLOBAL running = TRUE
GLOBAL mx, my, ma, mb

LOCAL t
FOR t = 0 TO 900
LOADSPRITE "test.png",t
NEXT
LOADSPRITE "gui3.PNG", 1000

WHILE running = TRUE


IF KEY(0) OR KEY(200) THEN running=FALSE

MOUSESTATE mx,my,ma,mb

PRINT "Mouse x="+mx+" y="+my+" buttons L="+ma+" R="+mb, 10,10

LOCAL t
FOR t=0 TO 620
DRAWSPRITE RND(899), RND(320), RND(200)+40
NEXT

DRAWSPRITE 1000,30,30

SHOWSCREEN
WEND

PRINT "Mousewait", 10,10
SHOWSCREEN
MOUSEWAITTried several scenarios, but the code above is loading a lot of duplicate sprites and detecting the mouse inputs.  I've not used any mp3's, wav's, various graphics operations, file I/O and other things that might be going on in the original game so obviously this is a limited test.

First of all, the above code with a smaller for loop to display sprites (say 120 instead of 620) ran at full speed.  Mouse x,y and buttons were very responsive.  No problems there at all.

With the for loop displaying many sprites per frame (620), it slows down my Pocket PC.  Mouse responsiveness is still good - keeping up with the screen refreshes although the FPS is not at full speed.

What I did notice was the Left mouse click (variable ma) would rarely register a 1 if I did quick-medium length clicks.  I guess this is understandable because I am probably pressing the pen on the screen and off again in between calls to the MOUSESTATE command.  The X and Y position of the mouse is always updated.

My guess is that original game on the PPC may not always be picking up the mouse button, which is possibly causing the odd behaviour on the PPC but not when running on Windows.  I'd also guess that perhaps there is some other logic dependant upon the mouse clicks registering in the game to make it work correctly.  So the above test suggests this could be the likely cause of the problem.

Question is... will the GP2X exhibit a similar issue as the Pocket PC?  My PPC is not that slow, but it's not a high spec processor and I have no idea how it compares to the GP2X in real terms.

Second question, what is the best way to catch the mouse click events if MOUSESTATE misses them?  Is there a work around?  I've just spotted the MOUSEAXIS() command which can read mouse button states, but I wonder if that would suffer the same problem where it will return the value of the current mouse button state at that point in time (ie: pressing on the PPC's touchscreen or not).

I guess you can compensate in your game to design for a longer mouse press, should you want to support the platform.

When I created a new project I set the project-options for the Win-CE platform, but when I tried to compile the project for the Win-CE platform it said I had the configure the Project-Options for Win32-DLL.  Is this correct or a bug?  Once I set the Win32-DLL project options I could compile for Win-CE.

I'm having a little trouble with the debugger.  On the whole it works very well, better than many other languages I've seen.  However I can't see the variables I create from TYPES. Am I doing something wrong?:

Code (glbasic) Select Expand

SETSCREEN 320,240,0
LIMITFPS 60

TYPE Fred
a$
ENDTYPE

GLOBAL per AS Fred
per.a$="Mr Bloggs"

WHILE TRUE
DEBUG per.a$
SHOWSCREEN
WENDI put a breakpoint on the DEBUG statement (F9) and run.  My debug panel has Variables, but nothing listed under Global and Locals.  Why isn't per shown (was expecting a tree to expand showing a$ underneath.  I've tried declaring per with LOCAL and GLOBAL but no luck.  TYPE's are a really useful data structure that I imagine everyone would want to be able to view in the Debug variables panel.

Also the game window disappears when paused.  It will pop up momentarily when SHOWSCREEN executes but disappears again.  I'd like to be able to look at the output in this window.  How do I do that?

Thanks.


EDIT: should add that I can see straight integer, string and arrays in the Variables Debug panel, just not TYPES.

In the editor (make sure there is code above and below) insert the following:

Code (glbasic) Select Expand

INLINE
const int v=1;
ENDINLINEThe line 'const ...' has a different background colour (in my colour scheme).

Now delete the const line and the ENDINLINE line leaving only the INLINE from the above code.   From the INLINE down to the end of the file the background colour in the editor changes to signify some 'inline' code.  Now delete the INLINE statement.  The background colour remains changed from where the INLINE statement used to be.  You can correct this either by reloading your project, or keep deleting from around the line that INLINE was on until it goes away.


The other issue is one I think I mentioned in a general thread, the BACKSPACE key does not work in the editor if you hold shift down.  This seems to catch me out every day as I don't release the Shift key quick enough before pressing the Backspace key.

[FIRST PROBLEM]

I think I have found a bug with the ALPHAMODE command and also an issue with ZOOMSPRITE, tested in Vista, I have the latest graphics card drivers which I believe has updated the OpenGL support to work correctly.


FIRST PROBLEM

Code (glbasic) Select Expand

SETSCREEN 320,240,0
LIMITFPS 60

LOADBMP "gpxsplash.png"
SYSTEMPOINTER TRUE

LOADSPRITE "test.png", 0

GLOBAL ang = 0
GLOBAL size = 1
GLOBAL alp = -1.0

WHILE TRUE

LOCAL mx,my,a,b
MOUSESTATE mx,my,a,b

alp = (mx/160)-1
PRINT "Alpha setting: "+ INTEGER(alp*100), 4,4

ALPHAMODE alp
ROTOZOOMSPRITE 0, 120,120, -ang+45, size

ALPHAMODE 0

INC ang,0.2
size = SIN(ang)*1.5

SHOWSCREEN
WENDImages required:




Move the mouse left and right and you will see the alpha value go from -100 to +99 ... I've *100 and displayed as an integer to make it easier to read.

This value is used as the parameter for ALPHAMODE.  Note that the sprite will flick on to normal display mode when this =0.

I'm not sure I understand what it is I am seeing with this command.

* At -1.0 I see the sprite as normal - as if ALPHAMODE is 0.  All pixels displayed normally.
* between -0.15 and -1.0 it goes from semi-transparent with a darkness to normal full colour pixels.  Shouldn't it be going to darker nearer to -1.0?
* between -0.14 and +0.14 I get no image drawn at all.
* between 0.15 and 1.0 it looks like an additive blend, although there's very little difference above (about) 0.6 to 1.0 that I can tell anyway.

Should it be working this way or is it a bug?  


SECOND PROBLEM
The test.png image when scaled up with ROTOZOOMSPRITE is showing a thin black line on the rightmost edge.


THIRD PROBLEM
Am I correct in saying values passed to ALPHAMODE of <0 being subtractive blends and values >0 being additive blends?  As described in the First Problem I'm not sure I am seeing this.  Assuming it is a bug which can be fixed, we therefore have additive and subtractive blend modes but what about just semi-transparency levels (no additive or subtractive blends applied)?

BlitzMax has a command called SetAlpha taking a value 0.0 to 1.0 to specify the alpha blend ratio and a separate command called SetBlend to change the type of blending it will do.  It takes values of ALPHABLEND (missing in GLB?), LIGHTBLEND (values of >0 in GLB) and SHADEBLEND (values of <0 in GLB).  For information it also takes SOLIDBLEND and MASKBLEND to tell it to use or ignore the transparent color.

So you first choose what type of drawing mode you want with SetBlend, then you choose what ratio to display at using that blend with the SetAlpha command.  

Could we have a command in GLB to allow us to do similar functionality as seen in MAX?

Very minor documentation errors I've spotted.  Nothing end of the world but worth correcting for benefit of new users to the language.



SAVESPRITE - example code has an arrow char and " missing the ; I presume

Code (glbasic) Select Expand

// SaveSprite
FOR i = 0 TO 1000
SETPIXEL RND(100), RND(100), RND(1677215)
NEXT
GRABSPRITE 0, 0,0, 100,100
SAVESPRITE "ugly.bmp", 0;

// MSPaint?
SHELLCMD("explorer.exe ugly.bmp", FALSE, TRUE, i)This one not an error, but could help new users.  In help Index there is an entry for "Types" and "TYPE".  "TYPE" is more informative and gives an example, where as "Types" appears in the Contents - Tutorials section of the help and will likely be what the user sees first (I certainly did).  Could you add a link to the "TYPE" help page in the Refs section of "Types" (if I haven't confused you enough already )


For the UCASE$ help topic the example has a bit of odd colour coding and ' COLOR="white">' in there;

Code (glbasic) Select Expand

// UCASE$ - LCASE$
PRINT UCASE$("123 - miniMIN"), 0, 20
PRINT LCASE$("123 - MAXImax" COLOR="white">), 0, 40
SHOWSCREEN
MOUSEWAITLCASE$ has the wrong help page (it is a copy of the MIN help:

Code (glbasic) Select Expand

LCASE$()

num#$ = MIN(a#$, b#$)
Returns the smaller value of a#$ and b#$.



// MIN / MAX
   a = RND(100)
   b = RND(100)
   PRINT "a: "+a+" b: "+b, 0, 100
   PRINT "max: " + MAX(a,b), 0,120
   PRINT "min: " + MIN(a,b), 0, 140
   SHOWSCREEN
   MOUSEWAIT

Hi - Could we please have a function added to allow us to specify the x and y handle of each sprite.  I could not find any reference to doing this in the docs.

Code (glbasic) Select Expand

SETSCREEN 640,480,0
LIMITFPS 60

BLACKSCREEN


LOADSPRITE "test.png", 0

GLOBAL ang = 0
GLOBAL size = 1

WHILE TRUE

DRAWSPRITE 0, 320,240

ROTOZOOMSPRITE 0, 320,240, -ang+45, size
ROTOSPRITE 0 , 320, 240, ang

INC ang,1
size = SIN(ang)*5

SHOWSCREEN
WENDGet Image here:

First I draw the sprite normally at 320 by 240, the centre of the screen.  It starts to draw from the top left of the sprite so the sprite is not central on the screen.  I could write a function to wrap around the display of a sprite to take into account my own handle co-ordinates, and as long as I remember to apply this transformation to other things such as SPRCOLL it should be OK, however I think we need this built in.  Especially so when looking at the other sprite drawing routines...

I also do a ROTOSPRITE.  I see that the sprite rotates around it's centre, but it is still displayed at the same position as before.  Having a handle x and y position would make sense here for sure, as I could specify where I want it to rotate around.

Finally I do a ROTOZOOMSPRITE which suffers from the same rotation at the sprites centre, but the scale up and down will change the actual position of where the edges are drawn as you'd probably expect.

Also what if I need the centre of my sprite to rotate around is not the physical centre of the image?  I'd need to make my image bigger to compensate.  If we can specify the x and y handle this would not be an issue.

For compatibility with older programs which expect the handle on the sprite position to act as it does now, perhaps you could add a command that switches OFF automatic sprite handles in order to use the x and y handle.  By default it can be ON and the sprite commands can work as they do now.  ON and they will use the X and Y handle for the rotation of sprites.

EDIT:  So the code could look like the following -

Code (glbasic) Select Expand

SETSCREEN 640,480,0
LIMITFPS 60
SETSPRITEHANDLES true

BLACKSCREEN


LOADSPRITE "test.png", 0
SPRITEHANDLE 0, 10, 5 // set the handle to be 10,5 for sprite 0.
// note that when a DRAWSPRITE or ROTOSPRITE is used to display the sprite at say pos
// 320, 240 GLB would automatically take 10 off the x pos, 5 off the Y pos and the ROTOSPRITE
// would rotate around this centre (10,5)

GLOBAL ang = 0
GLOBAL size = 1

WHILE TRUE

DRAWSPRITE 0, 320,240

ROTOZOOMSPRITE 0, 320,240, -ang+45, size
ROTOSPRITE 0 , 320, 240, ang

INC ang,1
size = SIN(ang)*5

SHOWSCREEN
WEND

Has anyone here created code for a nice Hash table or Dictionary they would be able to share?  You know the key - value type of object.