Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


ShyGuy92

Member Since 16 Jan 2010
Offline Last Active Apr 19 2015 11:20 AM

#5214191 Mobile Game Development - Java, C++, Lua? Whats best?

Posted by ShyGuy92 on 03 March 2015 - 07:09 AM

I generally see two ways, I'd reommend you. Either, you use tools like Unity or Game Maker, which - as far, as I know - support mobile devices and allow you quick game development, or you choose the same way like I used and start developing PC applications first. I have never really done Java, I rather started with C++, so I wanna suggest you my personal way how I got into game development:

Write some basic "command line" application in C/C++ with stuff like printf or using std::cout to understand how to work with the language itself. There are possible ways for Java as well, but I have never really worked with it. Decide yourself whether you wanna continue with Java (on the computer) or try C++.

If you got some basics working with C++, the next step would be to create a "real" window on the computer, draw something there and react on user input. I recommend you the SFML library, as it is really easy to use. You find good tutorials on the homepage about all these next steps.

If you kind of understand how everything worked so far, you should learn about the general specifics of the mobile platforms - such as Android apps are usually coded in Java and iOS apps, I think, in Objective-C. At least for Android I know you can use C++ code (more complicated then pure Java for Android) using only a bit of Java as "glue code".

If you like Lua, you could first try to use Lua on a PC app, embedded in a small C/C++ application. Lua is really easy to embed in a C application, and I think, there are good binding for Java (Android) and Objective-C (iOS) available. That way, you could write just the basics (such as draw something on the screen) in C/C++, Java AND Objective-C and make these functions available to the embedded lua scripts and then write most of your game in Lua; you could use frameworks like Corona too, which already did all that for you, I guess.


If you really want to start with mobile development (and not trying some stuff on the computer itself), I'd recommend you to use Unity etc. as mentioned first or at least use some an IDE like Eclipse and focus on one platform first (e.g. Java Android).




#4692330 OpenAL Streaming (Queue Buffers)

Posted by ShyGuy92 on 16 August 2010 - 03:21 AM

Okay, I changed sleep time from 92ms to 20ms, and I don't notice any more CPU usage (program uses 0-3% CPU). I listened to a stream for many minutes and there seemed to be no interrupt.

Maybe that's really the solution now :)


#4692100 OpenAL Streaming (Queue Buffers)

Posted by ShyGuy92 on 15 August 2010 - 01:38 PM

Quote:
Original post by KulSeran
Quote:

What might be the problem? Could it be that the program "miss" the time to update the stream and the source stops?

Seems you didn't read what I said about sleep. If you say "sleep(92)" the program won't return for ATLEAST 92ms. It doesn't mean it will return after exactly 92ms or before 92ms. It will only return sometime after 92ms have passed. There is a really good chance that you are going to miss your window (windows is granular on sleeps with about 15ms of jitter). You need to sleep for less time, and poll OpenAL to see if the buffers are ready to be filled (looks like "number of processed buffers can be detected using an alSourcei call to retrieve AL_BUFFERS_PROCESSED").

The calculation of buffer duration results (~)92 ms. That means, with all the lost time for other code in the thread and somewhere else it should be VERY propably that 1 of 4 buffers is processed. That means after sleeping there should be a buffer to fill.
Even if I haven't slept enough and there's no buffer to fill, after 92 more ms there must be 1 or even 2 (of 4) buffers to fill, but (usually) never 3 or 4.

(I have a "semi-solution": If the source stopped for some reason I just resume it. Still I might get a short moment in the stream where just nothing is to be heard.)



Quote:
Original post by KulSeran
There is a really good chance that you are going to miss your window (windows is granular on sleeps with about 15ms of jitter).

What do you mean by that? What does a thread in the background have to do with a window?


Quote:
Original post by KulSeran
You need to sleep for less time, ...

But if I sleep less then 92ms (the duration of a single buffer) it is more propably that one buffer is processed yet and I waste CPU.


#579607 OpenAL Streaming (Queue Buffers)

Posted by ShyGuy92 on 14 August 2010 - 09:42 AM

I have written some code that plays an ogg vorbis file with OpenAL.
My code opens the ogg-file and reads from it whenever a buffer is to be filled.

As a "simple" loop would cost me 100% CPU, I have to sleep a little bit somewhere.
So I set up 4 buffers which will be queued and played one after the other.
After one processed buffer is filled again and queued on the source, I sleep as long as 1 buffer should need to be played. That is (float)PCM_PER_BUFFER/44100*1000 ms.

But it can still happen that the stream stops playing (e.g. when computer is busy I think), which means that all 4 queued buffers were played before new buffers are filled and queued.
But how can that be? I can't imagine that some of my code in the thread takes as long as 3 or 4 buffers.

Does anybody has a tip how I might solve that problem? Is it possible to use callbacks that OpenAL automatically calls as a buffer on a source was processed?


My code looks about like that (pseudo-code):
while(playing)
{
n = getProcessedBuffers(); // should be 0, 1 or maybe 2. Never 3 or 4...
while(n--) // while there are processed buffers to fill
{
// unqueue processed buffer
alSourceUnqueueBuffers(Source, 1, &b);


cur = getCurrentBuffer(); // buffer num (0-3) to fill
fillBuffer(Buffer[cur]);
alSourceQueueBuffers(Source, 1, &(Buffer[cur]));
}
sleep(sleepTime);
}



PARTNERS