FR2996975A1 - Method for displaying data set representative of isometric map within browser on screen of restitution terminal in on-line video game industry, involves associating background image of map to boxes so as to display map background - Google Patents

Method for displaying data set representative of isometric map within browser on screen of restitution terminal in on-line video game industry, involves associating background image of map to boxes so as to display map background Download PDF

Info

Publication number
FR2996975A1
FR2996975A1 FR1259875A FR1259875A FR2996975A1 FR 2996975 A1 FR2996975 A1 FR 2996975A1 FR 1259875 A FR1259875 A FR 1259875A FR 1259875 A FR1259875 A FR 1259875A FR 2996975 A1 FR2996975 A1 FR 2996975A1
Authority
FR
France
Prior art keywords
map
boxes
data
representative
display
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1259875A
Other languages
French (fr)
Other versions
FR2996975B1 (en
Inventor
Mathias Latournerie
Levan Sardjeveladze
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CELSIUS ONLINE
Original Assignee
CELSIUS ONLINE
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by CELSIUS ONLINE filed Critical CELSIUS ONLINE
Priority to FR1259875A priority Critical patent/FR2996975B1/en
Publication of FR2996975A1 publication Critical patent/FR2996975A1/en
Application granted granted Critical
Publication of FR2996975B1 publication Critical patent/FR2996975B1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/08Protocols specially adapted for terminal emulation, e.g. Telnet
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T3/00Geometric image transformations in the plane of the image
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/131Protocols for games, networked simulations or virtual reality
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/472End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/4728End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for selecting a Region Of Interest [ROI], e.g. for requesting a higher resolution version of a selected region
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/478Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4781Games
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/478Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4782Web browsing, e.g. WebTV

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Processing Or Creating Images (AREA)

Abstract

The method involves receiving (10) data (20) representative of width and data representative height of a map to be created by a server (100), and creating (30) a set of boxes (40) i.e. squared boxes, according to the data representative of the width and the data representative of the height. A background image of the map from a set of IMGS images is associated with each box so as to display a map background, where the images include axonometric representation adapted to an axonometric map and a transparent portion. Independent claims are also included for the following: (1) a data structure interpretable by intermediate of HTTP client application (2) a computer program product downloadable from a communication network and/or stored on a computer-readable medium and/or executable by a microprocessor comprising program code instructions to perform a method for displaying a data set representative of axonometric map within HTTP client application (3) a display device for displaying a data set representative of axonometric map within HTTP client application.

Description

Moteur de carte Axonométrique 1. Domaine de l'invention L'invention se rapporte à une technique d'affichage de données sur un écran d'un terminal de restitution. Plus particulièrement, l'invention se rapporte à une technique d'affichage simple de données à caractère multimédia. L'invention trouve notamment son application dans l'industrie du jeu vidéo, notamment pour le jeu vidéo en ligne. Par exemple, l'invention trouve une application particulière dans les jeux vidéo à affichage axonométrique, dimétrique, et encore isométrique. Depuis la généralisation de la présence de connexion à l'Internet chez les particuliers, le jeu en ligne jouit d'une popularité grandissante. Son avantage réside dans l'interaction poussée avec d'autres utilisateurs ce qui est nettement plus amusant qu'une interaction avec une intelligence artificielle d'un ordinateur ou d'un serveur. Parmi les jeux proposés, on trouve des jeux de rôle massivement multijoueurs. Ce type de jeu est découpé en plusieurs catégories. Il n'est pas nécessaire de détailler ces catégories dans le cas présent. On peut toutefois noter que certains de ces jeux sont en trois dimensions tandis que d'autres sont en deux dimensions. Les jeux en trois dimensions sont généralement des jeux d'action (jeu à la troisième personne ou jeu en vue subjective). Les jeux en deux dimensions sont plus souvent des jeux de stratégies ou des jeux de plateforme. Cette présentation n'est bien sûr pas exhaustive et la créativité des concepteurs de jeux vidéo brouille souvent les typologies établies. Parmi les applications en deux dimensions (2D), il existe des moyens de représentation dits axonométriques dans lesquelles les niveaux de jeux sont représentés à l'écran du terminal sous la forme d'une carte, comprenant des éléments graphiques représentés sous une forme axonométrique (en général, il s'agit d'une représentation sous forme dimétrique ou isométrique). Pour faire fonctionner ce type d'application (principalement des applications de jeux mais pas uniquement), il est nécessaire de disposer d'un moteur, qui est généralement appelé moteur de cartes, généralement appelé moteur de cartes isométriques. Il s'agit d'un abus de langage car le moteur est en réalité un moteur de carte axonométrique. 2. Art antérieur Dans u jeu ou une application, le moteur de carte axonométrique (dimétrique, isométrique ou autre) a pour principal objet l'affichage de la carte et des éléments graphiques qui la compose à l'écran. Le moteur est également capable de prendre en compte les interactions de l'utilisateur sur la carte pour modifier l'affichage en question (sélection, déplacement de la carte, etc.). Pour ce faire, le moteur dispose de la carte, des éléments graphiques et réalise une fusion de ces données graphiques afin de les afficher à l'écran.FIELD OF THE INVENTION The invention relates to a technique for displaying data on a screen of a rendering terminal. More particularly, the invention relates to a technique for simple display of multimedia data. The invention finds particular application in the video game industry, especially for online video games. For example, the invention finds particular application in video games with axonometric, dimetric, and still isometric display. Since the generalization of the presence of connection to the Internet among individuals, the online game enjoys a growing popularity. Its advantage lies in the interaction with other users which is much more fun than an interaction with an artificial intelligence of a computer or a server. Among the games on offer, there are massively multiplayer RPGs. This type of game is divided into several categories. It is not necessary to detail these categories in this case. It may be noted, however, that some of these games are in three dimensions while others are in two dimensions. Three-dimensional games are usually action games (third-person games or games in subjective view). Two-dimensional games are more often strategy games or platform games. This presentation is of course not exhaustive and the creativity of video game designers often blurs the established typologies. Among the two-dimensional (2D) applications, there are so-called axonometric representation means in which the game levels are represented on the screen of the terminal in the form of a card, comprising graphical elements represented in an axonometric form ( in general, it is a representation in dimetric or isometric form). To operate this type of application (mainly game applications but not only), it is necessary to have a motor, which is usually called card engine, usually called isometric card engine. This is an abuse of language because the engine is actually an axonometric map engine. 2. PRIOR ART In a game or an application, the axonometric map engine (dimetric, isometric or other) has for main object the display of the map and the graphical elements that compose it on the screen. The engine is also able to take into account the user's interactions on the map to modify the display in question (selection, moving the map, etc.). To do this, the engine has the map, graphical elements and performs a merge of these graphics data for display on the screen.

Outre le fait que dans les jeux et applications actuels les éléments graphiques à afficher sont nombreux et que cela occasionne des problèmes de performance lors de la fusion, le jeu doit également recevoir des données en provenance d'un ou plusieurs serveurs, ce qui pose des problèmes lors de connexion lentes. Pour régler ce problème, le client local sur lequel tourne le jeu ou l'application comprend une grande quantité de données en cache afin de ne pas avoir à recevoir ces données de la part du serveur. Ainsi, le serveur ne transmet plus que des données d'interactions entre les éléments plutôt que les éléments eux-mêmes. Cependant, il est quand même nécessaire que le jeu reçoive ces données d'interaction préalablement à la fusion pour pouvoir exécuter celle-ci correctement. Ainsi, on le comprend, les différentes opérations à mener préalablement à la fusion des éléments graphiques et l'affichage sont nombreuses. Il existe de nombreux exemples de techniques de moteur de carte isométrique destinés aux applications dites « Web », car fonctionnant par le biais d'un navigateur. Elles peuvent être catégorisées selon la technologie employée : AdobeTM FlashTm : C'est sur cette technologie qu'il existe le plus d'exemples de moteurs de carte isométrique. As3isolib, OpenSpace Engine, ffilmation en sont de bons exemples. HTML5 : Le Aves Engine, et quelques autres moteurs encore au stade de développement comme Glacial Fictive.In addition to the fact that in the current games and applications the graphics to be displayed are numerous and that this causes performance problems during the merger, the game must also receive data from one or more servers, which poses problems. problems when connecting slowly. To solve this problem, the local client running the game or application has a large amount of cached data so that it does not have to receive this data from the server. Thus, the server only transmits interaction data between the elements rather than the elements themselves. However, it is still necessary for the game to receive this interaction data before the merge to be able to execute it correctly. Thus, it is understood, the various operations to be carried out prior to the merger of the graphic elements and the display are numerous. There are many examples of isometric map engine techniques for so-called "web" applications because they work through a browser. They can be categorized according to the technology used: AdobeTM FlashTm: It is on this technology that there are the most examples of isometric map engines. As3isolib, OpenSpace Engine, ffilmation are good examples. HTML5: The Aves Engine, and some other engines still in the development stage like Fictive Glacial.

Il est à noter qu'en dehors du Aves Engine, ces moteurs ne proposent qu'une gestion de l'affichage de la carte à l'écran, pas de gestion coté serveur. Les technologies basées sur Adobe Flash, largement plébiscitées il y a encore quelques années présentent plusieurs désavantages assez pénalisants. Tout d'abord, elles réclament la présence sur l'ordinateur du client un logiciel de lecture de fichiers au format SWF, format des fichiers générés par Adobe Flash. Or ce lecteur n'est pas natif aux systèmes d'exploitation grand public tels que WindowsTM ou OSXTM. De plus, il est inexistant sur le système d'opération iOSTM qui gère les produits nomades de la société Apple comme l'iPadTM et l'iPhoneTM. Plus récemment, le support de Flash a également été retiré pour le système d'exploitation AndroidTM. De plus, d'importants problèmes de performances sont reconnus sur des machines de moyenne gamme. Ces problèmes s'accentuent si le logiciel de lecture SWF n'est pas à jour, ce qui est d'après les statistiques communiquées par la société Mozilla, très courant.It should be noted that apart from the Aves Engine, these engines offer only a management of the display of the map on the screen, no management server side. Adobe Flash-based technologies, which were widely acclaimed a few years ago, have a number of disadvantages that are quite disadvantageous. First, they claim the presence on the computer of the client a file reading software in SWF format, files format generated by Adobe Flash. But this player is not native to mainstream operating systems such as WindowsTM or OSXTM. In addition, it does not exist on the iOSTM operating system that manages nomadic products from the Apple company such as the iPadTM and iPhoneTM. More recently, Flash support has also been removed for the AndroidTM operating system. In addition, significant performance issues are recognized on mid-range machines. These problems are accentuated if the SWF reading software is not up-to-date, which is according to the statistics communicated by the company Mozilla, very current.

Concernant les moteurs basés sur l'utilisation du langage HTML5, ils nécessitent l'utilisation d'un navigateur compatible HTML5. On rappelle qu'un navigateur est un logiciel qui permet de réaliser un affichage de pages, dites « pages web », lesquelles sont transmises depuis un serveur. Le serveur est connecté au réseau Internet, de même que le terminal sur lequel le navigateur s'exécute. Actuellement, les navigateurs sont plus ou moins compatibles avec ce langage. De plus, bien que prometteurs, les moteurs basés sur HTML5 restent encore à l'état de démonstrateurs techniques et ne sont pas utilisables en production. Aucun des moteurs de carte isométrique existant, à l'exception de l'Aves Engine, ne propose un modèle gestion des informations dynamiques, tel un protocole d'échange avec un serveur. Par ailleurs, ces techniques antérieures, étant des solutions clé en main, peinent à fournir une carte sans fin « never ending map » car dans la mesure où la communication avec le serveur n'est pas gérée par le moteur, ce dernier ne peut prendre en charge une carte sans fin. Il a y donc un besoin pour fournir à l'industrie un moteur qui d'une part ne soit pas pénalisant au niveau des performances de la machine sur laquelle l'application s'exécute et qui d'autre part puisse être mis en oeuvre sur tout type de système d'exploitation. 3. Résumé de l'invention L'invention ne présente pas ces inconvénients de l'art antérieur. Plus particulièrement, l'invention se rapporte à une méthode d'affichage. Plus particulièrement, l'invention se rapporte à une Procédé d'affichage, au sein d'une application cliente HTTP, dite navigateur, d'un ensemble de données, ledit ensemble de données étant représentatif d'une carte axonométrique, ledit ensemble des données comprenant une pluralité d'images, chaque image représentant une portion prédéterminée d'un fond de carte, ledit procédé d'affichage étant caractérisé en ce qu'il comprend : une étape de réception, en provenance d'un serveur, d'une donnée représentative d'une largeur et d'une donnée représentative d'une hauteur de carte à créer ; une étape de création d'une pluralité de cases en fonction de ladite donnée représentative d'une largeur et de ladite donnée représentative d'une hauteur ; une étape d'association, à chacune des cases de ladite pluralité de case, d'une image de fond de carte provenant de ladite pluralité d'image, provoquant un affichage dudit fond de carte. Ainsi, l'invention est simple à mettre en oeuvre et permet l'affichage de données sans qu'il soit nécessaire de réaliser une fusion de plusieurs éléments graphiques avant affichage. Selon un mode de réalisation particulier, chaque case de ladite pluralité de case est de forme carrée et en ce que ladite carte axonométrique est une carte isométrique. Selon une caractéristique particulière une image, de ladite pluralité d'image, qui est associée à une case comprend une représentation axonométrique adaptée à ladite carte axonométrique et au moins une portion transparente. Selon un mode de réalisation particulier, ladite étape de création comprend une étape de superposition de cases de sorte qu'une portion transparente d'une image courante d'une case courante soit positionnée par-dessus une portion opaque d'une image adjacente d'une case adjacente à ladite case courante. Selon une caractéristique particulière, ledit procédé d'affichage comprend en outre, lors d'une action d'un utilisateur : une étape d'obtention, par l'intermédiaire dudit navigateur, d'au moins une coordonnée de réalisation de l'action dudit utilisateur ; une étape de transformation de ladite au moins une coordonnée associée à ladite carte, dite coordonnée cliente ; une étape de calcul d'une case à laquelle s'adresse ladite action en fonction de ladite au moins une coordonnée cliente et d'au moins une donnée représentative d'une hauteur et d'une largeur des cases de ladite pluralité de case. Dans un autre mode de réalisation, l'invention concerne également une structure de données interprétable par l'intermédiaire d'une application client HTTP dite navigateur, ladite structure étant destinée à afficher une carte axonométrique dans une interface utilisateur dudit navigateur. Selon l'invention, une telle structure de données comprend une pluralité de cases, chaque case comprenant une référence à au moins une image d'une portion d'un fond de carte, et en ce qu'elle comprend une première strate de cases et une deuxième strate de cases, ladite deuxième strate de cases étant superposée sur ladite première strate de cases selon un paramètre de décalage prédéterminé. Ainsi, il est possible d'afficher une carte axonométrique en affichant des cases HTML dans deux strates (ou deux couches), la deuxième couche étant décalée de la première selon, par exemple en fonction de la largeur des cases. Si les cases sont carrées et qu'il s'agit d'une carte isométrique (c'est-à-dire que chaque portion d'image du fond de carte est un losange), alors le paramètre de décalage est égal à la largeur de la case divisé par deux. Dans le cas d'une carte axonométrique dans laquelle les cases sont des carrés, mais que chaque portion d'image du fond de carte est un parallélogramme, le paramètre de décalage est fonction de la forme de ce parallélogramme. Bien entendu, les deux couches auxquelles il est fait référence ne sont que des représentations particulières. Il est également possible d'organiser la superposition des cases HTML sous la forme d'une alternance de cases paires et de cases impaires correspondant aux coordonnées des cases dans la carte. Selon une implémentation préférée, les différentes étapes du procédé selon l'invention sont mises en oeuvre par un logiciel ou programme d'ordinateur, ce logiciel comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un module relais selon l'invention et étant conçu pour commander l'exécution des différentes étapes de ce procédé. En conséquence, l'invention vise aussi un programme, susceptible d'être exécuté par un ordinateur ou par un processeur de données, ce programme comportant des instructions pour commander l'exécution des étapes d'un procédé tel que mentionné ci- dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de 20 stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou 25 optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. 30 Selon un mode de réalisation, l'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set-top-box, routeur, etc) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc). De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. L'invention se rapporte également à un dispositif d'affichage comprenant un module client HTTP, dit navigateur, d'un ensemble de données, ledit ensemble de données étant représentatif d'une carte axonométrique, ledit ensemble des données 20 comprenant une pluralité d'images, chaque image représentant une portion prédéterminée d'un fond de carte. Selon l'invention, un tel dispositif comprend : - des moyens de réception, en provenance d'un serveur, d'une donnée représentative d'une largeur et d'une donnée représentative d'une hauteur de carte à créer ; 25 - des moyens de création d'une pluralité de cases en fonction de ladite donnée représentative d'une largeur et de ladite donnée représentative d'une hauteur ; - des moyens d'association, à chacune des cases de ladite pluralité de case, d'une image de fond de carte provenant de ladite pluralité d'image, provoquant un affichage dudit fond de carte. 30 Un tel dispositif peut être mis en oeuvre de manière purement matériel en créant ces circuits électroniques spécifiquement destinés à remplir chacune des tâches précitées. Un tel dispositif peut également être mis en oeuvre sous la forme d'un ou plusieurs circuits électroniques programmables (FPGA). Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en oeuvre de l'invention. 4. Figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1, présente un système mettant en oeuvre les étapes du procédé de l'invention ; La figure 2 illustre une carte comprenant une pluralité de cases HTML ; la figures 3 illustre une image isométrique à intégrer dans une carte ; la figure 4 illustre une carte telle que perçue par un utilisateur. 5. Description d'un mode de réalisation 5.1. Rappel du principe L'invention propose une nouvelle manière de réaliser un affichage d'une carte axonométrique dans un navigateur. Plus précisément, l'invention propose de se baser sur les possibilités offertes par le langage HTML dans sa version 4. Bien entendu, le langage HTML5, assurant une compatibilité avec le langage HTML4, peut également servir de base à la création du moteur selon l'invention. Bien entendu, les capacités de traitement d'un navigateur ne sont pas les mêmes que celle d'une machine dédiées, ni les mêmes que celles d'un lecteur Flash dédié. Il est donc nécessaire, pour parvenir à 1"objectif de l'invention, d'une part de combiner des techniques pour permettre une gestion la plus simple possible et d'autre part limiter les calculs à réaliser par le navigateur. Le système proposé repose sur des techniques simples et efficaces : en premier lieu une isolation de l'affichage de la carte axonométrique par rapport au reste de la page. En effet, comme cela est souvent le cas, à l'affichage, la carte est « entourée » par d'autres éléments graphiques. Il s'agit par exemple de données relatives à des points de vie, à des ressources, à des coordonnées, à des comptes d'utilisateurs, etc. Dans une application utilisant par exemple la technologie flash ces données sont rendues par le moteur d'affichage du logiciel client flash et ne sont pas séparées du reste de l'affichage. Cela oblige le logiciel client flash à réaliser un affichage global de la carte et de ces données. Par ailleurs, l'isolation mise en oeuvre dans l'invention évite d'utiliser les ressources du navigateur à mauvais escient, comme cela sera explicité par la suite. La deuxième technique est relative à la gestion multicouche de l'affichage. Là où les techniques antérieures nécessitent des calculs complexes de rendus pour la réalisation d'un affichage complet, l'invention utilise une technique d'affichage multicouche qui est obtenue par la combinaison de plusieurs techniques différentes : en premier lieu, la mise en oeuvre d'une ou plusieurs couches liées à l'affichage du fond de carte ; en deuxième lieu, la mise en oeuvre d'une couche liée à l'affichage d'objets graphiques complémentaires (objet d'agréments, qui peuvent être fixes ou animés) ; en troisième lieu, la mise en oeuvre d'une technique de pointage.For engines based on the use of HTML5, they require the use of an HTML5-compatible browser. It is recalled that a browser is a software that allows to display pages, called "web pages", which are transmitted from a server. The server is connected to the Internet, as well as the terminal on which the browser is running. Currently, browsers are more or less compatible with this language. In addition, although promising, HTML5-based engines are still in the state of technical demonstrators and can not be used in production. None of the existing isometric map engines, with the exception of the Aves Engine, offers a dynamic information management model, such as an exchange protocol with a server. Moreover, these prior techniques, being turnkey solutions, struggle to provide a never ending map endless because since the communication with the server is not managed by the engine, it can not take support an endless map. There is therefore a need to provide the industry with an engine which on the one hand is not penalizing in terms of the performance of the machine on which the application is running and which on the other hand can be implemented on any type of operating system. 3. Summary of the invention The invention does not have these disadvantages of the prior art. More particularly, the invention relates to a display method. More particularly, the invention relates to a method for displaying, within an HTTP client application, called a browser, a set of data, said set of data being representative of an axonometric map, said set of data comprising a plurality of images, each image representing a predetermined portion of a base map, said display method being characterized in that it comprises: a step of receiving, from a server, a data item representative of a width and a datum representative of a map height to be created; a step of creating a plurality of boxes based on said data representative of a width and said data representative of a height; an association step, at each of the boxes of said plurality of cells, of a card background image from said plurality of images, causing a display of said base map. Thus, the invention is simple to implement and allows the display of data without it being necessary to perform a merger of several graphic elements before display. According to a particular embodiment, each box of said plurality of boxes is of square shape and in that said axonometric card is an isometric card. According to one particular characteristic, an image of said plurality of images, which is associated with a box, comprises an axonometric representation adapted to said axonometric map and at least one transparent portion. According to a particular embodiment, said creating step comprises a step of superposing boxes so that a transparent portion of a current image of a current box is positioned over an opaque portion of an adjacent image of a box adjacent to said current box. According to a particular characteristic, said display method further comprises, during an action of a user: a step of obtaining, via said browser, at least one coordinate of realization of the action of said user; a step of transforming said at least one coordinate associated with said card, said client coordinate; a step of calculating a box to which said action is addressed as a function of said at least one client coordinate and at least one piece of data representing a height and a width of the boxes of said plurality of boxes. In another embodiment, the invention also relates to an interpretable data structure via an HTTP client application called browser, said structure being intended to display an axonometric map in a user interface of said browser. According to the invention, such a data structure comprises a plurality of boxes, each box comprising a reference to at least one image of a portion of a basemap, and in that it comprises a first layer of boxes and a second layer of cells, said second layer of cells being superimposed on said first layer of cells according to a predetermined offset parameter. Thus, it is possible to display an axonometric map by displaying HTML boxes in two layers (or two layers), the second layer being shifted from the first according to, for example, according to the width of the boxes. If the boxes are square and it is an isometric map (that is, each image portion of the basemap is a rhombus), then the offset parameter is equal to the width the box divided by two. In the case of an axonometric map in which the squares are squares, but each image portion of the basemap is a parallelogram, the offset parameter is a function of the shape of this parallelogram. Of course, the two layers to which reference is made are only particular representations. It is also possible to organize the superposition of HTML boxes in the form of an alternation of even boxes and odd boxes corresponding to the coordinates of the boxes in the card. According to a preferred implementation, the various steps of the method according to the invention are implemented by software or computer program, this software comprising software instructions intended to be executed by a data processor of a relay module according to the invention and being designed to control the execution of the different steps of this method. Accordingly, the invention is also directed to a program that can be executed by a computer or a data processor, which program includes instructions for controlling the execution of the steps of a method as mentioned above. This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape. The invention also provides a data carrier readable by a data processor, and including instructions of a program as mentioned above. The information carrier may be any entity or device capable of storing the program. For example, the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a floppy disk or a disk. Hard disk. On the other hand, the information medium may be a transmissible medium such as an electrical or optical signal, which may be routed via an electrical or optical cable, by radio or by other means. The program according to the invention can be downloaded in particular on an Internet type network. Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question. According to one embodiment, the invention is implemented by means of software and / or hardware components. In this context, the term "module" may correspond in this document as well to a software component, a hardware component or a set of hardware and software components. A software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software capable of implementing a function or a program. set of functions, as described below for the module concerned. Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, set-top-box, router, etc.) and is capable of accessing the hardware resources of this physical entity (memories, supports recording, communication bus, input / output electronic boards, user interfaces, etc.). In the same way, a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions, as described below for the module concerned. It may be a hardware component that is programmable or has an integrated processor for executing software, for example an integrated circuit, a smart card, a memory card, an electronic card for executing a firmware ( firmware), etc. The invention also relates to a display device comprising an HTTP client module, called a browser, of a set of data, said data set being representative of an axonometric map, said set of data comprising a plurality of data elements. images, each image representing a predetermined portion of a basemap. According to the invention, such a device comprises: means for receiving, from a server, data representative of a width and data representative of a height of the card to be created; Means for creating a plurality of boxes as a function of said datum representative of a width and of said datum representative of a height; means for associating, with each of the boxes of said plurality of boxes, a card background image originating from said plurality of images, causing said base map to be displayed. Such a device can be implemented in a purely material way by creating these electronic circuits specifically intended to fulfill each of the aforementioned tasks. Such a device can also be implemented in the form of one or more programmable electronic circuits (FPGA). The various embodiments mentioned above are combinable with each other for the implementation of the invention. 4. Figures Other features and advantages of the invention will appear more clearly on reading the following description of a preferred embodiment given as a simple illustrative and nonlimiting example, and the appended drawings, among which: Figure 1 shows a system implementing the steps of the method of the invention; Figure 2 illustrates a map comprising a plurality of HTML boxes; FIG. 3 illustrates an isometric image to be integrated in a card; Figure 4 illustrates a map as perceived by a user. 5. Description of an embodiment 5.1. Recall of the Principle The invention proposes a new way of producing a display of an axonometric map in a browser. More precisely, the invention proposes to rely on the possibilities offered by the HTML language in its version 4. Of course, the HTML5 language, ensuring compatibility with the HTML4 language, can also serve as a basis for the creation of the engine according to the 'invention. Of course, the processing capabilities of a browser are not the same as that of a dedicated machine, nor the same as those of a dedicated Flash player. It is therefore necessary, in order to achieve the objective of the invention, on the one hand to combine techniques to allow the simplest possible management and, on the other hand, to limit the calculations to be made by the browser. on simple and effective techniques: in the first place, an isolation of the display of the axonometric map with respect to the rest of the page, as, as is often the case, on display, the map is "surrounded" by other graphic elements, for example, data relating to health points, resources, contact details, user accounts, etc. In an application using for example flash technology, these data are rendered by the display engine of the flash client software and are not separated from the rest of the display.This forces the flash client software to perform a global display of the card and these data. artwork in the invention avoids misuse of the browser resources, as will be explained later. The second technique relates to the multilayer management of the display. Where prior techniques require complex rendering calculations for the realization of a complete display, the invention uses a multilayer display technique which is obtained by the combination of several different techniques: first, the implementation of one or more layers related to the display of the base map; second, the implementation of a layer related to the display of complementary graphic objects (amenity object, which can be fixed or animated); thirdly, the implementation of a pointing technique.

