Sdljava? And Fps Query

[JamineBourne]

First off, I have a game in the makes: basically a really advanced asteriods with a fantasy setting, involving you, a truck-load of spells or modifiers or whatever, a bunch of weapons, and millions of saavy guards spawning out of forts coming to arrest you. And I'll throw in a map editor without level bounds to seal the deal (no garuntee in framerate if you make TEH BIGGEST LEVEL EVA!).

Anyway it's in java because that's clearly my best language, and it renders using sdljava, which is way way outdated. But hey, the lazyfoo tutorials helped a bunch and they were in SDL, so why not make it less complicated? Well I've come to ask that question: is sdljava too outdated to use for the Pandora? I have 0 linux experience as of right now, so I don't know what's going to happen if I drop a jar and a bunch of outdated sdljava dll's in a folder and expect it to run on something non-windows. Plus outdated things are usually slower, and I'm considering moving to lwjgl (though that's not garunteed to be on the Pandora yet). Worth it or not?

My second question is a coding one: Why are fps calculating functions overly complicated for their own good? I used the lazyfoo one for a while which had me at around 170.039424 at max, but I had no clue exactly why or what it was doing. FPS is frames per second right? or am I getting that wrong? Because it would be a whole lot easier and more accurate if there something like:

CODE
StartTimer();
int frame = 0;
MAIN GAME LOOP{
do game stuff...
frame = frame++;
if( the time is greater than a second ){
print out "the Frames gone by in a second are: " + frame;
frame = 0;
restart the Timer;
}
}


There, done. Without any math but addition. It measuers how many times the game looped in a second, which IS THE FPS is it not? This gets at max 40 fps on my computer, which makes me suspicious about the accuracy of every FPS measurer out there. Somebody tell me what's wrong with this, because that's what it begs for!

 

[lulzfish]

Yeah, that's pretty much how FPS counters work.

Lazyfoo seems to be recording average FPS over the entire run length instead of instanteous FPS, updated every second, maybe he's thinking of a benchmark rather than a performance meter.

If SDL Java is out of date, it will probably be broken by newer SDL libraries. This is bad for Linux systems, which almost always have centralized libraries.

Maybe you can package the SDL libraries along with your application, to ensure that the old version is always present. Ask somebody who knows more about packaging than I do, and more about Java. Like dflemstr.

 

[dflemstr]

Huh, someone called for me?
Well, the beauty of Java bindings is that they cannot become out of date; you just have to recompile the native binaries (and maybe fix some incompatibilities in them) and it'll work again!
It looks like this:
CODE
Java library with JNI (your app)
-----------------------------
Java native binding library (the DLLs/SOs that you include with your app) <-- recompile this to retain compatibility
-----------------------------
Actual library that you bind (in this case, SDL)


However, I would recommend using either the OGLES bindings for Java, or the lwjgl library, if you want to make games; you gain speed by a factor of thousands.
(Note, however, that lwjgl hasn't yet been ported to the Pandora, as you say)
Also, you'll have to jump some hoops tog et Linux compatibility, because DLLs don't work on Linux. If you send me your game when you're ready, I can make it compatible for you

BTW, for the FPS counting: I would recommend doing the following if your app requires FPS for more than just visuals. Your FPS (using your above algorithm) gets rounded to an integer number, which might not be enough.
(for example, if you want something to move smoothly, you have to readjust its speed every frame by using the FPS number; an integer number would then be too inaccurate)
And yes, FPS represents the frames per second.
CODE
// (if you don't find a good timer and need one, use System.nanoTime(); you get nanosecond accuracy)
void gameLoop() {
long lastTime = System.nanoTime();

while(gameIsRunning) {
long newTime = System.nanoTime();

// Use delta for smooth timing (movements etc, see below)
// it represents the number of seconds since the last frame; usually something very small
double delta = (newTime - lastTime) / 1e9d; //1e9d = 1 (american) billion; I use this because there are 1 billion nanoseconds in a second
lastTime = newTime;

/* This is the most accurate FPS you can get;
* however it might fluctuate because it only
* uses the last frame to calculate; not any averages
*/
double FPS = 1 / delta;

//...update game; example:

//(and this isn't possible in Java but you get what I mean; use Scala to make this possible)
myThing.position.X += 5 * delta; //this thing will move 5 units/pixels/whatever per second

//...draw the game
}
}

 

[JayFoxRox]

http://www.mvps.org/directx/articles/fps_v..._frame_time.htm

 

[dflemstr]

http://www.mvps.org/directx/articles/fps_v..._frame_time.htm

...which is why I
1. make delta available in my code and
2. derive the FPS from the delta, so as to not make it completely flawed

 

[JamineBourne]

And a very good reason to render in OGLES. However you need a cell phone emulator to run the games properly on a desktop. LWJGL just seems like the path of least resistance, assuming it gets ported to Pandora, which they make it seem like is possible at some point. However, I'm going to stay in SDLJava for now for compatability reasons, unless it's not a TON of work to port a 2D OpenGL game to ES. (On the LWJGL website, there's a nifty http://www.cokeandcode.com/spaceinvaderstutorialSpace Invaders Tutorial where they render the game first in java2D, then OpenGL, then LWJGL.)

Thanks, I'll most likely take you up on that when the time comes.

 

[JayFoxRox]

PowerVR provides an OpenGL ES Emulator for Linux and Windows which maps OpenGL ES functions to OpenGL 2.0 - No phone emulator required.
Also OpenGL and OpenGL ES are almost using the same API. OpenGL only provides more functions, but you can just use those which exist in both and your code stays really portable. But then again: Using the OpenGL ES Emulator is probably a lot easier.

 

[JamineBourne]

PowerVR provides an OpenGL ES Emulator for Linux and Windows which maps OpenGL ES functions to OpenGL 2.0 - No phone emulator required.
Also OpenGL and OpenGL ES are almost using the same API. OpenGL only provides more functions, but you can just use those which exist in both and your code stays really portable. But then again: Using the OpenGL ES Emulator is probably a lot easier.

Oh wow I did not know that, just found it now thanks.