I have a composition with a facebook message, it lasts for 10 seconds.
I dont have aly slider to change the duration of the beginning\edning neither can I change the overall duration of it. There is no code representing that. I couldnt find any parameter to change the duration...
Is there any way to change it. Because otherwise all these extensions packs with presets are useless if Im tied tightly to timing
From the description I'm not 100% sure of the composition setup you are going for.
However, in similar situations I've found that precomposing all of the layers can help. This would mean selecting all the layers you'd like to include, right click, precompose.
You can then change the in/out points of the composition as a whole.
Related
I am using the latest swiftui and would like to know if it is possible to create drag & drop boundaries based on color?
I already created a drag & drop with rotation, pinching, etc. But would like to be able to create regions where you can drop into.
Thanks
Yes it is! It's a great idea, and I think you should pursue it.
As it stands there's a hundred different ways to go about things. Spend some time thinking about how you would want it to work, then just take baby steps. You've already covered a lot of the ground work by implementing rotation and pinching.
Write some code (in a playground so you get instant feedback) that does some simple drag and drop work. Add in a line of code that turns the background a different color or changes its opacity when you let go/lift your finger.
Those types of incremental changes are well documented and you will be able to google them quickly. I think it's a great sign that you haven't found ready made examples. It means you are thinking outside the box.
This is an opportunity for you to think like a developer and a designer. If you post your results somewhere or release a project on GitHub at some point, others will be able to find your work using the same search criteria you used when you didn't find any results.
If you get stuck, post the code the code that has you baffled, and I'm sure you get help on this site. Best of luck 🍀
I cant wrap my head around properly creating a responsive design using foundation 5 when dealing with grid systems.
Is it imperative that everything be set the column width using the grid system?
To be more clear, does every element on the page require a number of columns for each width (small, medium, large) for the site to be considered truly responsive? Or is it sufficient to set width in % and ems and simple explicit media queries to achieve that goal?
I don't know anything about Foundation 5, but in principle, no, you do not even need a grid system at all to be responsive. As you rightly suspected, media queries used to rearrange the elements you want to move for different size screens will make any page responsive. And yes, set things in em units or %ages - especially the media query breakpoints.
Grids are of use if your page content naturally needs to be displayed in a grid like fashion.
By the way, you would probably have had an answer much earlier if you had tagged it correctly. Responsive design makes it a CSS question, so it needs a CSS tag! I just happened to see this because I was searching for something else.
I'm currently working on a C++/SDL/OpenGL game. I've already made a few small games, but only local ones (no netcode). So I know how to make the engine, but I'm unsure about the netcode.
Can I firstly create the full engine for split-screen play and later on add the netcode or will this make everything complicated? Do I already have to take netcode into consideration while programming the basic game engine or is it also okay to just put it on top of the game after it runs fine on one machine?
It's a 2D shooter type game, if that matters. And no, I don't like to change my choice of programming language/window manager/api because I already implemented the bare bones of the game. I'm just curous how this issue is approached best.
In theory, all you need is a good enough design. Write enough abstract classes and BAM! you can pop out one user interface (i.e. local-only) for another one (networked). I wouldn't believe the theory, though.
It's possible to do what you want, but it involves taking into consideration all of the new issues you address when dealing with networked gameplay - syncing views for multiple users, what to do when one user drops their network link (how to detect when one user drops their network link, of course), network latency in receiving user input, handling lag on one side and not the other. Networked programming is completely different, and some of the aspects (largely ones dealing with synchronization) may impact your core engine itself. Even "just showing two views" gets a lot tougher, because you now have data on two completely different machines, and the data isn't necessarily the same.
My suggestion would be to do the opposite of what you're hoping for. Get the networking code working first with minimal graphics. In fact, console messages will be far more important than pretty graphics. You already have experience with making the graphics of other games - work the most questionable technology first. Get a good feel of all the things the networked code will ask of you, then focus on the graphics afterwards.
Normally for a network oriented game there are five concepts too keep in mind:
events
dispatcher
synchronization
rendering
simulation
Events. A game engine is a event software, that means over a state of each generic object in the game (can be a unit, GUI, etc), you do an action, that means, you call a function or do nothing.
Dispatcher take each event change and dispatch that change to another subsystem.
Synchronization means that over a change of event, all clients in network must be advised throw his dispatcher over that change, in this way all players can see the changes of other players, render and simulate same things at same time.
Rendering The render read parameters and relevant states for each object and draw in screen. For example, is you have a property for each unit named life_points, you can draw a normal unit if life_points>50 and a damage unit if life_point>0 and life_point<50 and a destroyed unit if life_point=0. Render dont make changes in objects, just draw what read from them.
Simulation read every object and perform some task taking on count states and properties, for example, if you have cero point of life, you mark the state of a unit as DEAD (for example) or change de GUI, or if a unit get close to another of a enemy team, you change the state from static to move moving close to that another unit. Plus this, here you make the physics of units, changing positions, rotations, etc etc... as you have all objects synchronized over network, everybody will be watching the same thing.
Best regards.
Add in netcode as soon as you can. If you don't do this you may have to overhaul a lot of the engine later in the dev cycle, so better to do it early.
It also depends on how complex the game is, but the same principles still stand. Best not to tack it on at the last second
Hope this helps!
This question is a refinement of my question Different ways of observing data changes.
I still have a lot of classes in my C++ application, which are updated (or could be updated) frequently in complex mathematical routines and in complex pieces of business logic.
If I go for the 'observer' approach, and send out notifications every time a value of an instance is changed, I have 2 big risks:
sending out the notifications itself may slow down the applications seriously
if user interface elements need to be updated by the change, they are updated with every change, resulting in e.g. screens being updated thousends of times while some piece of business logic is executing
Some problems may be solved by adding buffering-mechanisms (where you send out notifications when you are going to start with an algorith, and when the algorithm is finished), but since the business logic may be executed on many places in the software, we end up adding buffering almost everywhere, after every possible action chosen in the menu.
Instead of the 'observer' aproach, I could also use the 'mark-dirty' approach, only marking the instances that have been altered, and at the end of the action telling the user interface that it should update itself.
Again, business logic may be executed from everywhere within the application, so in practice we may have to add an extra call (telling all windows they should update themselves) after almost every action executed by the user.
Both approaches seem to have similar, but opposite disadvantages:
With the 'observer' approach we have the risk of updating the user-interface too many times
With the 'mark-dirty' approach we have the risk of not updating the user-interface at all
Both disadvantages could be solved by embedding every application action within additional logic (for observers: sending out start-end notifications, for mark-dirty: sending out update-yourself notifications).
Notice that in non-windowing applications this is probably not a problem. You could e.g. use the mark-dirty approach and only if some calculation needs the data, it may need to do some extra processing in case the data is dirty (this is a kind of caching approach).
However, for windowing applications, there is no signal that the user is 'looking at your screen' and that the windows should be updated. So there is no real good moment where you have to look at the dirty-data (although you could do some tricks with focus-events).
What is a good solution to solve this problem? And how have you solved problems like this in your application?
Notice that I don't want to introduce windowing techniques in the calculation/datamodel part of my application. If windowing techniques are needed to solve this problem, it must only be used in the user-interface part of my application.
Any idea?
An approach I used was with a large windows app a few years back was to use WM_KICKIDLE. All things that are update-able utilise a abstract base class called IdleTarget. An IdleTargetManager then intercepts the KICKIDLE messages and calls the update on a list of registered clients. In your instance you could create a list of specific targets to update but I found the list of registered clients enough.
The only gotcha I hit was with a realtime graph. Using just the kick idle message it would spike the CPU to 100% due to constant updating of the graph. Use a timer to sleep until the next refresh solved that problem.
If you need more assistance - I am available at reasonable rates...:-)
Another point I was thinking about.
If you are overwhelmed by the number of events generated, and possibly the extra-work it is causing, you may have a two phases approach:
Do the work
Commit
where notifications are only sent on commit.
It does have the disadvantage of forcing to rewrite some code...
You could use the observer pattern with coalescing. It might be a little ugly to implement in C++, though. It would look something like this:
m_observerList.beginCoalescing();
m_observerList.notify();
m_observerList.notify();
m_observerList.notify();
m_observerList.endCoalescing(); //observers are notified here, only once
So even though you call notify three times, the observers aren't actually notified until endCoalescing when the observers are only notified once.
I´m looking to implement a way to avoid the user taking a screenshot from one desktop application. Yes, this seems to be weird asking for that, but we need it. I tried to use OpenGL (SDL_tff) to render the text, but it seems that doesn't stop the user from taking the screenshot. Please, does anybody have some clever idea about how to do it?
Render it to video and use a hardware overlay. those are much more difficult to capture since they are technically never rendered to the screen like other apps. It goes directly to the hardware and displays through the graphics card, bypassing normal screen shot domain.
It is still grab-able though.
personally, i'd take a high res photo and run it through a img2txt converter :D
Edit: check out http://www.gamedev.net/community/forums/topic.asp?topic_id=359319 , they seem to have an example, and it specifically states how a "screenshot" of the effect is kinda silly.
As I mentioned in my comment, you can't stop the user from taking a screenshot.
There might be a few things you can do to make it a bit more difficult though, and maybe deter less knowledgeable or driven individuals from taking a screenshot.
A suggestion: you might want to watch for key combinations that are often used for taking screenshots, then briefly hide your text. It may get the behavior that it seems you are looking for: allowing the user to take a screenshot without showing the text.
Another alternative is to provide a very easy and obvious way to let the application take the screenshot FOR the user, without saving the text. This might be useful in the case that you aren't trying to make the text "impossible" to capture, but rather that the user would prefer the screenshots to be text-free.
It's not clear from your question what the motivation behind your request is. If you just would like to have "prettier" screenshots without text, this shouldn't be a hard problem to solve: just do as I mentioned before and provide a built-in mechanism for saving "clean" screenshots.
Just remember that if the user DOES want to save that text, you cannot stop them from doing it.
You cannot accomplish what you want. What you want is, in fact, nonsensical.
Even if you find some clever way to stop them doing it with their computer,
using a good quality digital camera to take a picture of their monitor provides
a remarkably good quality screenshot.
Don't forget to add VM detection routines so you can disable display if you discover you're running under a virtual machine. That way they can't take a screenshot of the VM window.
Unless they modify an open VM to remove that sort of easy tell-tale, in which case you'll have to use something stronger.