Le système objet de l'invention est décrit en relation avec la figure 1. Un tel système comprend d'une part un serveur 100, comprenant un ensemble de données 200 de carte. Les données de carte sont par exemple stockées sur le serveur sous la forme d'un tableau à plusieurs dimensions (par exemple 2). Ces données permettent d'avoir une représentation de la carte côté serveur. Dans le système objet de l'invention, c'est le serveur qui gère la carte de manière centralisé. Le serveur est connecté à au moins un client 300 par l'intermédiaire d'un réseau de communication 400. Le client 300 comprend, soit sous une forme matérielle soit sous une forme logicielle, une application client http, encore appelée navigateur 301. L'application cliente HTTP 301 est compatible avec le langage HTML4. L'application cliente http 301 met en oeuvre une application de gestion 302 de carte axonométrique CRT. Cette application 302 est transmise par le serveur, par exemple lors de la connexion du navigateur à un site Internet donné. Dans la cadre de l'invention, l'application de gestion 302 de carte axonométrique CRT comprend trois modules : un module de pavage 303, chargé de réaliser une correspondance entre la carte affichée à l'écran du client CRT et la carte 200 du serveur, un module d'interaction 304 (également appelé module « cartes »), chargé de gérer les interactions entre l'utilisateur de l'application de gestion 302 de carte axonométrique et le serveur 100 et un module d'affichage 305 (également appelé module « cases »).The system that is the subject of the invention is described with reference to FIG. 1. Such a system comprises on the one hand a server 100, comprising a set of card data 200. The card data is for example stored on the server in the form of a multidimensional array (for example 2). These data make it possible to have a representation of the server-side map. In the system that is the subject of the invention, it is the server that manages the card centrally. The server is connected to at least one client 300 via a communication network 400. The client 300 comprises, either in hardware form or in software form, an http client application, also called a browser 301. HTTP client application 301 is compatible with HTML4. The client application http 301 implements a management application 302 of the axonometric map CRT. This application 302 is transmitted by the server, for example when connecting the browser to a given website. In the context of the invention, the axonometric card management application 302 CRT comprises three modules: a paving module 303, responsible for making a correspondence between the card displayed on the screen of the CRT client and the card 200 of the server an interaction module 304 (also called a "cards" module), responsible for managing the interactions between the user of the axonometric map management application 302 and the server 100 and a display module 305 (also called a module). "Boxes").

