I am trying to make an OpenGL game which has say 3 stages: Welcome, Battle and Armor. Each stage has different logic and works with different textures.
When is the best time to load those textures, all in the beginning, or load the ones that are used by each stage when it is activated. If so, should I then delete them when switching to another stage?
If the second method is best, how can I show static splash screen (image) while loading the textures per each stage?
Well, loading texture (especially from the sd card) can take time. The reason to load them before you need them is to avoid having a loading screen between stages. If the player will often switch between stages, and your texture are not so big, you might want to load them at startup (giving the pain of waiting for the game to load only once, even if it would be longer). You have to balance your choice between the memory that is available for you, and how much you want to piss the player by interrupting him in his playing experience.
You could also distract the player by displaying a scoreboard at the end of a stage to show him how good he's just been, instead of a loading bar.
If you can anticipate when the player will soon switch to another stage, you can try to stream the texture in background a little before, but it's a lot more complicated to do (well, especially on a mobile platform), so you'd need to do some research for that.
I think you should load them only if they are needed for that stage. Why waste memory by loading textures on your Video RAM if the player may not make it to the next stage?
You can show a dialog which is custom to your needs and dismiss it when you are ready. I don't have any samples right now.
Related
I am creating a simple infinite runner game for the android os using the libgdx framework, I have everything working fairly well but then I noticed that after a while mayne 2 or 3 minutes in the fps drops steadily until it goes all the way to 0... I am creating the game assets every 10 or so seconds and then setting their bodies active to false when they are out of screen, it was my understanding that it would not calculate for them after this but it slows down when I run the assets and it doesn't slow down when I don't run the assets...my question is is this normal and should I dispose of these assets a different way? how do other infinite runner games deal with this lag issue, also I am loading the texture from my asset manager so I believe it is only using the one texture instead of creating many....
okay so after testing all day I see that the game slows down after a while because its still rendering the images even after they leave the screen, I implemented a method to stop rendering them after a certain point and start rendering a new series of backgrounds, its a work around to be sure but im one step closer to my goal so ill take it as a win.
The question is a bit of a throw off, as I don't mean disposing the screen itself. What I am using is an enum and switch statement to switch screens, rather than the Screen and Game classes. What I am really asking here is, when I switch from one game state to the other, am I supposed to dispose all of my disposables before hand? Or do I just keep all of them and not worry about it, despite not rendering them anymore since I'm rendering a separate screen? I'd find it annoying to have to dispose all the resources on my screen every single time I want to switch to another one, so I'm wondering if it's truly necessary.
It's your choice and type of your game(Is your game having many resources).
If having lots of resources then it's better to dispose resource of one screen then load resource of another screen in memory and after that use that resource.
In this scenario show loading screen and load resource asynchronously.
If don't having lots of resources, dispose resource only when you exit from your game. Inherited Game's dispose() is best place for dispose your game resource in this scenario and call screen dispose from here. so that screen specific resource can disposed.
Quick rules can be:
If you loading something (Texture, TextureAtlas, Music, Sound etc.) at application start and you do not have problem with memory heap - dispose it at application dispose method.
But if you loading something special for your screen at screen start you should dispose it in screen dispose method.
If you do not dispose resource for ex. Texture it will be still in memory even if you dont render it. When you loading some texture inside screen without dispose it inside screen dispose method, it maybe to cause a memory leak because you load same texture second time when you start your screen again.
I'm developing an app that will connect to (my own) oscilloscope, read data via USB and display plots - so just normal oscilloscope.
USB is ok, now I have to draw the graphs.
As you know (or not) in oscilloscope there are really fast-changing signals, so I have to render graphs really fast.
So I'm looking for a fast way to do it.
I've read that GLSurfaceView uses OpenGL and GPU so it is used for games, but will I benefit from it in my project?
GL is really complicated (to draw a square or just lines, not to mention about text...) while SurfaceView has its Canvas so it's much easier.
I really care for performance, but have not much time and nerver used OpenGL so what do you think?
It is complicated, but you will benefit from GLES when using a SurfaceView.
Canvas on SurfaceView is not hardware-accelerated, so on some devices you'll have trouble hitting 60fps. (See for example the "multi-surface test" in Grafika. Tap the "bounce" button to cause it to animate. On some devices it'll do 60fps, on others it won't hit 30fps.)
One alternative would be to create a custom View. That way the rendering would be accelerated by hardware.
I am developing a game on android.Like tower defense.
I am using surface view.I am using some image as bitmap.(Spritesheets, tilesets, buttons, backgrounds,efects vs.)
Now images are nearly 5-6 mb.And i get this error when i run my game:
Bitmap size exceeds VM budget
19464192-byte external allocation too large for this process.
I call images like that
BitmapFactory.decodeResource(res, id)
and i put it to array.
I can't scale images.I am using all of them.
I tried that
options.inPurgeable=true;
and it work but the image is loading very slowly.I load a spritesheet with that and when it is loading, i get very very low fps.
What can I do?
I've had this problem too; there's really no solution other than to reduce the number/size of bitmaps that you have loaded at once. Some older Android devices only allocate 16MB to the heap for your whole application, and bitmaps are stored in memory uncompressed once you load them, so it's not hard to exceed 16MB with large backgrounds, etc. (An 854x480, 32-bit bitmap is about 1.6MB uncompressed.)
In my game I was able to get around it by only loading bitmaps that I was going to use in the current level (e.g. I have a single Bitmap object for the background that gets reloaded from resources each time it changes, rather than maintaining multiple Bitmaps in memory. I just maintain an int that tracks which resource I have loaded currently.)
Your sprite sheet is huge, so I think you're right that you'll need to reduce the size of your animations. Alternatively, loading from resources is decently fast, so you might be able to get away with doing something like only loading the animation strip for the character's current direction, and have him pause slightly when he turns while you replace it with the new animation strip. That might get complicated though.
Also, I highly recommend testing your app on the emulator with a VM heap set to 16mb, to make sure you've fixed the problem for all devices. (The emulator usually defaults to 24mb, so it's easy for that to go untested and generate some 1-star reviews after release.)
I am not a game dev however I would like to think I know Android enough.
Loading images of the size is almost certain to throw errors. Why are the images that file size?
There is an example at http://p-xr.com/android-tutorial-how-to-paint-animate-loop-and-remove-a-sprite/. If you notice he has an explosion sprite of only ~200Kb. Even a more detailed image would not take much more file space.
OK some suggestions:
Are you loading all your spritesheets onto a single sheet or is
each spritesheet in a seperate file? If they are all on one I would
split them up.
Lower the resolution of the images, an Android device is portable
and some only have a low resolution screen. For example the HTC
Wildfire has a resolution of 240x320 (LDPI device) and is quite a
common device. You have not stated the image dimensions so we can't be sure if this is practical.
Finally; I am not a game programmer but I found this tutorial (part of the same series) quite enlightening - http://p-xr.com/android-tutorial-2d-canvas-graphics/. I wonder if you are applying a pattern that is not appropriate for Android, however without code I cannot say.
Right something a little off topic but worth noting...
People under estimate the power of the View. While there is a certain amount of logic to using a SurfaceView, the standard View will do quite a lot on its own. A SurfaceView more often than not requires an underlying thread to run (that you will have to setup yourself) in order to make it work. A View however calls onDraw(), which can be utilized in a variety of ways including the postinvalidate() method (see What does postInvalidate() do?).
In any case it might be worth checking out this tutorial http://mindtherobot.com/blog/272/android-custom-ui-making-a-vintage-thermometer/. Personally, it was an excellent example of a custom View and what you can do with them. I rewrote a few sections and made a pocket watch app.
Best reader,
I'm stuck on one of my concepts.
I'm making a program which classroom children can measure themselves with.
This is what the program includes;
- 1 webcam (only used for a simple webcam view.)
- 2 phidgets (don't mind these.)
So, this was my plan. I'll draw a rectangle on the webcamview and make it repaint itself constantly.
When the repainting is stopped by one of the phidgets, the rectangle's value will be returned in centimeters or meters.
I've already written the code of the rectangle that's repainting itself and this was my result:
(It's a roundRectangle, the lines are kind of hard to see in this image, sorry about that.)
As you can see, the background is now simply black.
I want to set the background of this JFrame as a webcam view (if possible) and then draw the
rectangle over the webcam view instead of the black background.
I've already looked into jmf, fmj and such but am getting errors even after checking my webcam path and adding the needed jar libraries. So I want to try other options.
So;
- I simply want to open my webcam, use it as background (yes live stream, if possible in some way).
And then draw this rectangle over it.
I'm thus wondering if this is possible, or if there's other options for me to achieve this.
Hope you understand my situation, and please ask if anything's unclear.
EDIT:
I got my camera to open now trough java. The running camera is of type "Process".
This is where I got the code for my camera to open: http://www.linglom.com/2007/06/06/how-to-run-command-line-or-execute-external-application-from-java/
I adjusted mine a little so it'll open my camera instead.
But now I'm wondering; is it possible to set a process as background of a JFrame?
Or can I somehow add the process to a JPanel and then add it to a JFrame?
I've tried several things without any succes.
My program as it is now, when I run it, opens the measuring frame and the camera view seperatly.
But the goal is to fuse them and make the repainting-rectangle paint over the camera view.
Help much appreciated!
I don't think it's a matter of setting a webcam stream as the background for your interface. More likely, you need to create a media player component, add it to your GUI, and then overlay your rectangles on top of that component.
As you probably know from searching for Java webcam solutions in Stack Overflow already, it's not easy, but hopefully the JMF Specs and API Guide will help you through it. The API guide is a PDF and has sections on receiving media streams, as well as sample code.