CarRacing-v0 in Gym: The screen is totally black when I run the environment - opencv

I'm trying to run one of the gym environments, CarRacing, with the code from (https://gist.github.com/lmclupr/b35c89b2f8f81b443166e88b787b03ab) modified to work with the current versions of Keras etc.
And it works: that is, it starts training and, if I put a print in "action", I can see what actions it is taking at each moment.
However, the display is not as it should be (see https://www.youtube.com/watch?v=pTYOyl8To7g), but I get a big screen that is totally black, and a smaller one where the black bar moves as if it wanted to show something.
Do you know what it could be? Is this a typical problem of gym, or cv...?
PS: I don't know how it is usually done in Stack to share a more or less long code (approx. 250 lines). Tell me if necessary.

See link below
TDLR add env.render("human") to your code
https://github.com/openai/gym/issues/492

Related

Before diving in, is this possible with Awesome WM?

I've been trying different tiling WM's to see which one best fits my needs. Every time I try a new one, it looks good but I find other things that don't quite work the way I like. My requirements have evolved as I go. Initially, I didn't want to get into Awesome because having to learn Lua is not on my wish list but maybe I should give it a try IF it can do what I want better than the other tiling WM's out there.
I'm going to as specific as I can about what I want. I am running a 3440x1440 monitor. I want to use as much vertical space as possible (meaning, a full width, persistent but mostly empty status bar is not an option, but I do like the notification area and a date/time).
I understand it may not do everything exactly the way I want, which is oke. If it does more or less most of what I want I can weigh my options between Awesome and other tiling WM's (actually, only i3 which is what I'm using now but I'm open to better suggestions). I would very much appreciate it if people don't just say no to something it can't do, but say "no, but it can do ...". In other words, feel free to suggest alternatives that might be helpful as well.
Divide the screen in 3 columns, initially 30/45/25, with the right column split horizontally; Fully adjustable and resizable as needed during my work session;
Persistent layout; when closing the last application in a tile, I don't want that tile to disappear and the remaining tiles to resize. Just show an empty space and leave all tiles as they are.
tabbed tiles, so I see which applications are running in a tile (similar to i3).
Resizable tiles with the keyboard into 1 direction; When making the middle column/tile wider, I want that into a specific direction into another tile and leave the other side alone.
Certain applications I want to always launch into a specific tile. For instance, terminals always go into the right-most column top/bottom, browser/spotify always into the middle, atom/IDE always into the left. Some applications should always be floating. Obviously I want to be able to send them to a different tile after launch.
I don't want a 100% width status bar. It will be mostly empty which is a waste of screen estate. Preferably, I'd like a statusbar part of a tile, for example in the right-most tile, resizing with it. Otherwise I'd like it to be fixed to 30% and allow tiles which are not beneath it to use the full height of the screen. My reason for a statusbar is mute; I actually only want a notification area and a date time permanently visible. I don't need a "start menu", dmenu or similar is perfect, which I believe it has integrated.
Many thanks in advance!
The general answer is "Awesome configuration is code and it can do whatever you want". But there is a catch. Can Awesome be configured like you describe? Yes, totally. There is at least 2 distributions coming close enough (mine[1] and worron[2]) (at least for the tiling workflow, not the look).
The "catch" is that the workflow you describe isn't really the "Awesome way". Awesome is usually used as an automatic tiler. You have layouts that describe a workflow (code, web, internet) and manage the clients according to their programming. Manual tile management is rarely necessary once you have proper layouts. That doesn't mean you can't, I did, but it might be worth thinking outside the box and see if you can automate your workflow a bit further.
Also, the default layout system isn't very modern and makes it hard to implement the features you requested. My layout system (see link below) can be used as a module or as a branch and supports all features described above. Awesome is extremely configurable and it's components can be replaced by modules.
https://github.com/awesomeWM/awesome/pull/644
The layout "serialization" documentation is here:
https://elv13.github.io/libraries/awful.layout.html#awful.layout.suit.dynamic.manual
It is similar to i3 but has more layouts and containers. As for the "leaving blank space" part, it is configured using the fill_strategy:
https://awesomewm.org/doc/api/classes/wibox.layout.ratio.html#wibox.layout.ratio.inner_fill_strategy
As a word of conclusion, I would note that what you ask is "work exactly like i3". If you want such thing, well, use i3. Awesome is a window manager framework. Its goal and purpose is to create a customized desktop shell / WM. If it's what you want, then go ahead and learn it, nothing else can come close to the possibility and the level of control you can get out of it. However it takes time and effort to get to the point where you have "your own perfect desktop". Our users perfect desktops:
https://github.com/awesomeWM/awesome/issues/1395
[1] https://gfycat.com/SmallTerribleAdamsstaghornedbeetle
[2] https://www.youtube.com/watch?v=-yNALqST1-Y
The WM your are looking for is herbstluftwm (hlwm). Its a manual tiling window manager. The tiles which you are talking about are called frames in hlwm. Each frame can contain multiple windows. A frame can also be empty. Only if you kill a frame the other frames will automatically resize. You can add new frames vertically and horizontally and resize them. Each frame can also have a different layout to organize the windows inside. The layout you are looking for is max. This will stack the windows inside a frame on each other. It doesn't show you tabs like i3 however. hlwm allows you to create rules to open certain applications always in certain frames and workspaces. hlwm doesn't have a statusbar buildin. I personally like to use tint2. It can be used as a replacement for your requirement to see running applications as tabs.

Building for multiple screen sizes without size classes

I am currently writing an iPhone app (my first one) and never used
Size Classes
Auto Layout
Stack Views
To set the views/images/labels etc. on the screen. didn't use storyboard as well,
Every thing that is shown is coded.
I didn't start using these tools because back at the time (a couple of months ago) they seemed to be more of a pain than a true gain for my development process,
But looking back i feel i made a mistake and now I'm way too deep in code to start it all over again with the traditional/designated tools.
So, Having said that, are there any known frameworks and/or best practices to make sure that all that's printed are scaled exactly the same and have relevant ratio for each device size?
Something like: calculating the height/width ratio and somehow applying it to all the views/images etc?
is there any good way to get out of this mess?

Which is a better option for displaying irregular shapes in Swift?

let me start off by showing that I have this UIImageView set up in my ViewController:
Each one of the lines contains a UIButton for a body part. If I select a particular button, it will segue me appropriately.
What'd I like to do is, when the user taps (but doesn't release) the button, I'd like the appropriate body part to show like this:
I can achieve this using 2 options:
UIBuzierPath class to draw, but would take a lot of trial and error and many overlapping shapes per body part to get fitting nicely as similiar in a previous question: Create clickable body diagram with Swift (iOS)
Crop out the highlighted body parts from the original image and position it over the UIImageView depending on which UIButton selected. However there would only be one image per body part, but still less cumbersome then option 1.
Now, my question is not HOW to do it, but which would be a BETTER option for achieving this in terms of cpu processing and memory allocation?
In other words, I'm just concerned about my app lagging as well as taking up app size storage. I'm not concerned about how much time it takes to do it, I want to just make sure my app doesn't stutter when it tries to draw all the shapes.
Thanks.
It is very very very unlikely that either of those approaches would have any significant impact on CPU or memory. Particularly if in option 2, you just use the alpha channels of the cutout images and make them semitransparent tinted overlays. CPU/GPU-wise, neither of the approaches would drop you below the max screen refresh rate of 60fps (which is how users would notice a performance problem). Memory-wise, loading a dozen bezier paths or single-channel images into RAM should be a drop in the bucket compared to what you have available, particularly on any iOS device released in the last 5 years unless it's the Apple Watch.
Keep in mind that "premature optimization is the root of all evil". Unless you have seen performance issues or have good reason to believe they would exist, your time is probably better spent on other concerns like making the code more readable, concise, reusable, etc. See this brief section in Wikipedia on "When to Optimize": https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize
Xcode have tests functionality built in(and performance tests too), so the best way is to try both methods for one body part and compare the results.
You may find the second method to be a bit slower, but not enough to be noticed by the user and at the same time a lot more easier to implement.
For quick start on tests here.
Performance tests here.

Full width image strategy

I wanted to present the user with a screen shot of my app while it's in use, and then create a black overlay on it, and then create coach marks on the screen, similar to something like this, when the user first registers:
So I created the image and I want to make sure that no matter who uses it, it always fits nicely on their iphone4/iphone5/ipad mini/ipad, etc. What is the best approach to do this these days? Just take one giant image (make it like 1297 x 2208), add this to my asset catalog for all 3 sizes, and then just have autolayout resize it for me normally? I.e. put an imageview on the page, set it to always take up the entire screen width, and then set it's image to my giant image? Would it always resize down and look good?
Another thought that popped into my head is create lots of different images, then use all of the size classes to make the image (seems like a lot of tedious work for just a full page image so thinking this is the wrong approach).
What's the right strategy for creating a giant image that always fits? is it to go really high, and have it resize, or is it to create lots of images with different dimensions, and somehow detect which to use?
Thank you in advance!
I wouldn't take a screenshot of your image, just let the real UI show through. This lets you have some future changes to the UI w/o having to redo your "screenshotted" UI.
I'd also make different help images for each screensize, it isn't that much work and it lets you not squish or stretch your overlay.
I've also code up, but can't share the code, for a three part approach, top, middle and bottom, this way I could handle the 3.5" and 4" devices easily without stretching.