Le procédé de l'invention comprend : une étape de réception 10, en provenance d'un serveur 100, d'une donnée 20 représentative d'une largeur et d'une donnée représentative d'une hauteur de carte à créer ; une étape de création 30 d'une pluralité de cases 40 en fonction de ladite donnée 20 représentative d'une largeur et de ladite donnée représentative d'une hauteur ; une étape d'association 50, à chacune des cases de ladite pluralité de case, d'une image de fond de carte provenant de ladite pluralité d'image IMGS, provoquant un affichage dudit fond de carte. Ces trois modules, comme cela est précisé par la suite, permettent de répondre aux problèmes posés par les systèmes de l'art antérieur. Les solutions qu'ils mettent en oeuvre sont économes en ressources et assurent une parfaite fluidité de l'application de gestion de carte axonométrique 302. L'application de gestion de carte axonométrique 302, en tant que telle peut être un jeu, un utilitaire ou tout autre application qui nécessite la représentation d'une carte axonométrique. Dans un mode de réalisation particulier, tel que présenté ci-après, la carte axonométrique est une carte isométrique. Plus particulièrement, l'architecture de la carte axonométrique, qui fait partie intégrante de l'invention, repose est une structure de donnée particulièrement ingénieuse. Cette structure de données est interprétable par l'intermédiaire du navigateur. Elle comprend une pluralité de cases, chaque case comprenant une référence à au moins une image d'une portion d'un fond de carte, et elle comprend une première strate de cases et une deuxième strate de cases, la deuxième strate de cases étant superposée sur la première strate de case selon un paramètre de décalage prédéterminé. Les images associées aux cases comprennent des portions transparentes qui permettent à une image de ne pas déborder sur une autre. Le principe de l'invention permet de résoudre un certain nombre de problèmes qui se posent dans les systèmes actuels. Le principe de l'invention permet notamment de proposer un moteur de gestion de cartes axonométrique qui offre de nombreux avantages : un moteur pour les applications dites « Web » compatible avec une large majorité des navigateurs « Web », qu'ils soient sur ordinateur PC, tablettes ou autres plateformes ; un moteur rapide, capable d'afficher plusieurs centaines de cases et d'images, fixes ou animées ; une carte infinie (« never-ending map ») capable de se charger au fur et à mesure du déplacement de la carte visible par le joueur ; une utilisation de technologies natives sans téléchargement d'un plugin tiers, et qui ne nécessite donc aucune modification du système d'exploitation ; des cases interactives, que l'on peut cliquer avec précision ; des tuiles de décors capables d'utiliser une hauteur plus élevée que la taille de la tuile au sol sans pour autant causer de soucis d'affichage superposé ou de clic inexact. 5.2. Mode de réalisation : stratification isométrique Dans au moins un mode de réalisation, présenté ici, le moteur issu de la mise en oeuvre de l'invention se compose de trois modules : Le module pavage, le module de carte et le module de gestion des cases . Dans ce mode de réalisation de l'invention les cases qui constituent le fond de carte sont des cases HTML (il s'agit plus particulièrement de balises « div » de forme et de taille prédéterminée). 5.2.1. Le pavage Le module « Pavage » permet de représenter le damier virtuel de la carte. Il est chargé de réaliser la correspondance entre les cases graphiques (éléments HTML, qui sont des balises « div » de forme carrée ou rectangulaire) et les cases de la carte telles qu'elles existent sur le serveur. Sur le serveur, la carte est représentée sous la forme d'un tableau à au moins deux dimensions. Une troisième dimension peut être ajoutée au tableau en fonction des données que l'on souhaite afficher sur la carte ou de l'altitude. Concrètement, dans ce mode de réalisation de l'invention, le module prend la forme d'une classe écrite dans le langage javascript et initialisée sous la forme d'un objet lors du chargement de la page par une paire de coordonnée (X,Y) correspondant à la case graphique (élément div HTML) supérieure gauche de la carte (respectivement XO et YO en coordonnées serveurs ou x0 et y0 en coordonnées clients). Les cases graphiques sont placées comme un quadrillage, mais l'axe isométrique et l'impossibilité en langage HTML de créer autre chose qu'une case de forme rectangulaire parallèle à l'axe du regard posent un problème. Afin de créer tout de même une carte isométrique, les inventeurs ont eu l'idée de réaliser une superposition des cases graphiques afin de créer ce quadrillage (voir module « carte » ci-dessous). Selon l'invention, on distingue trois types de coordonnées. 1. Les coordonnées serveur, en 2D sur un angle de 450 à l'axe du regard. Nous les appellerons X et Y. 2. Les coordonnées client, en 2D sur un plan perpendiculaire à l'axe du regard. Nous les appellerons x et y. 3. Les coordonnées HTML, en 3D sur le même plan que les coordonnées clients. Nous les appellerons rx et ry.The method of the invention comprises: a reception step 10, originating from a server 100, of a datum representative of a width and a datum representative of a height of card to be created; a step of creating a plurality of cells 40 as a function of said datum representative of a width and said datum representative of a height; an association step 50, at each of said plurality of cells, of a card background image from said plurality of IMGS images, causing a display of said base map. These three modules, as is specified later, can address the problems posed by the systems of the prior art. The solutions they implement are resource-efficient and ensure a perfect fluidity of the axonometric map management application 302. The axonometric map management application 302, as such, can be a game, utility or any other application that requires the representation of an axonometric map. In a particular embodiment, as presented below, the axonometric map is an isometric map. More particularly, the architecture of the axonometric map, which is an integral part of the invention, is based on a particularly ingenious data structure. This data structure is interpretable via the browser. It comprises a plurality of boxes, each box comprising a reference to at least one image of a portion of a base map, and it comprises a first layer of boxes and a second layer of boxes, the second layer of boxes being superimposed. on the first box stratum according to a predetermined offset parameter. The images associated with the boxes include transparent portions that allow one image to not overflow onto another. The principle of the invention makes it possible to solve a certain number of problems which arise in the current systems. The principle of the invention makes it possible in particular to propose an axonometric card management engine which offers numerous advantages: a motor for the so-called "Web" applications compatible with a large majority of "Web" browsers, whether on a PC computer tablets or other platforms; a fast engine, able to display several hundred boxes and images, fixed or animated; an infinite map ("never-ending map") capable of loading as the player moves the map; a use of native technologies without downloading a third party plugin, and which therefore does not require any modification of the operating system; interactive boxes that can be clicked with precision; set tiles that can use a height higher than the size of the tile on the floor without causing problems with superimposed display or inaccurate click. 5.2. Embodiment: Isometric Laminating In at least one embodiment, presented here, the engine resulting from the implementation of the invention consists of three modules: The paving module, the card module and the box management module . In this embodiment of the invention the boxes that constitute the base map are HTML boxes (it is more particularly tags "div" of predetermined shape and size). 5.2.1. Paving The "Paving" module is used to represent the virtual checkerboard of the map. It is responsible for making the correspondence between the graphic boxes (HTML elements, which are square or rectangular "div" tags) and the boxes of the card as they exist on the server. On the server, the map is represented as an array of at least two dimensions. A third dimension can be added to the table based on the data you want to display on the map or altitude. Concretely, in this embodiment of the invention, the module takes the form of a class written in the javascript language and initialized as an object when the page is loaded by a pair of coordinates (X, Y ) corresponding to the upper left graphic box (HTML div element) of the map (respectively XO and YO in server coordinates or x0 and y0 in customer coordinates). The graphic boxes are placed like a grid, but the isometric axis and the impossibility in HTML to create anything other than a box of rectangular shape parallel to the axis of the gaze pose a problem. In order to create an isometric map anyway, the inventors came up with the idea of overlaying the graphic boxes in order to create this grid (see "map" module below). According to the invention, there are three types of coordinates. 1. The server coordinates, in 2D on an angle of 450 to the axis of the gaze. We will call them X and Y. 2. Customer coordinates, in 2D on a plane perpendicular to the axis of the gaze. We will call them x and y. 3. The HTML coordinates, in 3D on the same level as the customer coordinates. We will call them rx and ry.

Le module de pavage est capable de transformer n'importe quel type de coordonnées en un autre type grâce à un calcul dédié. Un exemple de réalisation d'un tel calcul est explicité ci-après. Pour passer des coordonnées serveurs aux coordonnées clients : var y - X - self.X0 + self.y0 + self.Y0 - Y; var x - X - self.x0 - self.X0 - Math.floor((y-self.y0+ y%2)/2); if(y<0&&y%21-0) X 1; Dans lequel, « XO » représente l'abscisse serveur de la case située au coin haut gauche lors du chargement du moteur sur le client ; « YO » représente l'ordonnée serveur de la case située au coin haut gauche au chargement du moteur sur le client ; « x0 » représente l'abscisse client de la case située au coin haut gauche lors du chargement du moteur sur le client (0 par défaut) ; « y0 » représente l'ordonnée client de la case située au coin haut gauche lors du chargement du moteur sur le client (0 par défaut) ; « self. » Se rapporte à l'objet courant ; La méthode « Math.floor() » retourne le plus grand entier inférieur ou égal à la valeur donnée en paramètre ; « && » est le ET logique d'une structure conditionnelle ; « %2 » représente le reste d'une division entière par deux ; « --1 » est une décrémentation de 1 Pour passer des coordonnées clients aux coordonnées serveurs : var X - x - self.x0 + self.X0 + Math.floor((y-self.y0 + Math.abs(y%2))/2); var Y - x - self.x0 + self.Y0 + Math.floor((self.y0 - y+ Math.abs(y%2))/2); « XO » représente l'abscisse serveur de la case située au coin haut gauche lors du chargement du moteur sur le client ; « YO » représente l'ordonnée serveur de la case située au coin haut gauche au chargement du moteur sur le client ; « x0 » représente l'abscisse client de la case située au coin haut gauche lors du chargement du moteur sur le client (0 par défaut) ; « y0 » représente l'ordonnée client de la case située au coin haut gauche lors du chargement du moteur sur le client (0 par défaut) ; « self. » Se rapporte à l'objet courant ; La méthode « Math.floor() » retourne le plus grand entier inférieur ou égal à la valeur donnée en paramètre ; « %2 » représente le reste d'une division entière par deux ; 5.2.2. La carte Le module de « Carte » est chargé de la partie graphique du moteur. Dans ce mode de réalisation, il s'agit également une classe « javascpt », qui permet de l'initialisation d'un objet juste après l'initialisation du module de pavage lors du chargement de la page sur le client. L'objet reçoit en paramètre la liste des cases transmises par le serveur. Chaque case de cette liste comprend des coordonnées au format (X, Y)(les coordonnées serveur), l'identifiant de la tuile graphique de cette case et l'éventuelle frontière. Sont également transmis et traités des listes d'objets, animés ou statiques, accompagnés de leurs paramètres tels que leurs emplacements ou leurs déplacements en cours. L'identifiant de la tuile graphique permet de savoir quelle est l'image à afficher en « css » (de l'anglais pour « Cascade Style Sheet ») pour représenter correctement la tuile. La frontière est ici utilisée dans son sens géographique. Une frontière d'un pays, d'une région, d'un champ. Le module servant à l'affichage de la carte, les frontières y jouent un rôle important. Les traitements effectués sur la liste d'objet sont les suivants : les objets sont affichés et placés au bon endroit sur la carte. Ils peuvent ensuite optionnellement être animés, par exemple si on charge l'image d'un chien, on va ensuite démarrer son animation.The paving module is able to transform any type of coordinates into another type thanks to a dedicated calculation. An exemplary embodiment of such a calculation is explained below. To change server coordinates to customer coordinates: var y - X - self.X0 + self.y0 + self.Y0 - Y; var x - X - self.x0 - self.X0 - Math.floor ((y-self.y0 + y% 2) / 2); if (y <0 && y% 21-0) X 1; In which, "XO" represents the server abscissa of the box at the top left corner when loading the engine on the client; "YO" represents the server ordinate of the box at the top left corner of loading the engine on the client; "X0" represents the customer's abscissa of the box at the top left corner when loading the engine on the client (0 by default); "Y0" represents the client ordinate of the box at the top left corner when loading the engine on the client (0 by default); "Self. "Refers to the current object; The method "Math.floor ()" returns the largest integer less than or equal to the value given in parameter; "&&" is the logical AND of a conditional structure; "% 2" represents the remainder of an entire division by two; "--1" is a decrementation of 1 To pass customer coordinates to server coordinates: var X - x - self.x0 + self.X0 + Math.floor ((y-self.y0 + Math.abs (y% 2 )) / 2); var Y - x - self.x0 + self.Y0 + Math.floor ((self.y0 - y + Math.abs (y% 2)) / 2); "XO" represents the server abscissa of the box at the top left corner when loading the engine on the client; "YO" represents the server ordinate of the box at the top left corner of loading the engine on the client; "X0" represents the customer's abscissa of the box at the top left corner when loading the engine on the client (0 by default); "Y0" represents the client ordinate of the box at the top left corner when loading the engine on the client (0 by default); "Self. "Refers to the current object; The method "Math.floor ()" returns the largest integer less than or equal to the value given in parameter; "% 2" represents the remainder of an entire division by two; 5.2.2. The card The "Card" module is responsible for the graphics part of the engine. In this embodiment, it is also a class "javascpt", which allows the initialization of an object just after the initialization of the pavement module when loading the page on the client. The object receives in parameter the list of boxes transmitted by the server. Each box in this list includes coordinates in the format (X, Y) (the server coordinates), the identifier of the graphic tile of this box and the possible border. Animated or static lists of objects, along with their parameters such as their current locations or movements, are also transmitted and processed. The identifier of the graphical tile makes it possible to know which image to display in "css" (of English for "Cascade Style Sheet") to correctly represent the tile. The border is used here in its geographical sense. A border of a country, a region, a field. The module used to display the map, borders play an important role. The treatments performed on the object list are as follows: the objects are displayed and placed in the right place on the map. They can then optionally be animated, for example if we load the image of a dog, we will then start its animation.

