I am working on a game in libgdx, my partial scenario is this
1: I have got 5 squares which I fill every 10 second and once they all are full[50 sec] nothing is done. I fill them by coloring them to blue from red which is by default.
2: A button which has its operations, one of those operations is that it will fill one of these square(color changed from red to blue.)
Here is the set up
act(float)-------calls---> updateSquare
updateSquare ---> checks whether it has been 10 second since last time, if yes then grab the first square available and change the color.
buttonListener ----> change the color of the first square available to blue from red.
Now my question is that whether it is thread safe? Will these threads overlap with each other?
Let's say my first two square are red and rest are blue so the first available is 3rd one, so if first updateSquare is called and than I click the button then two new squares will be turned blue and total four blue squares.
However if both happen at the same time(updateSquare and buttonClick) then both of them will make only the 3rd square blue.
Is this scenario(overlap) possible? My friends it is not and I also don't face any problems like this, but I don't know whether it is thread safe or not?
See this link:
Events are dispatched right before the call to ApplicationListener.render(), on the rendering thread.
What this means is that you actually do not have any multithreading here. All events (like the one your buttonListener receives) get collected during one frame. And they are dispatched to your handlers right before the next render call.
This is completely deterministic and there are no overlaps.
Related
I am trying to check if a KinematicBody2D enters an Area2D. There is a signal for that(on_body_entered), but it only emits when the body is completely inside the area. Is there a way to constantly get if a body is just overlaping?
but it only emits when the body is completely inside the area
This is not correct. A more accurate description of the "body_entered" would be that it triggers on contact. The body could be partially or totally overlapping.
I suggest you enable "Visible Collision Shapes" from the debug menu. Perhaps your collider are not set the way you expect them to be.
We do not have a signal for when the body is completely inside.
What you can do is set up a smaller area (or a larger one depending on your need)…
The idea is to have two areas that are one larger than the other, in such way that there is a margin for just the size of the player character, then when the outer one triggers, it means the character is only overlapping the larger one, and when the inner one triggers the character is fully inside the larger one.
For example, if you have a 500 by 500 area, and your player is 100 by 100, then set an area with the size 300 by 300 centered at the larger area… When the player enters in contact with the smaller area, it will trigger the "body_entered" signal, which will also mean it is entirely inside the larger one. If you only got "body_entered" from the outer area but the inner area, then the player character is overlapping the outer area, but not fully inside it.
I got feeling retro and decided to write my favorite 8-bit computer game (Williams' Defender) on my first computer (Commodore PET 4032). All the code is being done in 6502 Assembly language. For those not familiar with the PET, all the graphics are character-based and to build games you move different characters around a 40 column x 25-row screen. This is very old tech - there are no sprites, no graphics layers, no ability to AND at the screen level, etc that we would be used to today.
I want the game to have multiple "laser beams" to be fired at the same time, and those laser beams might go on top of one another as they traverse the screen. Right now, as the beams move along the screen they store in memory what was underneath themselves and then replace what was underneath themselves as they move along to restore the background to its original state. The problem comes when a second laser goes on top of the first .. the first moves along and replaces the original background rather than leaving the second laser on top, then that second laser moves along and leaves artifacts of the first behind.
Is there a classic "light" algorithm or rule-set that allows multiple objects to move across one another such that the original proper things underneath are retained? I've tried different approaches (swapping backgrounds as things traverse, etc) but nothing seems to give me the correct result that I want.
It's certain an option to have each sprite keep a copy of whatever it overwrote, and have them erase themselves in the opposite order to that in which you drew them. That can't fail, but it assumes you have time for a full sprite draw and erase each frame.
You can also use a screen-sized buffer of 'is background' and 'is sprite' flags. Each time a sprite is drawn, mark its character locations as 'is sprite'. To erase all sprites iterate through the screen-sized buffer repainting the background anywhere that isn't marked 'is background'. You can keep upper and lower bounds of updated positions if iterating the whole 2000 potential slots is too great a cost.
You can also compare the differences between two such buffers to reduce flicker substantially supposing you have only one video buffer: paint the new sprites first, wherever they should go, noting them in the new buffer. Once all sprites are drawn, fill in background anywhere that the new buffer isn't marked 'is sprite' but the old is.
I would suggest:
Maintain a model of the game state that would allow you to redraw the entire screen at any time. This would include the positions and other state of all movable elements
As you update the game state between frames, accumulate a mask of all the cells that will need to be redrawn, because something in them changed or moved.
Iterate through the game elements in depth order from top to bottom, redrawing the parts of each element that are in the changed-cell mask
Remove any cell you draw from the changed-cell mask so it won't be rewritten by deeper elements.
The background will be last, and will redraw all remaining cells, leaving you with an empty mask ready for the next frame.
This procedure avoids any flicker that would be caused by undrawing anything you draw in a single frame.
Various indexing structures can be added to the changed cell mask to avoid unnecessary drawing work. What kinds of optimizations are appropriate here depend on your game. If the background is mostly static, for example, then it would be useful to add the coordinates of each changed cell to a list during the update, and then only check those cells during the background redraw. Or you could do this based on the previous positions of all movable elements... up 2 you.
If the majority of the scene changes in every frame, then you can skip the mask accumulation and just start with a full screen mask... although I think a PET might not be fast enough for such games.
Having never programmed for the Pet, I can't offer any specific advice about what you might try, but I can recommend keeping a copy of the current on-screen background in about 1k of RAM. That way, you can use that data to restore your background when removing the last "sprite" written to that tile. Unfortunately, that also requires you to keep your code and object data combined under 31k, unless you are programming this as a cartridge. Just a few thoughts, for what they're worth.
I am playing around with http://boost-experimental.github.io/msm-lite/tutorial/index.html (tag is for boost-msm because there is not tag for msm-lite but similar question applies) and I have a question wrt designing state machines with many possible inputs.
Imagine you are modelling elevator. Beside obvious states like moving, stopped, door_open, door_closed I wonder how to model button pressed(that is a number from -2 to 39) since it is not feasible to have that many events(42 just for every button pressed).
I guess if you design a floor selection with 42 buttons you would probably not map them each to a single input, but make a matrix (nobody will put 42 buttons on top of each other, would one?). Then of course you would not model each row an column but only two so you can show the sequential polling of each row column. Maybe you could also use "intelligent" buttons today that have a microchip which sends some "I have been pressed" information a serial line. Or you introduce a voice recognition.
Having listed those few examples, I tend to close this question as simply too broad.
You can use guard conditions on transitions. They look like [currentFloor != requested floor]. Perhaps a better way is to model events like upper floor selected, lower floor selected, current floor selected. That collapses 42 buttons into three categories rather neatly.
I'm wondering about how the NES displays its graphical muscle. I've researched stuff online and read through it, but I'm wondering about one last thing: Nametables.
Basically, from what I've read, each 8x8 block in a NES nametable points to a location in the pattern table, which holds graphic memory. In addition, the nametable also has an attribute table which sets a certain color palette for each 16x16 block. They're linked up together like this:
(assuming 16 8x8 blocks)
Nametable, with A B C D = pointers to sprite data:
ABBB
CDCC
DDDD
DDDD
Attribute table, with 1 2 3 = pointers to color palette data, with < referencing value to the left, ^ above, and ' to the left and above:
1<2<
^'^'
3<3<
^'^'
So, in the example above, the blocks would be colored as so
1A 1B 2B 2B
1C 1D 2C 2C
3D 3D 3D 3D
3D 3D 3D 3D
Now, if I have this on a fixed screen - it works great! Because the NES resolution is 256x240 pixels. Now, how do these tables get adjusted for scrolling?
Because Nametable 0 can scroll into Nametable 1, and if you keep scrolling Nametable 0 will wrap around again. That I get. But what I don't get is how to scroll the attribute table wraps around as well. From what I've read online, the 16x16 blocks it assigns attributes for will cause color distortions on the edge tiles of the screen (as seen when you scroll left to right and vice-versa in SMB3).
The concern I have is that I understand how to scroll the nametables, but how do you scroll the attribute table? For intsance, if I have a green block on the left side of the screen, moving the screen to right should in theory cause the tiles to the right to be green as well until they move more into frame, to which they'll revert to their normal colors.
~~~~EDIT:
I do want to point out that I know about the scanlines, X and Y. This thought just ran through my mind.
Let's say I'm at scanline Y of 10. That means I'm reading 10 values into my nametables, horizontally. That would mean my first column is off of the screen, as it only has pixel width of 8. However, the color attribute stays, since it has width of 16.
Assuming the color attribute for the entire column is green, would I be correct in assuming that to the user, the first 6 pixels on the left of the screen would be colored green, and the rightmost 10 on the screen should be green as well?
So, would I be correct in my assumption that according to the screen, the left?
This site I'm sure you are already very, very familiar with. I will preface this by saying I never got to program for the NES, but I am very experienced with all the Gameboy hardware that was ever released and the NES shares many, ahh quirks with the GB/DMG. I going to bet that you either need to do one of a few things:
Don't scroll the attribute table. Make sure that your levels all have similiar color blocks along the direction you are moving. I'd guess that many first generation games did this.
Go ahead and allow limited attribute scrolling - just make sure that the areas where the changes are occuring are either partially color shared or sparce enough that the change isn't going to be noticable.
Get out your old skool atari 2600 timer and time a write to register $2006 in the end of HBlank update to get the color swap you need done, wait a few tics, then revert during the HBlank return period so that the left edge of the next line isn't affected. I have a feeling this is the solution used most often, but without a really good emulator and patience, it will be a pain in the butt. It will also eat a bit into your overall CPU usage as you have to wait around in interrupts on multiple scan lines to get your effect done.
I wish I had a more concrete answer for you, but this hopefully helps a bit. Thanks goodness the GB/DMG had a slightly more advanced scrolling system. :)
Both Super Mario Bros. 3 and Kirby's Adventure display coloring artifacts on the edge of the screen when you scroll. I believe both games set the bit that blanks the left 8 pixels of the screen, so 0-8 pixels will be affected on any one frame.
If I remember correctly, Kirby's Adventure always tries to put the color-glitched columns on the side of the screen that is scrolling off to make it less noticeable. I don't think these artifacts are preventable without switching to vertical mirroring, which introduces difficulties of its own.
Disclaimer: it's been like five years since I wrote any NES code.
Each nametable has its own attribute table, so there should be no graphical artifacts when scrolling from one nametable to another. The type of color glitching you are referring to is really only an issue if your game scrolls both vertically and horizontally. You only have two nametables, so scrolling both ways requires you to cannibalize the visible screen. There are various solutions to this problem, a great summary of which can be found in this nesdev post:
http://nesdev.parodius.com/bbs/viewtopic.php?p=58509#58509
This site may be of some help.
http://www.games4nintendo.com/nes/faq.php#4
(Search for "What's up with $2005/2006?" and begin reading around that area.)
It basically looks like its impossible to get it pixel perfect, however those are going to be the bits you're probably going to need to look into.
Wish I could be more help.
Each nametable has its own attribute table. If you limit your game world to just two screens, you'll only need to write the nametables and attribute tables once. The hard part comes when you try to make worlds larger than two screens. Super Mario Bros. 1 did this by scrolling to the right, wrapping around as necessary, and rendering the level one column of blocks at a time (16 pixels) just before that column came into view. I don't know how one would code this efficiently (keep in mind you only have a millisecond of vblank time).
I need to make a Java component that turns the background a certain colour when a process passed, and another colour when the process failed.
My first thought was: green for success, red for failure.
But then I read that 10% of males can't differentiate between these two colours. What would be a better combination of colours?
(For the nitpickers: yes, I know that colour alone doesn't suffice, that text, shape, and noise can also be used. Nevertheless I am asking about the appropriate use of colour.)
Red + x = Failure
Green + checkmark = Success
I think you've answered this yourself. Use green/red in addition to text. Most people will understand green/red. If you change it to blue/yellow, the 90% who see green/red will be confused. Stick w/ the convention and add text to help the 10% who can't see green/red.
Remember that these "obvious" color associations (green=good, red=bad) are culturally variant. Thus, not relying on only the color is a very good idea.
Use color and sign. Green with a "+" and Red with a "-", This way people that can't see color will understand.
If it's background color of grid line, to solve the problem, add a column called "State" and use an Icon + or -.
In my opinion the best way to go about this is to use a mix of colour and icon/text.
For example, when I have errors on my form I do the following:
Provide a text header on the top of the form stating something ala: "Oops, there was some issues with your submissions: Last name was not filled in, etc.."
On each error field, I highlight the background of the box pink and modify the border. Not only does it change the colour, it also puts a subtle, but noticeable focus on the error field.
Finally, depending on the site and amount of space I have I append a little "warning" icon with a small message after that field.
With all those 3 combined, the error form is easy to read and hard to miss what's going on for all people.
As a person with Red/Green colorblindness, I can easily tell the difference between the two colors in their "pure" form. The issue is that red tends to look "washed out" -- more of a brown and greens/yellows merge together. Of the 8% of males who are colorblind, I do believe that very few are completely unable to differentiate between pure Red and pure Green. The issue is that the exact color of the sweater I'm wearing or the Autumn leaves can be difficult and confusing. In addition, I DO have a hard time with any LEDs and particularly traffic lights; they can be confusing mainly because I've become more tied to the relative brightness than the hue and some signals vary dramatically in brightness.
Maybe a visual representation of a traffic light? In a neutral state, all three lights are greyed out, although still discernible by colour. In a "green" state, the green light is brighter, and the contrast between the background and the light is increased. Same for the red-light state.
I have to admit that
I don't know if the red-amber-green configuration of UK traffic lights is a worldwide standard that would not be open to interpretation, and
Whether the contrast between the light on and light off states would be enough for a visually impaired user to differentiate between them.
Just an idea...
We generally implement it like this:
We have written 2 common functions in which
we format the string with {0} for error fmsg and green for success.
So instead of using 2 different labels for error (red) and success (green) msgs you can use one single label and control the msgs and their type (success and error) on server side code itself.
But since , ppl for color blindness : use images X for error with the same above way to implement or even orange for error and blue for success is also a good option.
Don't use pure red and green. On safety devices such as traffic lights, the red is actually a red and orange mixture. If I remember correctly the green is also mixed with a little yellow.
It still would be a good idea to use a secondary method to indicate success/failure in addition to color. This can be text, a symbol, or something that attracts attention such as have the red failure back ground be an alternating color that flashes instead of being static. For example alternating the red with yellow.
To be honest, shape/position is almost always a more important solution than colour. There are aspects to colour, such as the human eye's insensitivity to blue, that mean that colour's an aid to clarity, and you can't neccessarily rely on it to be appropriate.