I'm trying to read raw video frames from a video capture device using JMF - the Java Media Framework.
I've successfully written the "capture" part - using a Player object created by Manager, I can display realtime video from a webcam. I don't know how to go about creating a custom component to access the actual frames, however. This is probably because up until now Manager has created every class instance I needed for me.
I would like to start by writing a GUI component that displays the video. (I'm not familiar with AWT/Swing, but based on knowledge of other GUI frameworks, I'd say something derived from a, say, JPanel that draws the video when a repaint request is made or a new frame is available.) I would like to be able to process every new frame and loop on x/y over all the pixels. I have access to the raw/RGB format on my device, but automatic conversion from, say, YUV wouldn't hurt.
I have no idea where to start. The JMF documentation recommends I derive my class from Processor or DataSink in several different places. Using the Processor interface seems like an overkill - I would have no need for the playback and timing control functions, for example; and I wouldn't know how to implement them in the first place. Deriving from DataSink seems like a simpler option with less useless abstract functions. However, in either case, I'm at a complete loss as how to:
a) Connect the component to my video capture DataSource
b) Access the actual frame buffers from within the class
I may even be going in a wrong direction here; I just wanted to document what I've tried so far. JMF documentation seems scarce and mostly oriented towards [designing] media players and converters.
Note: The Processing library seems to have a simple solution for this. I've seen an example along the lines of: x = new Image(captureDevice.getFrame()) which seems to suggest pixel-level access is possible, through Image if not the intermediate type.
But I would really like to see how hard it is in JMF first.
You might try out the code that I posted here, which uses JMF and a class named FrameGrabber.
I'm sorry, but at this point, JMF is essentially dead. You would probably use FX for that, but FX isn't exactly doing well either.
Related
I'm currently working on a training plugin, where every player would get his own region, to learn bridge for example. So when a player joins, the plugin should automatically generate a new area for this player and delete it when he leaves.
I've created a SetupCommand where you have to set the start and end of the region that should be copied.
Now the only thing to do is copy the region and teleport the player to it, however, I couldn't find any good ways to do that. The only solution I found so far is to loop through all blocks and copy them one by one. But I can imagine that this is not the best solution and would cause lag, not only server-side but also client-side.
Are there better ways to clone a region than that?
I've read you should use Schematics but they weren't going into detail.
If you are experienced with java and feel comfortable about your skills you can try to get the blocks in the list as List and save it as base64 into your database or whatelse. You can parse it everytime back into a list of blocks and replace it. I would rather recommend you to make a custom block class with implements Serializeable and then add some values like Location, Material and BlockData to it.
Use FAWE or WorldEdit to copy/paste sections
If you use Block#setType, performance will be very slow, so if you don't want to use the API, you should use NMS, but using NMS is not a good practice.
Disadvantages of NMS:
Most nms methods are obfuscated. In one version the method is called f(), in the next version maybe c().
How to copy/paste with FAWE:
https://www.spigotmc.org/threads/how-to-paste-a-schematic-with-fawe.402950/
How to copy/paste with worldedit:
https://www.spigotmc.org/threads/worldedit-api-schematic-copy-save-load-and-paste.498476/
In conclusion, it is recommended to use the API
I'm a novice programmer and recently I came across many methods of animation:
Using BufferedImages , ie. draw to image and display using double buffering or triple buffering methods .
Making my sprites components by extending Component or Button . and repainting by repaint(g).
Rastering, using rasters and integer arrays, bitmaps and the like.
I realise that method 1 and 2 are similar as they use paint() methods , however Rastering involves self-made functions , eg. creating functions that set background by traversing the whole array representing each pixel and setting colour to desired colour .
I've seen many folks online use raster methods even though 1 & 2 seem simpler .
Please help me out here guys and tell me what path i should follow and why .
The first and second methods are very similar and would come down to the context of the problem.
The third option would, for the most part come down to providing a flexible API which was independent of the toolkit or framework which was to be used to dipslay it. One could argue that there is a speed increase, but with Swing and JavaFX working more directly with the DirectX and OpenGL pipelines, this is less of an issue.
Unless your planning on dong some seriously low level functionality or interfacing to a non-standard API I wouldn't worry to much about it (some effects painting might be faster done this way, but it's all about context)
Personally, it would focus on developing an understanding of the basics and principles involved and how they might be implemented using the first two options as it allows you to focus on those concepts with a relatively easy API
As time progress or you come across a situation that can't be resolved using these techniques, then it might be time to consider playing with the rastering approach.
Remember though, you still need to get that byte array into a format that the API wants which in of itself, will add overheads
I am trying to use the AssetManager class in LibGDX and I understand how it works but I am trying to implement a loading screen. I have followed the AssetManagerTest.java file here,
but I am having a hard time trying to figure out how to get it to work correctly. Can someone point me in the right direction? My goal is to load the assets (textures, sounds, fonts, ... etc) and update a bar with the percentage complete on the screen. I don't understand the ResolutionFileResolver and the Resolution[] in the link I provided. What are they for? My goal is to support a static class that can give me access to all of the assets I need in my game from any screen. Is there a preferred method to do this? Thanks.
After looking at the source for ResolutionFileResolver as well as the other 'resolvers', I think it's just a way of loading textures that best match the screen resolution, but the match is just based on filename patterns.
So in AssetManagerTest, he's got textures for screen sizes 320x480, 480x800, and 480x854. It looks like each group of textures should be in a directory called ".320480" or ".480800" or ".480854" (although the name can be anything you want, like "low", "high", and "wide" if those are your directories), and he specifies all this info when creating the array of resolvers on line 56 of the test.
The advantage of doing all this stuff is that when he calls manager.load(), he just picks out a filename like "data/animation.png". Then the resolver finds the pack of textures that most closely matches the current screen resolution, and loads that one.
I think the rest of the example should be pretty clear, at least for the basics of AssetManager. Create a manager, set the loader, call load(), call get() to use it, and then call unload() when done.
For updating a progress bar, you'll just need to do that manually after each call to load.
And using a static class for asset management is certainly one possibility. Another similar option is to just use a singleton. It has its haters, but I think in a simple project in a garbage collected environment it should be ok, although it's about the same as a public static.
Another option--maybe the best?--is to use a base class that has a static copy of your game globals, and then all other game classes inherit from it. This is the approach used in Replica Island. See the base class and the object registry. Replica Island is well commented and worth checking out for Android & Java games.
The following simple snippet grabs all the available screen devices in Java no problem:
GraphicsDevice[] gds = ge.getScreenDevices();
That much is simple. However, I'd like to get notified when this changes (an existing screen changes, one is removed, a new one is added, etc.)
I could just poll on the above method call which is do-able, but ideally I'd like a notification (observer pattern style) when something changes. I can't see a way in the API to hook onto such an event though.
Is this possible, either through plain JDK or an add-on library, or should I just resort to polling every other second or so?
From all the looking around I've done, the answer at present (looking at Java 7 and the currently proposed Java 8 APIs) is simply no - you just have to poll it seems.
Although this is nasty from an OO perspective from a performance perspective it doesn't really make a difference as long as you're sensible with intervals - it seems to be a very cheap operation. My approach was to do the polling in a separate class and provide an observer pattern on which others could register. Does the job well, all the polling is in one place and if a better API comes along later, it'd be trivial to swap out with the new interface.
Whenever I try to write graphical programs (whether a game or really any GUI app) I always wind up with one or two god classes with way too many methods (and long methods, too), and each class having far too many responsibilities. I have graphics being done at the same time as calculations and logic, and I feel like this is a really bad way to go about organizing my code. I want to get better at organizing my code and abstracting out responsibilities to different classes. Here's an example of where I'd like to start - I want to write a Minesweeper clone, just sort of as practice and to try to improve my software engineering skills. How would I go about making this nice and object-oriented? For the sake of discussion, let's just say I'm using Java (because I probably will, either that or C#). Here's some things I would think about:
should each tile inherit from JButton or JComponent and handle drawing itself?
or should the tiles just be stored as some non-graphical MinesweeperTile object and some other class handles drawing them?
is the 8-segment display countdown timer (pre-Vista, at least) a separate class that handles drawing itself?
when the user clicks, do the tiles have mouse event listeners or does some other collision detection method loop through the tiles and check each one to see if it's been hit?
I realize that there's not just one way to write a GUI application, but what are some pretty basic things I can start doing to make my code more organized, manageable, object-oriented, and just over all write better programs?
edit: I guess I should add that I'm familiar with MVC, and I was originally going to incorporate that into my question, but I guess I didn't want to shoehorn myself into MVC if that's not necessarily what I need. I did searched for topics on MVC with GUI apps but didn't really find anything that answers my specific question.
edit2: Thanks to everyone who answered. I wish I could accept more than one answer..
Here is a simple (but effective) OO design to get you started:
First create a Game object that is pure Java/C# code. With no UI or anything else platform specific. The Game object handles a Board object and a Player object. The Board object manages a number of Tile objects (where the mines are). The Player object keeps track of "Number of turns", "Score" etc. You will also need a Timer object to keep track of the game time.
Then create a separate UI object that doesn't know anything about the Game object. It is completely stand alone and completely platform dependent. It has its own UIBoard, UITile, UITimer etc. and can be told how to change its states. The UI object is responsible for the User Interface (output to the screen/sound and input from the user).
And finally, add the top level Application object that reads input from the UI object, tells the Game what to do based on the input, is notified by the Game about state changes and then turns around and tells the UI how to update itself.
This is (by the way) an adaption of the MVP (Model, View, Presenter) pattern. And (oh by the way) the MVP pattern is really just a specialization of the Mediator pattern. And (another oh by the way) the MVP pattern is basically the MVC (Model, View, Control) pattern where the View does NOT have access to the model. Which is a big improvement IMHO.
Have fun!
use a MVC framework that handles all the hard organization work for you. there's a ton of MVC framework topics on SO.
using high quality stuff written by others will probably teach you faster - you will get further and see more patterns with less headache.
I'm not suggesting this is the only way to do it, but what I would suggest is something like the following. Other people, please feel free to comment on this and make corrections.
Each tile should inherit from something and handle drawing itself. A button seems like the best solution because it already has the button drawing functionality (pressed, unpressed, etc) built in.
Each tile should also be aware of its neighbors. You would have eight pointers to each of its eight neighbors, setting them to null of course if there is no neighbor. When it goes to draw, it would query each neighbor's IsMine() function and display the count.
If none of its neighbors are a mine, it would then recurse into each neighbor's Reveal() method.
For the 7-segment display, each digit is its own class that handles drawing. Then I would make a CountdownSegmentDigit class that inherits from this class, but has additional functionality, namely CountDown(), Set(), and Reset() methods, as well as a HitZero event. Then the display timer itself is a collection of these digits, wired up to propagate zeroes left. Then have a Timer within the timer class which ticks every second and counts down the rightmost digit.
When the user clicks, see above. The tile itself will handle the mouse click (it is a button after all) and call its Reveal() method. If it is a mine, it will fire the MineExploded event, which your main form will be listening to.
For me, when I think of how to encapsulate objects, it helps to imagine it as a manufacturing process for physical parts. Ask yourself, "How can I design this system so it can be most efficiently built and reused?" Think about future reuse possibilities too. Remember the assembly process takes small pieces and builds them up into larger and larger pieces until the entire object is built. Each bit should be as independent as possible and handle its own logic, but be able to talk to the outside world when necessary.
Take the 7-segment display bit, you could have another use for it later that does not count down. Say you want a speedometer in a car or something. You will already have the digits that you can wire up together. (Think hardware: stock 7-segment displays that do nothing but light up. Then you attach a controller to them and they get functionality.)
In fact if you think hard enough, you might find you want CountUp() functionality too. And an event argument in HitZero to tell whether it was by counting up or down. But you can wait until later to add this functionality when you need it. This is where inheritance shines: inherit for your CountDownDigit and make a CountUpOrDownDigit.
Thinking about how I might design it in hardware, you might want to design each digit so it knows about its neighbors and count them up or down when appropriate. Have them remember a max value (remember, 60 seconds to a minute, not 100) so when they roll over 0, they reset appropriately. There's a world of possibilites.
The central concern of a Graphic User Interface is handling events. The user does X and you need to response or not respond to it. The games have the added complexity in that it needs to change state in real time. In a lot of cases it does this by transforming the current state into a new state and telling the UI to display the results. It does this in a very short amount of time.
You start off with a model. A collection of classes that represents the data the user wants to manipulate. This could represent the accounts of a business or vast frontiers of an unknown world.
The UI starts with defining a series of forms or screens. The idea is that is for each form or screen you create a interface that defines how the UI Controller will interact with it. In general there is one UI Controller classes for each form or screen.
The form passes the event to the UI Controller. The UI Controller then decides which command to execute. This is best done through the Command design pattern where each command is it own class.
The Command then is executed and manipulate the model. The Command then tells the UI Controller that a screen or a portion of a screen needs to be redraw. The UI Control then looks at the data in the model and uses the Screen Interface to redraw the screen.
By putting all the forms and screen behind a interface you can rip out what you have and put something different in. This includes even not having any forms at all but rather mock objects. This is good for automated testing. As long as something implements the Screen Interface properly the rest of the software will be happy.
Finally a game that has to operate in real time will have a loop (or loops) running that will be continually transforming the state of the game. It will use the UI Controller to redraw what it updated. Commands will insert or change information in the model. The next time the loop comes around the new information will be used. For example altering a vector of a object traveling through the air.
I don't like the MVC architecture as I feel it doesn't handle the issues of GUIs well. I prefer the use of a Supervising Controller which you can read about here. The reason for this is that I believe automated tests are one of the most important tools you have. The more you can automate the better off you are. The supervising presenter pattern makes the forms a thin shell so there is very little that can't be tested automatically.
Sorry to say it, but it seems you have mess in your head trying to improve your coding too much in one step.
There is no way to answer your question as such, but here we go.
First start with OOP, think about what objects are required for your game/GUI and start implementing them a little at a time, see if there are chances to break up these objects further, or perhaps reunite some objects that make no sense on their own, then try to figure out if you have repeated functionality among your objects, if you do, figure out if this repeated functionality is a (or many) base class or not.
Now this will take you a few days, or weeks to really grok it well, then worry about dividing your logic and rendering.
I have some tutorials that are written in C#. It discusses this very same topic. It is a starting point for a RogueLike game.
Object Oriented Design in C# Converting Legacy Game
Object Oriented Design: Domain Type Objects
Object Oriented Design: Rethinking Design Issues
BROKEN LINK - Object Oriented Design: Baby Steps in Acceptance Testing