Le module de carte est situé dans une iframe d'isolation, qui est décrite avec les cases HTML. L'objet implémentant le module de carte comprend également une méthode capable de déterminer avec précision une tuile cliquée, chose impossible nativement du fait de la superposition des cases graphiques (éléments « div » HTML) et de la gestion des clics par les navigateurs.The map module is located in an isolation iframe, which is described with the HTML boxes. The object implementing the card module also includes a method capable of accurately determining a clicked tile, something impossible natively due to the superposition of graphic boxes ("div" HTML elements) and management of clicks by browsers.

Cette méthode, selon l'invention, prend en entrée l'événement du navigateur, (standardisé par jQuery par exemple), et le type de coordonnées à renvoyer. Lorsque la méthode est appelée, la procédure est la suivante : 1. Les éléments graphiques en dehors des tuiles sont cachés afin de ne pas s'interposer entre le clic et les cases. Ceci est une caractéristique importante permettant de faire fonctionner l'ensemble du moteur graphique puisque cela permet de récupérer les coordonnées de la tuile, comme on va le voir par la suite. Grâce à la méthode native Javascript « elementFromPoint », on récupère l'élément « div » HTML que le navigateur considère comme étant sous le pointeur de la souris, en lui donnant en paramètre les coordonnées absolues (Cx, Cy) du clic renvoyées dans l'événement standardisé (coordonnées de la souris). On réaffiche immédiatement les éléments graphiques précédemment cachés, de sorte que leur disparition est totalement invisible à l'utilisateur. Ceci est également une caractéristique importante permettant de faire fonctionner l'ensemble du moteur graphique de manière rapide et avec peu de ressources. Ensuite, grâce à la synchronisation du quadrillage (qui est décrit préalablement, voir pavage) avec le pavage, on récupère les coordonnées serveurs (X, Y) de la case récupérée à l'étape 2. Les tuiles étant d'une forme géométrique précise, il est possible de calculer la tuile que l'utilisateur visait avec son pointeur. Un exemple de réalisation d'un tel calcul est explicité ci-après : if(y<=a-b) y = y + b/2; if(y + (b/a*x) - (b/2) < 0) coords.X--; else if(y + (b/a*x) - (3*b/2) > 0) coords.X++; if(y - (b/a*x) - (b/2) > 0) coords.Y--; else if(y - (b/a*x) + (b/2) < 0) coords.Y++; 2. 3 4. 5. 30 Dans cette méthode : « X » représente l'abscisse serveur que l'on cherche à déterminer ; « Y » représente l'ordonnée serveur que l'on cherche à déterminer ; « x » représente l'abscisse client ; « y » représente l'ordonnée client ; « a » représente la largeur d'une tuile ; « b » représente la hauteur d'une tuile ; Il est nécessaire d'effectuer un calcul pour déterminer la tuile qui est visée par le clic de souris. En effet, les éléments « dbv » EFINHI, sont superposés. Il y a donc plusieurs couches d'éléments « dbv ». Il est nécessaire, pour permettre une bonne prise en compte de l'action réalisée par l'utilisateur, de déterminer qu'elle est l'élément « dbv » qui est cliqué. Or quand deux éléments « dbv » sont superposés (au moins partiellement), il est nécessaire de réaliser un calcul pour déterminer l'élément « dbv » visé. Le calcul présenté plus haut permet d'identifier cet élément « div ». 5.2.3. Les cases HTML Base de la carte, les cases HTML sont un ensemble d'éléments DIV mises en forme par le module de carte. C'est la seule partie du HTML qui existe déjà avant l'initialisation des modules du moteur. Elles sont disposées par le module de carte de façon à se superposer et créer grâce à leurs tuiles isométriques et grâce à de la transparence, un quadrillage isométrique. El effet il est impossible en HTML4 de créer un élément DOM qui ne soit pas un rectangle et qui soit capable de se comporter comme un élément standard. Un exemple de positionnement des cases HTML est décrit en relation avec la figure 2. Dans cette figure, le quadrillage isométrique comprend quinze tuiles. Chacune de ces tuiles comprend une image (par exemple au format « png ») qui représente une portion du «terrain ». Dans ce mode de réalisation, cette portion de terrain se présente sous la forme d'un losange. Il est connu qu'une image ne peut prendre une forme qui diffère du rectangle ou du carré. Ainsi, cette image est en réalité un rectangle dans lequel les coins sont transparents. Ceci est illustré en figure 3. Une image de terrain est en fait une image rectangulaire dans laquelle s'inscrit un losange (Lo). Claque coin (Car) de l'image est transparent En assemblant les images les unes à côté des autres, et en tirant avantage de la transparence, on construit une vue isométrique d'une carte (Mp) telle que celle présentée en figure 4. On a ainsi atteint un des objectifs poursuivis : afficher une carte isométrique à l'écran, laquelle, du point de vue de l'utilisateur, est identique à une carte isométrique continue.This method, according to the invention, takes as input the event of the browser, (standardized by jQuery for example), and the type of coordinates to be returned. When the method is called, the procedure is as follows: 1. The graphic elements outside the tiles are hidden so as not to intervene between the click and the boxes. This is an important feature to operate the entire graphics engine since it allows to recover the coordinates of the tile, as we will see later. Thanks to the native JavaScript method "elementFromPoint", we get the HTML "div" element that the browser considers to be under the mouse pointer, giving it as parameter the absolute coordinates (Cx, Cy) of the click returned in the standardized event (mouse coordinates). The previously hidden graphical elements are immediately re-displayed, so that their disappearance is completely invisible to the user. This is also an important feature for running the entire graphics engine quickly and with few resources. Then, thanks to the synchronization of the grid (which is described previously, see paving) with the tiling, we recover the server coordinates (X, Y) of the box recovered in step 2. The tiles being of a precise geometrical shape , it is possible to calculate the tile that the user was aiming with his pointer. An exemplary embodiment of such a calculation is explained below: if (y <= a-b) y = y + b / 2; if (y + (b / a * x) - (b / 2) <0) coords.X--; else if (y + (b / a * x) - (3 * b / 2)> 0) coords.X ++; if (y - (b / a * x) - (b / 2)> 0) coords.Y--; else if (y - (b / a * x) + (b / 2) <0) coords.Y ++; 2. 3 4. 5. 30 In this method: "X" represents the server abscissa that is to be determined; "Y" represents the ordinate server that one seeks to determine; "X" represents the customer abscissa; "Y" represents the client ordinate; "A" represents the width of a tile; "B" represents the height of a tile; It is necessary to perform a calculation to determine the tile that is targeted by the mouse click. Indeed, the elements "dbv" EFINHI, are superimposed. There are therefore several layers of "dbv" elements. It is necessary, to allow a good consideration of the action performed by the user, to determine that it is the element "dbv" that is clicked. But when two elements "dbv" are superimposed (at least partially), it is necessary to perform a calculation to determine the element "dbv" referred to. The calculation presented above makes it possible to identify this element "div". 5.2.3. The HTML boxes Base of the card, the HTML boxes are a set of DIV elements formatted by the card module. This is the only part of the HTML that already exists before the initialization of the engine modules. They are arranged by the map module so as to be superimposed and create thanks to their isometric tiles and thanks to the transparency, an isometric grid. In effect, it is impossible in HTML4 to create a DOM element that is not a rectangle and that is able to behave like a standard element. An example of positioning the HTML boxes is described in relation to Figure 2. In this figure, the isometric grid comprises fifteen tiles. Each of these tiles includes an image (for example in "png" format) which represents a portion of the "terrain". In this embodiment, this portion of land is in the form of a rhombus. It is known that an image can not take a shape that differs from the rectangle or the square. So, this image is actually a rectangle in which the corners are transparent. This is illustrated in Figure 3. A terrain image is in fact a rectangular image in which a rhombus (Lo) is inscribed. The corner (Car) of the image is transparent By assembling the images next to each other, and taking advantage of the transparency, is constructed an isometric view of a map (Mp) such as that presented in Figure 4. One of the objectives pursued was thus to display an isometric map on the screen, which, from the point of view of the user, is identical to a continuous isometric map.

