Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

01/12/2007

What Every Programmer Should Know About Memory

Tout est dans le titre ^_^
 

In the early days computers were much simpler. The various components of a system, such as the CPU, memory, mass storage, and network interfaces, were developed together and, as a result, were quite balanced in their performance. F

 

or example, the memory and network interfaces were not (much) faster than the CPU at providing data.

 

This situation changed once the basic structure of computers stabilized and hardware developers concentrated on optimizing individual subsystems. Suddenly the performance of some components of the computer fell significantly behind and bottlenecks developed.

 

This was especially true for mass storage and memory subsystems which, for cost reasons, improved more slowly relative to other components.

 

The slowness of mass storage has mostly been dealt with using software techniques: operating systems keep most often used (and most likely to be used) data in main memory, which can be accessed at a rate orders of magnitude faster than the hard disk.

 

Cache storage was added to the storage devices themselves, which requires no changes in the operating system to increase performance. {Changes are needed, however, to guarantee data integrity when using storage device caches.} For the purposes of this paper, we will not go into more details of software optimizations for the mass storage access.

 

Unlike storage subsystems, removing the main memory as a bottleneck has proven much more difficult and almost all solutions require changes to the hardware. Today these changes mainly come in the following forms:

 

  • RAM hardware design (speed and parallelism).

     

  • Memory controller designs.

     

  • CPU caches.

     

  • Direct memory access (DMA) for devices.

     

For the most part, this document will deal with CPU caches and some effects of memory controller design. In the process of exploring these topics, we will explore DMA and bring it into the larger picture. However, we will start with an overview of the design for today's commodity hardware.

 

This is a prerequisite to understanding the problems and the limitations of efficiently using memory subsystems. We will also learn about, in some detail, the different types of RAM and illustrate why these differences still exist.

 
 

13:05 Publié dans Code | Lien permanent | Commentaires (0)

28/11/2007

Samourai: Protéger les données critiques...

Quiconque a developpé, utilisé, ou maintenu un programme ou un jeu écrit en C ou en C++ sait à quel point les problèmes liées aux "buffer overflow", corruption de mémoire et autres pointeurs zombies peuvent être rageant. Ces problèmes sont quasi inévitables dans une production d'envergure.
 
 
Depuis des années, de nombreuses solutions ont étés développés, allant des simples design patterns à l'écriture de nouveaux langages, mais le prix à payer en termes de souplesse où de performance est toujours prohibitif.
 
 
Ici Microsoft propose Samourai, une solution un peu particulière, mais intéressante dans le concept ^_^
 
 
Programs written in type-unsafe languages such as C and C++ incur costly memory errors that result in corrupted data structures, program crashes, and incorrect results.
 
 
We present a data-centric solution to memory corruption called critical memory, a memory model that allows programmers to identify and protect data that is critical for correct program execution. Critical memory defines operations to consistently read and update critical data, and ensures that other non-critical updates in the program will not corrupt it.
 
 
We also present Samurai, a runtime system that implements critical memory in software. Samurai uses replication and forward error correction to provide probabilistic guarantees of critical memory semantics. Because Samurai does not modify memory operations on non-critical data, the majority of memory operations in programs run at full speed, and Samurai is compatible with third party libraries.
 
 

19:00 Publié dans Code | Lien permanent | Commentaires (0)

27/11/2007

XNA Game Studio Beta 2

 
 
9d8195013e85be14c8f216bdc0f2b9df.png
 

19:10 Publié dans Code | Lien permanent | Commentaires (0)

26/11/2007

L'utilisation des ressources mémoires d'un jeu XBLA...

Undertow - l'une des dernières nouveautés du XBLA - a publié la répartition des ressources mémoires du jeu. Evidemment, ce type de statistiques varie grandement d'un jeu à l'autre, d'autant plus que la taille finale des données n'est pas proportionnelle aux moyens nécessaires pour les produire, mais ça donne une idée de ce qui consitue un jeu d'arcade téléchargeable ^_^

 

bd7a9020a6d4105055e7bed41ff91282.jpg

 

 

