Hot answers tagged screen
8
I'm not sure what sort of hierarchical FSM do you have in mind, so I'm sorry if this does not directly answer your question, but I'd really like to take the chance and add some input from my own experience using a stack based screen manager.
Since you need the ability to open a popup screen but still be able to see the screens below, having a stack based ...
7
Developer priorities. It's more work to support than a simple windowed/fullscreen toggle, the latter of which is more or less built into DirectX/OpenGL and most windowing systems.
There are subtle bugs that you end up finding when you implement it, like on some OSs the mouse pointer position is reported incorrectly, offset by the height of where the title ...
7
I would also consider allowing a stack of states. That way when the state on top leaves, the state under activates. this is really nice for menu states. When one menu leads to another, it simply puts the next state on top. If the user wants to go back, you simply deactivate the current state and the previous state activates. Very easy for menu navigation.
...
7
I'm just going out on a limb here and assuming that your drawing is painter style, in that something drawing first will show up behind something drawn after it.
If that's the case, it's simply a matter of sorting your entities by y position before you draw. I'm assuming you have some mechanism of iterating through all of your entities. You'll have to sort ...
7
Do you think it would be a good idea to have each part of the screen (game session) handled by different thread?
When it comes to rendering: No!
OpenGL and multithreading don't mix well. It's best practice to keep all OpenGL operations to one single thread.
6
What that code is doing is limiting motion to only if you're inside the screen. What you should instead do is something like this:
//control code here
if(player.getx() > 1024){
player.setx(1024);
}else if(player.getx() < 0){
player.setx(0);
}
that way if the player exceeds the bounds of the screen the position will be set back to the ...
5
Depends on the game, if the game is single-player, let the user select a resolution, if they are happy for small characters, they can have it, if they want to feel connected with the game, they can use a lower resolution.
Games like Civilization opt for this method.
However, if you're building a multiplayer game, you're going to need a fixed resolution, ...
5
The problem here is that you are trying to get a controlled object (screen you're in) to direct it's controlling object (ScreenManager). Two approaches come to mind:
Adapt the code of the library so that the ScreenManager listens for and acts on custom events fired from the screens it manages. You could send events that carry an instance of class object ...
5
So you have two coordinates or vectors, one is the center of the screen (C from now on) and the other is your object (P from now on.)
If you know some math, you might know that a line can be expressed as an origin and a direction vector. The origin is your screen-center, while the direction vector can be found subtracting C from P. This equation can also be ...
4
Since it is most likely that the logic of your game will not change from level to level, rather it is the content that changes - map, characters, enemies - it doesn't make sense to create a new screen for each and every level.
Each new level screen will be almost identical to the previous ones except for maybe a few properties, fields, and the ...
4
Having tried every conceivable way of doing it, I have found if it's purely a 2D game, just use the screen drawing system, it will make your life much easier. Sin, Cos, and atan2 need to be used slightly differently, but this inconvenience is easily made up for by the simplicity of knowing which way up, down, clockwise and anti-clockwise are. I would also ...
4
1024x768 (or less) is still the minimum resolution you should be targeting. Plenty of laptops sold between ~2006 and now have fully capable video cards, but are stuck to the same resolution they were sold at.
Depending on the game, it may be even less - netbooks commonly sold with a 1024x600 resolution during the same period, so a casual or web-based game ...
4
As I understand it, the major difference between hierarchical state machines and stacked FSMs (HFSM and SFSM from now on) is that in an HFSM transitions away from a low level state can be specified directly, whereas in a SFSM, states in the subgroups cannot have specific exit conditions that leave the subgroup.
Probably best with an example:
This is a ...
3
Assuming that you have an array containing every object that needs to be drawn. On each game loop you would loop through this array and call each object's corresponding draw() method to place it on the canvas. If you are doing it this way then you can use a sorting function on the array that will sort the array based on the object's Y axis value. So when the ...
3
Introduce a state variable. When the state is paused and not running draw a scene2d stage with the elements of your pause screen. Unpausing sets the state back to running, which then starts rendering and updating your game screen.
The overlay or popup effect can be achieved through an image.
So in short: use a switch case statement on the game state in ...
3
A good architecture is keeping the GameState and ScreenManager objects separate so they don't directly know about each other and only indirectly communicate though an EventDispatcher object; ScreenManager registers with EventDispatcher as listening for messages about models being picked, and GameState sends a message to EventDispatcher about a model being ...
3
You can render the normal game objects using perspective view, and then when the render func is done with that, switch to orthographic view and render your GUI or whatever it is, this way.
Using glOrtho you can define your screen going exactly from left 0 to right 1 and the same for bottom and up. Since there is no perspective distortion anymore, those ...
3
There is a good and relevant article on Android.com :
http://developer.android.com/guide/practices/screens_support.html
This reference helps you sort through screen size, screen density, and resolution. The goal is to use the Android APIs to achieve "density independence" so that your user interface components and graphics can look good on various devices.
...
3
First of all pixel on the screen is a ray in your 3d world - all scene behind this pixel.
Second, what you must know, that any point in 3d converted into 2d motinor space via multiplying 3 matrices:
pointIn2DSpace = pointIn3DSpace * WorldMatrix * ViewMatrix * ProjectionMatrix
So you can do a back conversion, multiplying "monitor" point with inverted WVP ...
2
It's not so much a technical issue as a gameplay issue. Namely, if you try to click on something at the edge of the screen but move the mouse too far you might click outside the game instead, making the game lose focus or possibly even get covered up by a window that was partially behind it. It's particularly troublesome for first-person view games.
2
Steam details: http://store.steampowered.com/hwsurvey
Resolution %Users
1024 x 768 7.47%
1152 x 864 1.41%
1280 x 720 0.72%
1280 x 768 0.72%
1280 x 800 5.88%
1280 x 960 1.21%
1280 x 1024 15.13%
1360 x 768 1.34%
1366 x 768 6.27%
1440 x 900 10.14%
1600 x 900 3.63%
1600 x 1200 0.94%
1680 x 1050 18.46%
1920 x 1080 15.72%
1920 x 1200 ...
2
Honestly I hate the built-in page system in WPF. It is clearly designed for web-browsing.
I recommend just creating a grid and dynamically adding/removing (or changing visibility) your elements (CustomControls or UserControls) for your MainWindow. Because each of these are just WPF elements within the same grid you can blend their opacity for smooth ...
2
How to handle this really depends on what you mean by a 'screen'. Often the presentation of the game at a certain point is tied into the input system for that stage, and this is grouped together as some sort of game state object. I tend to dislike this approach because too often these states become dumping grounds for all sorts of unrelated data and ...
2
This is a ERR in Pygame i'm sorry to say.
Had this major problem when developing a toolkit for a company back in the days.
Edit: if the first "bug-ugly-fix" doesn't work, try my second suggestion!
The fix was sort of easy tho (if it works for you, this is NOT logical because it doesn't have anything to do with the actual problem BUT it worked for me, for ...
2
I think your idea is pretty much spot on! First calculate a ray for your cursor using both the near plane and the far plane as Z values for your 2D coordinates (i.e. use 0 and 1 for your Z coordinate). Here's an helper method to handle that:
public Ray GetScreenRay(Vector2 screenPosition, Viewport viewport, Matrix projectionMatrix, Matrix viewMatrix, Matrix ...
2
I wrote something just for this a while ago, but for a 2D camera. I haven't tried adapting it to use a 3D camera, but since your game is always top down, I think it can be considered as a 2D camera too, so the concepts should be similar enough. Hope it's useful:
http://www.david-gouveia.com/limiting-2d-camera-movement-with-zoom/ (Video Here)
It's basically ...
2
// 'Camera' is an object containing the position of the camera
// 'A' is the angle shown in the picture above
// wallHeight is an optional variable giving the height of a surrounding wall that you could not see through
// The gradient m
float m = Math.Sin(MathHelper.ToRadians(A))
/ Math.Cos(MathHelper.ToRadians(A));// Here A is the angle 'A' in ...
2
You can draw the reticule by using a percentage of the width and height of your resolution.
For example if you want the reticule to be a 5% size:
Resolution | Reticule Size
1024 x 768 | 51.2 x 38.4
1280 x 1024 | 64 x 51.2
So the size of the reticule will change depending on the resolution, but it would look the same to you.
2
No, you shouldn't.
There simply is no reason why you would want threads. Threads have two use-cases: performance and asynchronity. The performance isn't a problem and there is no reason to do it asynchronous.
Threads aren't to be taken lightly and don't simplify anything.
Splitscreen multiplayer only requires you to code a few things: a camera for each ...
2
I see that you've already accepted an answer, but I feel I can add to it. I have written a blog post about this here. The gist of it is as follows:
"After a bit of research, I’ve come to the conclusion that most Android phones that I want to target have a 480×800-ish resolution. I’ve also noted that the smallest aspect ratio of any Android phone (held in ...
Only top voted, non community-wiki answers of a minimum length are eligible
