Logicielsmoto.com

Nous sommes le 01 Oct 2020, 05:08

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 16 messages ]  Aller à la page 1, 2  Suivante
Auteur Message
 Sujet du message: JTEO et Logicielsmoto
MessagePosté: 19 Mai 2010, 07:18 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 444
Bonjour a tous,

Suivant une idee de Gilles de combiner son nouvel emulateur JTEO ainsi que le catalogue d'archives de Logicielsmoto, une nouvelle fonction voit le jour (experimental pour l'instant).

Vous trouverez certains jeux ou, en plus du traditionnel lien "Telecharger" apparait un autre lien : "JTEO (Beta)"

Ce lien permet d'ouvrir une fenetre popup et de charger JTEO et le logiciel en question et de l'auto demarrer.

Les titres qui ont cette fonction pour l'instant sont :

* HCL mega demo
* Chinese Stack
* Aigle d'or
* Turbo Cup
* Sapiens
* Captain Blood
* Bobo
* Lemmings
* Tetris
* Bivouac
* Iznogoud

Ceci est encore experimental, et l'emulateur JTEO est toujours en developpement. Gilles a cependant acces en FTP a Logicielsmoto ce qui lui permettra d'uploader les dernieres mises a jour de son emulateur JAVA.

Voila pour les news, d'autres viendront par la suite.

Le news concernant JTEO seront affichees dans la section "Emulateurs".

A+

Yoann


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 19 Mai 2010, 10:08 
Hors ligne

Inscription: 21 Avr 2010, 10:59
Messages: 230
Cette version est effectivement encore en Beta.
La touche F12 permet de basculer clavier/joystick.
Le pavé numérique n'est pas mappé.
Sous linux, les touches numériques du haut ne sont pas correctement mappées (ce qui est plus gênant...).
Les temps de chargement sont parfois un peu longs, il est possible de suivre l'avancement avec la console java ;)

_________________
http://www.alternative-system.com


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 19 Mai 2010, 10:41 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
Tout d'abord, mes félicitations à Gilles pour cet émulateur. Je n'ai pu m'empêcher d'en tester le fonctionnement.

Je ne m'acharnerai pas sur une version expérimentale, mais quelques remarques toutefois, dont certaines n'ont pas forcément de rapport avec l'état d'avancement du programme (testé avec Chinese Stack):

