Building Mac OS X version with XCode under Panther
Harrie,
The complier warnings you cited are just due to sloppiness on my part. One of these days I'll go through and clean them up. But I don't believe they are related to your keyboard problem.
The modifierFlags in the Event object are set by the OS input handler. If, as your test demonstrates, the main keyboard digit keys on your Powerbook are returning modifierFlags with NSNumericPadKeyMask set, then the Celestia code would be working correctly to invoke the functions assigned to the numeric keypad digit keys rather than the functions assigned to the main keyboard digit keys. If 1.3.0-a1 works differently it's probably due to a bug that's been fixed.
Perhaps Apple did this so that software which assumed the availability of a numeric keypad would work on Powerbooks using the main keyboard digit keys.
- Hank
The complier warnings you cited are just due to sloppiness on my part. One of these days I'll go through and clean them up. But I don't believe they are related to your keyboard problem.
The modifierFlags in the Event object are set by the OS input handler. If, as your test demonstrates, the main keyboard digit keys on your Powerbook are returning modifierFlags with NSNumericPadKeyMask set, then the Celestia code would be working correctly to invoke the functions assigned to the numeric keypad digit keys rather than the functions assigned to the main keyboard digit keys. If 1.3.0-a1 works differently it's probably due to a bug that's been fixed.
Perhaps Apple did this so that software which assumed the availability of a numeric keypad would work on Powerbooks using the main keyboard digit keys.
- Hank
HarrieS wrote:Ehm, shouldn't that be a single & in the NSNumericPadKeyMask test?
Ah, yes, I believe you're right! This is a problem both in 'keyDown' at 'CelestiaOpenGLView.m:146' and in 'toCelestaKey' at 'CelestiaAppCore.mm:92'. It must be fixed, of course, but I don't understand how it would produce the effect we're seeing. Does this fix correct the problem on your Powerbook?
- Hank
Yes, it does fix it. The explanation is I think as follows: the lower bits of the modifierflags are according to the Apple documentation hardware dependent. (No specification of what the bits would mean, though.) Probably one of these bits is set whenever a "small" keyboard is used. Thus,the flags are non-zero, or in C-parlance "true".
Since the NSNumericpadKeyMask is also non-zero, hence true, this always generates a "true" test when the Boolean AND is used instead of the logical AND.
My powerbook can simulate a numeric keypad, by the way, by pressing a function key while typing specific keys on the keyboard, roughly the block of keys below the 7-8-9 keys. They now generate proper keypad events.
Well, let's hope this adequately solves the problem.
Harrie
Since the NSNumericpadKeyMask is also non-zero, hence true, this always generates a "true" test when the Boolean AND is used instead of the logical AND.
My powerbook can simulate a numeric keypad, by the way, by pressing a function key while typing specific keys on the keyboard, roughly the block of keys below the 7-8-9 keys. They now generate proper keypad events.
Well, let's hope this adequately solves the problem.
Harrie
BusError,
Selden Ball's notes on "Creating Textures for Celestia" says:
Both BumpMaps and NormalMaps seem to work for me using the "NV C + ARB VP" rendering path. Using the "DOT3 + ARB VP" rendering path I see the blue/red symptom you describe. Could be a bug in the DOT3 rendering code.
- Hank
Selden Ball's notes on "Creating Textures for Celestia" says:
Code: Select all
3.2.2: Bumpmaps and Normalmaps.
Bumpmaps and Normalmaps make a surface look wrinkled.
For BumpMaps, use the directives
BumpMap
BumpHeight
For a Bumpmap, provide a grey-scale image that's white at the highest altitudes and black at the lowest. Celestia internally converts Bumpmaps into Normalmaps.
For NormalMaps, use the directive
NormalMap
For a Normalmap, provide a full color image. The R, G and B channels define the amplitudes of the surface normal vecors in the X, Y and Z directions respectively for each pixel.
In this usage, "Normal" is an abbreviation for "Surface Normal Vectors". They're the directions which are perpendicular to the wrinkled surface at each pixel's location.
Both BumpMaps and NormalMaps seem to work for me using the "NV C + ARB VP" rendering path. Using the "DOT3 + ARB VP" rendering path I see the blue/red symptom you describe. Could be a bug in the DOT3 rendering code.
- Hank
Guys,
I've just added a clarification about bump and normal maps which would seem to be relevant to this issue.
I've just added a clarification about bump and normal maps which would seem to be relevant to this issue.
Internally, Celestia converts bumpmaps into normalmaps for use by your graphics hardware. Since bumpmap images can contain only 256 height values, this may cause problems when displaying a surface at high resolution. You can provide your own NormalMap to improve on this.
Selden
pre compiled os-x
hi,
could someone make a pre-compiled version of celestia 1.3.1
available in a .dmg as some of us aren't technically minded
enough to use x-code or dont have panther.
thanks
could someone make a pre-compiled version of celestia 1.3.1
available in a .dmg as some of us aren't technically minded
enough to use x-code or dont have panther.
thanks
I've just uploaded Celestia 1.3.1 for MacOS X to SourceForge.
You can download it from here:
http://sourceforge.net/project/showfiles.php?group_id=21302&package_id=47943
- Hank
You can download it from here:
http://sourceforge.net/project/showfiles.php?group_id=21302&package_id=47943
- Hank
-
- Posts: 312
- Joined: 04.03.2002
- With us: 22 years 8 months
Fixing the rainbow problem
The_Tick wrote:I have managed to download it.
However, I have two problems :
1) Celestia apparently doesn't remember my settings
2) Mercury, Moon, Mars and Pluto are rainbow-colored[/img]
I'm seeing both of these problems too. They're things that also appeared initially with the first Cocoa release.
(1) seems to be a problem for some preferences but not others.
(2) is probably because your video card doesn't support bump maps. It can be fixed. Go into solarsys.ssc and comment out the "BumpMap" lines for the rainbowed objects by putting a pound and space before the world "BumpMap" like so:
# BumpMap "mercurybump.*"
etc.
-
- Posts: 312
- Joined: 04.03.2002
- With us: 22 years 8 months
Great job!
By the way, the few problems aside, this is an absolutely tremendous release, with a gigantic number of new features and some bug fixes. The Mac version finally fixes the long-standing orbit display bug, and the implementation of oblate atmospheres is something I've wanted to see for a long time.
I hope that the final Mac OS X release of 1.3.1 will have a prominent link on Chris's page.
I hope that the final Mac OS X release of 1.3.1 will have a prominent link on Chris's page.
Crap. I have an ATI Radeon 9000. Must be the drivers again. I should have stuck with Nvidia... Anyway, thanks, that helped.(2) is probably because your video card doesn't support bump maps
this is an absolutely tremendous release, with a gigantic number of new features and some bug fixes
I agree. I hadn't touched Celestia since 1.2.5 and I see the difference.
The_Tick wrote:Crap. I have an ATI Radeon 9000. Must be the drivers again. I should have stuck with Nvidia... Anyway, thanks, that helped.(2) is probably because your video card doesn't support bump maps
I would say that a 9000, or my 9700 Pro have to support bumpmaps! Those are not exactly rage 128.
What extension is used to make them ? Heres the list from my 9700 :
Code: Select all
ATI Radeon 9700 OpenGL Engine
Vendor Name ATI Technologies Inc.
Version 1.3 ATI-1.3.4
Renderer Name ATI Radeon 9700 OpenGL Engine
OpenGL Extensions
GL_ARB_transpose_matrix
GL_ARB_vertex_program
GL_ARB_vertex_blend
GL_ARB_window_pos
GL_EXT_multi_draw_arrays
GL_EXT_clip_volume_hint
GL_EXT_rescale_normal
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_APPLE_client_storage
GL_APPLE_specular_vector
GL_APPLE_transform_hint
GL_APPLE_packed_pixels
GL_APPLE_fence
GL_APPLE_vertex_array_object
GL_APPLE_vertex_program_evaluators
GL_APPLE_element_array
GL_APPLE_flush_render
GL_NV_texgen_reflection
GL_NV_light_max_exponent
GL_IBM_rasterpos_clip
GL_SGIS_generate_mipmap
GL_APPLE_texture_range
GL_APPLE_vertex_array_range
GL_APPLE_ycbcr_422
GL_APPLE_pixel_buffer
GL_APPLE_float_pixels
GL_ARB_depth_texture
GL_ARB_fragment_program
GL_ARB_imaging
GL_ARB_multisample
GL_ARB_multitexture
GL_ARB_shadow
GL_ARB_shadow_ambient
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_texture_mirrored_repeat
GL_ATI_blend_equation_separate
GL_ATI_blend_weighted_minmax
GL_ATI_text_fragment_shader
GL_ATI_texture_env_combine3
GL_ATI_texture_mirror_once
GL_ATI_separate_stencil
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_func_separate
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_blend_color
GL_EXT_compiled_vertex_array
GL_EXT_secondary_color
GL_EXT_stencil_wrap
GL_EXT_texture_compression_s3tc
GL_EXT_texture_env_add
GL_EXT_texture_lod_bias
GL_EXT_texture_rectangle
GL_EXT_texture_filter_anisotropic
GL_NV_blend_square
GL_SGIS_texture_edge_clamp
GL_SGIS_texture_lod
Display Mask 1 (0x00000001)
Renderer ID 137216 (0x00021800)
Off Screen No
Full Screen Yes
Hardware Accelerated Yes
Robust No
Backing Store No
MP Safe Yes
Window Yes
Multi Screen No
Compliant Yes
Screen Mask Yes
Buffer Modes 15 (0x0000000f)
Color Buffer Modes 176194560 (0x0a808400)
Accum Buffer Modes 8421376 (0x00808000)
Depth Buffer Modes 7169 (0x00001c01)
Stencil Buffer Modes 129 (0x00000081)
Max Aux Buffers 2 (0x00000002)
Total Video Memory 134217728 (0x08000000)
Total Texture Memory 124936192 (0x07726000)
Generic