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.

Topics - jaywat

Pages: [1]
Can I reference the members of a type based upon the order of membership? ie, it's ID.

In other words...

Assume I have a type set up like:

Code: GLBasic [Select]

GLOBAL allCharacterStats[] AS tCharacterStats

TYPE tCharacterStats

and I want to use a one-size-fits all function when these members are updated, something like :

Code: GLBasic [Select]
FUNCTION userEditsStat:statBeingEdited

IF addButtonPressed = TRUE
inc allCharacterStats[0].statBeingEdited, 1  // no, you cant really do this. that's the point!



my point is, right now, I have to do something like:

Code: GLBasic [Select]
SELECT statBeingEdited
inc allCharacterStats[0].strength, 1
inc allCharacterStats[0].dexterity, 1
inc allCharacterStats[0].constitution, 1


... which means I duplicate a lot of code. Obviously my real life example is MUCH more complex than this, and while type members give me far more readable code, not being able to reference them by index, I'm duplicating so much code it's getting unwieldy.

So, is there a way to reference the members by ID that I'm missing?

If not, it would be a REALLY welcome addition. I would think they must be internally referenced by an ID of their dimension in an array anyway, no? So it would surely not be too hard to implement?

I'm making a thread about this here because although I've extensively covered the findings of a days testing in another thread, I didn't want the point or the implication to get lost or diluted.

Simply put, ALL glbasic applications (as far as I can tell) built for iPhone OS4 and deployed for 3.x, which I believe is Apple's requirement for acceptance, will crash on exit on any iPhone or iPod that supports multi-tasking (ie, a very large number of devices). In doing so, GLB_ON_QUIT is never called. The implication of this, of course, is that any state saving or tidying up you try and do on exit never happens.

Under OS4, any device supporting multi-tasking apparently ALWAYS puts the app to the background when you exit, whether you exit normally, or exit to the multi-tasking bar. Glbasic apps, though, seemingly  cant recognise that it's a background task and will try to illegally write to the screen with SHOWSCREEN, and generates an application error, "background gpu access not permitted", which results in the application crashing immediately without executing any further code.

From the Apple documentation:

Do not make any OpenGL ES calls from your code. You must not create an EAGLContext  object or issue any OpenGL ES drawing commands of any kind. Using these calls will cause your application to be terminated immediately.

This is the same for GLB7 and GLB8. The same code used for testing does indeed quit successfully when compiled and built for OS3 only, but of course that isn't really the point, other than to demonstrate that this is a problem with glbasic and OS4.

I also noted in the other thread that I had tried both with and without 'AUTOPAUSE TRUE' with the same results. I also noted that using HIBERNATE to halt showscreen calls wasnt really an option because it causes the application screen to flash to black every time we update the screen.

Admittedly, testing isn't made easy by the fact I have to send code to Mike to compile for xcode, run on a device I don't have access to,  and then watch the results by screensharing or video ;)

I'd really appreciate if this could be looked at as soon as possible; for us, at least, it's pretty much a 'show stopper'; and that includes our just released app getting an update... not only can we not support pause and resume, but we can't even code our own save and load. And if you haven't had this problem, then thats just because you haven't released an app or update since OS4!

GLBasic - en / iPhone 'resume'
« on: 2010-Aug-16 »
Sorry if this has been asked before - couldn't find an answer anywhere.

We've had it pointed out that our game does not support resume on an iPhone (after a call interrupts a game or whatever), and that this is an essential feature.

It's not something I can easily test, unfortunately, so I'd like to know how the iphone deals with this, and how glb interprets that. Does the app simply loses focus and therefore 'autopause true' would solve this problem? Or does it essentially exit the app, calling glb_on_quit, and therefore I'd need to implement a save state and reload everything?

And while I'm asking, is multi-tasking on iOS4 the same or different? ie, if someone double-taps and starts a different app, does it lose focus? can i make my glb app 'os4 multi-task capable'?