En revanche, comme cela est présenté en figure 2, du fait de l'inclusion des images dans des éléments HTML « div », ces éléments « div » se recouvrent. Cela est présenté par les pointillés de la figure 2. Ainsi, par exemple, l'image représentée à la case C(1,2) est insérée dans l'élément HTML div(1,2). Cependant, ce n'est pas moins de cinq éléments HTML div qui recouvrent partiellement cet élément div(1,2). Ainsi, comme cela a été explicité préalablement, il est nécessaire de réaliser un calcul pour connaître la tuile visée par l'utilisateur lorsqu'il clique à un endroit de la carte (voir l'étape 5 précédente, module « carte »). Ces cases HTML sont par ailleurs intégrées dans une frame d'isolation. Cet aspect est décrit en relation avec la figure 4. L'iframe d'isolation (Ifrm), permet d'isoler la carte (Mp) des autres partie de l'interface (un menu supérieur Mup et un liste d'option Lo par exemple). Les inventeurs ont constaté qu'une telle architecture était en fait adaptée à la problématique de l'invention. Ceci permet d'augmenter les performances. Lors du déplacement des cases lors d'une réorganisation après un drag de la souris (action de déplacement de la souris associée à un clic durant ce déplacement), le navigateur va effectuer un ou plusieurs « reflow ». Ce terme désigne le moment où le navigateur recalcule les styles CSS de la page afin d'afficher correctement les éléments HTML. Or, ce « reflow » recalcule l'ensemble des styles et pas uniquement ceux qui sont modifiés. Si cela ne pose pas de soucis dans un environnement de test, une fois en production les « reflow » deviennent une source très importante de perte de performance du fait de la présence autour du moteur graphique d'un site Internet souvent complexe lui aussi en HTML/CSS (un menu supérieur Mup et un liste d'option Lo par exemple). En plaçant tous les éléments devant subir un « reflow » lors d'un drag dans une frame, les inventeurs ont permis d'augmenter les performances, car alors seul les styles situés dans l'Uranie d'isolation sont « reflow » par le navigateur. Un pont est créé au chargement de la page entre l'Uranie et le site parent afin que cette isolation des styles soit invisible lors d'un développement avec le moteur graphique objet de l'invention. 5.2.4. Mise en oeuvre du moteur Le client (c'est-à-dire le navigateur) initialise le module de pavage, créant en mémoire un quadrillage d'une taille déterminée par un nombre de case en largeur et en hauteur défini dans les paramètres du moteur (Nx et Ny représentent respectivement le nombre de cases en largeur et le nombre de cases en hauteur). Puis le module de carte s'initialise à son tour, plaçant chaque case HTML dans sa position initiale sur un plan en trois dimensions, l'axe Z définissant les superpositions des tuiles graphiques (ou d'images lorsque d'autres images sont isérées par-dessus les tuiles). Le module de carte crée une liste d'événements sur les cases HTML afin de supporter les clics et les drags effectués par l'utilisateur (les évènements en question sont par exemple les évènements suivants : « onclic », « ondrag », etc.).On the other hand, as shown in FIG. 2, because of the inclusion of images in HTML "div" elements, these "div" elements overlap. This is shown by the dotted lines in Figure 2. Thus, for example, the image represented in box C (1,2) is inserted in the HTML element div (1,2). However, it is not less than five HTML div elements that partially overlap this element div (1,2). Thus, as has been explained previously, it is necessary to perform a calculation to know the tile referred by the user when clicking at a point on the map (see the previous step 5, module "map"). These HTML boxes are also integrated into an isolation frame. This aspect is described in relation with FIG. 4. The isolation iframe (Ifrm) enables the card (Mp) to be isolated from the other parts of the interface (a higher menu Mup and a list of option Lo by example). The inventors have found that such an architecture was in fact adapted to the problem of the invention. This increases the performance. When moving the boxes during a reorganization after a drag of the mouse (movement action of the mouse associated with a click during this movement), the browser will perform one or more "reflow". This term refers to the moment when the browser recalculates the CSS styles of the page in order to correctly display the HTML elements. However, this "reflow" recalculates all styles and not only those that are modified. If this does not cause any problems in a test environment, once in production the "reflow" become a very important source of performance loss due to the presence around the graphic engine of a website often complex too in HTML / CSS (a top Mup menu and a Lo option list for example). By placing all the elements to undergo a "reflow" during a drag in a frame, the inventors have increased the performance, because only the styles located in the Urania insulation are "reflow" by the browser . A bridge is created at the loading of the page between Urania and the parent site so that this isolation of the styles is invisible during a development with the graphic engine object of the invention. 5.2.4. Implementing the Engine The client (that is, the browser) initializes the pavement module, creating in memory a grid of a size determined by a number of boxes in width and height defined in the engine parameters. (Nx and Ny represent respectively the number of boxes in width and the number of boxes in height). Then the map module initializes itself, placing each HTML box in its original position on a three-dimensional plane, the Z axis defining the overlays of the graphic tiles (or images when other images are iseged by above the tiles). The map module creates a list of events on the HTML boxes to support clicks and drags made by the user (the events in question are for example the following events: "onclic", "ondrag", etc.). .

Enfin, il charge les tuiles graphiques en tant qu'images de fond des cases (ce que l'on appèle tuile graphique dans ce mode de réalisation correspond à une image particulière qui est décrite en relation avec la figure 3) . L'utilisateur peut alors, et ce dès la création des événements, sans attendre le chargement des tuiles graphiques, interagir avec la carte grâce au dispositif de pointage de son ordinateur (souris, trackpad ou autre) par deux types d'interaction : le clic et le drag. Lors d'un clic sur la carte, le comportement par défaut d'un navigateur est de déclencher un événement clic sur l'élément situé au premier plan. Les cases HTML « div » étant superposées comme vu précédemment, le moteur calcule selon les coordonnées absolues du clic (top et left) la tuile visée par l'utilisateur. Une fois cela fait, l'événement de clic est correctement déclenché pour la case choisie. Lors d'un drag de la carte (glisser), le moteur calcule la distance parcourue sur les axes top et left sous la forme d'une différence entre sa position initiale et sa position actuelle et informe le module de pavage dès que cette distance dépasse la hauteur et/ou la largeur d'une case. Le module de pavage va alors vérifier si il est nécessaire selon la marge de préchargement de se réorganiser et de demander le chargement de nouvelles cases. Le cas échéant, il va commencer par modifier son propre quadrillage en calculant les coordonnées x et y des cases HTML dont il demandera le déplacement au module de carte, de sorte que le module de pavage et le module de carte reste parfaitement synchronisé en cas de demande de correspondance de coordonnées de différents types. Ensuite, il notifie le module de carte du nombre de ligne et de colonne à déplacer effectivement ainsi que la direction de ce déplacement (haut/bas/gauche/droite). Alors le module de carte redéfini les propriétés CSS top, left et z-index des cases 10 HTML afin d'impacter visuellement la carte. Dans le même temps, le module de carte génère une requête à envoyer au serveur afin d'obtenir les informations de jeu sur les cases situées aux nouvelles coordonnées chargées. Lorsque le serveur répond à la demande d'information, le module de carte charge, comme lors de l'initialisation, les tuiles graphiques des nouvelles cases.Finally, it loads the graphics tiles as background images of the boxes (what is called graphical tile in this embodiment corresponds to a particular image which is described in connection with Figure 3). The user can then, and from the creation of the events, without waiting for the loading of the graphical tiles, interact with the card thanks to the pointing device of his computer (mouse, trackpad or other) by two types of interaction: the click and the drag. When clicking on the map, the default behavior of a browser is to trigger an event click on the item in the foreground. The HTML boxes "div" being superimposed as seen previously, the engine calculates according to the absolute coordinates of the click (top and left) the tile aimed by the user. Once done, the click event is correctly triggered for the selected box. When dragging the map (dragging), the engine calculates the distance traveled on the top and left axes as a difference between its initial position and its current position and informs the pavement module as soon as this distance exceeds the height and / or width of a box. The paving module will then check whether it is necessary according to the preloading margin to reorganize and to request the loading of new boxes. If necessary, it will start by modifying its own grid by calculating the x and y coordinates of the HTML boxes which it will request the displacement to the card module, so that the paving module and the card module remains perfectly synchronized in case of request for coordinate correspondence of different types. Then, it notifies the card module of the row and column number to actually move as well as the direction of that move (up / down / left / right). Then the map module redefined the top, left and z-index CSS properties of the HTML 10 boxes in order to visually impact the map. At the same time, the card module generates a request to be sent to the server in order to obtain the game information on the boxes located at the new coordinates loaded. When the server responds to the information request, the card module loads, as during initialization, the graphical tiles of the new boxes.

15 Grâce à la synchronisation entre les différents modules, il n'est pas nécessaire de créer de nouveaux événements de clic ou de drag, ceux crées à l'initialisation pouvant toujours fonctionner. Ainsi, l'invention permet d'augmenter grandement les performances : en effet, il n'est pas nécessaire de recharger la carte à chaque « glissé/déposé ». En effet, la seule chose à réaliser lors d'une opération de glisser 20 déposé est transmettre au client HTTP (au navigateur), une nouvelle définition de carte (c'est-à-dire juste les coordonnées d'association d'une image du fond de carte à une case donnée). En d'autres termes, les cases HTML restent fixes et seules les images associées à ces cases sont modifiées. Or, comme les images sont déjà dans le cache du navigateur, cette association est extrêmement rapide et ne nécessite pas la réception de 25 grande quantité de données de la part du client. Par ailleurs, cela permet de mettre en oeuvre le principe de carte infinie de manière très simple. La carte étant gérée du côté serveur, la seule chose que le serveur à faire est de transmettre des coordonnées de cases et des références d'images associées pour que le client puisse immédiatement afficher cette carte.Due to the synchronization between the different modules, it is not necessary to create new click or drag events, those created during initialization may still work. Thus, the invention can greatly increase the performance: indeed, it is not necessary to reload the card with each "dragged / dropped". Indeed, the only thing to realize during a drag-and-drop operation is to transmit to the HTTP client (to the browser) a new map definition (i.e. just the association coordinates of an image from the base map to a given square). In other words, the HTML boxes remain fixed and only the images associated with these boxes are modified. However, since the images are already in the browser cache, this association is extremely fast and does not require the receipt of a large amount of data from the client. Moreover, it makes it possible to implement the principle of infinite map in a very simple way. Since the card is managed on the server side, the only thing the server has to do is transmit box coordinates and associated image references so that the client can immediately display that card.

Claims (8)

REVENDICATIONS1. Procédé d'affichage, au sein d'une application cliente HTTP, dite navigateur 301, d'un ensemble de données 200, ledit ensemble de données étant représentatif d'une carte axonométrique, ledit ensemble des données 200 comprenant une pluralité d'images IMGS, chaque image représentant une portion prédéterminée d'un fond de carte, ledit procédé d'affichage étant caractérisé en ce qu'il comprend : une étape de réception 10, en provenance d'un serveur 100, d'une donnée 20 représentative d'une largeur et d'une donnée représentative d'une hauteur de carte à créer ; une étape de création 30 d'une pluralité de cases 40 en fonction de ladite donnée 20 représentative d'une largeur et de ladite donnée représentative d'une hauteur ; - une étape d'association 50, à chacune des cases de ladite pluralité de case, d'une image de fond de carte provenant de ladite pluralité d'image IMGS, provoquant un affichage dudit fond de carte.REVENDICATIONS1. A method of displaying, within an HTTP client application, called a browser 301, a data set 200, said set of data being representative of an axonometric card, said set of data 200 comprising a plurality of IMGS images , each image representing a predetermined portion of a basemap, said display method being characterized in that it comprises: a reception step 10, from a server 100, of a representative datum of a width and a datum representative of a map height to be created; a step of creating a plurality of cells 40 as a function of said datum representative of a width and said datum representative of a height; an association step 50, at each of the boxes of said plurality of boxes, of a card background image originating from said plurality of IMGS images, causing a display of said base map. 2. Procédé d'affichage selon la revendication 1, caractérisé en ce que chaque case de ladite pluralité de case est de forme carrée et en ce que ladite carte axonométrique est une carte isométrique.2. Display method according to claim 1, characterized in that each box of said plurality of boxes is square in shape and in that said axonometric map is an isometric map. 3. Procédé d'affichage selon la revendication 1, caractérisé en ce qu'une image, de ladite pluralité d'image, qui est associée à une case comprend une représentation axonométrique adaptée à ladite carte axonométrique et au moins une portion transparente.3. Display method according to claim 1, characterized in that an image, said plurality of image, which is associated with a box comprises an axonometric representation adapted to said axonometric map and at least one transparent portion. 4. Procédé d'affichage selon la revendication 3, caractérisé en ce que ladite étape de création comprend une étape de superposition de cases de sorte qu'une portion transparente d'une image courante d'une case courante soitpositionnée par-dessus une portion opaque d'une image adjacente d'une case adjacente à ladite case courante.4. Display method according to claim 3, characterized in that said creating step comprises a step of superposing boxes so that a transparent portion of a current image of a current box is positioned over an opaque portion an adjacent image of a box adjacent to said current box. 5. Procédé d'affichage selon la revendication 1, caractérisé en ce qu'il comprend en outre, lors d'une action d'un utilisateur : une étape d'obtention, par l'intermédiaire dudit navigateur, d'au moins une coordonnée de réalisation de l'action dudit utilisateur ; une étape de transformation de ladite au moins une coordonnée associée à ladite carte, dite coordonnée cliente ; - une étape de calcul d'une case à laquelle s'adresse ladite action en fonction de ladite au moins une coordonnée cliente et d'au moins une donnée représentative d'une hauteur et d'une largeur des cases de ladite pluralité de case.5. Display method according to claim 1, characterized in that it further comprises, during an action of a user: a step of obtaining, via said browser, at least one coordinate performing the action of said user; a step of transforming said at least one coordinate associated with said card, said client coordinate; a step of calculating a box to which said action is addressed as a function of said at least one client coordinate and of at least one item representing a height and a width of the boxes of said plurality of boxes. 6. Structure de données interprétable par l'intermédiaire d'une application client HTTP dite navigateur, mise en oeuvre au sein du procédé d'affichage selon la revendication 1, ladite structure étant destinée à afficher une carte axonométrique dans une interface utilisateur dudit navigateur et étant caractérisée en ce qu'elle comprend une pluralité de cases, chaque case comprenant une référence à au moins une image d'une portion d'un fond de carte, et en ce qu'elle comprend une première strate de cases et une deuxième strate de cases, ladite deuxième strate de cases étant superposée sur ladite première strate de cases selon un paramètre de décalage prédéterminé.6. Interpretable data structure via an HTTP client application called browser, implemented within the display method according to claim 1, said structure being intended to display an axonometric map in a user interface of said browser and characterized in that it comprises a plurality of boxes, each box comprising a reference to at least one image of a portion of a base map, and in that it comprises a first layer of boxes and a second layer of boxes, said second layer of cells being superimposed on said first layer of cells according to a predetermined offset parameter. 7. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution d'un procédé selon la revendication 1, lorsqu'il est exécuté sur un ordinateur.307. Computer program product downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor, characterized in that it comprises program code instructions for the execution of a method according to claim 1 when executed on a computer. 8. Dispositif d'affichage comprenant un module client HTTP, dit navigateur, d'un ensemble de données, ledit ensemble de données étant représentatif d'une carte axonométrique, ledit ensemble des données comprenant une pluralité d'images, chaque image représentant une portion prédéterminée d'un fond de carte, ledit dispositif d'affichage étant caractérisé en ce qu'il comprend : des moyens de réception, en provenance d'un serveur, d'une donnée représentative d'une largeur et d'une donnée représentative d'une hauteur de carte à créer ; des moyens de création d'une pluralité de cases en fonction de ladite donnée représentative d'une largeur et de ladite donnée représentative d'une hauteur ; des moyens d'association, à chacune des cases de ladite pluralité de case, d'une image de fond de carte provenant de ladite pluralité d'image, provoquant un affichage dudit fond de carte.158. A display device comprising an HTTP client module, said browser, a set of data, said data set being representative of an axonometric map, said set of data comprising a plurality of images, each image representing a portion predetermined device of a base map, said display device being characterized in that it comprises: means for receiving, from a server, a data representative of a width and a datum representative of a map height to create; means for creating a plurality of boxes according to said data representative of a width and said data representative of a height; associating means, at each of the boxes of said plurality of cells, of a card background image from said plurality of images, causing a display of said base map.
FR1259875A 2012-10-16 2012-10-16 AXONOMETRIC CARD MOTOR Active FR2996975B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1259875A FR2996975B1 (en) 2012-10-16 2012-10-16 AXONOMETRIC CARD MOTOR

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1259875A FR2996975B1 (en) 2012-10-16 2012-10-16 AXONOMETRIC CARD MOTOR

Publications (2)

Publication Number Publication Date
FR2996975A1 true FR2996975A1 (en) 2014-04-18
FR2996975B1 FR2996975B1 (en) 2015-12-04

Family

ID=47833108

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1259875A Active FR2996975B1 (en) 2012-10-16 2012-10-16 AXONOMETRIC CARD MOTOR

Country Status (1)

Country Link
FR (1) FR2996975B1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6456305B1 (en) * 1999-03-18 2002-09-24 Microsoft Corporation Method and system for automatically fitting a graphical display of objects to the dimensions of a display window
US20090083661A1 (en) * 2007-09-26 2009-03-26 Yahoo! Inc. System and method for selectively displaying web page elements
EP2444134A1 (en) * 2010-10-19 2012-04-25 Travian Games GmbH Methods, server system and browser clients for providing a game map of a browser-based online multi-player game

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6456305B1 (en) * 1999-03-18 2002-09-24 Microsoft Corporation Method and system for automatically fitting a graphical display of objects to the dimensions of a display window
US20090083661A1 (en) * 2007-09-26 2009-03-26 Yahoo! Inc. System and method for selectively displaying web page elements
EP2444134A1 (en) * 2010-10-19 2012-04-25 Travian Games GmbH Methods, server system and browser clients for providing a game map of a browser-based online multi-player game

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
DATABASE COMPENDEX [online] ENGINEERING INFORMATION, INC., NEW YORK, NY, US; 2010, PENA J ET AL: "Open source isometric browser games framework", XP002711797, Database accession no. E20111113748613 *
HAIM LEVKOWITZ ET AL: "Cloud and Mobile Web-Based Graphics and Visualization", GRAPHICS, PATTERNS AND IMAGES TUTORIALS (SIBGRAPI-T), 2012 25TH SIBGRAPI CONFERENCE ON, IEEE, 22 August 2012 (2012-08-22), pages 21 - 35, XP032283170, ISBN: 978-1-4673-5091-4, DOI: 10.1109/SIBGRAPI-T.2012.12 *
KEVIN CURRAN ET AL: "The Future of Web and Mobile Game Development", INTERNATIONAL JOURNAL OF CLOUD COMPUTING AND SERVICES SCIENCE (IJ-CLOSER), VOL.1, NO.1, 1 April 2012 (2012-04-01), pages 25 - 34, XP055076129, Retrieved from the Internet <URL:http://www.iaesjournal.com/online/index.php/IJ-CLOSER/article/download/Londonderry, UK/pdf> [retrieved on 20130822] *
LONG J C ET AL: "Modeling patterns for javascript browser-based games", PROCEEDINGS OF THE 15TH IASTED INTERNATIONAL CONFERENCE ON INTERNET AND MULTIMEDIA SYSTEMS AND APPLICATIONS, MAY 16 - 18, 2011, WASHINGTON, DC, USA,, 16 May 2011 (2011-05-16), pages 51 - 56, XP009172016, ISBN: 978-0-88986-902-8 *
PAUL BAKAUS: "Building a JavaScript-Based Game Engine for the Web", 11 June 2010 (2010-06-11) - 10 July 2010 (2010-07-10), Google Tech Talks, pages 1, XP054975200, Retrieved from the Internet <URL:http://www.youtube.com/watch?v=_RRnyChxijA> [retrieved on 20130827] *
PAUL BAKAUS: "Building a JavaScript-Based Game Engine for the Web", 11 June 2010 (2010-06-11), Google Tech Talks - June 11, 2010, pages 1 - 11, XP055076347, Retrieved from the Internet <URL:http://transcriptvids.com/v/_RRnyChxijA.html> [retrieved on 20130823] *
PROCEEDINGS OF THE WORKSHOP - OPEN SOURCE AND DESIGN OF COMMUNICATION, OSDOC 2010 - PROCEEDINGS OF THE WORKSHOP - OPEN SOURCE AND DESIGN OF COMMUNICATION, OSDOC 2010 2010 ASSOCIATION FOR COMPUTING MACHINERY USA, 8 November 2010 (2010-11-08), pages 51 - 53, XP002711815, DOI: 10.1145/1936755.1936772 *

Also Published As

Publication number Publication date
FR2996975B1 (en) 2015-12-04

Similar Documents

Publication Publication Date Title
US10529106B2 (en) Optimizing image cropping
US11287946B2 (en) Interactive menu elements in a virtual three-dimensional space
CN104471574B (en) According to the image identification of layout and tissue in the case of no user intervention
US9704281B2 (en) Systems and methods for creation and sharing of selectively animated digital photos
US20150248722A1 (en) Web based interactive multimedia system
WO2018005050A1 (en) Sharp text rendering with reprojection
FR2954536A1 (en) METHOD FOR INTEGRATING THE WEB BROWSER WITH A GRAPHICAL APPLICATION
US20190215503A1 (en) 360-degree video post-roll
EP2511842A1 (en) Digital model lookup from lightweight stations
US8140404B1 (en) Browsing with static pages
Kurt et al. ARgent: A web based augmented reality framework for dynamic content generation
AU2017202682A1 (en) Rendering of digital images on a substrate
BE1022580B1 (en) Method of obtaining immersive videos with interactive parallax and method of viewing immersive videos with interactive parallax
FR2996975A1 (en) Method for displaying data set representative of isometric map within browser on screen of restitution terminal in on-line video game industry, involves associating background image of map to boxes so as to display map background
US20180322667A1 (en) Network graphing selector
WO2020128206A1 (en) Method for interaction of a user with a virtual reality environment
US10296592B2 (en) Spherical video in a web browser
US20230419612A1 (en) Virtual gallery space system
EP1864260B1 (en) Method for image reconstruction in a vector graphic
US10789327B2 (en) Method and apparatus of generating and providing page of data object information
FR2883996A1 (en) METHOD FOR CONSTRUCTING MULTIMEDIA SCENES COMPRISING AT LEAST ONE POINTER OBJECT, SCENES RESTITUTION METHOD, TERMINAL, CORRESPONDING COMPUTER PROGRAMS, SERVER AND POINTER OBJECT
WO2005031556A1 (en) Modulation of cursor position in video data for a computer screen
NO345656B1 (en) Game Story System for Mobile Apps
FR3013492A1 (en) METHOD USING 3D GEOMETRY DATA FOR PRESENTATION AND CONTROL OF VIRTUAL REALITY IMAGE IN 3D SPACE
González et al. An information-theoretic ambient occlusion

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8

PLFP Fee payment

Year of fee payment: 9

PLFP Fee payment

Year of fee payment: 10

PLFP Fee payment

Year of fee payment: 11

PLFP Fee payment

Year of fee payment: 12