- L'émulateur est très lent, autant pour le chargement que l'exécution des programmes
- Synchro raster pour Colors of China pas encore au point (mais c'est peut-être normal)
- Pas de son (mais c'est peut-être normal)
- Freeze sur une image dans l'animation Mongolian Stunt

Testé sur :
Ubuntu 9.10 "Karmic Koala"
CPU Pentium III 1.266 GHz


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 19 Mai 2010, 11:08 
Hors ligne

Inscription: 21 Avr 2010, 10:59
Messages: 230
Un P/// 1.2G est un peu limite pour le moment.
Je peux accélérer la mise à jour de l'écran (pour le moment tout est intégralement retracé à chaque trame) mais le problème reviendra dès qu'un raster sera utilisé...

Il y a moyen de gagner sur la gestion de la mémoire.
Pour le chargement disquette il y a sans doute moyen de faire plus rapide (par utilisation des classes de buffer, actuellement chaque octet est lu individuellement).

J'ai aussi observé le freeze sur cette animation, je n'ai pour le moment pas intégré certaines subtilité de TEO 1.7 (comme l'ajout d'un cycle sur les lignes impaires...), je dois retravailler la structure de la boucle principale pour coller à la génération des trames de son (qui est donc absent pour le moment).
Egalement c'est plus rapide en compilant avec 1.6 mais je suis resté en 1.4 pour des raisons de compatibilité (test à faire avec 1.6 en mode de compatibilité...).

_________________
http://www.alternative-system.com


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 01 Juin 2010, 15:55 
Hors ligne

Inscription: 21 Avr 2010, 10:59
Messages: 230
Pas de nouveauté pour le moment, la nouvelle version est plus stricte sur les timings... mais cela bloque avec les demos PULS (alors que la version théoriquement incorrecte tournait mieux).
Cela devrait tourner plus vite dans la prochaine version, l'écran était retracé 2x à chaque trame...

_________________
http://www.alternative-system.com


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 10 Jan 2011, 15:19 
Hors ligne

Inscription: 21 Avr 2010, 10:59
Messages: 230
mise à jour de l'applet:
_ affichage plus rapide
_ son 6bits.
_ gestion du pourtour
_ correction du timing

Il reste un bug subtil dans le 6809 qui pose un problème au basic lors du recalcul float -> int

Une partie des optimisations provient de la collaboration avec devilMarkus de CPC wiki.


nouvel exemple:
http://www.alternative-system.com/specific/emu/jteo/space.htm

_________________
http://www.alternative-system.com


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 10 Jan 2011, 20:21 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1264
Localisation: Brest
gilles a écrit:
mise à jour de l'applet:
_ affichage plus rapide

J'ai l'impression que l'affichage est saccadé, pas fluide.. comme si on affichait une image sur 4, ou 6-8 imgs/secs. Ca fait des effets stroboscopique pas top parfois. Par exemple pendant la partie worm-hole avec le tunnel et la musique. Normalement la charge CPU sur le TO8 doit être hyper faible à ce moment là, et pourtant c'est pas fluide. C'est normal ou ces ma VM/carteGFX qui est à la traine?

Au passage, je suis surpris par la ligne 2056 de
Code:
// force sign extension in a portable but ugly maneer
2053    private int signed16bits(int v) {
2054    if ((v&0x8000)==0) return (v & 0xFFFF);
2055    int delta=-1; // delta is 0xFFFF.... independently of 32/64bits
2056    delta=delta<<16; // force last 16bits to 0
2057    return (v&0xFFFF) | delta; // result is now signed
2058    }

C'est bizzare ce décalage: tu peux écrire delta = ~0xFFFF directement. Mais perso j'ecrirais cette methode ainsi:
Code:
private int signed16bits(int v) {
    return (short)v;
}
C'est pareil que pour signedChar(): moins d'opcodes.

sam.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 10 Jan 2011, 21:09 
Hors ligne

Inscription: 21 Avr 2010, 10:59
Messages: 230
le passage du canvas au jpanel semble accelerer le rendu, j'ai l'impression que java drop de lui même quelques images si on essaye d'en afficher trop sans double buffer.
ok pour le ~FFFF ca marche aussi, ca va gagner un peu en vitesse.

_________________
http://www.alternative-system.com


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 10 Jan 2011, 23:30 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1264
Localisation: Brest
gilles a écrit:
le passage du canvas au jpanel semble accelerer le rendu, j'ai l'impression que java drop de lui même quelques images si on essaye d'en afficher trop sans double buffer.

Oui, le canvas.repaint() ne redessine pas immédiatement.. il bufferise. Perso quand j'ai bricolé des portages java des vieux progs basic/c que j'avais dans les cartons (ici, ou , ou encore là(*)), j'avais constaté qu'avec
Code:
canvas = new Canvas() {
                        BufferedImage img = ...;
         public void paint(java.awt.Graphics g) {
            g.drawImage(img, 0, 0, getWidth(), getHeight(), this);
         }

         @Override
         public void update(Graphics g) {
            paint(g);
         }
      };
il vaut mieux appeler canvas.repaint() une fois pour l'ensemble d'une image plutot que plusieurs fois canvas.repaint(x,y,w,h) pour l'ensemble des points (cf DEM.jar). La gestion de fusion des demandes de repaint() consécutives m'a semblé couteuse.
___
(*) que j'espère porter sur thomson avec des minifloats
Citation:
ok pour le ~FFFF ca marche aussi, ca va gagner un peu en vitesse.

Avec (short)value, ca irait encore un peu plus vite (les petits ruisseaux font des grandes rivières).


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 11 Jan 2011, 09:38 
Hors ligne

Inscription: 21 Avr 2010, 10:59
Messages: 230
après test:
v | (~0xFFFF)
me semble pas mal
(short)v ne me plait pas trop, je me demande si le short n'est pas comme le short du C, c'est à dire au bon vouloir de l'implémentation. (le short est un 32bit comme l'int sur pas mal de processeurs RISC en C, la norme C dit que le short est inférieur ou égal à la taille de l'int).
Je vais merger les modifs de markus, l'animation devient parfaitement fluide avec (du moins sur mon Atom 450)

_________________
http://www.alternative-system.com


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 11 Jan 2011, 10:03 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1264
Localisation: Brest
gilles a écrit:
(short)v ne me plait pas trop, je me demande si le short n'est pas comme le short du C, c'est à dire au bon vouloir de l'implémentation. (le short est un 32bit comme l'int sur pas mal de processeurs RISC en C, la norme C dit que le short est inférieur ou égal à la taille de l'int).

En java l'implémentation de short est nécessairement 16bits. C'est dans le livre blanc de la JVM. C'est l'un des gros avantage de java sur du C (à mon avis), c'est qu'il n'y a aucun pb de savoir si un int vaut 16, 32 ou 64 bits: il vaut 32 toujours. Short c'est 16, byte c'est 8 et long 64 partout et toujours. De plus ils sont tous signés ce qui évite pas mal de soucis avec les règles de promotion/conversion implicite du C (unsigned <-> signed étant dépendant du nombre de bits de l'entité sous jacente, donc dépendant du compilo et de l'architecture matérielle et OS, etc). C'est le point fort: sémantique unique permettant qu'une seule compile marche partout pareil et qu'on peut faire des JIT portables efficaces.
Citation:
Je vais merger les modifs de markus, l'animation devient parfaitement fluide avec (du moins sur mon Atom 450)

Cool! On pourra faire tourner JTEO sur le browser web de la Freebox(*) V6 alors? et voir un TO8 sur son ecran TV comme dans le bon vieux temps? Whaaa :)
__
(*) Sam: il a free mais il ne comprends plus rien à leur tarifs.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 11 Jan 2011, 10:24 
Hors ligne

Inscription: 21 Avr 2010, 10:59
Messages: 230
les modifs sont dans le svn, et seront en ligne un peu plus tard apres test de l'applet en ligne.
Ca tourne tres rapidement, 50fps sans pb sur atom

_________________
http://www.alternative-system.com


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 11 Jan 2011, 19:23 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 421
Localisation: France
Note: en C99 il exite les types int8_t, int16_t et int32_t qui ont une taille fixe, lorsque c'est nécessaire.

Les int short et long sont les types 'natifs' du processeur, donc par exemple sur un processeur 36 bits ou un atre truc extraterrestre du genre, on aura un int à cette taille native. short et long peuvent avoir une taille différente si c'est intéressant, par exemple sur 6809 on aurait normalement int=8bit et long=16bit, et sur 6309 il faudrait en plus un long long=32 bit. Le but de tout ceci est de permettre au C d'être compilé en code natif dans tous les cas.

Lorsqu'on veut garantir une taille minimale, les types int_least*_t permettent aussi de le faire. Enfin, il existe des types int_fast*_t qui permettent de toujours prendre la solution la plus rapide (ça peut être 32 bit pour int_fast8_t sur un processeur RISC 32 bits par exemple).

Que demander de plus ? :)


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 11 Jan 2011, 19:26 
Hors ligne

Inscription: 21 Avr 2010, 10:59
Messages: 230
il faut que je pense à héberger ailleurs... mon petit hébergement ovh est à ses limites, le lancement de l'applet est donc tres lent...

_________________
http://www.alternative-system.com


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 12 Jan 2011, 00:49 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1264
Localisation: Brest
PulkoMandy a écrit:
Note: en C99 il exite les types int8_t, int16_t et int32_t qui ont une taille fixe, lorsque c'est nécessaire.

Oui ne pas oublier
Code:
#include <stdint.h>
.
En tout cas pour java, il ne vaut pas se compliquer la vie. les tailles sont fixes et on peut coder efficacement avec ce qu'il y a comme types de base (je n'ai pas encore été gêné avec le "tout signed"). Parfois, pour voir la qualité du code source, j'utilise "javap -c" pour décompiler et inspecter le bytecode et voir s'il n'y a pas trop de trucs inutilement calculés.

Pour info la conversion int->short n'est qu'un seul opcode "i2s" dans la JVM. Et avec l'inline du JIT, il y a fort à parier que les appels à signed16bits() sont remplacés par la version native du i2s. Pour le vérifier il faudrait utiliser les options magiques utilisées ici (on peut afficher le code X86 générés par la JVM lors du JIT).

sam (iconst_0; ireturn;)


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 16 messages ]  Aller à la page 1, 2  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 0 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com