Blurry fonts in GLES1 mode

[IMbackK]

When running in GLES1 mode, 2d elements are rendered in very low resolution and then bilinar scaled see image below. tested at git commit 2331440 with mesa llvmpipe and PVR SGX DDK 1.17 @ 960x454 resolution in windowed mode.

[parasti]

What is GLES1 mode? On what platform does this happen? How was the game compiled? How did you arrive at that resolution (default windowed resolution is 800x600)? Does this happen if you delete the ~/.neverball folder? All of these things are relevant here.

[IMbackK]

hi @parasti

1. its compiled with GLES1 enabled this forces it to use a GLES1 context see

   neverball/share/video.c

   Line 241 in b7c23cb

   SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);

2. it was compile by me for armhf on on Debian buster but against a recent git of mesa, but the problem persists with stable mesa (and SGX too so its not the opengles driver).
3. deleting the folder has no effect
4. it arrives at this resolution because that is the resolution of the panel attached to this machine, (its a motorola droid 4 running linux 5.15 & debian buster)

[IMbackK]

i can also affirm that rasing the resolution to 800x600 dosent help any while building for opengl makes the fonts work fine at 960x454 (on llvmpipe, the machine dosent have a gpu that can do desktop gl)

[parasti]

Can you check the parent commit of this: 36033d5 What are the differences, if any?

It might also help to see the console output of neverball.

[IMbackK]

sure heres the output with llvmpipe, ill test the commit in a sec:

FS: reading from "/usr/share/games/neverball" (directory)
FS: writing to "/home/user/.neverball-dev"
FS: reading from "/home/user/.neverball-dev" (directory)
ATTENTION: default value of option vblank_mode overridden by environment.
Creating a window (960x484, windowed)
ATTENTION: default value of option vblank_mode overridden by environment.
GL vendor: Mesa/X.org
GL renderer: llvmpipe (LLVM 8.0.1, 128 bits)
GL version: OpenGL ES-CM 1.1 Mesa 21.2.5
GL extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_lod_bias GL_OES_byte_coordinates GL_OES_fixed_point GL_OES_stencil_wrap GL_OES_compressed_paletted_texture GL_OES_query_matrix GL_OES_read_format GL_OES_single_precision GL_EXT_texture_compression_dxt1 GL_OES_draw_texture GL_OES_point_size_array GL_OES_point_sprite GL_EXT_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_framebuffer_object GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_stencil8 GL_OES_texture_env_crossbar GL_OES_texture_mirrored_repeat GL_OES_texture_npot GL_OES_EGL_image GL_OES_packed_depth_stencil GL_OES_texture_cube_map GL_APPLE_texture_max_level GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_OES_blend_equation_separate GL_OES_blend_func_separate GL_OES_blend_subtract GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_array_object GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_EXT_map_buffer_range GL_KHR_debug GL_OES_required_internalformat GL_OES_surfaceless_context GL_EXT_compressed_ETC1_RGB8_sub_texture GL_EXT_polygon_offset_clamp GL_KHR_no_error 
Failed to load texture "mtrl/default"
Size change event (2, 960x484)
Resize event (2, 960x484)

[parasti]

Another thing might be checking if SDL2 is returning good values. Again on the latest commit, you could add a debug print after this line:

neverball/share/video.c

Line 154 in b7c23cb

SDL_GL_GetDrawableSize(window, &video.device_w, &video.device_h);

Something like this:

log_printf("Drawable size: %d x %d\n", video.device_w, video.device_h);

That will show in the output.

[IMbackK]

i havent checked this but this must be fine, as all the 3d elements are rendered at the right size, oly the 2d elements / fonts are rendered wrong

[parasti]

Hard to say from the screenshot, because the 3D is all black, but fine. Then it must be a GUI scaling problem, but only on GLES. Hmm. I'm out of ideas for now.

[IMbackK]

in a level everything is fine (except gui/hud) im compilling the commit rn, will take a while i have to do it on device (cross compile failes, maybe my fault)

[IMbackK]

is probably just your render target size for the gui element texures

[parasti]

GUI is scaled based on the video.device_* values by gui_resize() in share/gui.c. You could add some debug prints there to cross-check.

[IMbackK]

So tried 5508e07 and this makes no difference (perhaps unsurprising, as the changes in 36033d5 would also be expected to affect 3d elements if they where the root cause.)

[parasti]

I don't know why you think that, because the most extensive changes from that commit were in the GUI code. I know this because I wrote it.

Those SDL_GL_GetDrawableSize debug prints would be helpful here.

[IMbackK]

So i figured out what the problem is. i accidentally was deleting .neverball/ when my build was using .neverball-dev/.
The problem is that in gles1 mode, the setting "textures" changes the render size for all textures, including fonts. setting this to 1 makes it work, while i had 4.

Obv this is a bug the texture setting should not affect the fonts.

[parasti]

It is not a bug. What do you think caused "textures" to be set to 4?

[IMbackK]

not sure really. if its not a bug its at least a bit unfortunate, because it makes the textures setting pretty useless

[rlk]

Fonts are textures. Thus the texture setting affects the fonts. It’s not a bug. It’s a rational and well implemented feature. It gives you a quality-space trade-off setting, so If it makes the game look bad then don’t set it.

[IMbackK]

fonts may be implemented as textures but they are special because they should be readble at all times, its not about the game looking bad, its about this setting makeing it unplayable because you cant read the text