-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slider bodies don't show up at all on 0.10.1 on linux 64 (nouveau, GeForce GT 640) #120
Comments
Thanks for the detailed report. I'm unfortunately not familiar enough with some of these issues to provide solutions, but maybe someone else can help.
|
also, have you tried using the proprietary nVidia driver? i think this may be related... |
Did opsu! render the new slider style in 0.10.0 on your machine? Also what OpenGL version and GLSL version does your graphics card run? Might be related to #114 (940e9ba). According to my sources OpenGL version 3.3 is required for GLSL 330, also this fixed the issue for me, where in 0.10.0 the sliders bodies didn't render at all. |
@itdelatrisu nah, reverting that won't do anything. The issue is in the logs, the drivers don't support GLSL 3.30. I'll look into which version I actually need since the shaders really aren't that complex. |
Tested with a machine with an i3 M380 and GeForce 310M, same results, even with nouveau blacklisted. Tested with that 310M machine with nvidia's proprietary drivers, sliders look different, this is the new style? not reproducible on an eeepc with Intel Atom N270 (i686) and its integrated graphics (945GSE) Opsu runs surprisingly well on that eeepc, only lagging noticeably when doing a long slider. (0.10.1, renders old slider style) |
Any updates on the slider rendering after merging #122? |
I'm sorry that testing this took so long! I had never compiled java before and I kinda forgot this for a while after it didn't succeed the first time I tried it. same results with openjdk 1.7.0_79 and 1.8.0_66. This cursor thing, by the way. I only had cursor.png (like all older skins, no cursormiddle.png) in that skin and the default cursormiddle got drawn on my cursor. If I put a cursormiddle there, it replaces the default one. Is this intended behavior not to use the skin's cursor at all with this in "No"? Frame rate seems to stay at monitor's refresh rate plus one with nouveau if the Frame Limiter >= monitor's refresh rate (I can't get more than 61 on my LCD or more than 86 on my CRT, putting the limit of 60 on the CRT makes it stay at 61, too). Maybe this is just a thing nouveau does. EDIT: an example with all cursor.png, cursormiddle.png and cursor2.png present: |
Also fixed an issue where songMenu.resetGameDataOnLoad() sometimes wasn't being called when it should be (e.g. after playing a beatmap, if you move to a different screen, your score won't appear in the song menu right away). It's now being called more often than necessary, but that should be fine. Signed-off-by: Jeffrey Han <itdelatrisu@gmail.com>
Previously, enabling old-style cursors would try to load files "cursor2" and "cursortrail2". Now the actual files are loaded, and the -2 images are only used when no game skin image is provided. Added a hasGameSkinImage() method in GameImage to check if the "default" image is skinned (by a game skin). Signed-off-by: Jeffrey Han <itdelatrisu@gmail.com>
Sorry for the late reply, and thanks for providing so many details again! The cursor2/cursortrail2 was sort of a hack to begin with, and I totally forgot to account for it when implementing game skins. It should be fixed in 5efb61d -- if you use a non-default skin, the files "cursor" and "cursortrail" will always be loaded, and the "-2" files will only be used if the original files are absent and "Enable New Cursor" is disabled. (I know the last part is not a part of osu!, but I don't think it hurts.) Also, after ae5016f, the game shouldn't crash anymore if you try to play a track that doesn't exist. The game should throw reasonable warnings if this happens in the song menu, and the music file should be locked when it's currently playing so this shouldn't happen elsewhere. I didn't test this extensively though, so let me know if there are still problems with it. |
This also catches more MP3 loading errors that could occur and properly cleans up resources. Signed-off-by: Jeffrey Han <itdelatrisu@gmail.com>
Okay, let me know if 20d40dd solves the remaining issue with the misnamed MP3/OGG files. I couldn't reproduce the problems you had (lag/high CPU/"Failed to destroy OpenAL") because I received null pointer exceptions immediately when playing any OGG with a .mp3 extension. If you still run into the same issue (or different ones), also tell me which beatmap it happens with. Thanks! |
Closing for now. Please re-open if this didn't fix the problem. |
The issue is NOT present on 0.10.0
tested with 64bit:
openjdk 1.8.0_66
openjdk 1.7.0_79
oracle java 1.8.0_51
Also, this cursor: doesn't look like itself at all on any version of opsu I've tried on linux, it's always like this (there are no artifacts in the image, it always has that square around it)
This is tested on multiple computers, including 32b ones.
A minor thing I noticed too: if a beatmap with ogg music named *.mp3 (osu plays it normally) is selected, opsu loses sound and gets very laggy, java stays 100% usage on a single core and a "Failed to destroy OpenAL" exception gets thrown every time opsu tries to load another song. This is also tested with the versions above.
.opsu.log after doing all the tests (gzipped 5415 B):
http://54.213.154.174:777/B/.opsu.log%202015-08-13%2002:45:45.gz
Opsu crashes in the end when I move the beatmap dir in question away from Songs while running with oracle java.
The text was updated successfully, but these errors were encountered: