Jump to content

  • Log In with Google      Sign In   
  • Create Account

Muhammad Haggag

Member Since 22 Sep 2000
Offline Last Active Oct 02 2013 06:02 AM

Topics I've Started

Electronic Arts Standard Template Library

18 May 2007 - 09:29 PM

This paper came up on programming.reddit today: Electronic Arts Standard Template Library. Abstract:
Gaming platforms and game designs place requirements on game software which differ from requirements of other platforms. Most significantly, game software requires large amounts of memory but has a limited amount to work with. Gaming software is also faced with other limitations such as weaker processor caches, weaker CPUs, and non-default memory alignment requirements. A result of this is that game software needs to be careful with its use of memory and the CPU. The C++ standard library's containers, iterators, and algorithms are potentially useful for a variety of game programming needs. However, weaknesses and omissions of the standard library prevent it from being ideal for high performance game software. Foremost among these weaknesses is the allocator model. An extended and partially redesigned replacement (EASTL) for the C++ standard library was implemented at Electronic Arts in order to resolve these weaknesses in a portable and consistent way. This paper describes game software development issues, perceived weaknesses of the current C++ standard, and the design of EASTL as a partial solution for these weaknesses.
It's a very interesting read.

[C++] DirectDraw Overlay Library

24 April 2007 - 07:46 AM

I have created a C++ overlay library based on the C++ Overlay Sample published almost a year and a half ago. It improves a number of things over the sample: 1. It works on nVidia cards, using either the YUY2 or UVYV surface formats. 2. It is packaged as a C++ library. A C++/CLI wrapper will be written as soon as I fix any outstanding issues with the native library. 3. A better sample is included, which shows how one can blit a window to the overlay. The project page can be found on Codeplex, here. Currently, the only available release is 0.5b, which includes 3 files: 1. DirectDrawOverlay-lib-0.5b.zip, the release and debug builds of the library. 2. DirectDrawOverlay-bin-0.5b.zip, the sample binary files. 3. DirectDrawOverlay-src-0.5b.zip, the source code (VS8 solution). Build instructions can be found at the project homepage. The sample Details on what the sample does can be found here. The YUV issue There's a known issue with YUV formats--i.e, on nVidia cards--where the colors for some controls are messed up. Most notably, black-text-on-white is shown in the overlay as white-text-on-black. It's on my TODO list, and it's probably some silly conversion error, so ignore this for now. I need your help I need people with pre-Vista systems to test the sample on any fullscreen games they have, both Direct3D and OpenGL ones. So far, the one XP tester I had has never reported failure. With Vista systems, the situation is rather strange. The 2 Vista testers I had reported that: 1. Fullscreen DirectX SDK samples work fine with the overlay. 2. Fullscreen Direct3D applications other than the samples cause the overlay to be lost. 3. Fullscreen OpenGL applications cause the overlay to be lost. It's not entirely clear what's going on with #2, perhaps it has to do with multisampling or some setting used by the games by default. No idea what's going on with #3, though. It's either related to the new Vista driver architecture, or a driver issue. Further testing should provide some clues. Please include your graphics card type and driver version with any error reports.

Oz...what do you think of it?

27 March 2007 - 06:14 PM

Greetings, I'm interested in knowing your opinion of the language Oz, as it stands now, and your expectation for it in the future. I've been reading about the "big" functional languages recently, and Haskell, Lisp, and Ocaml seem to be the most frequently mentioned languages. However, whenever Oz is mentioned, even though it's rare, it is often praised for doing whatever it does, which according to Wikipedia is a lot of things, very well. I tried to take a sneak peak at it a year or 2 before, but I was just getting interested in FP then, and the weirdness factor was too high for me to continue (Kind of like Haskell in that regard). Have you tried it? I'm especially interested in the opinions of those who use a functional language professionally, in their main job. SamLowry, I'm looking at you :P

Scheme-like ML with macros?

27 March 2007 - 06:06 PM

Greetings, So I kinda cheated and read a bit about macros, as well as some advanced Scheme code. In my mind, I keep comparing the code to OCaml (the only ML-derived language I've studied), and can't help but prefer OCaml for mainly 2 reasons: 1. Improved syntax (Or just the mere existence of "syntax"). Scheme has almost no syntax, and that's somewhat appreciable while learning the language. Some would argue that parentheses aren't a big deal with smart editors, but I usually find the equivalent ML syntax much more readable and enjoyable. For example: let. In Scheme, I just keep messing it up. The equivalent let ... in ... syntax of ML is quite more clear, and doesn't even need a syntax-highlighting, bracket-matching editor to be readable. 2. Static typing. I feel closer at home here, and I generally like type inference systems. So, I was wondering what ML-like languages out there (as in: satisfying the above 2 points) come with the ability to customize the syntax (macros or otherwise)? For OCaml, I've been reading How to customize the syntax of OCaml, using Camlp4 and I've been enjoying it, although it gets a bit difficult at times. What about others? Is syntax customization oft-used in the OCaml/ML commerical software world?

[GLSL] gl_LightSource[0] fields always zeroed

15 February 2007 - 06:18 AM

Greetings, While implementing per-pixel lighting in GLSL, I attempted to use the built-in gl_LightSource array instead of creating and setting uniform variables for the light properties. I kept getting black results, and I narrowed it down to this: gl_LightSource[0] fields are all zeroed. I'm 100% positive I'm setting the lights and enabling them--fact is, while gl_LightSource[0].diffuse is all zeros, gl_FrontLightProduct[0].diffuse is the correct (non-zero) value (multiplied by material diffuse, which is (1,1,1,1)). I'm running on this on an X300, with the only available ATi driver for Vista x64. I reproduced the same results with TyphoonLabs "Shader Designer". The stripped-down shaders:
// Vertex
void main()
	gl_Position = ftransform();
	gl_FrontColor = gl_Color;
// Fragment
void main()
	// The following line always produces black. I tried using many fields
	// including position, specular, etc, and all are zero
	vec3 diffuse = gl_LightSource[0].diffuse.rgb;

	// The following (commented) line produces the expected diffuse color
	// vec3 diffuse = gl_FrontLightProduct[0].diffuse.rgb;

	gl_FragColor.rgb = diffuse;
	gl_FragColor.a = 1.0;
So: 1. Is this a driver bug, or I'm missing something? Is support for gl_LightSource optional or mandatory for GL 2.0+ drivers?1 2. Anyone ran into this before? Is it a known issue? Any known workarounds? (other than using uniform variables and setting them, obviously [smile]) [1] Pardon the noobiness. I'm used to the Direct3D approach, and have only plunged into GLSL the day before yesterday