Satisfying me — and hopefully your — curiosity at long last are the Mustard brothers, Donald and Geremy, creators of this Wednesday’s Xbox Live Arcade twin-stick shooter “Undertow.”

 

They have provided Multiplayer an exclusive breakdown of how much room everything from the explosions to the theme song to Captain Nemo’s submarine occupy in their nearly 50 MB game (49832KB).

 

I think they wanted to show off, because their game packs a lot for being just a Live Arcade download: 15 levels single and co-op campaign, a storyline, 16-player multiplayer modes. How’d they cram it all in?

 

[ MTV Multiplayer

13:00 Publié dans Code | Lien permanent | Commentaires (5)

24/11/2007

L'art du script...

La plupart des moteurs de jeu modernes ont plus de rapport avec des systèmes d'opérations qu'avec des jeux. Contraint d'être souple et versatile, les moteurs sont amenés à être exploité dans de multiples productions.
 
 
Du coup, la "logique"  d'un jeu - le flow des niveaux, les évènements, le scénario, l'IA - tous ces élèments sont passées du coté des données, au même titre que les textures ou les meshs 3D.
 
 
Et la meilleur façon de décrire des élèments logiques, ça reste le langage. D'ou la multiplication des systèmes de scripts, de LUA à Quake C, de Kismet à Ruby...
 
 
1133eb103a0e79c50ceace6c3024c8cf.jpg
 
 
 
Seulement, ça n'est pas sans problèmes. Ou placer la disctinction entre ce qui relève du script et ce qui relève du moteur ? Est ce que les designers doivent apprendre à programmer ? Comment débugger et maintenir ce qui ressemble à du code sans avoir les outils appropriés (debuger, analyseur de flow...) ?
 
 

It seems like everyone got together and decided to have an interesting discussion right as I was out of town. The issue brought up by Joe Ludwig was: No designer scripting. This assertion created a lot of discussion, including a followup post by Joe.

 

...



I wrote a post about scripting languages years ago on this blog. My core assertion was that for online RPGs, you want to give non-programmers the ability to create content easily. But, the larger issue is that you need to use the tool that's appropriate for your situation.

 

If you need a fast-and-lean solution, then that limits what tools are appropriate for your task. But, taking this a step further, you need the right tool for the resources you have, particularly the people in your team and the schedule you have to meet.

 

Damion explained the issue with scheduling with a fair amount of snark. Programmers, especially ones with experience, don't grow on trees. Therefore, expecting all game implementation to only happen with programmers is usually something that hurts the schedule.

 

Having designers wait on a programmer to implement a feature is a waste of time that can impact the schedule; if you have programmers sitting around idle waiting for things to implement from designers, then you're wasting money.

 

However, you also need to keep in mind the type of people you have on the team. A designer like myself, with a Computer Science degree, shouldn't fill the "real" programmers with a sense of dread because of having to deal with my code...

 

Other people have other strengths, and this is the point that Raph and Sara are talking at each other about. Someone like Sara, with a background and keen interest in data, will work better in a system that allows for interesting combinations of data. I, however, would probably find such a system very limiting since I probably don't think in terms of data as well as Sara does; I think in terms of code.

 

Raph makes the comment that data-driven systems designers don't have as much of a career path. I disagree slightly, because given that the position of "designer" is so ill-defined, any designer will have to make his or her own career path.

 

However, I think it's important for designers to understand the basics of coding and computer science even if they can't sling C++ code around like an expert, because it gives insight into what can and cannot easily be done. For example, if a programmer notices that a design is NP-hard, I know what that means and won't argue the point. :)

 
 

13:00 Publié dans Code | Lien permanent | Commentaires (5)

23/11/2007

EA STL

Aaahhh, les Standard Template Library - ou STL pour les intimes! Des heures et des heures de discutions, disputes, voir franches bagarres autour des fonctionnalités qu'elles apportent et de leurs problèmes dans le cadre du jeu vidéo...
 
 
Je ne vais pas ici détailler la teneur du débat, alors allons à la conclusion: en théorie, les STL sont de fantastiques outils de production qu'il faut absolument connaitre... sauf dans le code du jeu. 
 
 
En pratique, dans a peu près toutes les codebases que j'ai pu voir, les STL restent réservés au code des outils ou des éditeur. En général, au mieux, une implémentation alternative fourni un sous ensemble des fonctionnalités des STL pour le code du jeu.
 
 
Au pire, vous êtes livrés à vous même ^_^.
 
 
Du coup, il existe des dizaines d'implémentations alternatives des STL, comme celle d'EA, que Paul Pedriana détaille dans un excellent article de fond.
 
 
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.

 

The purpose of this document is to explain the motivation and design of EASTL so that it may help the C++ community better understand the needs of game software development.

 

 

This document is not a proposal, though some of EASTL's changes and extensions could form the basis for such discussions. The large majority of EASTL would be useful to any kind of C++ software development.

 

 

This document describes an STL implementation (EASTL) developed within Electronic Arts as an alternative to and extension of the STL defined by the C++ standard library. By STL, we mean the container, iterator, and algorithm components of the C++ standard library, hereafter referred to as std STL (with std referring to the std namespace, whereas the S in STL refers to standard C++).

 

 

By C++ standard, we mean ISO 14882 (1998) and the 2003 update. The large majority of the design of std STL is excellent and achieves its intended purpose. However, some aspects of it make it hard to use and other aspects prevent it from performing as well as it could.

 

 

Among game developers the most fundamental weakness is the std allocator design, and it is this weakness that was the largest contributing factor to the creation of EASTL. Secondarily was the lack of std STL containers designed to be memory-friendly. There are additional reasons that will be discussed below.

 
 
[ EASTL
 
 

13:00 Publié dans Code | Lien permanent | Commentaires (3)

26/10/2007

Comment animer un personnage que vous n'avez jamais vu...

Non, je n'ai pas trouvé la formule magique du golem. Il s'agit juste du probème que Chris Hecker a à résoudre sur Spore. Faut dire que c'est bien beau de pouvoir créer n'importe qu'elle créature, encore faut-il qu'elle puisse bouger !
 
 
dc436c64019e04112088ebad2f2be1ed.gif
 
cfafe1bc30cdc6ebdab32b6230d51593.jpg
 
Spore has a unique problem: most of the content in the game will be made after the game ships. This includes the animated creatures, which can have almost arbitrary shapes and skeleton topology...my creature might have two arms and one leg, yours might have no arms and seven legs, and two mouths.
 
 
How can we animate these creatures when we haven't seen them before, and hopefully animate them well enough to convey emotions? How do we let animators use their skills "today" in a way we can apply "later" to the user's creature?
 
 
This lecture will discuss the various approaches we used to procedurally animate user-created creatures in Spore, and what worked and what didn't, along with some suggestions about how some of the techniques might benefit other more traditional games.
 

13:20 Publié dans Code | Lien permanent | Commentaires (13)

25/10/2007

Rotation vs Orientation

Le problème en algèbre, c'est qu'un vecteur peut tout aussi bien représenter un point qu'une direction. Du coup, ça pose quelques problèmes en terme de nomenclature.
 
Mais y a pire: les rotations c'est pareil. Un quaternion peut parfaitement représenter une rotation ou une orientation. Ce qui est génant, compte tenu du fait que leur espace de définition est beaucoup plus contraignant (pas de commutativité, tout ça tout ça)...
 
Stan Melax revient sur la rotation, cette grande incomprise dans les notations des programmeurs:
 
 

...

 

It is true that the orientation is described as a 'rotation relative to the identity orientation'. In other words, orientation is implemented as a 3x3, upper-left 3x3 of a 4x4, or (most often) as a quaternion.

 
Trying to use this piece of data in any meaningful way can only be done by applying a rotation - i.e. rotating something. But what this is really suggesting is that rotation has more to do with the 'type' of the member variable, not the 'name' of that member.

 

By the same false reasoning that uses 'rotation' instead of 'orientation', the class member 'position' should be changed to 'translation' to be consistent (yuck). In this context, most developers would prefer to describe a game object's pose as position and orientation.

 

Beware; the dagger of terminology misuse is sharp on both sides. Observe how the inconsistent usage of the term 'rotation' now affect further game development as we try to add additional physics members (angular properties) to our game object class.

 

Fortunately, angular velocity has a non-ambiguous non-verbose term: 'spin'. So use that. The trouble now with adding a member called 'rotation' to describe angular momentum (btw it's not the same thing as spin) is that others are likely to misinterpret it and assume it means orientation.

 

Isn't name pollution wonderful? Consequently, we're stuck using a verbose member name such as "angular_momentum" or some sort of shorthand like "ang_mntm". Groan.

 

... 

 
 

13:00 Publié dans Code | Lien permanent | Commentaires (9)

16/10/2007

Developing in Second Life...

Ca fait un bail que je me tate a essayer les outils de productions dans Second Life, d'autant plus qu'ils ont l'air d'être très "particuliers". Il y a des choses à faire apparement pour améliorer l'état de l'art !!!
 
 
 
f08dbca6cf5076dbdf80b932b602b1b9.png
 
 
...
 

Il faut savoir que le système des hiérarchies de Second Life est simpliste, on a un objet parent, et un maximum de 255 enfants. POINT. Pas de notion de sous groupes ou autres joyeusetés de ce genre. Or mon carrousel comporte un peu plus de 580 primitives.

 

Pour animer, j’ai crée globalement 3 ensembles : le masse du carrousel, les attractions fixes (certains chevaux et le carrosse) et les attractions mobiles (les autres chevaux et les tasses).

 

Les deux premiers ont juste à tourner sur eux même, rien de compliqué en soit… En apparence. Second Life est fait de tel sorte que l’essentiel du script est effectué coté serveur, donc si un objet se déplace, c’est le serveur qui le déplace et envoi les nouvelles coordonnées à chaque client. Logique, puisque tout le monde doit voir la même chose. Il y a juste un hic, entre 2 coordonnées différentes, le client ne vas pas extrapoler le mouvement, et donc l’animation apparait saccadée. De plus, le temps d’exécution d’un évènement en d’environ 0.2 secondes minimum. C’est comme si on jouait à 5fps, c’est vraiment pas agréable à l’oeuil.

 

Heureusement pour moi, le carrousel ne fais que tourner, et il existe une commande qui permet de faire une rotation coté client, donc totalement fluide.

 

Pour animer correctement le carrousel, j’ai donc utilisté, du coté serveur, un timer avec une commande qui redifinit l’orientation du carrousel à intervale régulier, et coté client la commande de rotation, ce qui au final, permet d’avoir une rotation synchronisée sur tous les client, et fluide.

 

... 

 
 

13:05 Publié dans Code | Lien permanent | Commentaires (6)

11/10/2007

Capcom + Cedec

Capcom est décidemment très fier de leur moteur, puisqu'ils ont de nouveaux fait une présentation au Cedec cette année après celle de l'an dernier ! C'est en Japonais, mais je ne serai pas surpris de trouver une version anglaise sur - au pif - Beyond3D ^_^
 
fcf71fa13523b19249f05589dd90a49c.jpg
b78631da8b53d8ec1c5102d2e1613a27.jpg
8e16911dd8ddb4914926cd8ba12a7bbc.jpg
1a8b4b7d27388cbaee7c0ceca2e3b855.jpg
 

14:40 Publié dans Code | Lien permanent | Commentaires (0)

20/08/2007

Stanford Course...

Oh, je parlais de stat récemment, et je suis tombé sur un cours de l'université de Stanford. Pour ceux qui ont besoin de se raffraichir la mémoire ^_^

 

a1566b79487501745d129b0e23170ca7.gif

 

 

13:00 Publié dans Code | Lien permanent | Commentaires (0)

19/08/2007

D3D10 au Siggraph...

Microsoft a mis en ligne la totalité des présentations DirectX 10 au siggraph de cette année. Pleins de choses intéressante à lire…

 

1117213b6c02953cb1dd320ad34d88ff.jpg

 

13:05 Publié dans Code | Lien permanent | Commentaires (0)