Pixel-perfect acceptance testing on iOS

I'm given exact size .png renders from Application Design showing exactly what my app should look like on Retina 4", Retina 3.5", etc.
Would like to automate a comparison between these "golden master" renders and screenshots of what the app actually looks like when that screen is shown.
Ideally I would like to have something I can run via continuous integration so I can break the build if a .xib gets messed up.
How can I do this?
Already tried:
Used Command-S in iPhone simulator to grab a screenshot suitable for comparison
Used GitHub's excellent image diff interface to manually compare the images
Pulled them up side-by-side in Preview.app, in actual size (Command-0)
Did some research on ImageMagick's comparison capabilities (examples)
Possible approaches:
Getting a screenshot of the app in code is already implemented
Similarly, I'm pretty sure I can find code to simulate a tap on the screen
Might need some way to exclude a mask or bounding box of areas known to not match exactly
Take a look at ios-snapshot-test-case, which was built for something close to this.
It will take a reference image the first time a test is run and then compare subsequent test outputs to the reference image. You could essentially use this but instead of creating reference images from the tests, you supply your own reference images.
In practice, this will be extremely tricky to do correctly. There are subtle differences in how text, gradients, etc are rendered between iOS and whatever tool your designers are using.
I'd check out KIF for functional testing.
You can create a custom test (small example near the end of the readme just above "Use with other testing frameworks") that takes a screenshot and compares it to your expected screenshot for that view. Just call failWithException:stopTest: if it doesn't match.
As you mentioned, you will want to save a mask with each expected screenshot, and apply the mask before comparing. You will always have parts of the screen that won't match, like the time in the status bar at a minimum.
For the comparison itself, here are a couple links:
Building an image mask
Slow, straightforward way to compare two images
OpenCV: I've seen this recommended, but haven't tried it.
I know this is an older question, but it's worth pointing out that KIF has built a "Perceptual Difference Testing Framework" called Lela:
https://github.com/kif-framework/Lela
If you're already using KIF this is the way to go. I believe it uses somewhat fuzzy image diffing so it may be able to get around the text rendering issues David Grandinetti mentioned. I haven't tried using it against external comps though.
If you're more comfortable with BDD/Cucumber/Gherkin syntax, you should also check out Zucchini, which uses reference images:
http://zucchiniframework.org/
I haven't used it but it's well spoken of.
I suggest you take a look at Visual CI
It's a software built for Continuous integration image compare,
It has UI that allows you to control settings which also include which parts of your image to compare
It's kind of new, but may answer your requirements better.

Resources