XNA How to Render and Update while resizing - xna

Is it even possible to continue rendering and updating while resizing the window so that it doesn't stretch?

This is pretty deeply baked into XNA's Game class's behaviour. I'm dealing with this exact problem now, but I don't have a good solution yet. EDIT: I how now found a solution - but it doesn't answer the bit about scaling - so I've posted it as a question/answer pair over here.
You could possibly dive in with reflection and disconnect the events that pause the game's timer when you start resizing (and unpause it when you stop). I haven't tried this yet, I'm a bit loathe to do it without understanding why they exist in the first place.
(Personally I am thinking of having my game subscribe to the resize start/end events as well, and then pumping Update myself on an appropriate timer until XNA comes back. I wasn't going to worry about the scaling of the display.)
One way to work around this problem is to replace the Game class entirely. The XNA WinForms Sample provides a suitable replacement - although you have to implement your own Draw/Update loop and timing. I've just tested this in an old level editor and it works just as you want when resized.
Although it does slow down quite a bit when you make the window larger, as it constantly re-allocates the backbuffer to make it bigger. You could replace that behaviour to make it over-allocate the backbuffer size, so it doesn't reallocate so often.
The underlying problem has something to do with win32, and is described in some detail in this thread on GameDev.net. But it doesn't really provide a satisfying solution either.
It might be interesting to note that the WinForms sample draws on its OnPaint method (and you get a loop by constantly calling Invalidate). Whereas XNA's built-in Game class subscribes to Application.Idle.

Related

Implementing Perfectly Timed Animations

Creating Perfectly "up to spec" Animations
I'm working with a designer right now that likes to work a lot with After Effects. They create beautiful, well timed animations that look great, but I'm having trouble actually implementing the designs.
I can make everything look perfect, as in everything is the right size, shape, color, etc., but I can't get the movements to feel perfect, like they are in the spec. I can try my best to eyeball it, and tweak my animation parameters until things look close enough to the original design, but this isn't very satisfying. All of that tweaking and recompiling is super time consuming, and not very fun, and in the end things don't always feel correct as I can only approximate the timing functions.
Are there any tools that make implementing After Effects animations in iOS easier?
I would suggest that you take a look at my animation library for iOS. iOS Animation Examples With this native library you can import Quicktime video data using the Animation codec and convert that data with exact timing already defined by the animators. This ability to export directly from After Effects can really save you a lot of time.

Best GDI drawing approach

I am developing an interactive CD most of my life I wrote console applications writing something mostly graphical is akward for me.
So here is my approach :
I am drawing on the canavas using shapes and images the left and top position are stored in a file. Is there any easier approach ? I thought using shapes objects would simplify my work what do you guys think ?
Any examples are welcome.
If you consider this question subjective please vote for closing.
The proper way is to write an OnPaint handler (that is, listening to the WM_PAINT message) and drawing using the GDI.
Here are a couple of simple examples:
Moving triangles
Bouncing ball
Drawing by moving controls is very awkward.
Since you didn't specify a any version, I assume you're not wasting your time with an ancient Delphi, so maybe you should also take a look at FireMonkey.
That also opens the door to having your interactive stuff work on other platforms..
I recommend the Delphi GDI+ Library which I have used with success. It's a wrapper around GDI+ which takes alot of the pain out of it.

up-to-date simple OpenGL ES tutorial / template for iOS

At the moment i can draw a route on a map.
On the map i can zoom and i can pan. If the route is very big it goes really slow.
Therefor i want to do it with OpenGl.
From the map i can convert coordinateToPixel and get the current zoom.
I thought it would be the best to base the translation and zoom on that for the transformation matrix.
I never worked with OpenGL before. I have been reading stuff for the last few hours but most stuff i read is outdated or goes into things i don't care about for now like shaders.
Can someone provide me with resources for simple stuff like on the image?
I never worked with OpenGL before.
You are asking a lot, and I do mean a lot, of work from yourself if you want to switch from using native iOS drawing methods to using an advanced real-time rendering system that you don't even know yet.
I agree with Brad Larson that you are going to go much further and faster by leveraging the tools in iOS for your purpose. However, that does not mean you can't improve performance while using them.
I have found that when using Core Graphics for complicated drawing, you can dramatically reduce the time it takes to render a drawing by drawing it on a background thread. And Apple makes it much much easier to learn and use Grand Central Dispatch than the time it would take you to do all of this in OpenGL.
I learned how to use dispatch queues also for the single purpose of making drawing go faster. The simple technique is to render in the background, then take the results to the main thread for displaying them. Since you already have your drawing code figured out, you won't have to do much extra work to take this extra step, and I think you will be impressed with the performance.
I saw an improvement of at least 5 - 10 times in drawing speed when I implemented Core Graphics drawing with dispatch queues. They are really awesome.

iOS OpenGL ES - Only draw on request

I'm using OpenGL ES to write a custom UI framework on iOS. The use case is for an application, as in something that won't be updating on a per-frame basis (such as a game). From what I can see so far, it seems that the default behavior of the GLKViewController is to redraw the screen at a rate of about 30fps. It's typical for UI to only redraw itself when necessary to reduce resource usage, and I'd like to not drain extra battery power by utilizing the GPU while the user isn't doing anything.
I tried only clearing and drawing the screen once as a test, and got a warning from the profiler saying that an uninitialized color buffer was being displayed.
Looking into it, I found this documentation: http://developer.apple.com/library/ios/#DOCUMENTATION/iPhone/Reference/EAGLDrawable_Ref/EAGLDrawable/EAGLDrawable.html
The documentation states that there is a flag, kEAGLDrawablePropertyRetainedBacking, which when set to YES, will allow the backbuffer to retain things drawn to it in the previous frame. However, it also states that it isn't recommended and cause performance and memory issues, which is exactly what I'm trying to avoid in the first place.
I plan to try both ways, drawing every frame and not, but I'm curious if anyone has encountered this situation. What would you recommend? Is it not as big a deal as I assume it is to re-draw everything 30 times per frame?
In this case, you shouldn't use GLKViewController, as its very purpose is to provide a simple animation timer on the main loop. Instead, your view can be owned by any other subclass of UIViewController (including one of your own creation), and you can rely on the usual setNeedsDisplay/drawRect system used by all other UIKit views.
It's not the backbuffer that retains the image, but a separate buffer. Possibly a separate buffer created specifically for your view.
You can always set paused on the GLKViewController to pause the rendering loop.

Is iOS glGenerateMipmap synchronous, or is it possibly asynchronous?

I'm developing an iPad app that uses large textures in OpenGL ES. When the scene first loads I get a large black artifact on the ceiling for a few frames, as seen in the picture below. It's as if higher levels of the mipmap have not yet been filled in. On subsequent frames, the ceiling displays correctly.
This problem only began showing up when I started using mipmapping. One possible explanation is that the glGenerateMipmap() call does its work asynchronously, spawning some mipmap creation worker (in a separate process, or perhaps in the GPU) and returning.
Is this possible, or am I barking up the wrong tree?
Within a single context, all operations will appear to execute strictly in order. However, in your most recent reply, you mentioned using a second thread. To do that, you must have created a second shared context: it is always illegal to re-enter an OpenGL context. If already using a shared context, there are still some synchronization rules you must follow, documented at http://developer.apple.com/library/ios/ipad/#DOCUMENTATION/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/WorkingwithOpenGLESContexts/WorkingwithOpenGLESContexts.html
It should be synchronous; OpenGL does not in itself have any real concept of threading (excepting the implicit asynchronous dialogue between CPU and GPU).
A good way to diagnose would be to switch to GL_LINEAR_MIPMAP_LINEAR. If it's genuinely a problem with lower resolution mip maps not arriving until later then you'll see the troublesome areas on the ceiling blend into one another rather than the current black-or-correct effect.
A second guess, based on the output, would be some sort of depth buffer clearing issue.
I followed #Tommy's suggestion and switched to GL_LINEAR_MIPMAP_LINEAR. Now the black-or-correct effect changed to a fade between correct and black.
I guess that although we all know that OpenGL is a pipeline (and therefore asynchronous unless you are retrieving state or explicity synchronizing), we tend to forget it. I certainly did in this case, where I was not drawing, but loading and setting up textures.
Once I confirmed the nature of the problem, I added a glFinish() after loading all my textures, and the problem went away. (Btw, my draw loop is in the foreground and my texture loading loop - because it is so time consuming and would impair interactivity - is in the background. Also, since this may vary between platforms, I'm using iOS5 on an iPad 2)

Resources