Alternate method for brightmaps?

Moderator: Graf Zahl

Locked
User avatar
BetaSword
Posts: 132
Joined: Thu Sep 01, 2005 0:01

Alternate method for brightmaps?

Post by BetaSword »

Basically, I'm requesting an alternate way for brightmaps to be rendered, besides using shaders for them. Besides the fact that they don't work in the software renderer as is, they also don't work on my current computer of choice, as it has an Intel GM915, or whatever it is that sounds close to that. Can't remember off the top of my head.

I realize this is more of an unnecessary feature to request, and it is probably more than a bit selfish. But personally, having to copy wads over to a flash drive, and plug them into another computer, just to test brightmaps on a level, is slightly annoying. I'm also of the belief that, used properly, bright maps could be used to add a decent amount of atmosphere as well, and if someone's playing on a computer that doesn't support shaders, then they'd be out of luck for that.

Course, I guess that's what I get for mapping on an eeePC. :P
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Post by Graf Zahl »

Sorry, but it can't be done properly without shaders. And as you said, it's more than a bit selfish. Your graphics card must be relatively old and to be honest, the money you had to pay me to implement this is more than a new low end card would cost. :mrgreen:
CSonicGo
Posts: 39
Joined: Sun Apr 02, 2006 3:35

Re: Alternate method for brightmaps?

Post by CSonicGo »

I did a quick search on these forums and was quite expected that this was known since last year.

the main issue I have with this is that this chipset *does* have support for shaders, and it has support for GLSL. Problem is, GZDoom is not seeing it. The odd coincidence that other software doesn't have a problem wiht this is anyone's guess. Let's try Sauerbraten for example.

Image
Above: No shaders here, no-siree

So either gzdoom doesn't know how to deal with the GM915, or the shader support in GZDoom is less than stellar. Ive read some other posts saying that you are aware of this, calling it a "hack" and that the new renderer you are planning should resolve some of this. I can only hope that is the case.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Alternate method for brightmaps?

Post by Graf Zahl »

How about the driver is crap?

If the driver does not tell me that it supports GLSL I can't do anything about it. Can you post the entire startup log of this card?

BTW, the requirements for the new renderer are a lot more steep than the old one. I at least require GL 2.1 and a few additional extensions to even start it.
John Smith
Posts: 1
Joined: Sun Aug 09, 2009 7:13

Re: Alternate method for brightmaps?

Post by John Smith »

Graf Zahl wrote:BTW, the requirements for the new renderer are a lot more steep than the old one. I at least require GL 2.1 and a few additional extensions to even start it.
Ok so people with a video card more than about 3-4 years old, and probably most ATI users, can just fuck off right? Seriously are you making a doom port or the sequel to Crysis.
CSonicGo
Posts: 39
Joined: Sun Apr 02, 2006 3:35

Re: Alternate method for brightmaps?

Post by CSonicGo »

here's what GLInfo tells me. I can't nab the output from gzdoom just yet, but when I do I will post it.

Code: Select all

Renderer: Intel 915GM
Vendor: Intel
Memory: 64 MB
Version: 1.4.0 - Build 7.14.10.4764
Shading language version: ERROR, assuming 1.0


Max texture size: 2048 x 2048
Max texture coordinates: 8
Max vertex texture image units: 1
Max texture image units: 16
Max geometry texture units: 1
Max anisotropic filtering value: 4
Max number of light sources: 16
Max viewport size: 2048 x 2048
Max uniform vertex components: 0
Max uniform fragment components: 0
Max geometry uniform components: 0
Max varying floats: 0
Max samples: 0
Max draw buffers: 0


Extensions: 52

GL_3DFX_texture_compression_FXT1
GL_ARB_depth_texture
GL_ARB_fragment_program
GL_ARB_multitexture
GL_ARB_point_parameters
GL_ARB_shadow
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar
GL_ARB_texture_env_dot3
GL_ARB_transpose_matrix
GL_ARB_vertex_buffer_object
GL_ARB_vertex_program
GL_ARB_window_pos
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_func_separate
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_clip_volume_hint
GL_EXT_compiled_vertex_array
GL_EXT_cull_vertex
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_EXT_multi_draw_arrays
GL_EXT_packed_pixels
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_shadow_funcs
GL_EXT_stencil_two_side
GL_EXT_stencil_wrap
GL_EXT_texture3D
GL_EXT_texture_compression_s3tc
GL_EXT_texture_env_add
GL_EXT_texture_env_combine
GL_EXT_texture_filter_anisotropic
GL_IBM_texture_mirrored_repeat
GL_NV_blend_square
GL_NV_texgen_reflection
GL_SGIS_generate_mipmap
GL_WIN_swap_hint
WGL_ARB_buffer_region
WGL_ARB_extensions_string
WGL_ARB_make_current_read
WGL_ARB_pbuffer
WGL_ARB_pixel_format
WGL_EXT_swap_control
Hope that helps or something

But still, opengl 2.1? Is that a little overboard? Surely there's a better way than relying solely on GLSL.
CSonicGo
Posts: 39
Joined: Sun Apr 02, 2006 3:35

Re: Alternate method for brightmaps?

Post by CSonicGo »

oh here we are! this might help

Code: Select all

GL_VENDOR: Intel
GL_RENDERER: Intel 915GM
GL_VERSION: 1.4.0 - Build 7.14.10.4764
GL_EXTENSIONS: GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_multitexture GL_ARB_point_parameters GL_ARB_shadow GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_env_crossbar GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_cull_vertex GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture_compression_s3tc GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_filter_anisotropic GL_EXT_texture3D GL_3DFX_texture_compression_FXT1 GL_IBM_texture_mirrored_repeat GL_NV_blend_square GL_NV_texgen_reflection GL_SGIS_generate_mipmap GL_WIN_swap_hint 
WGL_EXTENSIONS: WGL_ARB_buffer_region WGL_ARB_extensions_string WGL_ARB_make_current_read WGL_ARB_pixel_format WGL_ARB_pbuffer WGL_EXT_swap_control 
Resolution: 1024 x 600
Probably won't change a damned thing but I am known to be optimistic
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Alternate method for brightmaps?

Post by Graf Zahl »

As expected: No GLSL extensions are reported. It does support assembly shaders but that's not enough.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Alternate method for brightmaps?

Post by Graf Zahl »

CSonicGo wrote: But still, opengl 2.1? Is that a little overboard? Surely there's a better way than relying solely on GLSL.

That's where the old renderer comes in. It will continue to work on older cards.

But I absolutely see no point in investing time in something that has to compromise all the way just to work on old hardware. The new renderer is meant to better exploit the capabilities of modern hardware. It uses shaders for everything and completely circumvents the old fixed function pipeline which is the root of all the problems that have crept into the rendering code. The new renderer uses a much leaner system interface because it doesn't have to bother with all the cruft that is needed to render both with shaders and with the hard coded functionality of old cards. This alone should make it faster.

On the other hand, if I had to code everything with compatibility fallbacks in mind it'd go nowhere. I rather keep the old code around, stripped off all shader support so that the end result will essentially 2 rendering paths - the current one for old hardware and the new one for new hardware.

So the system requirements are:

- OpenGL 2.1
- full GLSL support
- full vertex buffer and texture buffer object support.

If I wouldn't set these minimum requirements the entire rewrite would be an exercise in pointlessness.

That means Geforce 8xxx series or better and modern ATI cards only.
Everything else will fall back to the existing rendering code - but will also obviously miss out on future enhancements.
Locked

Return to “Closed Feature Suggestions”