Our new game, Stacked Sevens, has just hit the iTunes app store for 99 cents. We're hopeful that a Friday 13th release date won't bring us any bad luck :)

I had already posted the details in the appstore thread a few days ago, which I've just updated with our  iTunes store link.

We're very pleased with the game, both in terms of coming up with what we think is a really engaging and original puzzle game, yet feels instantly familiar, and with the overall look and feel. Stacked Sevens is our second release, and our attempt to go a bit more 'mainstream' after our first glb game Hungry Birdz (also on the appstore thread).

We're always interested in feedback, if any of you guys are willing to give it a go.

So, after a terrifying battle with the xcode distribution build process, our first game has just been submitted to Apple for review!

You can read about it on the appstore thread here:

Mykyl66 and myself would like to thank those of you who gave answers and advice in response to our avalanche of questions over the last few months, and our thanks to Gernot for making it possible for the two of us to realise our game development ambitions. In fact it's only taken 5 weeks to develop Hungry Birdz from concept to submission, but we have so many other ideas and concepts we've already coded, it was hard to decide which project to concentrate on, and it's an amazing feeling to finally have finally finished something we started!  :P

And when we say we're 'finished', we have a number of further features and modes for Hungry Birdz that we're dying to reveal in future updates.


I am using INIOPEN to save and load some simple files that hold persistent data. Although not documented as such, I noted in the examples and other code on the forums that using INIOPEN "" after you've done your last INIPUT writes that file to disk, seemingly by calling a 'null file' to open.

However, when I call the save function next, I get the following error in the debug console on opening my file:

fopen("/var/mobile/Applications/<etc>/Documents/file.dat", "rb") failed

and when I next call INIOPEN "" at the end of the function, I get:

request: fopen("", "rb") failed

To clarify, there are two seperate files I am saving to, and I have to assume that they may have made changes and saved to the preferences file before I am next able to call the save file, so I can't just 'leave it open', as such.

I know that I could use OPENFILE and then explicitly call CLOSEFILE, but it seems so, so much easier for my purposes to use INIOPEN because it does all the hard work of formatting it in a readable format. To further clarify, apart from these debug messages, what I'm trying to do works just fine!

1) are these considered 'just for info' messages? And I don't mean just by you guys!  :P  What I mean is, would Apple reject it as a bug?

2) Is there any way round it? Am I ordering something wrong? Is there a way to explicitly TEST if a particular file opened for writing with INIOPEN is *still* open and therefore not make the duplicate call?

Thanks in advance for any wisdom or advice you can impart  :)


I'm getting "Error enqueuing new buffer: -66632" in debug on an iPhone compile specifically when I stop the (mp3) music, which is consistent with how it's documented here:

But even though I know what the state of the music toggle on/off ought to be, I am still explicitly only issuing a STOPMUSIC command if ISMUSICPLAYING() = TRUE, which surely ought to combat exactly that problem (ie, rather than just brute-force issuing a STOPMUSIC even if it was already stopped, which is when I'd expect to see this kind of error)

Any ideas? Thanks!

GLBasic - en / Default.png Splash Screen
« on: 2009-Nov-25 »
I'd like to know more about the apparently undocumented feature for instant splash screens, please?

I first read about it in the 'Crackshot' thread, but there is still insufficient information there for me to be able to decipher how to use it. Tried it about six different ways so far and no joy. So if anyone can enlighten me, I'd appreciate it.

From what I understood from that thread, if you have a full screen sized image called "Default.png", it should display instantly on running the app.

What wasn't clear is:

what platforms does it work for?

Where do you put it? root folder? app folder? media folder?

does it need ANY code to enable it? I got the impression it didn't.

either way, does it use a bitmap identifier? does it unload automatically after use?

If there is any documentation on it, perhaps someone can point me to it. If not, perhaps information on it ought to be added to the help file?



Pages: [1]