This might be a primitive question but I really like to get more information. I have seen many professional programs have a splash screen and during that a progress bar and some text indicating that program is loading...
I want to know what CAN or SHOULD be loaded during such time? Do they load classes or something? I am noob and do not know what requires loading before a program actually starts.
In summary, yes. They load classes.
If the program's design is modular enough, the outer shell can be small enough to run almost immediately on most devices (think mobile phones here) and display a progress bar while loading behavior (features provided by external modules, assemblies in C#) in the background.
However, that's not always the best approach to program loading. If your user interface can be up and running in less than five seconds on a typical client machine, it may not even be worth a progress bar.
Well it depends on the program. I use a loading screen when my game is randomly generating terrain which can take anywhere between 1 second to 2 minutes.
Related
I am currently making a simple game in XNA but am at a point where testing various aspect gets a bit tricky, especially when you have to wait till you have 1000 score to see if your animation is playing correctly etc. Of course i could just edit the starting variable in the code before I launched but I have recently been interested in trying to implement a console style window which can print out values and take input to alter public variables during run-time.
I am aware that VS has the immediate window which achieves a similar thing but i would prefer mine is an actual part of the game with the intention that the user may have limited access to it in the future.
Some of the key things i have yet to find an answer to after looking around for a while are:
how i would support free text entry
how i would access variables during runtime
how i would edit these variable
I have also read about using a property grid from windows form aps (and partially reflection) which looked like it could simplify a lot of things but i am not sure how I would get that running inside my XNA game window or how i would get it to not look out of place (as the visual aspect of is seems to be aimed just for development time viewing).
All in all I'm quite open to any suggestions on how to approach this task as currently I'm not sure where to start. Thanks in advance.
I've used this in the past, and it worked great.
http://xnacc.codeplex.com/
It will require some programming to set it up to work with your game, but may be worth the effort if this is something that interests you.
Ok, this might be a silly question but...
Is it possible to have a custom xaml load/splash screen within the xap?
There is a game site I wish to upload my Silverlight game to, which only allows a single xap to be uploaded, and so I wondered whether there is a possibility of modifying the splash screen that it uses.
My gut feeling is that this is impossible, but I thought I might as well ask.
You can't have a true splash screen that is within the xap file. The whole point is that the splash screen is displayed while the xap file is downloading, so it can't be inside of it.
There's a great MSDN page detailing several different aspects of splash screens, as well as a how-to article that walks you through the basic process.
Who ever is hosting these silverlight games should be responsible for having their "splash screen" for when the xap's are loading.
However, there is nothing from preventing you to create your own splash screen(s) as these are typical within games (and no, the point of a splash screen is not necessarily to hide the downloading/loading of something, especially in a game).
Hope that helps.
As you might surmise from the question title, we are required to decode and display multiple (e.g., eight) H.264 encoded videos at the same time (and keep them all time synchronized, but that's another question for another time). The videos are usually at at 25 FPS with a resolution of 640x480.
I'm going to provide a bit of background before I get to the crux of the problem.
The feature needs to be baked into a fairly large C# 3.5 (WinForms) application. The videos will occupy rectangles in the application - the managed code needs to be able to specify where each video is drawn as well as it's size.
We get the H264 packets in C# and fire them into a native H264 decoder to get YUV12 image data.
An early attempt consisted of converting the YUV12 images to RGB24 and BitBlt'ing them to a HWND passed into the native code from C#. While functional, all BitBlt'ing had to happen on the UI thread which caused it to bog down when displaying more than a couple videos (on a 2.6 GHZ core 2 duo).
The current attempt spins up one-thread-per-cpu-core on startup and load balances the decoding/displaying of videos across these threads. The performance of this is mind-blasting (I find watching task manager much more interesting than the videos being displayed). UI-wise, it leaves a lot to be desired.
The millisecond we started drawing to an HWND created on the UI thread (e.g., a panel docked in a WinForms control) from a non-UI thread, we started getting all sorts of funky behavior due to the un-thread-safeness of WinForms. This led us to create the HWND's in native code and draw to those, with C# providing the rectangles they should be drawn to in screen coordinates.
Gah! CanOfWorms.Open().
Problem: When the C# application receives focus, it jumps to the front of the Z-Order and hides the video windows.
Solution: Place the video windows Always On Top.
Problem: When the user switches to another application, the video windows are still on top.
Solution: Detect activation and deactivation of the C# application and show/hide the video windows accordingly.
Problem: User says, "I want my videos playing on one monitor while I edit a Word document in the other!"
Solution: Tell user to shut up and that Word sucks anyways.
Problem: I get fired.
etc. etc.
I guess the crux of the problem is that we have HWND's created on a non-UI thread and we want to 'simulate' those being embedded in the C# application.
Any thoughts/suggestions? Am I completely out to lunch here?
I'm more than open to taking a completely different approach if one exists (This project required a lot of learning - winning the lottery would have a greater likelihood than me having picked the best approach at every step along the road).
Forget about BitBlt-ing and do this:
for each window you want your video to be played, create one DirectShow graph and attach the renderer of the graph to that window
before renderer in the graph put the samplegrabber filter. It will allow you to have callback in which you'll be able to fill the buffer
instead of blitting, decode to the buffer provided in samplegrabber.
In addition, I guess that you'll be able to put raw YUV12 into the buffer, as VMRenderer is able to display them directly.
Use DirectShowNet library.
EDIT:
And yes, BTW, if the videos are on the same 'canvas', you can use same technique with renderer and create only one large window, then shift decoded video rectangles 'by hand' and put them into the framebuffers buffer.
YET ANOTHER EDIT:
BitBlts are ALWAYS serialized, i.e. they can't run in parallel.
The millisecond we started drawing to an HWND created on the UI thread (e.g., a panel docked in a WinForms control) from a non-UI thread, we started getting all sorts of funky behavior due to the un-thread-safeness of WinForms. This led us to create the HWND's in native code and draw to those, with C# providing the rectangles they should be drawn to in screen coordinates.
What kind of funky behavior?
If you mean flickering or drawing delay, have you tried to lock() the panel or any other class for thread/drawing synchronisation?
Again: Whats the exact problem when you send the data to the decoder, receive a image, convert it and then draw it with an OnPaint handler. (Setup a different thread that loops at 25fps, call panel1.Invalidate() then)
I guess the crux of the problem is that we have HWND's created on a non-UI thread and we want to 'simulate' those being embedded in the C# application.
Don't do that. Try to draw the received data in your c# application.
In general, I wouldn't reccomend mixing native code and c#. Having the h264 decoder in native code is the only exception here.
Use your threads to decode the video packets (as you already do) then have one thread that loops and calls Invalidate(as said above). Then have an OnPaint handler for each panel you are displaying a video in. In this handler get the most recent video picture and draw it (e.Graphics).
I hope this helps, but also need more information about the problem...
I like the DirectShow answer posted earlier, but I wanted to include an additional option that might be easier for you to implement, based on this excerpt from your question:
While functional, all BitBlt'ing had to happen on the UI thread which caused it to bog down when displaying more than a couple videos
My idea is to start from that code, and use the Async CTP for Visual Studio 2010 that is currently available and includes a go-live license. From there it should be a relatively simple to modify this existing code to be more responsive: just add await and async keywords in a few places and the rest of the code should be largely unchanged.
I am looking for a decent programmatic approach to delivering the illusion of "riding in a van". Here is the synopsis:
I have a friend who is opening up a bar in San Francisco with a room interior designed to be like the inside of a van (picture the inside of the Scooby Doo Mystery Machine) . Set into the walls are “windows” and behind those windows are monitors. There are two servers (for the left and right sides) that are delivering simultaneous presentations from pre-recorded footage of a vehicle driving down the road.
At the moment the screens are split across a shared workspace so as items in the background move from the right to the left the impression of motion is flawless. However, once you move the screens apart there is no delay for empty "wall space" or the natural delay that one would expect to perceive as an object progresses from one screen through the space in the wall to the next screen.
Is there a managed code approach I could take to construct a project that could take a time delay argument for delivering content between monitors in this case? Or is there even an off-the-shelf program that might do the trick as well?
EDIT:
What I am really looking for is advice on how to program this: Can I load in a windows media file and stream it to separate monitors on separate threads with a slight delay?
Sure, you just have to do playback on both monitors separately and delay one of the videos.
I have a C# Windows application (i.e. not a web app) in Visual Studio. The original development environment was a Dell Latitude D800 with a 1920x1200 pixel screen. Since the large number of pixels made the text very small, I adjusted lots of different default fonts in the name of readability.
I have moved development to new laptop, a Latitude D630 with 1440x900 display. The app was moved by creating a new project on the new machine, and adding the existing objects/files/etc.
THE PROBLEM is that many of my forms are no longer displaying uniformly. Some are now too large so that items on the right are out of the frame, and others are smaller with excess space on the right of the frame. It is as if the value of a 'pixel' is now different from one form to another. These changes persist when the executable is installed on production machines.
Any idea on what happened, and how to restore order? Thanks.
A good bet would be to check your font DPI setting. By default its set to 96. Its part of your windows display settings.
As best I understand, that would not explain why some forms are affected differently from others.
Winforms contains a lot of technology designed around the problem of making the display of forms reasonably resolution-independent. But a lot of this technology requires you to understand and use it - anchoring, docking, layout panels, and automatic scaling, for instance. If you've misapplied these properties, you often don't know about it until the day that you first test your app at a different resolution.
Unfortunately, there isn't really a magic bullet answer to the question "why are my forms screwed up?" Your forms are screwed up because resolution-independence wasn't designed into them. There's a whole host of possible problems: you could have controls anchored to the wrong things, someone could have "fixed" a layout problem by overriding automatic scaling on a control, really, it's endless.
Often, the best way to fix this kind of problem in a legacy app is to slowly build up a prototype duplicate of the offending form in a test application and watch its behavior when you resize it and change your screen resolution. That'll help you identify how the form should originally have been designed; you can then take what you've learned back to the original form and fix it.
And then design this into your development process from the beginning. One of the reasons that I don't have these problems in the big UI-intensive desktop app I'm building is that I've made every form in the program resizable, and I resize them during testing all the time to see if they're screwing up. I also test with different screen resolutions as a matter of course. These are the kinds of problems that are really hard to solve once they've become systemic; spotting them early keeps a lot of misery out of my life.
Some experimentation reveals that the declared size of a form apparently affects the size of objects in the scale (length and width units per screen inch) of the form when displayed as a maximized MDI child.
I have no idea why it should affect that.