[C++] plasma (adapted from Clyde's BMAX code)

[hellfire]

Here one version using tinyptc_ext for MSVC 2008

Nice

The idea of my screen-lib is to stretch the output-image using hardware-acceleration.
Manual scaling reduces performance quite drastically - especially with the hd-resolutions that are common nowadays.
I usually prefer to run in display's native resolution as you never know what it's doing when changing it.
And I also like the comfort of resizing the window or moving it across screens.

I'm trying to sort out the reported problems - which is a bit tricky as eg intel-chipsets claim to support non-power-of-two-textures but actually they don't...

[Jim]

rbz's version works, and not only that it's doing real-time frame rates (20+fps, maybe more) on battery on my Intel Atom netbook (specs above) whereas the previous working version was doing about 2fps.  Is that down to the scaling?

Jim

[hellfire]

whereas the previous working version was doing about 2fps

Interessting.
That "working" version uploads a 512x256 texture and draws a single fullscreen quad (addressing a 320x240 subregion) with bilinear filtering.
I guess rbz' is uploading 640x480 using glDrawPixels; if that's significantly faster, there's apparently no hardware-acceleration on your system.

[Jim]

It runs Aero, so that means that it has PS2.0 and DirectX9.  I really should run some experiments myself...

Jim

[Rbz]

....
I guess rbz' is uploading 640x480 using glDrawPixels; ....

tinyptc_ext uses DirectDraw surface and it this case it use a 640x480 buffer.

We tried to use Opengl some time ago but we got some problems on some PC's config (slow down) and decided to use the old method that Gaffer developed for the original tinyptc.

In fact, tinyptc is one of the best know library for old school pixel coders, it work's everywhere,  and those features added in the "ext" version make it nicer to use and still making small files.

[Jim]

We have a winner!

Microsoft Corporation
GDI Generic
1.1.0
Extensions
   GL_WIN_swap_hint
   GL_EXT_bgra
   GL_EXT_paletted_texture

This is on my netbook - it doesn't hardware accelerate OpenGL at all!  Which explains why DirectDraw is better.  Wonder if that problem will get addressed with final release drivers?

Jim

Later:
I went back to the Vista driver and installed it on Windows 7.
Now I get

Intel
Intel 945GM
1.4.0 - Build 7.14.10.4906
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_lod_bias
   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_SGIS_texture_edge_clamp
   GL_SGIS_texture_lod
   GL_WIN_swap_hint

and the extended region version works brilliantly and is much faster than the ptc version.
Shame though that this driver is horrible for everything else

Jim

[Jim]

Ask and ye shall receive!  A new Windows 7 driver from Intel today with OpenGL support
Intel
Intel 945GM
1.4.0 - Build 8.15.10.1825
Extensions
   GL_EXT_blend_minmax
   GL_EXT_blend_subtract
   GL_EXT_blend_color
   GL_EXT_abgr
   GL_EXT_texture3D
   GL_EXT_clip_volume_hint
   GL_EXT_compiled_vertex_array
   GL_EXT_cull_vertex
   GL_SGIS_texture_edge_clamp
   GL_SGIS_generate_mipmap
   GL_EXT_draw_range_elements
   GL_SGIS_texture_lod
   GL_EXT_rescale_normal
   GL_EXT_packed_pixels
   GL_EXT_separate_specular_color
   GL_ARB_multitexture
   GL_EXT_texture_env_combine
   GL_EXT_bgra
   GL_EXT_blend_func_separate
   GL_EXT_secondary_color
   GL_EXT_fog_coord
   GL_EXT_texture_env_add
   GL_ARB_texture_cube_map
   GL_ARB_transpose_matrix
   GL_ARB_texture_env_add
   GL_IBM_texture_mirrored_repeat
   GL_EXT_multi_draw_arrays
   GL_NV_blend_square
   GL_ARB_texture_compression
   GL_3DFX_texture_compression_FXT1
   GL_EXT_texture_filter_anisotropic
   GL_ARB_texture_border_clamp
   GL_ARB_point_parameters
   GL_ARB_texture_env_combine
   GL_ARB_texture_env_dot3
   GL_ARB_texture_env_crossbar
   GL_EXT_texture_compression_s3tc
   GL_ARB_shadow
   GL_ARB_window_pos
   GL_EXT_shadow_funcs
   GL_EXT_stencil_wrap
   GL_ARB_vertex_program
   GL_ARB_fragment_program
   GL_EXT_stencil_two_side
   GL_ARB_vertex_buffer_object
   GL_EXT_texture_lod_bias
   GL_NV_texgen_reflection
   GL_ARB_depth_texture
   GL_WIN_swap_hint

Jim

[hellfire]

Thanks for your investigations, Jim.
I'm still a bit confused about how some hardware can run complex shaders but can not access an arbitrary-sized texture.
Probably just some strange form of economy...